Modification du cadre
Parmi toutes les unités de ce module, c’est certainement l’une des plus importantes. Dans cette leçon, nous allons considérer quelques idées susceptibles de changer la façon dont s’organise notre compréhension de ce qu’il est important de surveiller et pourquoi. Pour certaines personnes, cela peut radicalement changer la façon dont elles approchent la surveillance pour améliorer leur fiabilité.
Mise au point #1 : Fiabilité du point de vue du client
Nous avons abordé précédemment les aspects de la fiabilité que nous pouvons envisager de surveiller, mais cela semblait n’avoir fait que développer l’ensemble d’éléments que nous pouvons surveiller. Voici une idée qui peut vous aider à vous concentrer sur ce que vous devez surveiller pour améliorer votre fiabilité :
La fiabilité doit être mesurée du point de vue du client, pas de celui du composant.
C’est très important. Vous souhaiterez peut-être lire cela à nouveau, car c’est ce qui est important. Par le passé, les gens plaidaient pour « tout superviser ! » À partir du moment où nous pouvions lire un élément à partir d’un compteur, l’exprimer en statistique ou l’ajouter dans un tableau de bord, nous pensions qu’il fallait le superviser. « Mesurer du point de vue du client » est une approche bien plus spécifique.
Examinons un bref scénario qui illustre ce point et le renforce.
Scénario
Vous êtes responsable de l’exécution du site web e-commerce de votre entreprise. Vous avez une batterie de serveurs web avec 100 instances de serveur. Soudainement, 14 de ces 100 instances cessent de fonctionner en raison d’une défaillance du système d’exploitation, d’une mise à jour logicielle, d’une fluctuation de la fourniture d’électricité ou d’un autre événement inattendu. Ces 14 instances sont désormais complètement hors service.
Récapitulatif : 86 instances de serveur sont opérationnelles, 14 ne sont pas opérationnelles.
Laquelle des propositions suivantes est vraie dans cette situation ?
A : Ce n’est pas très grave. Vous pouvez régler le problème lorsque vous aurez le temps de le résoudre.
B : C’est un problème sérieux. Vous devez arrêter tout ce que vous faites et remettre les 14 instances de serveur en service dès que possible.
C : Il s’agit d’une crise existentiel pour l’entreprise. Vous devez informer les dirigeants et demander à tout le monde de travailler sur la situation aussi rapidement que possible, même si vous devez réveiller toute votre équipe au beau milieu de la nuit.
Prenez un moment pour réfléchir soigneusement à ce scénario avant de répondre, puis continuez à lire. Pensez-vous qu’il s’agit de la réponse A, B ou C ?
La réponse correcte n’est ni A, ni B, ni C. En fait, c’est « Ça dépend » ou plus précisément « Cela dépend de la façon dont vos clients subissent cette panne. »
Si vous avez conçu le site de manière à ce qu’aucun client n’ait encore remarqué les défaillances et que les 86 autres instances de serveur supportent la charge sans problème, il n’y a pas de crise ici. Il peut s’agir d’un incident de gravité 3 ou 4, voire d’un simple ticket de support.
Si la panne paralyse l’ensemble de votre activité et que vous perdez des sommes importantes chaque minute que ces serveurs passent en panne, c’est probablement une bonne raison d’appuyer sur le gros bouton rouge et de rassembler tout le monde. Il peut également s’agir d’une situation intermédiaire pour laquelle la réponse est « B ».
Encore une fois, la fiabilité doit être mesurée du point de vue du client, et non du point de vue du composant. C’est la raison pour laquelle le nombre « 14 machines en panne sur 100 », bien qu’exact, n’était pas l’élément d’information le plus important dans ce scénario, du point de vue de la fiabilité.
Cette idée est vraie même lorsque nous parlons d’une surveillance plus traditionnelle basée sur les composants. Si vous constatez que le serveur de base de données s’exécute à 50 % de la charge de l’UC, est-ce une bonne ou une mauvaise chose ? Si la valeur monte à 90%, est-ce mieux ou pire ? Si le service fonctionne normalement et que les utilisateurs sont heureux, 90 % peut être une bonne évaluation, car cela signifie que nous avons considérablement amélioré notre utilisation des ressources. Mais si les utilisateurs se plaignent de la lenteur de l’exécution de votre application à 50 % de la charge de l’UC, il est peu probable que 90 % constitue une amélioration.
Mise au point #2 : Niveaux de fiabilité appropriés
Pour définir correctement cette idée, nous devons nous pencher rapidement sur son origine. Cette idée provient de l’ingénierie de fiabilité de site (SRE). Nous pouvons extraire plusieurs idées utiles (y compris dans cette section) simplement en examinant attentivement la définition de l’ingénierie de fiabilité de site :
Remarque
L’ingénierie de fiabilité de site est une discipline d’ingénierie ayant pour vocation d’aider une organisation à atteindre durablement le niveau de fiabilité approprié dans ses systèmes, produits et services.
Il y a trois mots importants dans cette définition :
Fiabilité : Nous avons accordé une grande importance à la fiabilité dans l’unité d’introduction : nous n’y reviendrons donc pas ici.
Durablement : Dans ce contexte, « durablement » fait référence au rôle des personnes dans tout cela. Il est essentiel de mettre en place des pratiques opérationnelles durables. Les systèmes, les services et les produits fiables sont tous créés par des personnes. Si nous n’agissons pas dans une optique de travail durable (par exemple, si nous appelons nos collaborateurs chaque nuit à trois heures, si nous ne leur accordons pas de temps de repos pour être avec leur famille ou si nous ne leur laissons pas la possibilité de prendre soin d’eux-mêmes), il n’y a aucune chance qu’ils puissent créer des systèmes fiables. L’ingénierie de fiabilité de site part du principe que la mise en place de pratiques opérationnelles durables est essentielle pour permettre aux employés d’être les plus performants possible dans leur travail.
Approprié : C’est le mot qui peut tout changer pour certaines personnes. Autrefois, dans le monde de l’exploitation, notre objectif était de garantir que tout était fonctionnel 24h sur 24, 7j sur 7. Nous voulions que tout reste opérationnel toute la journée, tous les jours, pendant toute la semaine, tout le mois et toute l’année. L’indisponibilité n’était jamais acceptable. Une des choses que l’ingénierie de fiabilité de site a introduites dans discussion est la notion que nous devrions viser un niveau de fiabilité approprié à la place.
Intéressons-nous à cette idée. Un point clé ici est qu’une fiabilité de 100 % n’est presque jamais le bon objectif. À certaines exceptions près, comme les appareils médicaux ou de l’aviation, nous n’avons pas vraiment besoin de 100 % de fiabilité et, en réalité, 100 % de fiabilité est souvent difficile à atteindre.
Voici un exemple de « même pas possible » : de nos jours, nous exécutons tous des systèmes avec des inter-dépendances. Vous exécutez peut-être un logiciel qui doit appeler un système de traitement des paiements ou d’authentification. Si le traitement des paiements n’est pas fiable à 100 % ou si le système d’authentification n’est pas fiable à 100 %, il peut être très difficile pour votre système d’être fiable à 100 %.
L’autre chose délicate avec un objectif de fiabilité de 100 % est que cela ne laisse pas de place à des temps d’arrêt. Cela signifie également qu’il n’est pas possible d’apporter des modifications qui pourraient éventuellement créer des temps d’arrêt. Vous n’avez pas de marge de manœuvre, alors que vous allez probablement en avoir besoin.
Il est utile de commencer à réfléchir aux choses sous un autre angle : « Quel est le niveau de fiabilité approprié ? » pour un élément particulier que vous essayez d’exploiter. Pour revenir au sujet, notre surveillance doit soutenir cet objectif.
Avec ces deux cadres à l’esprit, passons à la pratique et découvrons les outils qui nous aideront à atteindre nos objectifs.