Close

La voie vers une meilleure gestion des incidents
débute ici

Gestion des incidents à l'ère de DevOps

Appliquez les principes d'une communication ouverte et sans reproches aux équipes de gestion des incidents

Vous ne pouvez pas repenser la façon dont vous développez, déployez et utilisez des logiciels sans repenser votre réponse aux incidents.

Dans leur discussion phare de 2009, « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr » (Plus de 10 déploiements par jour : la coopération entre les équipes de développement et opérationnelles chez Flickr), John Allspaw et Paul Hammond ont esquissé une vision d'un monde dans lequel les développeurs et les équipes informatiques opérationnelles collaborent et livrent régulièrement. Au cours de la décennie qui a suivi, cette vision s'est concrétisée en tant que mouvement DevOps.

Par nature, DevOps s'appuie sur de nouvelles méthodes de réponse aux incidents. Ce n'est pas surprenant que la gestion des incidents ait reçu autant d'attention dans le discours de John Allspaw et Paul Hammond.

Paul Hammond explique : « Il est important de comprendre que des échecs vont se produire. La question n'est pas de savoir s'ils surviendront, mais quand. »

Contrairement aux frameworks comme ITIL, il n'existe pas de document dit officiel reprenant les bonnes pratiques pour une équipe DevOps. Mais nous pouvons généralement convenir que, au fond, DevOps vise à apporter une valeur business à une organisation en éliminant les silos organisationnels, en augmentant la transparence et en favorisant une communication ouverte entre les développeurs et les équipes des opérations informatiques.

Cette même culture de la transparence, de la visibilité et de l'apprentissage rapide s'étend à la gestion des incidents.

Pourquoi ? Parce que les premières étapes de la gestion des incidents (qui sont aussi les plus critiques) consistent à comprendre ce qui a posé problème, à charger les bonnes personnes de résoudre le problème et à favoriser une culture sans reproches.

La gestion des incidents DevOps requiert une culture de communication ouverte et sans reproches entre les développeurs et les équipes informatiques opérationnelles. Elle nécessite également d'établir des processus légers qui améliorent la fiabilité des services informatiques, augmentent la satisfaction client et accroissent la valeur métier. Un ingénieur DevOps peut aider à implémenter la culture et les pratiques DevOps.

En comparaison, ITIL est un ensemble prescrit de 26 processus, procédures, tâches et checklists conçus pour améliorer des pratiques spécifiques dans la gestion des services informatiques. Le framework se concentre sur la qualité et la cohérence des services et sur la création de systèmes plus résilients.

L'un des avantages d'ITIL ? Les organisations qui souhaitent améliorer l'ITSM peuvent s'appuyer sur des bonnes pratiques sous forme de modèle au lieu de partir de zéro. Bien que certaines personnes pensent qu'ITIL est plus adapté aux grandes entreprises, le framework est si flexible que les petites entreprises peuvent choisir les processus qui leur sont utiles et y trouver de la valeur.

ITIL a cependant un inconvénient : si vous êtes pressé de modifier votre processus de réponse aux incidents, le framework peut impliquer une gestion formelle des changements et un consultant expert, ce qui retarde les améliorations.

Pour les équipes qui souhaitent se lancer immédiatement, l'approche DevOps de gestion des incidents les aidera à se rassembler et à profiter immédiatement des avantages.

Processus de gestion des incidents DevOps

L'approche DevOps de gestion des incidents ne diffère pas radicalement des étapes traditionnelles d'une gestion efficace des incidents. La gestion des incidents DevOps met explicitement l'accent sur la participation des équipes de développement dès le début (y compris les équipes d'astreinte) et sur l'assignation du travail en fonction de l'expertise, et non des intitulés de poste.

1. Détection
Au lieu d'espérer qu'aucun incident n'arrive (car ils arriveront sans aucun doute), les équipes de réponse aux incidents DevOps accordent une grande importance à la préparation. Elles travaillent en collaboration pour planifier leurs réponses en cas d'incidents en identifiant les faiblesses des systèmes. Elles mettent en place des outils de surveillance, des systèmes d'alerte et des runbooks qui aident chaque membre à savoir qui contacter lorsqu'un incident est détecté et quoi faire ensuite.

2. Réponse
Plutôt que d'avoir un seul ingénieur d'astreinte responsable de la réponse à tous les incidents dans une équipe d'astreinte, les équipes de gestion des incidents DevOps désignent plusieurs de leurs membres à contacter lors des remontées. Si l'ingénieur d'astreinte désigné ne peut pas résoudre un incident seul, il peut se servir d'un runbook comme guide. Il peut faire appel aux bonnes personnes pour évaluer l'impact et le niveau de gravité du problème et le faire remonter aux bons intervenants.

3. Résolution
Lorsque le moment est venu de répondre à un incident, les équipes de gestion des incidents DevOps parviennent souvent à une résolution rapidement. En effet, à l'échelle globale, elles connaissent mieux le code de l'app ou du système, car elles l'ont rédigé. Grâce à une préparation avancée et à de bons systèmes de communication, elles peuvent résoudre ensemble l'incident, et ce, plus rapidement qu'une équipe de réponse tierce découvrant le code.

4. Analyse
Les équipes de gestion des incidents DevOps clôturent un incident grâce à un processus de post-mortem sans reproches. Elles se réunissent pour partager des informations, des métriques et des enseignements dans le but d'améliorer continuellement la résilience de leurs systèmes et de résoudre rapidement et efficacement les incidents futurs.

5. Préparation
Une fois qu'un incident est résolu, que toutes les étapes de remédiation sont terminées et que le système est restauré, les équipes de gestion des incidents DevOps prennent du recul pour évaluer leur préparation au prochain incident. À l'aide des enseignements tirés de leur processus de post-mortem, elles actualisent leurs runbooks et font les ajustements nécessaires pour surveiller les outils et les systèmes d'alerte. Dans l'univers DevOps, l'accent mis sur l'amélioration continue s'applique au personnel et à l'équipe, et pas seulement à la technologie. Après un incident, chaque membre de l'équipe est mieux préparé pour le prochain.

Bonnes pratiques pour des équipes DevOps de gestion des incidents efficaces

L'adoption d'une approche DevOps pour la réponse aux incidents peut conduire à une meilleure communication entre les équipes de développement et informatiques opérationnelles, à une réponse aux incidents et à une remédiation plus rapides, ainsi qu'à un système plus résilient.

Automatisez les processus et les workflows
Intégrez vos outils de centre de services, de surveillance, de tickets, de CMDB/de gestion des actifs et de chat pour simplifier les alertes d'incidents informatiques et les workflows afin de garantir que les bonnes personnes reçoivent les informations nécessaires pour démarrer une résolution. Configurez des runbooks grâce à des workflows prédéfinis afin que les utilisateurs puissent se mettre rapidement au travail en cas d'incident.

Communiquez entre les équipes
Assurez-vous que les membres de vos équipes peuvent communiquer au sein de l'organisation grâce à des outils de chat en temps réel. Utilisez des outils qui créent un enregistrement de l'incident afin que tout le monde puisse se lancer à tout moment et se tenir informé de ce qui s'est passé et de ce qui doit être fait.

Utilisez l'approche sans reproches
Une fois que vous avez résolu l'incident, rassemblez-vous en équipe pour examiner ce qui s'est passé lors d'une session de post-mortem sans reproches. Évitez de pointer du doigt et concentrez-vous sur le partage d'informations qui aident chacun à mieux faire son travail et qui contribuent à créer un système plus fiable.

Identifiez la valeur métier et concentrez-vous sur celle-ci
La réponse aux incidents DevOps est plus qu'un moyen pour améliorer la communication. En effet, c'est un moyen d'assurer la collaboration entre les équipes de développement et opérationnelles pour offrir une réelle valeur métier. Suivez les métriques telles que le temps moyen de détection (MTTD), le temps moyen jusqu'à la réparation (MTTR) et le temps moyen entre pannes (MTBF) pour comprendre la vitesse d'amélioration de votre équipe.

Utilisez la planification des astreintes pour positionner les développeurs et les administrateurs système en tant que SRE
Dans les équipes DevOps, la frontière entre développeur et administrateur système commence à s'estomper, et les personnes qui répondent à l'incident se transforment souvent en ingénieurs chargés de la fiabilité du site (SRE). Néanmoins, les membres de l'équipe auront probablement des connaissances spécialisées soit dans le code applicatif, soit dans le code infrastructurel. Configurez votre planning d'astreinte pour vous assurer que vous disposez des bons experts pour répondre aux incidents.

suivant
SRE