Tu sembles beaucoup apprécier la métaphore médicale pour parler de ton métier. L’image est accrocheuse, mais une machine est une matière morte. Elle n’a rien de vivant.
Tu vas voir que parfois, c’est à se le demander, toutes proportions gardées évidemment.
Pour moi, les warnings sont les symptômes. Avec mon expérience, je peux savoir s’ils sont anodins ou très graves. S’ils annoncent une catastrophe ou s’ils sont un simple incident de parcours. Les indicateurs me font identifier la nature du problème, et par exemple un warning nocturne seul ne m’inquiétera pas. C’est sa réitération, ou un certain nombre d’alertes simultanées de différents types qui vont amener à ma réaction proportionnée, calme ou urgente.
Par exemple, si ce warning indique que le CPU chauffe et qu’un autre montre une surcharge, je sais qu’il existe une activité inattendue qui brûle beaucoup de puissance machine indûment. Si cela se produit sur plusieurs serveurs qui n’ont rien à voir les uns avec les autres, je diagnostique qu’une attaque de hackers est en cours, de type déni de service par exemple, et qu’on est là dans l’extrême urgence. Les capteurs du serveur sont réglés pour ne pas réagir à l’activité normale d’une machine, avec une certaine tolérance. Mais dès que cette activité devient vraiment inattendue, alors l’administrateur système interprète la manière dont le tableau de bord représente les réactions de la machine et son job est de comprendre la nature de la panne, et de réagir de manière proportionnée au mieux.
Effectivement, le job d'administrateur système est moins contemplatif que je ne le croyais, du coup…
Heureusement, ce n’est pas tous les jours l’apocalypse. Certaines alertes vont me signaler que notre client a lancé un export sur ses données comptables sur les dix dernières années avant de partir le soir, ce que je vais constater à la charge processeur et avec une petite vérification. Idem pour les grosses campagnes de com de la part des e-commerçants : là, je ne vais pas lever le petit doigt mais surveiller du coin de l’œil que le serveur en question ne chauffe pas trop. Mais on considérera ces activités comme parfaitement normales.
Donc finalement, tu ne lis pas les données : tu les interprète et en guéris les causes profondes de la « maladie » … C’est cela, ta métaphore du « vivant » ?
Ce n’est qu’un début de métaphore. Mon métier réel, celui qu’on ne voit pas, consiste en beaucoup d’interprétations et de détections. C’est avant tout un boulot d’enquête. Ainsi, plusieurs alertes de charge, à la même heure, sur des serveurs totalement distincts d’habitude calmes, posent immédiatement question. Sans monitoring ni expérience, nous n’aurions même pas fait attention et n’aurions pas limité un processus d’attaque dans les meilleurs délais en stoppant drastiquement la casse.
Mais plus loin, en effet, les serveurs ont un comportement proche de celui du vivant ! Quand un serveur est en train de mourir, c’est une mort définitive. Pas une fausse, mais une « vraie » mort. On ne peut pas la simuler pour la guérir, on ne peut pas la « rejouer » plusieurs fois pour optimiser les processus. Ainsi, ne pas intervenir sur un serveur qui meurt, c’est mettre en péril parfois tout un système d’information par effet dominos, système qui va être contaminé par l’élément « malade ».
Un disque va alors se remplir de manière imprévue, qui va répercuter sa charge de données sur l’ensemble de la plateforme et tout va s’écrouler pièce après pièce. Ou alors un serveur proche va se retirer du jeu pour se protéger d’une surcharge provoquée par la mort de son collègue, au détriment de la continuité de service évidemment, et tous les autres serveurs vont récupérer la charge résiduelle, ce qui va provoquer au fur et à mesure chaque serveur à se protéger en se retirant jusqu’à une panne générale. Or, ces comportements peuvent parfois être difficiles à anticiper.
Effectivement, je ne voyais pas du tout le métier d’administrateur système comme ça… ni d’ailleurs le fait qu’un « cluster » de machines pouvait être comparé à un organisme vivant !
Eh oui ! D’ailleurs, en tant qu’administrateur système chez un hébergeur, si une telle panne arrivait et que je n’y faisais rien, la pauvre mort d’un serveur pourrait à la limite entraîner un grand nombre de sites à être « down » alors qu’ils n’ont rien demandé et qu’ils sont fonctionnels à 100 % !
La notion de « vivant » provient du fait que les serveurs se comportent un peu à la manière des organes d’un même corps. Certes ils sont indépendants les uns des autres. Mais chacun est dans une harmonie forte, tous sont liés, comme une fourmi avec sa fourmilière. Il existe une logique globale du système. Or, il est impossible d’agir bille en tête sur une machine ou une application sans prendre en considération tout ce qui se passe autour. Ainsi, si une machine monte dans les tours, des informations vont signifier qu’elle dysfonctionne, ou qu’elle sort de la norme de l’harmonie globale du système. On a là un symptôme. Je peux faire baisser la machine dans ses tours très facilement, mais je n’aurai strictement rien résolu. Or, mon métier étant la continuité de service, c’est un peu assurer l’immortalité du tout… Si je touche à un élément, j’impacte la « vie » de tout le système autour. Cela rend la tâche encore plus difficile, mais rajoute beaucoup de piment au quotidien !
L’immortalité… ? Cela est-il vraiment possible ?
En extrêmement humble, presque ! De ce fait, pour arriver à mes fins de continuité de service et de stabilité, mon but va être d’interpréter tous les symptômes pour aller au cœur du problème. Par expérience, je vais par exemple comprendre que mon serveur vieillit et que si je ne le change pas avant sa mort, il va entraîner tout le système dans une défaillance chaotique malvenue. Ou je vais comprendre qu’une attaque est en cours. Ou encore que du code est mal structuré, qui se comporte de manière inattendue… Mon diagnostic va me permettre de rassembler toutes les informations pour comprendre l’exacte cause du dysfonctionnement et d’y remédier. Comme un chirurgien, où j’opère un serveur à disque dur ouvert…
Lire ou relire : Administrateur système : « je suis un genre de médecin… » – Partie 3
