Pendant les dix premières années chez Google, j'ai travaillé comme ingénieur ordinaire: j'ai lancé les transports en commun sur les cartes, amélioré la recherche et pris du spam sur YouTube. À un moment donné, il s'est avéré que dans le quartier avec les équipes SWE (Software Engineers), il y avait de mystérieux SRE (Site Reliability Engineers) qui vivent dans la production et savent tout sur l'infrastructure, les configurations et la surveillance. Habituellement, ils nous sont venus avec des horaires incompréhensibles et ont fortement recommandé de réécrire quelque chose à notre service afin qu'il explose proprement et en morceaux, et non dans son intégralité avec tous ses voisins. Ou ils ont construit une infrastructure qui résout par magie tous nos problèmes une fois pour toutes. Ou il a été signalé qu'il n'y aurait pas de deuxième version cette semaine, car un centre de données a été emporté par un ouragan, et un cheval a été enterré à côté d'un autre et le câble du tronc a été coupé. Après un certain temps, il est devenu clair que vous pouvez rencontrer ces personnes avec une grande variété de problèmes et repartir avec des solutions trouvées par quelques niveaux d'abstraction inférieurs à ce que vous attendez de votre propre produit («vous, bien sûr, avez payé le trafic requis, mais ici il ne rentre pas bêtement dans l'interrupteur en haut du rack »).
En conséquence, je me suis intéressé à l'apparence de tout ce SRE de l'intérieur et je suis allé à
Mission Control , un programme de rotation qui me permet de passer une demi-année dans le rôle de SRE, d'acquérir une expérience de production précieuse et, si désiré, de retourner dans mon équipe précédente pour partager les connaissances acquises. Au lieu de cela, je suis resté, comme les deux tiers de mes collègues actuels du traitement vidéo SRE, également recyclé d'ingénieurs réguliers. Maintenant, je fais peur à SWE avec des graphiques incompréhensibles et j'évacue les vidéos YouTube des centres de données en train de brûler, avec des pauses pour un codage créatif pacifique. Il s'est avéré qu'en quinze ans, une organisation SRE saine et efficace a grandi au sein de Google avec ses pratiques, principes et méthodes - mais personne ne les connaît, à cause de ceux qui y sont arrivés, personne n'est encore revenu.
La solution au problème de la disparition des informations en service, SLO et post-mortem dans le trou noir de Google SRE était le
livre "Site Reliability Engineering" , qui décrit en détail le fonctionnement réel de notre SRE. En fait, tout ce post est commencé pour deux nouvelles:
- Il y a deux semaines , une traduction russe du livre SRE susmentionné a été publiée. Si vous êtes curieux de savoir comment obtenir de saines pratiques DevOps dans votre entreprise, ce livre est pour vous. Si vous vous soupçonnez d'inclinaisons SRE, alors ce livre est encore plus pour vous.
- Après le premier livre vient d'être publié (jusqu'à présent uniquement en anglais) Site Reliability Workbook avec des exemples pratiques de la vie de Google Cloud Platform - je le recommande également fortement.