Un workflow efficace de gestion des incidents dépend d’outils accessibles et intégrés ainsi que de canaux de communication clairs et directs. Et même après une résolution de problème, la documentation et l’analyse post-mortem sont essentielles. Marc Weisman – VP of Product, Datadog, partage de bonnes pratiques visant à éviter que des mêmes incidents ne se reproduisent. Autrement dit, comment en tirer des leçons afin d’être plus résilient à l’avenir ?
Marc Weisman – VP of Product, Datadog
Un logiciel financier bloqué ou une banque en ligne indisponible sont certes fâcheux pour les employés et les clients, mais chaque minute d’interruption coûtera à la banque beaucoup d’argent. Si les pannes sont inévitables dans notre monde moderne, au développement d’applications toujours plus rapide, leur anticipation demande du temps et des ressources pour éviter une intervention inefficace et désorganisée qui ne ferait qu’aggraver la situation.
A lire aussi : Volkswagen, Audi et McDonald’s pris dans la tourmente des fuites de données
« Apprendre de ses erreurs » s’applique aussi à l’informatique. Chaque incident est l’occasion de s’améliorer. C’est pourquoi des bonnes pratiques et des workflows de gestion d’incident éprouvés accélèrent chaque résolution de problème, réduisent le temps moyen de leur résolution, et permettent d’en tirer de nouveaux enseignements. Par conséquent, un processus de gestion des incidents efficace de bout en bout renforce la résilience globale de l’infrastructure de l’entreprise.
Ne pas tomber dans la simplicité
Sans vouloir enfoncer des portes ouvertes, de bonnes données et de bons outils sont essentiels pour traiter les incidents : des métriques aux logs (historiques des événements) en passant par les traces des applications, sans oublier les outils de communication (chat, messagerie et vidéo). L’essence d’un bon processus de gestion des incidents est de structurer les différentes mesures et options ainsi que les données relatives à l’incident. Toutefois, ce processus est inutile si les responsabilités en matière d’alerte, de collaboration et de documentation des incidents ne sont pas clairement définies.
Il est compréhensible que la gestion des incidents s’apparente à un grand bazar si elle n’est considérée que lorsque les problèmes surviennent. Leurs processus se doivent d’être définis et établis en amont, lorsque les systèmes fonctionnent bien et que l’on dispose du temps et de la tranquillité d’esprit nécessaires à la planification et à l’organisation qui en découlent. En effet, même lorsque tout est opérationnel, les processus complexes et l’expertise nécessaires à la définition d’un workflow de résolution ne sont pas une promenade de santé. Qui est responsable de la gestion des réponses aux incidents ? Quels autres rôles et responsabilités doivent être attribués dans l’équipe ? Quelles informations sont nécessaires, où et quand ? D’où viennent les données et comment les rendre universellement accessibles ? Comment l’incident sera-t-il documenté pour s’y référer ultérieurement ? Comment cette documentation sera-t-elle communiquée ? Tout cela doit être planifié et renseigné à l’avance. Mais si cela était facile, ce serait ennuyeux !
Miser sur les « post-mortems »
Un ensemble d’informations, un stockage et un flux de communication communs constituent la base d’une résolution collective de problèmes. À cette fin, les alertes, les graphiques et diagrammes associés, ainsi que les canaux de communication doivent être accessibles dans des outils collaboratifs, aujourd’hui qualifiés de multiplateformes. Pour une recherche efficace de la source du problème, les équipes doivent avoir aussi bien accès aux logs, qu’aux traces, au trafic réseau ou aux métadonnées de l’infrastructure, ainsi qu’à une liste chronologique des mises à jour relatives au problème et à sa solution. Chacun peut alors ajouter à cette chronologie des liens ou du texte pour fournir des commentaires, un contexte et d’autres informations utiles à tous, telles que des tableaux de bord des métriques pertinentes.
Outre les données sur l’infrastructure et ses performances, les liens vers les données métiers et les informations sur l’architecture des applications sont également importants: l’incident ne touche-t-il que certains groupes de clients, certains lieux ou certaines versions ? Comment évaluer l’impact en termes de nombre d’utilisateurs ou de transactions affectées ? Bien entendu, il n’est pas possible de planifier à l’avance la manière dont un incident sera traité. Si c’était le cas, il n’y aurait pas besoin de workflow, juste d’un kit de premiers secours. Une fois le problème résolu, il s’agit maintenant de s’assurer qu’il ne se reproduise pas à l’identique ou, si c’est le cas, de l’identifier pour le résoudre plus rapidement. La documentation et ce que l’on appelle communément les “post-mortems”, documents dans lesquels les données collectées sont documentées et stockées, sont essentiels à la gestion anticipée des incidents. Si un nouvel incident est en corrélation avec un incident antérieur, les problèmes ou parties des problèmes peuvent être identifiés plus rapidement.
Une liste des tâches à suivre pour résoudre les problèmes sérieux, une planification de la mise à jour des alertes et un document post-mortem détaillé accessible à toute l’équipe impliquée sont déterminants pour que chacun comprenne le problème survenu et son impact, et puisse à l’avenir plus rapidement identifier des problèmes similaires. Cette documentation se doit également d’être centralisée et les points de données y afférant se doivent d’y être incorporés. Les post-mortems permettent également d’éliminer durablement les causes des problèmes dans le cadre d’une version de logiciel et de vérifier ensuite l’efficacité de ce changement.
Il est donc possible de réagir aux incidents de manière plus efficace et plus durable sans avoir à jouer au pompier de service. Une fois établie, une gestion collaborative des incidents laisse place à l’innovation, car elle profite à la stabilité du système dans son ensemble, ce qui crée une véritable liberté d’action.