Tous les quelques mois, un service majeur tombe en panne d'une façon qui entraîne une bonne part d'internet avec lui, et la cause s'avère être quelque chose dans la couche que tout le monde pensait abstraite.
L'abstraction masque la couche, elle ne la supprime pas
Le récit qu'on raconte sur l'infrastructure ces quinze dernières années est qu'elle a disparu dans le cloud. Les serveurs sont devenus des instances, puis des conteneurs, puis des fonctions. Les réseaux sont devenus de la configuration. Le stockage est devenu une interface.
Chacune de ces évolutions est réelle et utile, et aucune n'a rien supprimé. Le paquet doit toujours atteindre une destination. Le nom doit toujours se résoudre. Le certificat doit toujours être valide et à jour. Le disque doit toujours avoir de la capacité. L'horloge doit toujours s'accorder avec les autres horloges.
Ce qui a changé, c'est qui remarque quand l'un de ces éléments tombe en panne, et à quel point c'est difficile à voir.
L'abstraction éloigne la panne de la personne qui la subit, ce qui rend la faille plus difficile à trouver et la personne capable de la trouver plus précieuse.
C'est l'argument de fond de cette direction. Pas la nostalgie des serveurs qu'on installait en baie, mais le constat que le nombre de personnes capables de raisonner sur ce qui se passe réellement en dessous a chuté plus vite que le besoin de ces personnes.
Ce que couvre la direction
Le périmètre : systèmes d'exploitation, matériel, réseaux, serveurs, administration et dépannage.
Quatre domaines.
Réseau. Adressage, routage, résolution de noms, répartition de charge, pare-feu, et le chemin réellement emprunté par une requête.
Systèmes d'exploitation. Processus, permissions, systèmes de fichiers, services et journaux, sur les plateformes que l'organisation exploite.
Identité et annuaires. Authentification, autorisation, certificats et les systèmes qui les délivrent.
Exploitation. Supervision, sauvegarde et restauration, capacité, correctifs et dépannage structuré.
C'est toujours le DNS, et pourquoi cette blague est vraie
La blague récurrente chez les ingénieurs infrastructure pointe vers quelque chose de réel sur la façon dont les systèmes tombent en panne.
La résolution de noms sous-tend presque tout, est invisible quand elle fonctionne, et produit des symptômes qui ressemblent à des problèmes tout autres. Une application paraît lente quand la résolution expire. Un service paraît indisponible quand un enregistrement pointe vers une adresse retirée du service. Un changement se propage de façon inégale à cause de la mise en cache à plusieurs niveaux, si bien que le système est cassé pour certains utilisateurs et fonctionne pour d'autres, le schéma de panne le plus difficile à diagnostiquer.
Trois autres membres de la même famille causent une part similaire des incidents, pour la même raison.
Les certificats. Ils expirent. À une date connue des années à l'avance. De grandes organisations ont subi des pannes majeures exactement pour cette raison, à plusieurs reprises, parce que le renouvellement était manuel et que la personne qui le savait est partie.
Le temps. La dérive d'horloge casse les protocoles d'authentification, invalide les vérifications de certificat, corrompt la corrélation des journaux, et fait se comporter les systèmes distribués de façon incohérente. Elle se présente comme un problème d'authentification, si bien qu'on enquête sur l'authentification.
Le routage et le chemin. Routes asymétriques, changements de chemin, règles de pare-feu ajoutées pour un but et en affectant un autre. Les symptômes apparaissent de façon intermittente et seulement pour certaines sources.
Ce qui les réunit, c'est que chacun est une infrastructure dont tout le monde dépend et que personne ne possède, et chacun produit des symptômes à une couche très éloignée de la cause. Les ingénieurs qui savent vérifier ces points en premier résolvent en quelques minutes ce qui prend autrement une journée.
Où cela se situe dans le domaine
Systèmes informatiques et réseaux est la septième des huit directions du domaine IA, données et informatique d'Astra Trainer, et elle fonctionne comme une filière d'approvisionnement pour le reste. Le cloud computing et DevOps, la cybersécurité et le platform engineering recrutent tous ici, et reposent tous sur la compréhension que construit cette direction.
Elle se connecte le plus directement à l'informatique fondamentale pour le modèle des systèmes d'exploitation et des réseaux, et à la cybersécurité, où la capacité à raisonner sur ce qu'un système fait réellement est le fondement de la détection et de la réponse. Vous pouvez découvrir les huit directions ici.
Le dépannage est une méthode, pas un talent
La compétence la plus transférable et la moins enseignée de cette direction. On la traite comme quelque chose qu'on a ou qu'on n'a pas, alors que c'est une procédure.
Établir ce qui a réellement changé. Les systèmes qui fonctionnaient hier et échouent aujourd'hui ont généralement changé, même quand tout le monde dit que rien n'a changé. Déploiements, renouvellements de certificats, mises à jour de règles, identifiants expirés, un disque qui franchit un seuil.
Définir le périmètre précisément. Tous les utilisateurs ou certains. Tous les sites ou un seul. Tout le temps ou par intermittence. Chaque réponse élimine des catégories entières de causes, et c'est le manque de précision ici qui fait dériver les investigations.
Travailler le long du chemin. Une requête traverse une séquence connue de composants. Testez à des points le long de ce chemin et déterminez où le comportement cesse de correspondre à l'attendu. Cela transforme un problème ouvert en une recherche à réponse finie.
Changer une chose à la fois. Changer plusieurs choses et constater que ça marche laisse ignorer pourquoi, ce qui empêche de prévenir le problème et de le résoudre la prochaine fois.
Lire correctement les journaux. Pas la dernière erreur, souvent un effet en aval, mais la première anomalie et la séquence qui l'entoure, avec les horodatages corrélés entre systèmes.
Savoir quand restaurer plutôt que diagnostiquer. Pendant une panne, restaurer le service et enquêter après coup est souvent la bonne approche. Confondre la restauration avec la cause racine, c'est ainsi que le même incident se reproduit.
Enseignée explicitement, cette méthode rend des ingénieurs ordinaires considérablement plus efficaces. Laissée implicite, elle se développe sur des années, ou jamais.
Le vrai problème de carrière de cette direction
Cela mérite d'être dit clairement, car c'est la vraie contrainte, et elle n'est pas technique.
Le travail d'infrastructure est traité comme un coût indirect. Il apparaît dans les budgets comme une dépense, se mesure par l'absence de problèmes, et se remarque presque exclusivement quand quelque chose échoue. Le développement construit des choses qu'on annonce. L'infrastructure fait tourner les choses, ce qui ne produit aucune annonce.
Quatre conséquences en découlent.
La rémunération et le statut sont en retrait par rapport à des postes voisins de difficulté comparable ou moindre, ce qui pousse les personnes compétentes hors de la discipline.
L'investissement arrive après les incidents puis retombe, si bien que la capacité se construit de façon réactive.
L'externalisation a supprimé le terrain de formation. Les postes juniors où se construisait la compréhension de l'infrastructure ont, dans de nombreuses organisations, été externalisés, le même blocage de pipeline que décrit dans la direction cybersécurité.
La connaissance n'est ni documentée ni transmissible. Quels systèmes comptent, à quoi ressemble la normale, où se trouve la dépendance étrange. Elle part avec la personne, et le remplaçant la reconstruit lentement et à grands frais.
Une organisation qui souhaite des capacités cloud, sécurité et plateforme devrait reconnaître qu'elle sous-investit actuellement dans la population où ces disciplines recrutent, et que c'est une décision qu'elle peut inverser à peu de frais.
Les postes, nommés
Administrateurs systèmes, sur les principales plateformes.
Ingénieurs et architectes réseau.
Ingénieurs infrastructure.
Spécialistes identité et annuaires.
Ingénieurs stockage et sauvegarde, dont l'importance devient évidente exactement une fois.
Spécialistes virtualisation.
Ingénieurs poste de travail et terminaux.
Service desk et support technique, le point d'entrée le plus courant vers tout le domaine.
Techniciens data center, une population de nouveau en croissance avec l'expansion des capacités de calcul.
Qui peut être formé pour cela
Personnel de service desk et de support. La voie classique, et toujours la meilleure. Ils voient déjà tout le parc, savent ce qui casse, et ont un instinct de dépannage qu'une formation structurée transforme en méthode.
Techniciens télécoms. Vers le réseau, avec déjà la couche physique et transmission.
Personnel militaire des transmissions et systèmes d'information. Fréquemment excellent, arrivant à la fois avec la compétence technique et la discipline opérationnelle.
Électriciens et techniciens des systèmes du bâtiment. Vers le data center et l'infrastructure physique.
Quiconque a administré des systèmes de façon informelle, dans une petite entreprise ou comme la personne à qui les autres demandent de l'aide. Une vraie capacité sans reconnaissance formelle.
Développeurs. Vers l'infrastructure et la plateforme, avec besoin de la moitié opérationnelle qu'ils n'ont jamais eue.
Reconversions depuis des postes opérationnels en logistique, production ou services publics, où la discipline de process et le travail posté se transfèrent directement.
Accès, gestion du changement et obligations de continuité. L'accès administratif aux systèmes de production est un poste à haut privilège encadré par la gestion du changement, la journalisation et la séparation des tâches, et dans les secteurs réglementés par des référentiels de contrôle spécifiques. La capacité de sauvegarde et de restauration est soumise à des obligations légales et contractuelles dans de nombreux secteurs, et des sauvegardes non testées ont régulièrement échoué au moment d'en avoir besoin. Astra Trainer développe la compétence technique et la conscience de ces obligations. Cela ne confère aucune autorisation d'accès à un système et ne remplace pas les exigences de contrôle organisationnel.
Ce qu'il faut retenir
Les abstractions du cloud ont placé l'infrastructure derrière une interface sans la supprimer, ce qui a rendu les pannes plus difficiles à localiser et les personnes capables de les localiser plus précieuses.
La résolution de noms, les certificats, le temps et le routage causent une part disproportionnée des pannes parce qu'ils sont invisibles jusqu'à l'échec et produisent des symptômes loin de leur cause.
Le dépannage est une méthode enseignable plutôt qu'un talent, et l'enseigner explicitement est l'une des interventions techniques au meilleur retour disponible.
La vraie contrainte ici est le statut et le pipeline plutôt que la demande, et l'externalisation a supprimé les postes juniors où cette compréhension se construisait.
Et chaque équipe cloud, DevOps et sécurité recrute dans cette population. Sous-investir ici, c'est sous-investir dans toutes les autres.
Le cloud a-t-il rendu les compétences infrastructure obsolètes ?
Non. Il a placé l'infrastructure derrière une interface. Réseaux, systèmes d'exploitation, résolution de noms et stockage existent toujours et tombent toujours en panne, et l'abstraction éloigne la panne du symptôme, ce qui rend le diagnostic plus difficile.
Pourquoi le DNS, les certificats et le temps causent-ils tant de pannes ?
Parce que tout en dépend, que personne ne les possède, qu'ils sont invisibles quand ils fonctionnent, et que leurs pannes produisent des symptômes à une couche totalement différente. L'expiration des certificats en particulier a causé des pannes majeures répétées à des dates connues des années à l'avance.
Le dépannage peut-il s'enseigner ?
Oui. Établir ce qui a changé, définir le périmètre précisément, tester le long du chemin de la requête, changer une chose à la fois, lire les journaux depuis la première anomalie plutôt que la dernière erreur, et distinguer restaurer le service de trouver la cause racine.
Pourquoi l'infrastructure est-elle sous-valorisée ?
Parce qu'elle se mesure par l'absence de problèmes et n'est remarquée que pendant les pannes, ce qui la fait apparaître comme un coût dans les budgets. La rémunération et le statut sont en retrait sur des postes voisins, l'investissement arrive de façon réactive après les incidents, et l'externalisation a supprimé les postes juniors qui construisaient la compétence.
Qui se convertit bien vers les postes infrastructure ?
Le personnel de service desk et de support en premier, puis les techniciens télécoms vers le réseau, le personnel militaire des transmissions, les électriciens vers le data center, les administrateurs informels, et les développeurs ayant besoin de la moitié opérationnelle.