Bonsoir à tous!
Il ne reste donc plus rien (c'est-à-dire un jour) avant le début du
cours DevOps Practices and Tools , ce qui signifie que nous devons avoir le temps de terminer le reste de l'article
«Pourquoi la documentation SRE est importante» pendant ce temps.
Nous continuons.
Documents pour l'intégration d'un nouveau serviceLes SRE effectuent un PRR (examen de l'état de préparation de la production) pour vérifier que le service répond aux normes de préparation opérationnelle et pour s'assurer que les propriétaires de services comprennent comment utiliser les connaissances SRE pour gérer les grands systèmes.
Le service doit passer par ce test avant d'être lancé en production. (Avant le lancement, il n'est pas pris en charge par SRE, mais par l'équipe de développement elle-même.) L'objectif de PRR à ce stade est de s'assurer que le service répondra aux normes de fiabilité minimales au moment du lancement.
Le prochain PRR se produit avant le transfert du service SRE, c'est-à-dire que beaucoup de temps peut s'écouler après le lancement. Et lorsque l'équipe SRE décide de prendre un nouveau service, une analyse approfondie de l'état de production et des pratiques de service utilisées est réalisée. L'objectif est de simplifier le processus de transfert de services en termes de fiabilité et de stabilité opérationnelle, ainsi que d'aider SRE à mieux y faire face.
En effectuant des PRR avant de remettre le service, les SRE peuvent poser plus de questions et fixer des normes plus élevées de fiabilité et de facilité d'utilisation que lors de la réalisation de PRR avant le lancement. Le PRR avant le lancement peut être «léger» afin de ne pas ralentir l'équipe de développement.
Dans l'histoire de Zoe, l'équipe ne disposait pas d'un processus standardisé ou d'une liste de contrôle PRR, ce qui signifie qu'elle pouvait passer à côté de problèmes très importants lors du transfert du service. Ainsi, il existe un risque de collision avec un grand nombre de problèmes qui pourraient être facilement anticipés et résolus avant de prendre en charge la gestion du service.
Le transfert PRR / service nécessite la création de modèles PRR et de documentation de processus (doc de processus) qui décrit comment les équipes SRE travailleront avec le nouveau service et utiliseront des modèles PRR. Les modèles utilisés dans le processus de transfert peuvent être plus complets que ceux utilisés lors du démarrage.
Le modèle PRR couvre plusieurs domaines et est nécessaire pour vérifier les réponses aux questions critiques. Le tableau 1 présente certains des domaines et problèmes connexes couverts par le modèle.
| Zone | Des questions |
|---|
| Architecture et dépendances | Quel est le chemin de demande du client vers le frontend puis le backend? Existe-t-il différents types de demandes avec différentes exigences de latence? |
| Planification des capacités | Quelles sont les attentes concernant les volumes de trafic et les taux de croissance pendant et après le lancement? Avez-vous la puissance de calcul nécessaire pour prendre en charge ce trafic? |
| Types d'échecs | Existe-t-il des points de défaillance uniques dans votre architecture? Comment éliminer l'indisponibilité des dépendances? |
| Processus et automatisation | Existe-t-il des processus manuels nécessaires pour prendre en charge le service? |
| Dépendances externes | Quels sont les données, codes, services ou événements tiers qui dépendent du service et du lancement? Certains de vos partenaires dépendent-ils du service? Si oui, doivent-ils être informés du lancement? |
Tableau 1. Exemples de zones d'un modèle PRRLa documentation du processus doit également indiquer les documents que le SRE doit demander à l'équipe de développement de produit comme conditions préalables au transfert. Par exemple, ils peuvent demander à l'équipe de développement de créer un manuel pour les problèmes courants.
En outre, l'organisation SRE devra créer un document d'examen qui explique brièvement à l'équipe de développement le rôle et les domaines de responsabilité du SRE. Cela est nécessaire pour former des attentes réalistes. Le premier document doit expliquer ce qu'est le SRE, couvrir tous les sujets abordés dans la partie précédente et le début de cet article, y compris les fonctions principales, le cycle de vie du service, les responsabilités de support / maintenance. Le but principal de ce document est de s'assurer que les développeurs ne confondent pas SRE avec l'équipe OPS et ne considèrent pas les réponses de pageur comme le seul devoir du SRE. Comme le montre l'histoire décrite précédemment, si au moment du transfert du service les développeurs ne comprenaient pas pleinement ce que faisait SRE, cela entraînerait des problèmes de communication et des malentendus.
De plus, il est nécessaire de créer un document de modèle d'engagement pour clarifier les attentes et expliquer le processus d'interaction entre l'équipe SRE et l'équipe de développement produit pendant et après le transfert de service. Les sujets traités dans la documentation peuvent inclure les éléments suivants:
- Critères de transfert de service et processus PRR.
- Processus de discussion des rapports d'objectifs de niveau de service (brièvement SLO) et de calcul des erreurs.
- Nouveaux critères de lancement et démarrage de la politique de gel (si possible).
- Le contenu et la fréquence des rapports d'état de service de l'équipe SRE.
- Besoins en personnel SRE.
- Le processus de planification d'une feuille de route de nouvelles fonctionnalités et la priorité d'une fonctionnalité qui augmente la fiabilité (requise par SRE) par rapport aux nouvelles fonctionnalités du produit.
Documentation d'opération de servicePour soutenir le service, les équipes SRE s'appuient principalement sur la documentation opérationnelle principale: description générale (entretien) du service, playbooks et procédures, post-mortem, directives et SLA. (Remarque: cette section était présente dans le chapitre «Do Docs Better» de Seeking SRE.)
Entretien de serviceUne description générale du service est essentielle pour comprendre le SRE quel type de service ils prennent en charge. SRE a besoin de connaître l'architecture du système, ses composants et dépendances, les contacts du service et de ses propriétaires. La description générale du service est le résultat du travail conjoint de l'équipe de développement et de l'équipe SRE, il est créé pour guider et hiérarchiser les tâches SRE et identifier les domaines à approfondir. Ces entretiens sont généralement obtenus à la suite du PRR et doivent être mis à jour à mesure que le service change (par exemple, si de nouvelles dépendances apparaissent).
Une simple interview donne suffisamment d'informations SRE pour explorer davantage le service. Une interview complète fournit une description complète du service et de la façon dont il interagit avec le monde qui l'entoure, ainsi que des liens vers des tableaux de bord, des mesures, toutes les informations dont SRE a besoin pour résoudre des problèmes imprévus.
Playbook
Parfois aussi appelé runbook, c'est un document fondamental qui permet aux ingénieurs de répondre aux notifications d'un système de surveillance de service lors d'un quart de travail. Par exemple, si l'équipe de Zoey avait un manuel expliquant la signification de l'alerte «Job Ragnarok se pencha en arrière» et ce qui doit être fait dans la situation où elle a été reçue, l'incident serait résolu en quelques minutes. Les playbooks réduisent le temps de récupération des incidents et fournissent des liens utiles vers les consoles et les procédures.
Les playbooks contiennent des instructions pour vérifier, éliminer et escalader toute notification générée des processus de surveillance du réseau. Les noms des notifications dans les playbooks coïncident généralement avec ce que le système génère. Ils contiennent des commandes et des étapes dont la précision doit être testée. Ils doivent être régulièrement mis à jour lorsque de nouvelles méthodes de résolution des problèmes sont découvertes, ainsi que lorsque de nouveaux types de défaillance sont identifiés et que des dépendances sont ajoutées.
Les playbooks ne sont pas créés exclusivement pour les notifications. Ils peuvent également contenir des procédures de production pour la publication des versions, la surveillance et le dépannage. D'autres exemples de procédures de production incluent l'activation / la désactivation d'un service, la maintenance d'un service et un accident / escalade.
Post mortemLes SRE fonctionnent avec des systèmes distribués complexes à grande échelle et améliorent également les services à l'aide de nouvelles fonctionnalités et de l'ajout de nouveaux systèmes. Par conséquent, étant donné l'ampleur et la vitesse des changements, les incidents et les perturbations sont inévitables. L'autopsie est un outil SRE important, formalisant le processus d'apprentissage de nos erreurs. Dans l’histoire hypothétique de Zoe, l’équipe n’avait pas de procédure post-mortem officielle, il n’y avait donc pas de processus officiel pour enregistrer les conclusions de l’incident qui empêcherait sa récurrence. L'équipe est donc vouée à répéter encore et encore les mêmes erreurs.
Les équipes SRE doivent créer un modèle post-mortem normalisé avec des sections qui capturent des informations importantes sur l'échec. Idéalement, le modèle doit être structuré de manière à pouvoir être facilement analysé par un outil d'analyse de données. Il envoie des rapports sur la dynamique des accidents en utilisant l'autopsie comme source de données. Chaque post mortem créé à l'aide de ce modèle décrit un échec de production, y compris les informations suivantes (minimum):
- Chronologie des événements (chronologie).
- Description de l'impact sur l'utilisateur.
- Cause profonde
- Points d'action / leçons apprises.
Postmortem est écrit par un membre de l'équipe qui rencontre un échec, idéalement à ceux qui ont participé à sa suppression et peuvent prendre la responsabilité des améliorations. L'autopsie doit être rédigée de manière innocente. Il doit contenir les informations nécessaires pour comprendre ce qui s'est passé, ainsi qu'une liste des décisions qui doivent être prises pour réduire la probabilité de récurrence, réduire les conséquences et / ou simplifier le rétablissement.
DirectivesDans la documentation de politique, des règles techniques et non techniques spécifiques et des directives de production sont indiquées. Les règles techniques peuvent s'appliquer, par exemple, à la journalisation des modifications de la production, à la maintenance des journaux, à la dénomination des services internes (règles de dénomination que les ingénieurs doivent suivre lors de la mise en œuvre des services), ainsi qu'à l'utilisation et à la disponibilité des données d'identification d'urgence.
Les directives peuvent également être dirigées vers des processus. Les règles d'escalade aident les ingénieurs à classer les défaillances comme urgentes et non urgentes et à comprendre les actions à entreprendre dans une situation donnée; les directives sur les attentes de quart décrivent la structure de l'équipe et le domaine de responsabilité de chacun de ses membres.
Accord de niveau de serviceService Level Agreement (Service-Level Agreement, en bref - SLA) - un accord formel avec le client sur le travail fourni du service et les mesures prises en cas de manquement aux obligations. Les équipes SRE documentent la disponibilité et la latence des services et surveillent les performances des services associées aux SLA.
La documentation et la publication des SLA, ainsi qu'une analyse approfondie de l'expérience utilisateur et de sa comparaison avec les SLA, permettent aux équipes SRE d'innover plus rapidement sans perdre la qualité UX. Les SRE qui prennent en charge les services avec un avis SLA clair échouent plus rapidement et les corrigent donc plus rapidement. Le SLA réduit également la quantité de friction entre les équipes SRE et SWE (développeurs de logiciels), permettant aux équipes de discuter objectivement des objectifs et des résultats, en évitant les jugements subjectifs sur le risque.
Il convient de noter que l'existence d'un accord externe juridiquement valide peut ne pas s'appliquer à la plupart des équipes SRE. Dans de tels cas, les équipes SRE peuvent être limitées aux objectifs de niveau de service (SLO pour faire court). SLO - Déterminez le niveau de service souhaité pour une métrique spécifique, par exemple, la disponibilité ou le retard.
Documentation produitLes équipes SRE s'efforcent de consacrer 50% de leur temps à travailler sur un projet, à développer des logiciels pour automatiser le travail manuel ou à améliorer la fiabilité des services. Cette section décrit les documents liés au produit et aux outils développés par SRE.
Ces documents sont importants car ils permettent aux utilisateurs de comprendre si ce produit leur convient, comment commencer à travailler avec lui et comment obtenir une assistance. Ils offrent également la bonne expérience utilisateur et facilitent l'adoption des produits.
Page À propos du produitLa page de description aide SRE et les ingénieurs de développement de produits à comprendre ce qu'est un produit ou un outil, ce qu'il fait et comment l'utiliser.
Manuel conceptuelUn guide conceptuel ou un glossaire définit tous les concepts propres au produit. La définition des concepts permet de maintenir la cohérence de la documentation et des éléments des interfaces utilisateurs, API et CLI (interfaces de ligne de commande).
Guide de mise en route
L'objectif du guide de mise en route est de mettre rapidement à jour les ingénieurs avec un minimum de retards. Ceci est utile pour les nouveaux utilisateurs qui souhaitent essayer le produit.
CodelabLes ingénieurs peuvent utiliser ces didacticiels, combinant des explications théoriques, des exemples de code et des exercices, pour se familiariser rapidement avec le produit. Les Codelabs fournissent également des scripts détaillés qui guident les ingénieurs pas à pas à travers une série de tâches. Ces didacticiels sont généralement plus longs que les guides de démarrage. Ils peuvent couvrir plusieurs produits ou outils s'ils sont liés à quelque chose.
Guide pratiqueCes conseils sont nécessaires pour les utilisateurs qui souhaitent résoudre un problème spécifique. Ces guides sont généralement un guide étape par étape que vous devez suivre.
FAQ
Sur la page FAQ, l'utilisateur peut obtenir des réponses aux questions les plus fréquentes, découvrir les difficultés et les limites qui peuvent être rencontrées, trouver des liens vers des documents et d'autres pages pour des informations plus détaillées.
Le soutienSur la page d'assistance, les ingénieurs peuvent apprendre à résoudre le problème auquel ils sont confrontés. Vous pouvez également trouver un plan d'escalade, des informations de dépannage, des liens de groupe, des tableaux de bord et des SLO, ainsi que des informations sur les équipes.
Description de l'APICe guide décrit les fonctions, les classes et les méthodes, généralement avec un minimum de texte d'accompagnement. Cette documentation est le plus souvent créée sur la base des commentaires du code et est parfois écrite par des rédacteurs techniques.
Guide du développeurÀ partir de ce guide, les développeurs peuvent apprendre à programmer avec l'API du produit. Ces guides sont généralement nécessaires si les SRE créent des produits qui fournissent des API aux développeurs, ce qui vous permet de créer des outils mixtes qui s'appellent mutuellement pour des tâches plus complexes.
Documents pour signaler l'état du serviceCette section décrit les documents que l'équipe SRE crée pour décrire l'état des services pris en charge.
Revue de service trimestrielleLes informations sur l'état du service sont présentées sous deux formats: un rapport trimestriel convenu par le chef de file SRE, qui est distribué dans toute l'organisation SRE, et des présentations pour le chef de file en développement de produits et l'équipe.
Les dirigeants SRE sont intéressés par les rapports trimestriels, car ils fournissent des informations sur les points suivants:
- Problèmes de support (quarts, tickets, autopsie). Les dirigeants SRE savent que si les problèmes de support commencent à occuper plus de 50% des ressources de l'équipe SRE, il est nécessaire de répondre et de changer les priorités. L'objectif est d'identifier le problème dès les premiers stades.
- Exécution de SLA. Les dirigeants du SRE veulent savoir si tout va bien avec le SLA, s'il y a des composants malsains dans l'écosystème qui constituent une menace.
- Les risques Les dirigeants de SLA veulent connaître les risques connus de SRE qui peuvent interférer avec les produits et les objectifs commerciaux.
Des rapports trimestriels permettent à l'équipe SRE de:
- Soulignez les avantages de SRE pour l'équipe de développement de produits, ainsi que le travail même de l'équipe SRE.
- Demander la priorité pour résoudre les problèmes qui interfèrent avec la commande SRE (résilience).
- Demandez des commentaires sur les priorités de l'équipe SRE.
- Soulignez la contribution plus large de l'équipe.
Aperçu des techniques réussiesCette revue permet d'adopter des techniques performantes et d'arriver à un état stable dans lequel les opérations nécessitent un minimum de temps. Pour préparer ces rapports, les équipes SRE fournissent une charte de site et d'équipe, des détails sur le statut des équipes, les projets par rapport à interruptions, planification des capacités, etc.
Un examen des pratiques réussies aide l'équipe SRE à se comparer au reste de l'organisation SRE et à améliorer les performances dans des domaines clés: statut de quart de travail, projets vs interruptions, SLO et planification des capacités.
La fin de la deuxième partie.
Lisez la partie suivante.Nous attendons vos questions et commentaires comme d'habitude.