Gestion des incidents pour les équipes haute vélocité
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.
Configuration d'un planning d'astreinte grâce à Opsgenie
Ce tutoriel vous apprendra à configurer un planning d'astreinte, à appliquer des règles de remplacement, à configurer les notifications d'astreinte, etc. Et tout cela, sans quitter Opsgenie.
Lire ce tutorielBonnes pratiques en matière de communication sur les incidents
La communication sur les incidents est le processus qui consiste à alerter les utilisateurs lorsqu'un service est touché par une panne ou des performances dégradées.
Lire cet article