Étape 4 : opérer

Vous avez créé une application résiliente et l'avez testée. Aujourd'hui, la réalité quotidienne est de le faire fonctionner. Mais dans une start-up, vous ne pouvez pas surveiller toutes les opérations, et vous ne devriez pas essayer de le faire. L'essentiel est de rester attentif à ce qui compte, sans fournir trop de statistiques ni surcharger votre équipe.

Commencez par le point de vue du client. Les canaris Amazon CloudWatch Synthetics agissent comme des clients automatisés. Ils testent en permanence les parcours critiques des utilisateurs. Demandez-leur de se connecter, de simuler des achats à l'aide de comptes de test ou d'accéder à des fonctionnalités clés, en particulier pendant les heures les plus chargées. Cela vous permet de comprendre l'expérience client et de détecter les problèmes avant que les vrais utilisateurs ne le fassent. Lorsqu'un canari échoue, vous savez immédiatement que quelque chose ne va pas du point de vue du client.

Tirez parti de cette base en surveillant de manière ciblée l'infrastructure de soutien. Quels signaux vous indiquent qu'il y a un problème ? Amazon vous CloudWatch aide à créer des tableaux de bord qui permettent de suivre ces signes. Ne vous contentez pas de surveiller les indicateurs techniques, associez-les à l'impact commercial. Par exemple, une utilisation élevée du processeur est importante, mais c'est parce qu'elle peut dégrader l'expérience client que vous suivez avec des canaris.

Concrètement, associez votre surveillance aux parcours de vos clients. Si vous utilisez une plateforme SaaS (Software as a Service), vous vous souciez probablement des temps de réponse des API, des taux de réussite de l'authentification et de la disponibilité des fonctionnalités de base. Configurez des alertes qui vous avertissent lorsque ces indicateurs dérivent. Soyez toutefois sélectif. Chaque alerte doit exiger une action. Si votre équipe commence à ignorer les alertes parce que « ce n'est probablement rien », c'est que vous en avez défini trop ou que vous suivez les mauvais indicateurs.

Transférez ces alertes par le biais d'outils que votre équipe utilise déjà. Si vos ingénieurs utilisent une application de messagerie en particulier, envoyez-y des alertes. L'objectif est une prise de conscience rapide sans créer de nouveau processus. Lorsqu'une alerte se déclenche, votre équipe doit savoir exactement ce que cela signifie et comment y remédier.

Veillez à ce que votre documentation opérationnelle soit simple et pratique. Stockez des runbooks contenant votre code dans le contrôle de version, mais n'oubliez pas qu'il ne s'agit pas de romans. En cas de panne, votre équipe a besoin de mesures claires et concrètes. Chaque alerte doit renvoyer à un runbook correspondant, et chaque runbook doit répondre à trois questions :

Mettez en œuvre un processus simple de gestion des incidents. Vous n'avez pas besoin de cadres complexes, mais simplement de définitions claires de ce qui constitue un incident et des personnes à contacter en cas d'escalade. Conservez les journaux d'incidents, car ils vous aident à améliorer la résilience de votre application.

L'essentiel est de trouver le juste équilibre entre vigilance et frais généraux. Utilisez AWS des outils pour automatiser ce que vous pouvez, concentrez-vous sur le suivi des indicateurs qui ont un impact sur les clients et maintenez vos processus suffisamment légers pour évoluer au fur et à mesure de votre croissance.

Le chapitre suivant explore comment favoriser un état d'esprit de résilience sans pour autant sacrifier la rapidité et l'innovation qui font la particularité des startups. En fin de compte, la résilience concerne autant les personnes que la technologie.