La fragmentation des responsabilités a perturbé la communication au sein des équipes, rendant difficile pour les différents services d'avoir une vision globale d'une situation lors des phases de crise. Cela a non seulement réduit la qualité de la communication entre les équipes de développement, mais a également engendré un problème grave qui touche de nombreux acteurs opérationnels : la fatigue liée aux alertes. Cette fatigue ne se limite pas à l'insatisfaction des membres de l'équipe ; elle impacte également la capacité de la chaîne de livraison logicielle à se développer.

L'avantage de DevOps est qu'il supprime les barrières de communication et simplifie les opérations. Les équipes DevOps se déclinent en deux types : les équipes centralisées pour toutes les applications, plus grandes mais néanmoins plus petites que les environnements NOC traditionnels ; et les équipes décentralisées, qui regroupent une équipe très réduite pour chaque application ou service principal.

Ces équipes, en plus d'être responsables de la fourniture de l'infrastructure et parfois du processus de mise en production, ont la charge de maintenir la production opérationnelle, une tâche stressante, chronophage et pénalisante pour l'ensemble de l'environnement si elle n'est pas correctement menée. Personne ne souhaite être d'astreinte, mais nous le faisons, car nous savons qu'un délai moyen de résolution (MTTR) plus court et une réponse rapide aux problèmes simplifient grandement les journées et les semaines à venir pour tous, sans parler du maintien de la continuité de l'activité. Cependant, lorsque l'astreinte commence à impacter l'humeur d'une équipe et accapare la majeure partie du temps de l'équipe opérationnelle, elle représente un risque considérable.

Les configurations centralisées et décentralisées sont sujettes à la lassitude liée aux alertes, avec de légères variations dans chaque cas. Pour la configuration centralisée, la lassitude ne se limite pas au nombre d'alertes cumulées sur l'ensemble des applications ; il est également difficile de savoir qui est la personne compétente pour traiter le problème, car il est fort probable que ce ne soit pas la personne d'astreinte. Pour les configurations décentralisées, la lassitude liée aux alertes se traduit simplement par un volume élevé d'alertes pour une petite équipe.

L’impact de la fatigue des alertes sur les équipes DevOps et IT Ops est quadruple :

• • Moral bas : Si vous consacrez la majeure partie de votre temps à résoudre des problèmes, non seulement vous gérez des incidents jour et nuit, mais vous passez aussi votre temps à faire des choses moins intéressantes. Vous tombez dans le cercle vicieux de la simple extinction des incendies, ce qui peut nuire à la communication au sein de l'équipe et nuire à son efficacité.

• • Point de défaillance unique : Dans un scénario centralisé, le MTTR dépend de la rapidité avec laquelle un nombre très limité d'agents d'astreinte peuvent réagir à un problème et en identifier la cause profonde. Dans un scénario décentralisé, le temps d'identification de la cause profonde est plus long, mais la couverture est insuffisante pour trier les problèmes et les résoudre plus rapidement. De plus, la liste d'appels étant plus courte, le risque que le problème ne soit pas traité du tout est plus élevé. Tout cela crée un goulot d'étranglement et un point de défaillance unique pour tout problème survenant.

• • Coût d'opportunité: C'est l'impact le moins reconnu de la lassitude face aux alertes : le coût pour l'ensemble de l'équipe et de la chaîne de livraison. Lorsque votre équipe DevOps est débordée et épuisée par le processus d'alerte, elle est incapable d'innover et d'améliorer la chaîne de livraison. Étant uniquement capable de réagir, elle est incapable d'explorer de meilleures versions, de mettre en place des processus d'automatisation de l'infrastructure ou d'être proactive pour prévenir les problèmes futurs. Non seulement cela freine les améliorations, mais cela peut aussi aggraver la dette technique, car les problèmes récurrents ne sont jamais résolus par des correctifs à long terme.

• Cadence de libération plus lente : Plus il faut de temps pour résoudre les problèmes, plus l'impact sur la dynamique de sortie est important. Combien de fois votre équipe a-t-elle reporté une sortie ?

La réponse la plus simple pour gérer la fatigue des alertes est de développer l'équipe d'exploitation. Cependant, ce n'est pas nécessairement la meilleure option, car cette « solution » finit par contrecarrer les avantages d'avoir une équipe DevOps plus petite.

Il existe plusieurs autres options à prendre en compte pour lutter contre la fatigue liée aux alertes :

1. 1. Créer de meilleures politiques d’escalade : Planifiez. Ne vous contentez pas d'établir une liste de rappel pour votre équipe. Planifiez et réfléchissez à l'impact potentiel sur les ressources et le moral de votre équipe. Un peu de stratégie peut être très utile. Par exemple, une astuce simple consiste à fractionner les rotations.

1. 1. Mettez l'assurance qualité et les développeurs à disposition : Cette solution nécessite l'adhésion de toute l'équipe, ce qui peut s'avérer très difficile. Cependant, en intégrant les développeurs et les équipes d'assurance qualité à la rotation, vous bénéficiez d'une meilleure couverture et de délais de résolution plus rapides. Même en collaboration avec un membre de l'équipe opérationnelle, un soutien plus large peut améliorer la visibilité des problèmes de production, aider les développeurs à résoudre les problèmes liés aux applications et améliorer la compréhension afin de prévenir les problèmes futurs.

1. 1. Avoir des analyses détaillées des incidents : La visibilité sur l'efficacité de votre système d'alerte vous permet de l'améliorer au fil du temps et d'identifier vos points faibles actuels. Les données mettront également en évidence les problèmes récurrents. Laissez-vous guider par les données.

1. 1. Consacrez du temps à l’arrêt des problèmes récurrents : Consacrez du temps à identifier les problèmes résolus rapidement et à les corriger afin qu'ils ne se reproduisent pas. Le problème devra inévitablement être corrigé, tout comme chaque problème ultérieur. C'est une charge énorme pour l'équipe opérationnelle.

1. 1. Normaliser les règles de notification : Ne laissez pas les membres de l'équipe d'astreinte établir arbitrairement leurs propres règles. Standardisez ou modélisez les règles pour garantir la cohérence et la responsabilisation.

1. 1. Autoriser les alertes parallèles : Il existe un appel vertical, mais il peut également y avoir des alertes horizontales où plusieurs membres de l'équipe peuvent attaquer les problèmes ensemble pour un MTTR plus rapide.

1. 1. Tirez parti des outils : Les outils de gestion des incidents contribuent grandement à lutter contre la lassitude liée aux alertes. Une excellente solution de gestion des incidents, comme PagerDuty Automatisez les alertes et filtrez-les pour éviter d'être submergé par des alertes non critiques. Cela vous permet d'identifier précisément vos alertes et d'optimiser vos interventions d'astreinte. Ainsi, si un incident survient la nuit, vous savez qu'il y a un problème réel.

1. Écrivez un meilleur code : Consacrer du temps à la qualité réduit les pannes. C'est si simple, et pourtant la qualité est trop souvent négligée. Consacrez plus de temps à démontrer les avantages pour tous : un code de meilleure qualité, une meilleure couverture de tests, de meilleurs tests système et une meilleure automatisation des tests.

Tout cela s'inscrit dans une stratégie plus large d'optimisation des performances opérationnelles et profite à tous. La lassitude liée aux alertes est une réalité et elle impacte non seulement votre DevOps et ITOps le bonheur des équipes, mais aussi la capacité de toute l'équipe de développement à innover et à s'améliorer dans la publication du code.