Les NetOps prennent note de l'accent mis par le SRE sur le MTTR pour garantir la disponibilité
L'ingénieur en fiabilité du site (SRE) est un rôle relativement nouveau – généralement au sein de l'ingénierie ou des opérations – axé sur le maintien, sans surprise, de la fiabilité du site. Cela signifie généralement la disponibilité des applications, mais cela inclut également les performances. Cela a du sens, car les applications qui ne répondent pas sont aujourd’hui considérées comme indisponibles par la plupart des utilisateurs finaux.
En parcourant le rapport SRE 2018 de Catchpoint , j'ai été frappé par des graphiques comparant les indicateurs de niveau de service et les mesures SRE. Généralement, lorsque vous voyez la « disponibilité » comme indicateur de niveau de service de niveau supérieur, vous voyez également le « temps de disponibilité » ou le « temps d’arrêt » comme mesure. Ce n’est pas le cas pour les SRE dans cette enquête.
Lorsqu'on leur a demandé quels indicateurs de niveau de service étaient les plus importants pour leurs services, 84 % ont déclaré sans ambages que « la disponibilité de l'utilisateur final » était la première. La latence arrive en deuxième position avec 61 % et le taux d'erreur arrive en troisième position avec 60 %. Les performances, décrites comme le temps de réponse de l'utilisateur final dans le rapport, ont recueilli un impressionnant pourcentage de 58 % des réponses.
Notez maintenant les mesures utilisées pour définir le succès. Dans le monde des infrastructures et des opérations, nous sommes plus habitués à voir des indicateurs tels que « temps de disponibilité » et des expressions accrocheuses telles que « 5 9 ».
Les SRE ont plutôt tendance à considérer le succès en termes de taux d’incidents et de MTTR. Étant donné que le même rapport indique que 41 % des SRE occupaient un poste d’« ingénieur DevOps » avant de devenir SRE, cela ne devrait pas être surprenant. DevOps lui-même est plus préoccupé par le MTTR que par le calcul du temps de disponibilité, car il suppose qu'il y aura des temps d'arrêt . La clé est de le minimiser en le résolvant rapidement plutôt que de perdre du temps à essayer de l’éviter complètement.
Cependant, les lecteurs astucieux remarqueront qu’en minimisant le MTTR, vous minimisez les temps d’arrêt. Résolution plus rapide, moins de temps d’arrêt.
La différence subtile entre les deux est que les êtres humains ont tendance à optimiser ce sur quoi ils sont mesurés. Si vous êtes évalué en termes de lignes de code, vous allez écrire beaucoup de lignes de code, que vous en ayez besoin ou non. Si vous êtes mesuré en fonction des incidents de sécurité, vous allez tout verrouiller et crier NON à tout changement qui pourrait encourager une violation. Si vous mesurez les gens en fonction du temps de disponibilité, les opérations se concentreront sur le maintien des systèmes opérationnels et disponibles, mais pas sur l'architecture et l'instrumentation des systèmes et des applications qui réduisent le MTTR.
Il s’agit de l’un de ces aspects « culturels » de DevOps – un changement dans la façon dont nous abordons les opérations – qui doit être transféré à NetOps. Si nous continuons à optimiser la disponibilité, nous manquons l’opportunité de mettre en place l’alerte et l’observabilité (comme la surveillance et la journalisation robuste) qui réduisent le temps moyen de résolution et atteignent notre objectif de minimiser les temps d’arrêt.
Fouiller dans les journaux – même centralisés – n’est pas un moyen efficace d’atteindre le cœur d’un problème et de le résoudre. La surveillance et les alertes en temps réel sur les variables clés qui ont un impact sur la disponibilité, telles que la capacité, la connectivité et les performances sur l'ensemble du chemin de données (réseau, infrastructure, application), réduiront invariablement le temps nécessaire pour résoudre les problèmes si vous avez connaissance de systèmes ou de services qui se dégradent ou qui ont échoué brusquement.
NetOps doit adopter cette approche en matière de fiabilité dans le pipeline de production, car il s'agit d'une meilleure approche globale pour gérer les échecs inévitables et elle s'aligne sur ses homologues DevOps. Après tout, il y a une raison pour laquelle nous n'avons atteint que 5 9, n'est-ce pas ? Parce que nous reconnaissons que l’échec survient , quels que soient nos efforts, et que la perfection est impossible.
Passer du temps de disponibilité/temps d'arrêt au MTTR comme mesure de réussite encourage la collaboration entre les équipes et l'utilisation d'outils d'observabilité sur toute la longueur du pipeline de production. Il y a une raison pour laquelle les outils de surveillance et d'alerte figuraient en tête des « outils indispensables » pour les SRE dans l'enquête. L'observabilité (avec pour objectif d'alerter en cas d'erreur/incident) et la collaboration constituent une meilleure formule pour garantir que tout le monde (NetOps, DevOps et App Dev également) puisse atteindre son objectif de maintenir les applications à la fois rapides et disponibles.