# OPS 7. Comment savoir si vous êtes prêt à assurer une charge de travail ?
Évaluez la disponibilité opérationnelle de votre charge de travail, des processus et des procédures, ainsi que le personnel pour comprendre les risques opérationnels liés à votre charge de travail.
**Topics**
+ [OPS07-BP01 Garantie des compétences du personnel](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Assurer un examen cohérent de l’état de préparation opérationnelle](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Utilisation de runbooks pour effectuer des procédures](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Utilisation de playbooks pour analyser les problèmes](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Prise de décisions avisées pour déployer des systèmes et des modifications](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 Création de plans de support pour les charges de travail de production](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Garantie des compétences du personnel
Prévoyez un mécanisme pour confirmer que vous disposez du nombre approprié de membres du personnel formés pour supporter la charge de travail. Ils doivent être formés à la plateforme et aux services qui constituent votre charge de travail. Donnez-leur les connaissances nécessaires pour exploiter la charge de travail. Vous devez former un nombre suffisant de membres du personnel pour assurer le fonctionnement normal de la charge de travail et résoudre les incidents qui surviennent. Prévoyez suffisamment de personnel pour pouvoir effectuer une rotation pendant les astreintes et les vacances afin d’éviter l’épuisement professionnel.
**Résultat escompté :**
+ Le personnel formé est en nombre suffisant pour faire face à la charge de travail lorsque celle-ci est disponible.
+ Vous assurez la formation de votre personnel sur les logiciels et services qui constituent votre charge de travail.
**Anti-modèles courants :**
+ Déploiement d’une charge de travail sans que les membres de l’équipe soient qualifiés pour gérer la plateforme et les services utilisés.
+ Ne pas disposer d’un personnel suffisant pour assurer les rotations d’astreinte ou les congés du personnel.
**Avantages liés au respect de cette bonne pratique :**
+ Le fait de disposer de membres d’équipe compétents vous permet de prendre efficacement en charge votre charge de travail.
+ Avec un nombre suffisant de membres de l’équipe, vous pouvez prendre en charge la charge de travail et les rotations d’astreinte tout en diminuant le risque d’épuisement professionnel.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Confirmez qu’il y a suffisamment de personnel formé pour soutenir la charge de travail. Vérifiez que vous avez suffisamment de membres de l’équipe pour couvrir les activités opérationnelles normales, y compris les rotations d’astreinte.
**Exemple client**
AnyCompany Retail veille à ce que les équipes qui prennent en charge la charge de travail soient correctement dotées en personnel et formées. Elles disposent de suffisamment d’ingénieurs pour assurer une rotation d’astreinte. Le personnel reçoit une formation sur le logiciel et la plateforme sur lesquels repose la charge de travail et est encouragé à obtenir des certifications. Il y a suffisamment de membres du personnel pour que les gens puissent prendre des congés tout en prenant en charge la charge de travail et la rotation des astreintes.
### Étapes d’implémentation
1. Affectez un nombre suffisant d’employés à l’exploitation et au soutien de votre charge de travail, y compris aux tâches d’astreinte, aux problèmes de sécurité et aux événements du cycle de vie, tels que les tâches de fin de prise en charge et de rotation des certificats.
1. Formez votre personnel aux logiciels et aux plateformes qui composent votre charge de travail.
1. [AWS Training and Certification](https://aws.amazon.com/training/) dispose d’une bibliothèque de cours sur AWS. Le service propose des cours gratuits et payants, en ligne et en personne.
1. [AWS organise des événements et des webinaires au cours](https://aws.amazon.com/events/) desquels vous pouvez apprendre auprès d’experts AWS.
1. Effectuez régulièrement les tâches suivantes :
+ Évaluez la taille et les compétences de l’équipe en fonction de l’évolution des conditions d’exploitation et de la charge de travail.
+ Adaptez la taille et les compétences de l’équipe aux besoins opérationnels.
+ Vérifiez l’aptitude et la capacité à [traiter les événements de cycle de vie planifiés](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html), la sécurité non planifiée et les notifications opérationnelles via AWS Health.
**Niveau d’effort du plan d’implémentation :** élevé L’embauche et la formation d’une équipe pour soutenir une charge de travail peuvent demander des efforts considérables, mais présentent des avantages importants à long terme.
## Ressources
**Bonnes pratiques associées :**
+ [OPS11-BP04 Effectuer la gestion des connaissances](ops_evolve_ops_knowledge_management.md) – Les membres de l’équipe doivent disposer des informations nécessaires au fonctionnement et au soutien de la charge de travail. La gestion des connaissances est la clé pour y parvenir.
**Documents connexes :**
+ [Événements et webinaires AWS](https://aws.amazon.com/events/)
+ [Formation et certification AWS](https://aws.amazon.com/training/)
# OPS07-BP02 Assurer un examen cohérent de l’état de préparation opérationnelle
Utilisez les examens de disponibilité opérationnelle (ORR) afin de vous assurer que vous pouvez gérer votre charge de travail. L’ORR est un mécanisme élaboré par Amazon afin de s’assurer que les équipes peuvent exécuter leurs charges de travail en toute sécurité. Un ORR est un processus d’examen et d’inspection qui utilise une liste de contrôle des exigences. Un ORR est une expérience en libre-service que les équipes utilisent pour certifier leurs charges de travail. Les ORR comprennent les bonnes pratiques tirées des enseignements liés aux années que nous avons consacrées à la création de logiciels.
La liste de contrôle d’un ORR est composée de recommandations architecturales, de processus opérationnels, de gestion d’événements et de qualité de version. Notre processus de correction des erreurs (CoE) est l’un des principaux moteurs de ces éléments. Votre propre analyse post-incident doit orienter l’évolution de votre propre ORR. Un ORR consiste non seulement à suivre les bonnes pratiques, mais permet également d’éviter la répétition d’événements que vous avez déjà vus. Enfin, les exigences en matière de sécurité, de gouvernance et de conformité peuvent également être incluses dans un ORR.
Exécutez les ORR avant qu’une charge de travail ne soit généralement disponible, puis tout au long du cycle de développement du logiciel. L’exécution d’un ORR avant le lancement augmente votre capacité de gestion de la charge de travail en toute sécurité. Réexécutez régulièrement votre ORR sur la charge de travail afin de détecter toute dérive par rapport aux bonnes pratiques. Vous pouvez avoir des listes de contrôle des ORR pour les lancements de nouveaux services et des ORR pour les examens périodiques. Cela vous permet de vous tenir au courant des nouvelles bonnes pratiques et d’intégrer les leçons tirées de l’analyse après incident. Au fur et à mesure que votre utilisation du cloud évolue, vous pouvez intégrer les exigences des ORR dans votre architecture par défaut.
**Résultat escompté :** vous avez une liste de contrôle de l’ORR avec les bonnes pratiques pour votre organisation. Les ORR sont effectuées avant le lancement des charges de travail. Les ORR sont exécutés périodiquement tout au long du cycle de vie de la charge de travail.
**Anti-modèles courants :**
+ Vous lancez une charge de travail sans savoir si vous pouvez l’utiliser.
+ Les exigences en matière de gouvernance et de sécurité ne sont pas incluses dans la certification d’une charge de travail pour le lancement.
+ Les charges de travail ne sont pas réévaluées périodiquement.
+ Les charges de travail sont lancées sans procédures requises en place.
+ Vous voyez la répétition de la même cause première de défaillances dans plusieurs charges de travail.
**Avantages liés au respect de cette bonne pratique :**
+ Vos charges de travail comprennent les bonnes pratiques en matière d’architecture, de processus et de gestion.
+ Les enseignements tirés sont intégrés à votre processus d’ORR.
+ Les procédures requises sont en place lors du lancement des charges de travail.
+ Les ORR sont exécutés tout au long du cycle de vie logiciel de vos charges de travail.
**Niveau de risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Un ORR est composé de deux éléments : un processus et une liste de contrôle. Votre processus d’ORR doit être adopté par votre organisation et soutenu par un responsable exécutif. Au minimum, les ORR doivent être effectués avant qu’une charge de travail ne soit généralement disponible. Exécutez l’ORR tout au long du cycle de développement du logiciel afin de l’actualiser avec les bonnes pratiques ou les nouvelles exigences. La liste de contrôle d’un ORR doit comprendre les éléments de configuration, les exigences en matière de sécurité et de gouvernance et les bonnes pratiques de votre organisation. Au fil du temps, vous pouvez utiliser des services tels que [AWS Config[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), et des [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html), pour intégrer les meilleures pratiques issues de l’ORR à des barrières de protection afin de détecter automatiquement les meilleures pratiques.
**Exemple client**
Après plusieurs incidents de production, AnyCompany Retail a décidé de mettre en place un processus d’ORR. L’entreprise a élaboré une liste de contrôle composée de bonnes pratiques, d’exigences en matière de gouvernance et de conformité et d’enseignements tirés des pannes. De nouvelles charges de travail effectuent des ORR avant leur lancement. Chaque charge de travail effectue un ORR annuel avec un sous-ensemble de bonnes pratiques pour intégrer de nouvelles bonnes pratiques et des exigences qui sont ajoutées à la liste de contrôle de l’ORR. Au fil du temps, AnyCompany Retail a utilisé [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) pour détecter certaines bonnes pratiques, accélérant ainsi le processus ORR.
**Étapes d’implémentation**
Pour en savoir plus sur les ORR, lisez le [livre blanc intitulé Operational Readiness Reviews (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Il fournit des informations détaillées sur l’historique du processus d’ORR, sur la façon d’établir votre propre pratique d’ORR et sur la façon d’élaborer votre liste de contrôle pour les ORR. Les étapes suivantes sont une version abrégée de ce document. Pour une compréhension approfondie des ORR et de la façon dont vous pouvez créer les vôtres, nous vous recommandons de lire ce livre blanc.
1. Réunissez les parties prenantes clés, notamment les représentants de la sécurité, des opérations et du développement.
1. Demandez à chaque partie prenante de fournir au moins une exigence. Pour la première itération, essayez de limiter le nombre d’éléments à trente ou moins.
+ L’[Annexe B : exemples de questions ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) du livre blanc Operational Readiness Reviews (ORR) contient des exemples de questions que vous pouvez utiliser pour démarrer.
1. Regroupez vos exigences dans une feuille de calcul.
+ Vous pouvez utiliser des [objectifs personnalisés](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) dans [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) pour développer vos ORR et les partager entre vos comptes et votre organisation AWS.
1. Identifiez une charge de travail pour effectuer l’ORR. Il est recommandé d’utiliser une charge de travail avant le lancement ou une charge de travail interne.
1. Parcourez la liste de contrôle de l’ORR et notez toutes vos découvertes. Les découvertes peuvent être acceptables si une mesure d’atténuation est en place. Pour toute découverte qui ne comporte pas de mesures d’atténuation, ajoutez ces dernières à votre liste de tâches en attente et implémentez-les avant le lancement.
1. Continuez d’ajouter des bonnes pratiques et des exigences à votre liste de contrôle de l’ORR au fil du temps.
Les clients Support bénéficiant du Support aux entreprises peuvent demander l’[atelier de révision du niveau de préparation opérationnelle](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) auprès de leur responsable de compte technique. L’atelier est une session interactive de *travail à rebours* visant à développer votre propre liste de contrôle ORR.
**Niveau d’effort du plan d’implémentation :** élevé L’adoption d’une pratique d’ORR dans votre organisation nécessite un parrainage de la haute direction et l’adhésion des parties prenantes. Créez et mettez à jour la liste de contrôle à l’aide des commentaires de l’ensemble de votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [OPS01-BP03 Évaluer les exigences de gouvernance](ops_priorities_governance_reqs.md) – Les exigences en matière de gouvernance conviennent naturellement à la liste de contrôle d’un ORR.
+ [OPS01-BP04 Évaluation des exigences de conformité](ops_priorities_compliance_reqs.md) – Les exigences de conformité sont parfois incluses dans la liste de contrôle d’un ORR. Parfois, il s’agit d’un processus distinct.
+ [OPS03-BP07 Ressources appropriées pour les équipes](ops_org_culture_team_res_appro.md) – La capacité de l’équipe peut faire partie des exigences d’un ORR.
+ [OPS06-BP01 Planifier les modifications infructueuses](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Un plan de restauration ou de retour en arrière doit être établi avant le lancement de votre charge de travail.
+ [OPS07-BP01 Garantie des compétences du personnel](ops_ready_to_support_personnel_capability.md) – Pour gérer une charge de travail, vous devez disposer du personnel requis.
+ [SEC01-BP03 Identifier et valider les objectifs de contrôle](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – Les objectifs de contrôle de sécurité constituent d’excellentes exigences d’ORR.
+ [REL13-BP01 Définissez les objectifs de restauration en cas d’indisponibilité et de perte de données](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – Les plans de reprise après sinistre constituent une bonne exigence ORR.
+ [COST02-BP01 Élaborez des politiques basées sur les exigences de votre organisation](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – Les politiques de gestion des coûts sont bonnes à inclure dans votre liste de contrôle ORR.
**Documents connexes :**
+ [AWS Control Tower – Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool – Approches personnalisées](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template par Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Livre blanc Operational Readiness Reviews (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**Vidéos connexes :**
+ [AWS Supports You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**Exemples connexes :**
+ [Sample Operational Readiness Review (ORR) Lens](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**Services connexes :**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 Utilisation de runbooks pour effectuer des procédures
Un *runbook* est un processus documenté pour atteindre un résultat spécifique. Les runbooks consistent en une série d’étapes permettant à la personne qui les suit d’obtenir des résultats concrets. L’utilisation des runbooks dans les opérations remonte aux débuts de l’aviation. Dans les opérations de cloud, nous utilisons des runbooks pour réduire les risques et obtenir les résultats souhaités. Dans sa forme la plus simple, un runbook est une liste de contrôle pour exécuter une tâche.
Les runbooks représentent une part essentielle du fonctionnement de votre charge de travail. De l’intégration d’un nouveau membre de l’équipe au déploiement d’une version majeure, les runbooks sont des processus codifiés qui fournissent des résultats cohérents quelle que soit la personne qui les utilise. Les runbooks doivent être publiés dans un emplacement central et mis à jour à mesure que le processus évolue, car la mise à jour des runbooks est un composant essentiel du processus de gestion des changements. Ils doivent également inclure des conseils sur la gestion des erreurs, les outils, les autorisations, les exceptions et les remontées en cas de problème.
À mesure que votre entreprise évolue, commencez à automatiser les runbooks. Prenez tout d’abord les runbooks courts et fréquemment utilisés. Utilisez des langages de scripts pour automatiser les étapes ou les rendre plus faciles. À mesure que vous automatiserez les premiers runbooks, vous consacrerez du temps à l’automatisation de runbooks plus complexes. Au fil du temps, la plupart de vos runbooks seront automatisés d’une certaine façon.
**Résultat escompté :** votre équipe dispose de plusieurs guides détaillés pour exécuter des tâches de charge de travail. Les runbooks contiennent le résultat souhaité, les outils et autorisations nécessaires, ainsi que les instructions pour gérer les erreurs. Ils sont stockés dans un emplacement central (système de contrôle des versions) et mis à jour fréquemment. Par exemple, vos runbooks permettent à vos équipes de surveiller, de communiquer et de répondre aux événements AWS Health concernant les comptes critiques lors d’alarmes d’applications, de problèmes opérationnels et d’événements planifiés du cycle de vie.
**Anti-modèles courants :**
+ Utilisation de la mémoire pour exécuter chaque étape d’un processus.
+ Déploiement manuel des changements sans liste de contrôle.
+ Différents membres de l’équipe exécutant le même processus, mais avec des étapes ou résultats différents.
+ Désynchronisation des runbooks avec les changements du système et l’automatisation.
**Avantages liés au respect de cette bonne pratique :**
+ Réduction du taux d’erreur pour les tâches manuelles.
+ Exécution cohérente des opérations.
+ Exécution plus précoce des tâches par les nouveaux membres de l’équipe.
+ Automatisation des runbooks pour diminuer la quantité de travail.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Les runbooks peuvent prendre plusieurs formes selon le niveau de maturité de votre entreprise. Au minimum, ils doivent consister en un document texte détaillé. Le résultat souhaité doit être clairement indiqué. Documentez explicitement les autorisations spéciales ou outils nécessaires. Fournissez des conseils sur la gestion des erreurs et les remontées en cas de problème. Recherchez le propriétaire du runbook et publiez-le dans un emplacement central. Une fois votre runbook documenté, validez-le en demandant à un membre de votre équipe de l’exécuter. À mesure que les procédures évoluent, mettez à jour vos runbooks conformément à votre processus de gestion des changements.
Vos runbooks texte doivent être automatisés à mesure que votre entreprise évolue. En utilisant des services tels que les [automatisations d’AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), vous pouvez transformer un fichier texte en automatisations pouvant être exécutées sur votre charge de travail. Ces automatisations peuvent être exécutées en réponse aux événements, tout en réduisant la charge opérationnelle pour maintenir votre charge de travail. AWS Systems Manager Automation fournit également une [expérience de conception visuelle](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html) à faible code pour créer plus facilement des runbooks d’automatisation.
**Exemple client**
AnyCompany Retail doit mettre à jour des schémas de bases de données lors de déploiements logiciels. L’équipe en charge des opérations de cloud en collaboration avec l’équipe responsable de l’administration des bases de données a créé un runbook, pour déployer manuellement ces changements. Le runbook répertoriait chacune des étapes du processus sous forme de liste de contrôle. Il comprenait une section sur la gestion des erreurs en cas de problème. Les équipes ont publié le runbook sur leur wiki interne contenant leurs autres runbooks. L’équipe en charge des opérations de cloud envisage d’automatiser le runbook dans un prochain sprint.
### Étapes d’implémentation
Si vous ne disposez pas d’un référentiel de documents, un référentiel de contrôle de version est un emplacement idéal pour commencer à créer votre bibliothèque de runbooks. Vous pouvez créer vos runbooks en utilisant le format Markdown. Voici un exemple de modèle de runbook que vous pouvez utiliser pour commencer à créer vos runbooks.
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. Si vous ne possédez pas de référentiel de documentation ou de wiki existant, créez un référentiel de contrôle de version dans votre système de contrôle de version.
1. Identifiez un processus ne possédant pas de runbook. Le processus idéal doit être réalisé de manière semi-régulière, contenir peu d’étapes et avoir des échecs à faible impact.
1. Dans votre référentiel de documents, créer un brouillon au format Markdown en utilisant le modèle. Renseignez le titre du runbook et les champs obligatoires sous Runbook Info (Informations sur le runbook).
1. En commençant par la première étape, remplissez la section Steps (Étapes) du runbook.
1. Donnez le runbook à un membre de l’équipe. Demandez-lui d’utiliser le runbook pour valider les étapes. En cas d’élément manquant ou de besoin de clarification, mettez à jour le runbook.
1. Publiez le runbook sur votre référentiel de documentation interne. Une fois le runbook publié, partagez l’information avec votre équipe et les autres parties prenantes.
1. Au fil du temps, vous créerez une bibliothèque de runbooks. À mesure que cette bibliothèque s’étoffe, commencez à travailler sur l’automatisation des runbooks.
**Niveau d’effort du plan d’implémentation :** faible La norme minimum pour un runbook est un guide texte détaillé. L’automatisation des runbooks peut augmenter l’effort d’implémentation.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 Utilisation de playbooks pour analyser les problèmes](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 Utilisation d’un processus pour la gestion des événements, des incidents et des problèmes](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Disposer d’un processus par alerte](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Gestion des connaissances](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documents connexes :**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager : utilisation des runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Playbook d’atténuation des risques pour les importantes migrations AWS – Tâche 4 : amélioration de vos runbooks de migration](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Utiliser les runbooks AWS Automation pour résoudre des tâches opérationnelles](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Vidéos connexes:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Intégrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Exemples connexes:**
+ [Ateliers Well-Architected : automatisation des opérations avec les playbooks et les runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS Article du blog : Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Systems Manager : procédures détaillées sur l’automatisation](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager : restaurer un volume racine à partir du dernier runbook d’instantanés](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Création d’un runbook de réponse à un incident AWS à l’aide des blocs-notes Jupyter et de CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab – Runbooks](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix – Une bibliothèque Python pour créer des runbooks dans les blocs-notes Jupyter](https://github.com/Nurtch/rubix)
+ [Utilisation de Document Builder pour créer un runbook personnalisé](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Services connexes:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 Utilisation de playbooks pour analyser les problèmes
Les *playbooks* sont des guides étape par étape utilisés pour analyser un incident. Lorsque des incidents se produisent, les playbooks sont utilisés pour analyser, évaluer l’impact et identifier une cause racine. Les playbooks sont utilisés dans le cadre de différents scénarios allant des échecs de déploiement aux incidents de sécurité. Dans la plupart des cas, les playbooks identifient la cause racine qui est atténuée par l’utilisation d’un runbook. Les playbooks sont une composante essentielle des plans de réponse de votre organisation en cas d’incident.
Un playbook efficace comporte plusieurs fonctionnalités clés. Il guide l’utilisateur, étape par étape, dans le processus de découverte. Si vous optez pour un point de vue extérieur, quelles étapes devez-vous suivre pour diagnostiquer un incident ? Définissez clairement dans le playbook si des outils spéciaux ou des autorisations élevées sont nécessaires. Il est essentiel d’élaborer un plan de communication pour informer les parties prenantes du statut de l’analyse. Lorsqu’il est impossible de déterminer la cause racine, le playbook doit comporter un plan de remontée des informations vers la hiérarchie. Si la cause racine est identifiée, le playbook doit faire référence à un runbook décrivant une solution pour la résoudre. Les playbooks doivent être stockés dans un emplacement central et mis à jour régulièrement. Si des playbooks sont utilisés pour des alertes précises, donnez aux membres de votre équipe des indications relatives au playbook dans le cadre de l’alerte.
Au fur et à mesure que votre organisation évolue, automatisez vos playbooks. Commencez par des playbooks qui couvrent les incidents à faible risque. Utilisez des scripts pour automatiser les étapes de découverte. Veillez à créer des runbooks complémentaires destinés à atténuer les causes racines courantes.
**Résultat escompté :** votre organisation dispose de playbooks pour les incidents courants. Les playbooks sont stockés dans un emplacement central et mis à la disposition des membres de votre équipe. Les playbooks sont souvent mis à jour. Pour toute cause racine connue, des runbooks complémentaires sont créés.
**Anti-modèles courants :**
+ Il n’existe pas de façon standard d’analyser un incident.
+ Les membres de l’équipe comptent sur la mémoire musculaire ou les connaissances institutionnelles pour résoudre un échec de déploiement.
+ Les nouveaux membres de l’équipe apprennent à analyser les problèmes par un procédé de tâtonnement.
+ Les bonnes pratiques d’analyse des problèmes ne sont pas partagées entre les équipes.
**Avantages liés au respect de cette bonne pratique :**
+ Les playbooks dynamisent les efforts nécessaires pour atténuer les incidents.
+ Différents membres de l’équipe peuvent utiliser le même playbook pour identifier une cause racine de façon cohérente.
+ Les causes racines connues peuvent être associées à des runbooks développés spécialement pour leur résolution, ce qui permet d’accélérer le délai de récupération.
+ Les playbooks permettent aux membres de l’équipe de commencer à apporter leur contribution plus tôt.
+ Les équipes peuvent adapter leurs processus à l’aide de playbooks reproductibles.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
La façon dont vous créez et utilisez les playbooks dépend de la maturité de votre organisation. Si vous débutez dans le cloud, créez des playbooks sous forme de texte dans un référentiel de documents centralisé. Au fur et à mesure que votre organisation évolue, les playbooks peuvent devenir semi-automatisés avec des langages de script comme Python. Ces scripts peuvent être exécutés dans un bloc-notes Jupyter afin d’accélérer la découverte. Les organisations avancées ont des playbooks entièrement automatisés pour les problèmes courants qui sont corrigés automatiquement avec des runbooks.
Pour commencer à créer vos playbooks, répertoriez les incidents qui affectent couramment votre charge de travail. Pour commencer, choisissez des playbooks pour les incidents à faible risque dont la cause racine a été réduite à quelques problèmes. Une fois que vous disposez de playbooks pour des scénarios plus simples, passez aux scénarios à risque élevé ou à ceux dont la cause racine est peu connue.
Vos playbooks sous forme de texte doivent être automatisés à mesure que votre entreprise évolue. Grâce à des services comme [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), les textes plats peuvent être transformés en automatismes. Ces automatisations peuvent être exécutées en fonction de votre charge de travail pour accélérer les analyses. Ces automatisations peuvent être activées en réponse à des événements, ce qui réduit le temps nécessaire pour découvrir et résoudre les incidents.
Les clients peuvent utiliser [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) pour intervenir en cas d’incidents. Ce service offre une interface unique pour trier les incidents, informer les parties prenantes pendant la découverte et l’atténuation, et collaborer tout au long de l’incident. Il utilise AWS Systems Manager Automations afin d’accélérer la détection et la récupération.
**Exemple client**
AnyCompany Retail a dû faire face à un incident de production. L’ingénieur d’astreinte a utilisé un playbook pour analyser le problème. À mesure qu’il effectuait les différentes étapes, il a informé les parties prenantes identifiées dans le playbook de l’évolution de la situation. L’ingénieur a identifié que la cause racine était une condition de concurrence dans un service dorsal. À l’aide d’un runbook, il a relancé le service et a permis à AnyCompany Retail d’être à nouveau en ligne.
### Étapes d’implémentation
Si vous n’avez pas de référentiel de documents existant, nous vous suggérons de créer un référentiel de contrôle de version pour votre bibliothèque de playbooks. Vous pouvez créer vos playbooks en utilisant Markdown, qui est compatible avec la plupart des systèmes d’automatisation de playbook. Si vous démarrez de zéro, utilisez l’exemple de modèle de playbook suivant.
```
# Playbook Title
## Playbook Info
| Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan |
|-------|-------|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? |
## Steps
1. Step one
2. Step two
```
1. Si vous ne possédez pas de référentiel de documents ni de wiki existant, créez un référentiel de contrôle de version pour vos playbooks dans votre système de contrôle de version.
1. Identifiez un problème courant qui doit être analysé. Il doit s’agir d’un scénario où la cause racine se limite à quelques problèmes et où la résolution présente peu de risques.
1. À l’aide du modèle Markdown, remplissez la section Playbook Name (Nom du playbook) et les champs sous Playbook Info (Informations sur le playbook).
1. Remplissez les étapes de résolution du problème. Soyez aussi clair que possible sur les actions à effectuer ou les domaines à analyser.
1. Remettez le playbook à un membre de l’équipe et demandez-lui de le passer en revue afin de le valider. S’il manque quelque chose ou si un point n’est pas clair, mettez à jour le playbook.
1. Publiez le playbook dans votre référentiel de documents et informez votre équipe et les parties prenantes.
1. Cette bibliothèque de playbooks s’enrichira à mesure que vous ajouterez d’autres playbooks. Une fois que vous avez plusieurs playbooks, commencez à les automatiser en utilisant des outils comme AWS Systems Manager Automations afin de garantir la synchronisation entre l’automatisation et les playbooks.
**Niveau d’effort du plan d’implémentation :** faible Vos playbooks doivent être des documents texte stockés dans un emplacement central. Les organisations plus avancées évolueront vers l’automatisation des playbooks.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 Utilisation de runbooks pour effectuer des procédures](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Utilisation d’un processus pour la gestion des événements, des incidents et des problèmes](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Disposer d’un processus par alerte](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Gestion des connaissances](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documents connexes :**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager : utilisation des runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Utiliser les runbooks AWS Automation pour résoudre des tâches opérationnelles](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Vidéos connexes:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWSSystems Manager Incident Manager : ateliers AWS virtuels](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [Intégrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Exemples connexes:**
+ [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager : procédures détaillées sur l’automatisation](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [Création d’un runbook de réponse à un incident AWS à l’aide des blocs-notes Jupyter et de CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Rubix : une bibliothèque Python pour créer des runbooks dans les blocs-notes Jupyter](https://github.com/Nurtch/rubix)
+ [Utilisation de Document Builder pour créer un runbook personnalisé](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Services connexes:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 Prise de décisions avisées pour déployer des systèmes et des modifications
Mettez en place des processus pour les modifications réussies et ratées de votre charge de travail. Un pré-mortem est un exercice où une équipe simule un échec pour développer des stratégies d’atténuation. Utilisez des pré-mortems pour anticiper les échecs et créer des procédures le cas échéant. Évaluez les avantages et les risques liés au déploiement de modifications dans votre charge de travail. Vérifiez que toutes les modifications sont conformes à la gouvernance.
**Résultat escompté :**
+ Vous prenez des décisions éclairées lorsque vous déployez des modifications dans votre charge de travail.
+ Les modifications sont conformes à la gouvernance.
**Anti-modèles courants :**
+ Déploiement d’une modification dans notre charge de travail sans disposer de processus pour gérer un déploiement raté.
+ Modifications apportées à votre environnement de production qui ne sont pas conformes aux exigences de gouvernance.
+ Déploiement une nouvelle version de votre charge de travail sans établir une base de référence pour l’utilisation des ressources.
**Avantages liés au respect de cette bonne pratique :**
+ Vous êtes préparé à des modifications ratées de votre charge de travail.
+ Les modifications apportées à votre charge de travail sont conformes aux politiques de gouvernance.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** bas
## Directives d’implémentation
Utilisez des pré-mortems pour développer des processus pour les modifications ratées. Documentez vos processus pour les modifications ratées. Veillez à ce que toutes les modifications soient conformes à la gouvernance. Évaluez les avantages et les risques liés au déploiement de modifications dans votre charge de travail.
**Exemple client**
AnyCompany Retail effectue régulièrement des pré-mortems pour valider ses processus en cas de modification ratée. La société documente ses processus dans un wiki partagé et le met à jour fréquemment. Toutes les modifications sont conformes aux exigences de gouvernance.
**Étapes d’implémentation**
1. Prenez des décisions éclairées lorsque vous déployez des modifications dans votre charge de travail. Définissez et révisez les critères d’un déploiement réussi. Développez des scénarios ou des critères qui déclencheraient la restauration d’une modification. Comparez les avantages du déploiement des modifications avec les risques associés à l’échec d’une modification.
1. Vérifiez que toutes les modifications sont conformes aux politiques de gouvernance.
1. Utilisez les pré-mortems pour planifier les modifications ratées et documenter les stratégies d’atténuation. Réalisez un exercice théorique pour modéliser une modification qui n’a pas abouti et valider les procédures de restauration.
**Niveau d’effort du plan d’implémentation :** modéré La mise en œuvre d’une pratique de pré-mortems nécessite une coordination et des efforts de la part des parties prenantes de votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [OPS01-BP03 Évaluer les exigences de gouvernance](ops_priorities_governance_reqs.md) – Les exigences de gouvernance sont un facteur clé pour déterminer s’il faut déployer une modification.
+ [OPS06-BP01 Planifier les modifications infructueuses](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Établissez des plans pour atténuer les effets d’un déploiement raté et utilisez des pré-mortems pour les valider.
+ [OPS06-BP02 Déploiements de tests](ops_mit_deploy_risks_test_val_chg.md) – Chaque modification apportée à un logiciel doit être correctement testée avant le déploiement afin de réduire les défauts en production.
+ [OPS07-BP01 Garantie des compétences du personnel](ops_ready_to_support_personnel_capability.md) – Il est essentiel de disposer de suffisamment de membres du personnel formés pour gérer la charge de travail afin de prendre une décision éclairée quant au déploiement d’une modification du système.
**Documents connexes :**
+ [Amazon Web Services : risques et conformité](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [Modèle de responsabilité partagée AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in the AWS Cloud: The Right Balance Between Agility and Safety ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 Création de plans de support pour les charges de travail de production
Activez la prise en charge de tous les logiciels et services sur lesquels repose votre charge de travail de production. Sélectionnez un niveau de support approprié pour répondre à vos besoins en matière de niveau de service de production. Il convient de prévoir des plans de support pour ces dépendances en cas d’interruption de service ou de problème logiciel. Documentez les plans de support et les procédures de demande de support pour tous les fournisseurs de services et de logiciels. Mettez en œuvre des mécanismes permettant de vérifier que les points de contact du support sont tenus à jour.
**Résultat escompté :**
+ Mettez en œuvre des plans de support pour les logiciels et les services sur lesquels reposent les charges de travail de production.
+ Choisissez une formule de support appropriée en fonction des besoins du niveau de service.
+ Documentez les formules de support, les niveaux de support et les procédures de demande de support.
**Anti-modèles courants :**
+ Vous n’avez pas de plan de support pour un fournisseur de logiciels critiques. Votre charge de travail en est affectée et vous ne pouvez rien faire pour accélérer la mise en place d’une solution ou obtenir des mises à jour en temps voulu de la part du fournisseur.
+ Un développeur qui était le principal point de contact d’un fournisseur de logiciels a quitté l’entreprise. Vous n’arrivez pas à joindre directement le support du fournisseur. Vous devez passer du temps à rechercher et à naviguer dans des systèmes de contact génériques, ce qui augmente le temps nécessaire pour répondre en cas de besoin.
+ Un fournisseur de logiciels connaît un arrêt de production. Il n’existe pas de documentation sur la manière de déposer un dossier de support.
**Avantages liés au respect de cette bonne pratique :**
+ En adoptant le niveau de support approprié, vous êtes en mesure d’obtenir une réponse dans le délai nécessaire pour répondre aux besoins du niveau de service.
+ En tant que client bénéficiant du support, vous pouvez faire remonter les problèmes de production.
+ Les fournisseurs de logiciels et de services peuvent contribuer au dépannage pendant un incident.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** bas
## Directives d’implémentation
Activez les plans de support pour tous les fournisseurs de logiciels et de services sur lesquels repose votre charge de travail de production. Mettez en place des plans de support appropriés pour répondre aux besoins du niveau de service. Pour les clients AWS, cela signifie qu’il faut activer l’offre AWS Business Support ou supérieure sur tous les comptes où vous avez des charges de travail de production. Rencontrez régulièrement les fournisseurs de services de support afin d’obtenir des informations actualisées sur les offres de support, les processus et les contacts. Documentez les procédures de demande de support auprès des fournisseurs de logiciels et de services, y compris la manière de faire remonter les informations en cas de panne. Mettez en œuvre des mécanismes permettant de tenir à jour les contacts du support.
**Exemple client**
Chez AnyCompany Retail, toutes les dépendances des logiciels et services commerciaux disposent de plans de support. Par exemple, l’offre AWS Enterprise Support est activée sur tous les comptes comportant des charges de travail de production. Tout développeur peut créer une demande de support en cas de problème. Il existe une page wiki contenant des informations sur la manière de demander de l’aide, sur les personnes à prévenir et sur les bonnes pratiques pour accélérer le traitement d’un incident.
**Étapes d’implémentation**
1. Travaillez avec les parties prenantes de votre organisation pour identifier les fournisseurs de logiciels et de services sur lesquels repose votre charge de travail. Documentez ces dépendances.
1. Déterminez les besoins en matière de niveau de service pour votre charge de travail. Sélectionnez un plan de support qui leur corresponde.
1. Pour les logiciels et services commerciaux, mettez en place une formule de support avec les fournisseurs.
1. Nous vous conseillons vivement de souscrire à AWS Business Support ou à un niveau supérieur pour tous les comptes de production, ce qui vous permettra de bénéficier de temps de réponse plus courts de la part de AWS Support. Si vous ne disposez pas d’une offre de support premium, mettez en place un plan d’action pour gérer les problèmes qui nécessitent l’aide d’AWS Support. AWS Support fournit une combinaison d’outils et de technologies, de personnes et de programmes conçus pour vous aider à optimiser les performances, à réduire les coûts et à innover plus rapidement. En outre, AWS Business Support offre des avantages supplémentaires, notamment un accès par API à AWS Trusted Advisor et à AWS Health pour une intégration programmatique avec vos systèmes, ainsi que d’autres méthodes d’accès telles que la AWS Management Console et les canaux Amazon EventBridge.
1. Documentez le plan de support dans votre outil de gestion des connaissances. Il s’agit notamment de savoir comment demander de l’aide, qui avertir en cas de demande de support et comment faire remonter l’information pendant un incident. Un wiki constitue un bon mécanisme pour permettre à quiconque d’apporter les mises à jour nécessaires à la documentation lorsqu’il prend connaissance de changements dans les processus ou les contacts de support.
**Niveau d’effort du plan d’implémentation :** faible La plupart des fournisseurs de logiciels et de services proposent des plans de support à l’inscription. La documentation et le partage des bonnes pratiques en matière de support sur votre système de gestion des connaissances permettent de vérifier que votre équipe sait ce qu’il faut faire en cas d’incident de production.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](ops_ops_model_def_proc_owners.md)
**Documents connexes :**
+ [AWS Support Plans](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Services connexes :**
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)