La fragmentation des responsabilités a perturbé les communications au sein des équipes, ce qui a rendu difficile pour les différents services d'avoir une vision globale de la situation lors des combats. Cela a non seulement réduit la qualité de la communication entre les équipes de développement, mais a également créé un problème grave qui affecte de nombreux acteurs du côté des opérations : la fatigue liée aux alertes. La fatigue liée aux alertes n'est pas seulement un problème de mécontentement des membres de l'équipe : elle a un impact sur la capacité de la chaîne de distribution de logiciels à se développer.

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

Ces équipes, en plus d'être chargées de fournir l'infrastructure et parfois du processus de mise en production, ont la charge de maintenir la production en marche, ce qui est éprouvant, prend du temps et nuit à l'environnement tout entier si ce n'est pas fait correctement. Personne ne veut ê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 facilitent grandement les jours et les semaines à venir pour tout le monde, sans parler du fait que cela permet de maintenir l'activité. Cependant, lorsque l'astreinte commence à avoir un impact sur l'humeur d'une équipe et domine la majorité du temps de l'équipe d'exploitation, cela comporte un risque énorme.

Les configurations centralisées et décentralisées sont sujettes à la fatigue liée aux alertes, chacune avec une légère variation. Dans le cas de la configuration centralisée, il ne s'agit pas seulement de la fatigue liée au nombre d'alertes agrégées dans toutes les applications ; il est également difficile de savoir qui est la personne appropriée pour traiter le problème, car il y a de fortes chances que ce ne soit pas la personne de garde. Dans le cas des configurations décentralisées, la fatigue 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 passez la majorité de votre temps à résoudre des problèmes, non seulement vous faites face à des incidents jour et nuit, mais vous passez également votre temps à faire des choses moins intéressantes. Vous tombez dans le cycle qui consiste à simplement éteindre des incendies, ce qui peut nuire à la communication au sein de l'équipe et rendre difficile le maintien de l'efficacité.
• Point de défaillance unique: Dans un scénario centralisé, le MTTR dépend de la vitesse à laquelle un nombre très limité de personnes d'astreinte peuvent répondre à un problème et identifier la cause profonde. Dans un scénario décentralisé, le temps nécessaire pour identifier la cause profonde est plus long, mais la couverture n'est pas suffisante pour trier les problèmes et les résoudre plus rapidement. De plus, comme la liste d'appels est 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 qui survient.
• Coût d'opportunité: Il s’agit de l’impact le moins reconnu de la fatigue des 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. Comme elle ne peut que réagir, elle est incapable d’explorer de meilleures versions, des processus d’automatisation de l’infrastructure ou d’être proactive pour prévenir les problèmes futurs. Non seulement cela empêche l’amélioration, mais cela peut aussi aggraver la dette technique, car les problèmes qui se répètent fréquemment 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 à la gestion de 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 » contrecarre finalement les avantages d’avoir une équipe DevOps plus petite.

Il existe plusieurs autres options à prendre en compte pour lutter contre la fatigue des alertes :

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 que cela pourrait avoir 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 à diviser les rotations.
2. Mettez l'assurance qualité et les développeurs à disposition : Cette solution nécessite que toute l'équipe soit impliquée, ce qui peut s'avérer très difficile, mais si vous ajoutez des développeurs et des é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 si elle est en parallèle avec un membre de l'équipe d'exploitation, une assistance plus large peut améliorer la visibilité des problèmes de production pour aider les développeurs à résoudre les problèmes liés aux applications et peut accroître la compréhension pour éviter les problèmes à l'avenir.
3. Avoir des analyses détaillées des incidents : La visibilité sur l'efficacité de la configuration des alertes vous permet de l'améliorer au fil du temps et de voir où se trouvent vos goulots d'étranglement actuels. Les données mettront également en évidence les problèmes récurrents. Laissez-vous guider par les données.
4. Consacrez du temps à l’arrêt des problèmes récurrents : Consacrez du temps à identifier les problèmes qui ont été résolus rapidement et à les résoudre afin qu'ils ne se reproduisent pas à l'avenir. Le problème devra inévitablement être corrigé, tout comme chaque problème ultérieur. Cela représente une charge énorme pour l'équipe d'exploitation.
5. Standardiser 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.
6. Autoriser les alertes parallèles : Il existe un rappel 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.
7. Tirez parti des outils : Les outils de gestion des incidents aident grandement à lutter contre la fatigue des alertes. Une excellente solution de gestion des incidents, comme PagerDuty aide à automatiser les alertes et vous aide à trier le bruit des alertes, vous assurant ainsi de ne pas être submergé par des alertes non critiques. Cela vous aide à identifier vos alertes pour des opérations d'astreinte plus efficaces. Ensuite, si les choses tournent mal la nuit, vous savez qu'il y a un vrai problème.
8. É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. Passez plus de temps à présenter les avantages à tout le monde avec un code de meilleure qualité, une meilleure couverture de test, de meilleurs tests système et une meilleure automatisation des tests.

Tout cela fait partie d'une stratégie plus large visant à optimiser les performances opérationnelles et profite à tous. La fatigue des alertes est réelle et elle affecte 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.