Réagir efficacement à un incident en production

Anticiper les incidents

Aussi bien conçue soit-elle, une infrastructure cloud finit toujours par casser. Que ce soit un bug sur une application, un élément oublié ou mal configuré dans votre environnement, ou encore un service externe dont vous dépendez, tôt ou tard, il se passera quelque chose. Et le mieux que vous puissiez faire, c'est de vous y préparer.

Préparer votre infrastructure

Cela commence par un système de monitoring et d'alerting bien configuré. Sans alertes, vous ne seriez pas prévenu en cas d'incident, mais au contraire, trop d'alertes et vous ne saurez pas lesquelles traiter.

Dans l'idéal, une alerte ne dérange quelqu'un que lorsque c'est nécessaire. Une alerte sur laquelle on ne peut pas agir ou qui ne correspond pas à un service critique risque de réveiller en pleine nuit un ingénieur et de l'épuiser pour rien.

Sur la durée, cela va nuire considérablement à la productivité de votre équipe. Un bon réflexe est de hiérarchiser ses alertes par niveau de sévérité, seules les plus critiques ont besoin de faire intervenir un humain urgemment.

Une bonne alerte possède aussi une bonne description, son message suffit pour savoir quel service est cassé et contient les premiers éléments pour investiguer l'incident et rétablir la situation. Cela passe souvent par un schéma d'architecture et des runbooks.

Un runbook, c'est une recette pour intervenir lorsqu'un problème connu survient sur votre infrastructure. Si vous pouvez vous contenter de suivre une doc sans réfléchir pour remettre votre infra d'équerre, vous avez tout gagné. N'épargnez aucune précision dans les actions qu'il contient, même réveillé à 3h du matin sans avoir toute votre tête, vous devez pouvoir le suivre facilement pour tacler l’incident le plus vite possible même avec une connaissance limitée de l’infrastructure.

De bons sujets de runbooks un peu génériques sont par exemple "Comment rollback une mise en production ?", "Comment restaurer une sauvegarde de BDD ?" ou "Comment se connecter à cette db qui est derrière deux bastions et trois VPNs ?".

Bref, l'objectif c'est de prémâcher le travail des astreintes pour rendre l'intervention finale la plus efficace et la moins stressante possible peu importe l’ampleur de l’incident.

Préparez-vous

Pour intervenir rapidement, il faut déjà pouvoir se connecter aux services de votre infrastructure. Ce ne serait pas la première fois que quelqu’un se réveille pour une alerte d’incident et ne peut pas intervenir car son mot de passe a expiré. Pensez donc à tester vos accès fréquemment.

L’idéal c’est d’avoir un rituel régulier pour prendre le temps avec l’équipe d’astreinte de tester et de valider l’accès. L’utilisation de services managés comme IAP ou SSM pour centraliser vos accès peut aider grandement à automatiser ce processus.

Il est aussi important de s’assurer que quelqu’un est bien d’astreinte à tout moment. Cela passe par un planning d’astreinte défini au moins quelques jours à l’avance. À Padok on s’assure qu’il y ait toujours deux personnes sur chaque créneau.

D’une part, cela permet de ne pas se sentir seul face à l’incident et de pouvoir se répartir les tâches. D’autre part, cela donne la possibilité d’aller faire ses courses ou de prendre la voiture pendant son astreinte en s’assurant que quelqu’un est toujours prêt à répondre. C’est aussi important d’avoir un roulement suffisant dans l’équipe pour prendre des vacances ou des week-ends complets sans astreinte: un SRE fatigué c’est un SRE qui intervient mal.

On préférera aussi faire intervenir des ingénieurs qui connaissent bien l’infrastructure, mais celle-ci est souvent complexe et l’incident ne surviendra souvent pas là où on s’y attend. D’où l’importance de bien préparer les runbooks et de garder le schéma d’architecture à jour.

Réagir de manière efficace face au problème

Garder son calme et coordonner l'action

Une alerte sonne : votre site web n’est plus accessible. La première chose à faire c’est d’aborder le problème avec le bon état d’esprit : garder votre calme. Peu importe l’impact de l’incident, si vous êtes dans de mauvaises conditions, vous avez plus de chances d’empirer la situation que de la résoudre. Par exemple c’est dans ces moments que l’on commence à ne plus faire attention à la donnée et qu’on compromet ses objectifs de RPO.

Deuxièmement, il faut communiquer avec les autres équipes disponibles. L’objectif va être d’une part de rassurer les utilisateurs concernés en montrant que vous êtes sur le coup et d’autre part de récupérer suffisamment d’informations pour investiguer. Les causes d’incidents sont fréquemment les mêmes :

• bug dans le déploiement d’une nouvelle version
• modification récente de la configuration réseau
• pic de charge et autoscaling mal configuré

Il faut pouvoir éliminer rapidement ces causes ou alors pouvoir appliquer les runbooks associés. À Padok, on aime bien être deux pour qu’un ingénieur puisse se concentrer sur l’investigation tandis que l’autre s’occupe de faire l’intermédiaire avec les autres parties mobilisées.

L’objectif pour l’instant c’est de rétablir le service, résoudre le bug c’est pour plus tard. On s’en tirera donc souvent avec un simple rollback ou en modifiant les paramètres d’un autoscaler. C’est dans ces situations que la méthode GitOps prend tout son sens puisque vous pourrez accomplir ces actions rapidement avec un simple commit sur l’un de vos repo Git.

Quand la cause de l’incident n’est pas aussi évidente, c’est là qu’il faut commencer à investiguer.

Trouver et résoudre le bug rapidement

Commencez par regarder le monitoring du service en question et vous poser les bonnes questions. Est-ce qu’il y a des logs inhabituels ? Des pics de CPU ou de RAM ? Vous pouvez aussi repartir du schéma d’infrastructure et suivre le parcours d’une requête qui n’aboutit pas. Si vous avez mis en place de l’APM ou du tracing cela vous facilitera grandement la tâche. L’objectif n°1 c’est de trouver quelle partie de l’infra pose problème et pourquoi.

Chaque incident est unique et la solution universelle n’existe pas. Il faudra donc parfois faire preuve d’un peu de créativité et d’un bon esprit de déduction. Ce n’est pas non plus le moment de s’embêter avec des procédures complexes, ce qu’on cherche pour l’instant c’est un quick fix. La solution pérenne peut attendre. Attention quand même à ne pas trop se précipiter et à empirer le problème.

Gardez l’historique de vos actions afin d’avoir un post-mortem le plus détaillé possible, qui comme nous le verrons juste après, est essentiel dans la gestion d’incidents.

Après plusieurs heures d’investigation vous trouvez enfin le problème, l’alerte repasse au vert et vous pouvez retourner profiter de votre week-end.

Apprentissage et amélioration continue

Chaque incident est source d’apprentissage et il est important de capitaliser dessus pour améliorer votre infrastructure mais aussi vos process et vous-même.

Faire l’analyse post-mortem

En quelques mots, l’objectif c’est de creuser les causes du problème pour pouvoir prendre des actions qui empêcheront l’incident de se reproduire. Le faire systématiquement vous permettra d’améliorer la fiabilité de vos services et de réduire le nombre d’incident au fur et à mesure. Il aidera aussi à vous améliorer et à être encore plus efficace la prochaine fois qu’un incident similaire surviendra.

Parfois il n’est pas évident de trouver les causes ou alors les actions sont complexes et nécessitent du temps avant d’être implémenté, c’est dans ce cas qu’on écrit un runbook. Il vous permet de documenter un problème connu et de pouvoir le diagnostiquer plus rapidement la prochaine fois. C’est l’occasion aussi de mettre à jour les runbooks déjà écrit.

Appliquer la méthode SRE

On va pouvoir aussi en tirer des actions sur une échelle de temps plus longue. Si la fréquence des incidents sur votre infrastructure a augmenté sur les dernières semaines ou sur les derniers mois, c’est peut-être aussi l’occasion de motiver des changements au niveau de votre équipe ou des équipes dont vous dépendez.

En vous armant de SLA et SLO clairs et en surveillant vos SLI, vous allez pouvoir argumenter quantitativement qu’une de vos dépendances n’a pas un processus de qualité suffisant ou alors pouvoir justifier auprès de la gouvernance de votre projet un ralentissement des déploiements pour se concentrer sur la qualité.

D’un point de vue purement Ops, cela va pouvoir aussi vous aider à défendre qu’il faut dédier du temps et des moyens pour mettre en place plus de redondance et une infrastructure plus résiliante.

Pour conclure…

Restez calme, soyez méthodique, et tirez des leçons de chaque incident pour évoluer constamment.

Maintenir des infrastructures cloud complexes nécessite une préparation minutieuse et une réaction rapide et coordonnée. Si vous souhaitez ne plus vous en soucier, c’est par ici.