Close

Gestion des incidents pour les équipes haute vélocité

Manuel de gestion des incidents Atlassian

Les équipes responsables de services techniques devraient être disponibles 24h/24 et 7j/7.

En cas de problème (panne ou bug de fonctionnalité), les membres de l'équipe doivent réagir immédiatement et restaurer le service. Ce processus, appelé gestion des incidents, est un défi permanent et complexe pour les entreprises de toute taille.

Nous voulons aider les équipes partout dans le monde à améliorer leur gestion des incidents. Inspirés par des équipes comme celle de Google, nous avons créé ce manuel pour résumer le processus de gestion des incidents d'Atlassian. Ce sont les leçons que nous avons tirées en répondant aux incidents depuis plus d'une décennie. Bien qu'il repose sur nos expériences uniques, nous espérons qu'il pourra être adapté aux besoins de votre propre équipe.

Manuel de gestion des incidents

Obtenir le manuel en version imprimée ou au format PDF

Nous disposons d'un nombre limité de versions imprimées du manuel de gestion des incidents que nous fournissons gratuitement. Vous pouvez également télécharger la version PDF.

Nous voulons aider les équipes partout dans le monde à améliorer leur gestion des incidents. Inspirés par des équipes comme celle de Google, nous avons créé ce manuel pour résumer le processus de gestion des incidents d'Atlassian. Ce sont les leçons que nous avons tirées en répondant aux incidents depuis plus d'une décennie. Bien qu'il repose sur nos expériences uniques, nous espérons qu'il pourra être adapté aux besoins de votre propre équipe.


À qui est destiné ce guide ?

Si vous faites partie d'une équipe de développement ou opérationnelle responsable des services Internet pour des clients nécessitant une disponibilité 24h/24 et 7j/7, ce manuel est fait pour vous.


Qu'est-ce qu'un incident ?

Nous définissons un incident comme un événement ayant provoqué une perturbation ou une réduction de la qualité d'un service nécessitant une réponse d'urgence. À la place, les équipes qui adoptent les pratiques ITIL ou ITSM préfèrent le terme « incident majeur ».

Un incident est résolu lorsque le service affecté fonctionne de nouveau de manière habituelle. Cela inclut uniquement les tâches requises pour restaurer toutes les fonctionnalités.

Le post-mortem de l'incident est réalisé après l'incident pour en déterminer la cause profonde et mettre en œuvre des mesures pour la corriger avant qu'elle ne provoque un nouvel incident.


Nos valeurs en matière d'incidents

Un processus de gestion des incidents ne saurait couvrir toutes les situations possibles, c'est pourquoi nous fournissons à nos équipes des conseils généraux sous forme de valeurs. À l'instar des valeurs d'entreprise d'Atlassian, nos valeurs en matière d'incident sont conçues pour :

  • guider une prise de décisions autonome par les personnes et les équipes responsables des incidents et des post-mortems ;
  • développer une culture d'identification, de gestion et d'apprentissage des incidents cohérente entre les équipes ;
  • aligner les équipes quant à l'attitude qu'elles doivent adopter aux étapes d'identification, de résolution et d'analyse des incidents.
Étape Valeur relative aux incidents Valeur liée à Atlassian Justification
1. Détection Atlassian sait avant ses clients

Build with Heart and Balance

Un service équilibré inclut suffisamment de surveillance et d'alertes pour détecter les incidents avant nos clients.

Une surveillance de pointe nous prévient des problèmes avant même qu'ils ne deviennent des incidents.

2. Réaction Faites remonter, faites remonter, faites remonter

Miser sur l'esprit d'équipe

Personne n'aime être réveillé en pleine nuit, et nous ne prenons pas cette responsabilité à la légère. Mais les gens comprennent que, de temps en temps, ils seront réveillés pour un incident où il s'avère qu'ils ne sont même pas nécessaires. Mais le plus dur, c'est de devoir se réveiller pour un incident majeur et être contraint de rattraper le temps perdu alors que vous auriez dû être alerté plus tôt.

Nous n'avons pas toujours toutes les réponses, donc « n'hésitez pas à faire remonter ».

3. Reprise Quand c'est la cata, la solution doit être rapide Ne !@#$ les clients

Nos clients ne veulent pas savoir pourquoi leur service ne fonctionne pas, tout ce qu'ils souhaitent c'est que nous le restaurions aussi vite que possible.

N'hésitez jamais à résoudre un incident au plus vite pour réduire son impact sur nos clients.

4. Apprentissage Toujours sans reproche Open Company, No Bullshit Les incidents font partie de l'exécution de services. Nous améliorons nos services en responsabilisant nos équipes, pas en rejetant la faute.
5. Amélioration Évitez la répétition du même incident Incarner le changement visé

Identifiez la cause profonde et les changements qui empêcheront cette classe entière d'incidents de se reproduire.

Engagez-vous à apporter des changements spécifiques à des dates précises.


Exigences relatives aux outils

Le processus de gestion des incidents décrit ici utilise plusieurs outils spécifiques à Atlassian et pouvant être remplacés selon les besoins :

  • Suivi des incidents : chaque incident est suivi comme un ticket Jira, et un ticket de suivi est créé pour suivre l'achèvement des post-mortems (Atlassian utilisait une version fortement personnalisée de Jira Software pour cela).
  • Groupe de discussion : un canal de communication écrite en temps réel est fondamental pour diagnostiquer et résoudre l'incident en équipe.
  • Tchat vidéo : pour de nombreux incidents, un tchat vidéo d'équipe comme Blue Jeans peut vous aider à discuter et à vous mettre d'accord sur les approches.
  • Système d'alertes : un outil comme OpsGenie gère les rotations d'astreinte et les remontées.
  • Outil de documentation : nous utilisons Confluence pour nos documents d'état d'incident et pour le partage de post-mortems via des blogs.
  • Statuspage : communiquer l'état aux parties prenantes internes et aux clients via Statuspage permet de tenir en permanence tout le monde au courant.

Suivi des incidents

Chaque incident est suivi comme un ticket Jira, et un ticket de suivi est créé pour suivre l'achèvement des post-mortems. Le processus de ce manuel fait référence à notre version fortement personnalisée de Jira Software.

Les tickets d'incidents sont généralement créés par un ingénieur de support en réponse à un ticket client ou par un développeur reconnaissant une alerte de surveillance comme un incident. Nous exhortons toute personne à créer un ticket si quelque chose la préoccupe au lieu d'attendre que le problème potentiel ne s'aggrave.

Dans Jira, nous disposons d'un workflow simple pour suivre les incidents au cours de la phase de résolution et pour enregistrer toutes les actions importantes prises pendant la réponse à l'incident.


Responsable des incidents

Chaque incident est géré par un gestionnaire d'incident qui est globalement garant et dispose de toute autorité pour l'incident. Cette personne est indiquée par le responsable sur le ticket de l'incident. Le gestionnaire d'incident est habilité à prendre toutes les mesures nécessaires pour résoudre l'incident, ce qui implique notamment de contacter toute personne de l'organisation et de veiller à ce que les personnes impliquées dans un incident restent concentrées sur une restauration aussi rapide que possible du service.

Le responsable de l'incident est un rôle, plutôt qu'une personne spécifique. Définir des rôles lors d'un incident s'avère bénéfique, car cela rend les personnes interchangeables. Tant qu'une personne donnée sait jouer un certain rôle, elle peut jouer ce rôle pour tout incident.


Vous avez des idées ou des suggestions pour ce guide ?