Bonsoir à tous!
L'intensité de nos lancements varie d'un mois à l'autre. Avant que les étudiants de septembre ne terminent le deuxième mois du cours
«Devops - Pratiques et outils» , nous ouvrons le prochain volet. Nous sommes donc à nouveau prêts à partager avec vous des documents utiles sur le sujet et attendons
des leçons ouvertes non moins utiles.
Aujourd'hui, nous allons examiner la première partie de l'article sur la façon dont la documentation permet aux équipes SRE de gérer les services nouveaux et existants.
SRE (ingénierie de la fiabilité des sites, grosso modo traduit par «assurer la fiabilité des systèmes d'information», les spécialistes dans ce domaine portent la même abréviation) - une discipline particulière, une réflexion et un ensemble d'approches techniques visant à assurer le bon fonctionnement des produits et services Web. Les SRE sont à la croisée du développement logiciel et de l'ingénierie des systèmes, résolvent les problèmes opérationnels et développent des solutions évolutives, fiables et efficaces pour la conception, la création et l'exploitation de systèmes distribués à grande échelle.
Les principaux objectifs du SRE:
- Surveillance et collecte de métriques - déterminer le comportement souhaité du service, étudier le comportement réel du service et éliminer les différences.
- Réponse aux incidents - détection et réponse efficace aux pannes de service afin de maintenir la disponibilité du service conformément à son SLA (accord de niveau de service).
- Planification de la capacité - prévoir la demande future et fournir la quantité nécessaire de ressources informatiques aux emplacements appropriés pour répondre à cette demande.
- Évolutivité des services - déploiement prévisible et suppression de la puissance de calcul d'un service dans un centre de données, souvent en raison de la planification de la capacité.
- Gestion du changement - changer le comportement d'un service sans perdre sa fiabilité.
- Performance - conception, développement et ingénierie liés à la mise à l'échelle, l'isolement, la latence, le débit et l'efficacité.
SRE se concentre sur le cycle de vie des services: de l'idée et la conception au déploiement, l'exploitation, l'amélioration des performances et, finalement, le déclassement.
Avant de lancer le service SRE, ils le soutiennent en consultant dans le domaine de l'architecture système, en développant des plateformes logicielles, des frameworks et des plans de capacité, et en effectuant une revue de lancement.
Lorsqu'un service est déjà en cours d'exécution, les SRE le prennent en charge comme suit:
- Ils mesurent et surveillent la disponibilité, la latence et l'état général du système.
- Vérifiez les modifications prévues du système.
- Ils mettent à l'échelle la stabilité du système en utilisant certains mécanismes, par exemple l'automatisation.
- Améliorez le système en favorisant les changements visant à augmenter la fiabilité et la vitesse.
- Procéder à la réponse aux incidents et à l'autopsie «innocente».
Lorsque la durée de vie d'un service est sur le point de se terminer, le SRE le désaffectera de manière prévisible avec des explications claires et une documentation complète.
Une équipe SRE mature dispose toujours d'une documentation complète pour chaque fonction SRE. Si vous gérez une équipe SRE ou prévoyez de l'organiser, cet article vous aidera à comprendre les types de documentation dont votre équipe a besoin, ce qui vous aidera à planifier et à hiérarchiser le travail sur la documentation en parallèle avec d'autres tâches de l'équipe.
Histoire de SRE
Avant de discuter des nuances de la documentation SRE, regardons un jour dans la vie de Zoé, le SRE nouvellement créé.
Le deuxième changement de Zoe dans le rôle SRE est en cours dans le projet phare d'AcmeSale chez Acme Inc. Alors qu'elle ne s'adapte qu'à l'équipe, elle observe le travail de ses collègues et prend des notes. Mais maintenant, elle a toujours un téléavertisseur.
Par chance, le téléavertisseur appelle à 2 h 30 du matin. Le message dit "Job Ragnarok s'est penché en arrière", Zoé n'a aucune idée de ce que cela signifie. Elle feuillette ses notes et trouve un lien vers la page principale du tableau de bord. Tout semble OK. Elle essaie de trouver un document référençant Ragnarok sur l'intranet Acme, et après quelques précieuses minutes, elle trouve un document obsolète sur l'architecture de service, qui s'avère être une dépendance critique pour AcmeSale.
Heureusement, il y a un lien vers la page «Ragnarok Ops» dans la discothèque, qui a trouvé un lien vers un tableau de bord avec des graphiques utiles. La page mentionne également le script ragtool, probablement en mesure d'aider à résoudre le problème, mais Zoé en entend parler pour la première fois. Par conséquent, elle envoie une demande d'aide de téléavertisseur à un autre SRE avec de nombreuses années d'expérience dans ce service et ces outils. Malheureusement, il n'y a pas de réponse. Zoe vérifie le courrier et voit un message que son collègue est hors ligne pendant une heure en raison de problèmes de santé. Après avoir pesé tous les avantages et les inconvénients, elle appelle son technicien, mais l'appel passe à la messagerie vocale. Tout suggère que vous devez résoudre ce problème vous-même.
Après avoir passé un certain temps à chercher des informations sur le mystérieux script ragtool, elle trouve un document avec une brève description de ses paramètres de ligne de commande, ainsi que l'endroit où il peut être trouvé. Elle lance un chiffon - redémarre et croise les doigts d'espoir. Rien ne change, le trafic baisse encore plus. Elle regarde désespérément le reste des options de ligne de commande, mais n'est pas sûre qu'elles ne nuiront pas encore plus. Enfin, elle décide d'utiliser ragtool –rebalance e - dc = atlanta, car il ressort clairement des graphiques que le problème est particulièrement visible dans le centre de données d'Atlanta. Le graphique du trafic commence à monter lentement, et Zoé se réjouit de la victoire. MTTR (temps moyen de réparation) est de 45 minutes.
Le lendemain, Zoé mène une discussion post mortem sur l'incident. En effet, le problème s'est avéré être particulièrement important et a entraîné une perte de revenu, et le gestionnaire demande plus de séances d'autopsie. Elle demande à l'équipe comment le reste des participants résoudrait ce problème et elle entend trois approches différentes. Il s'avère qu'il n'existe tout simplement pas de processus de dépannage unique. Ses collègues admettent également que la notification «se pencha en arrière» n'est pas le meilleur nom, et l'échec s'est produit en raison d'un bug connu qui n'était tout simplement pas une priorité.
Enfin, Steve, son technologue, demande: «Quelle version de ragtool avez-vous eu?», Puis note que la version utilisée est terriblement ancienne. Une nouvelle version a été publiée il y a une semaine, ainsi qu'une toute nouvelle documentation décrivant toutes les fonctionnalités et expliquant même comment résoudre le problème «Job Ragnarok penché en arrière». Cette version réduirait le MTTR à cinq minutes.
L'existence d'une nouvelle version de ragtool est une surprise pour la moitié de l'équipe, tandis que l'autre moitié est plus ou moins au courant de la nouvelle version et du guide. La dernière version du script se trouve dans le répertoire personnel de Steve, évidemment dans le dossier bin /. Zoé ajoute cela à ses notes pour une utilisation future, dans l'espoir d'affiner calmement le reste du quart de travail. Elle se demande si le techlide ou l'un des membres de l'équipe traitera les problèmes discutés lors de l'autopsie, ou si tous les futurs SRE devront traverser une expérience aussi douloureuse.
Plus tard dans la journée, Zoe participe à une réunion où l'équipe SRE communique avec l'équipe de développement sur le transfert de service. Steve anime la réunion, pose plusieurs des questions posées précédemment sur les procédures d'exploitation et le problème actuel de fiabilité du service, demandant aux développeurs d'apporter des modifications avant que l'équipe SRE puisse prendre la responsabilité du service. Zoe a déjà participé à plusieurs rassemblements organisés par Steve et d'autres SRE seniors. Elle comprend que les questions posées et les tâches distribuées par les développeurs sont très différentes, selon qui organise la réunion et quel problème l'équipe SRE a traité la semaine dernière.
Zoe rêve secrètement de normes et de procédures plus cohérentes, mais ne comprend pas encore comment atteindre cet objectif. Plus tard, elle entend deux développeurs rire de la machine à café, que de nombreuses questions étaient vaguement liées au téléavertisseur, et ils ne comprennent généralement pas d'où ils viennent. Zoé veut que les développeurs comprennent que SRE n'emporte pas seulement un téléavertisseur avec eux. De retour au travail, Zoé trouve plusieurs billets qui doivent être triés et n'y pense plus.
Heureusement, tous les personnages et événements de cette histoire sont constitués. Néanmoins, demandez-vous si cela est similaire à quelque chose que vous avez rencontré en réalité. La solution aux problèmes de cette équipe fictive est très évidente, et dans la section suivante, nous en discuterons plus en détail.
L'importance de la documentation
Aux premiers stades de l'existence de l'équipe SRE, l'organisation dépend fortement du travail de personnes hautement qualifiées au sein de l'équipe. L'équipe stocke d'importants concepts et principes d'exploitation sous forme de particules de «connaissances tribales» qui sont transmises verbalement aux nouveaux membres de l'équipe. Si ces principes ne sont pas unifiés et ne sont pas documentés, très probablement, à un moment donné, ils devront être douloureusement enseignés à nouveau par essais et erreurs. Parfois, les membres de l'équipe exécutent des procédures opérationnelles comme une séquence stricte d'étapes définies par leurs prédécesseurs dans un passé lointain, sans même comprendre les relations de cause à effet de ces étapes. Si cela n'est pas arrêté, les processus se fragmentent et dégénèrent, cela ne coûte qu'à l'équipe de commencer à se développer pour résoudre de nouveaux problèmes.
L'équipe SRE peut empêcher ce processus en créant une documentation de haute qualité qui servira de base à la croissance de ces équipes et en introduisant une approche systématique de la gestion de services nouveaux et inconnus. Ces documents préservent les connaissances tribales sous la forme dans laquelle il est facile de les trouver, de les conserver et de les rechercher. Les nouveaux membres de l'équipe sont formés grâce à un programme systématique et réfléchi. Ce sont les caractéristiques de l'équipe SRE mature.
Le reste de cet article décrit les différents types de documents que SRE crée au cours du cycle de vie d'un service pris en charge.
LA FIN
Dans la
partie suivante, nous examinerons tous ces types en détail, mais pour l'instant nous attendons vos commentaires et questions, et nous vous invitons également à
une leçon ouverte .