View a markdown version of this page

Étape 5 : Réagir et apprendre - AWS Directives prescriptives

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Étape 5 : Réagir et apprendre

Lorsque vous dirigez une start-up, des processus post-mortem complexes peuvent ralentir votre équipe. Ce chapitre explique comment tirer des leçons des incidents sans les transformer en exercices bureaucratiques.

Intégrez l'apprentissage par incidents à vos rythmes existants. Si votre équipe se réunit déjà régulièrement, consacrez dix minutes à discuter des incidents récents. Concentrez-vous sur des questions pratiques, telles que :

  • Les runbooks vous ont-ils aidé ?

  • Les alertes ont-elles eu lieu au bon moment ?

  • Les services AWS gérés auraient-ils pu empêcher cela ?

Concentrez-vous sur les actions, pas sur le blâme. Dans une start-up, vous ne construisez pas un système parfait ; vous en créez un qui s'améliore chaque fois que quelque chose ne va pas.

Vous pouvez utiliser votre système de billetterie pour suivre les incidents ; aucun outil spécialisé n'est nécessaire. Créez un modèle simple qui inclut la chronologie des incidents, l'impact sur le client, les mesures de reprise prises et les leçons apprises. Cela peut devenir une mémoire institutionnelle si vous l'utilisez activement. Passez en revue les incidents passés lors de l'intégration afin de mettre les nouveaux ingénieurs au courant. Référencez-les dans les revues d'architecture lors de la conception de systèmes similaires. Intégrez-les aux journées de jeu pour créer des scénarios d'échec réalistes basés sur des événements réels. Le modèle capture ce qui s'est passé, et une utilisation régulière le transforme en apprentissage organisationnel.

Au fur et à mesure que les startups se développent, des modèles apparaissent. Il se peut que certains composants échouent plus souvent ou que certains types de modifications posent des problèmes. Utilisez ces modèles pour orienter les investissements dans la résilience. Si les basculements de base de données posent problème, envisagez d'améliorer la configuration de vos zones de disponibilité multiples. Si les interruptions des services fournis par des tiers sont un thème courant, envisagez d'améliorer les disjoncteurs.

L'objectif n'est pas d'empêcher tous les échecs possibles. C'est impossible et cela vous ralentirait trop. L'objectif est d'apprendre rapidement, de s'adapter rapidement et de maintenir la fiabilité de l'application pendant que vous vous développez rapidement. Profitez de chaque incident pour rendre votre système un peu plus résilient, votre équipe un peu plus compétente et vos clients un peu plus confiants dans votre service. Pour les entreprises en démarrage, la rapidité et l'apprentissage surpassent la perfection. Créez des processus légers qui vous aident à tirer les leçons des incidents sans ralentir l'innovation. Les meilleures pratiques de résilience sont celles que votre équipe utilise réellement.