In den ersten zehn Jahren bei Google habe ich als gewöhnlicher Ingenieur gearbeitet: Ich habe öffentliche Verkehrsmittel auf Karten gestartet, die Suche verbessert und Spam auf YouTube abgefangen. Irgendwann stellte sich heraus, dass es in der Nachbarschaft mit den SWE-Teams (Software Engineers) einige mysteriöse SRE (Site Reliability Engineers) gab, die in der Produktion leben und alles über Infrastruktur, Konfigurationen und Überwachung wissen. Normalerweise kamen sie mit unverständlichen Zeitplänen zu uns und empfahlen dringend, etwas in unserem Service neu zu schreiben, damit es ordentlich und in Stücken explodierte und nicht in seiner Gesamtheit mit all seinen Nachbarn. Oder sie haben eine Infrastruktur aufgebaut, die alle unsere Probleme ein für alle Mal auf magische Weise löst. Oder es wurde berichtet, dass es diese Woche keine zweite Veröffentlichung geben würde, da ein Rechenzentrum von einem Hurrikan weggespült wurde und ein Pferd neben einem anderen begraben und das Stammkabel durchtrennt wurde. Nach einiger Zeit wurde klar, dass Sie mit einer Vielzahl von Problemen zu diesen Menschen kommen und Lösungen finden können, die durch einige Abstraktionsebenen niedriger sind, als Sie von Ihrem eigenen Produkt erwarten („Sie haben natürlich für das erforderliche Verkehrsaufkommen bezahlt, aber hier er passt nicht dumm in den Schalter oben im Rack “).
Infolgedessen interessierte ich mich dafür, wie all dieses SRE von innen aussieht, und ging zu
Mission Control , einem Rotationsprogramm, mit dem ich ein halbes Jahr in der Rolle des SRE verbringen, wertvolle Produktionserfahrungen sammeln und auf Wunsch zu meinem vorherigen Team zurückkehren kann, um das erworbene Wissen zu teilen. Stattdessen blieb ich, wie zwei Drittel meiner derzeitigen Kollegen von Video Processing SRE, auch von regulären Ingenieuren umgeschult. Jetzt erschrecke ich SWE selbst mit unverständlichen Grafiken und evakuiere YouTube-Videos aus brennenden Rechenzentren, mit Pausen für friedliches kreatives Codieren. Es stellte sich heraus, dass im Laufe von fünfzehn Jahren eine gesunde und effektive SRE-Organisation innerhalb von Google mit ihren Praktiken, Prinzipien und Methoden aufgewachsen ist - aber niemand weiß davon, denn aufgrund derer, die dort ankamen, ist noch niemand zurückgekehrt.
Die Lösung für das Problem des Verschwindens von Informationen zu Dienst, SLO und Obduktion im Schwarzen Loch von Google SRE war das
Buch „Site Reliability Engineering“ , in dem detailliert beschrieben wird, wie unser SRE tatsächlich funktioniert. Eigentlich wird dieser ganze Beitrag aus zwei Gründen gestartet:
- Vor zwei Wochen wurde eine russische Übersetzung des oben genannten SRE-Buches veröffentlicht. Wenn Sie neugierig sind, wie Sie gesunde DevOps- Praktiken in Ihrem Unternehmen erreichen können, ist dieses Buch genau das Richtige für Sie. Wenn Sie sich SRE-Neigungen verdächtigen, ist dieses Buch noch mehr für Sie.
- In Verfolgung des ersten Buches wurde gerade das Site Reliability Workbook mit praktischen Beispielen aus dem Leben der Google Cloud Platform veröffentlicht (bisher nur in englischer Sprache) - ich kann es auch sehr empfehlen.