Les équipes IT consacrent énormément d'efforts à éliminer les points de défaillance uniques (Single Point of Failure - SPOF).
Elles mettent en place des firewalls en haute disponibilité, des clusters de bases de données, plusieurs fournisseurs Internet, des alimentations redondantes et des plateformes virtualisées résilientes.
Pourtant, un SPOF bien plus critique passe souvent inaperçu.
Une personne.
Le composant le plus fragile de nombreuses infrastructures n'est pas un serveur.
C'est l'ingénieur qui est le seul à savoir comment tout fonctionne.
Votre infrastructure est redondante. Vos connaissances ne le sont peut-être pas.
Posez-vous une question simple :
Si votre ingénieur le plus expérimenté disparaissait pendant deux semaines, quels services deviendraient impossibles à maintenir ?
Pour beaucoup d'entreprises, la réponse est inconfortable.
Des systèmes critiques reposent sur des connaissances qui n'existent que dans la mémoire d'une seule personne.
Ces connaissances peuvent concerner :
- l'architecture des firewalls ;
- la configuration des VPN ;
- les dépendances d'une application historique ;
- les procédures de sauvegarde ;
- l'architecture DNS ;
- les scripts d'automatisation ;
- les règles de supervision ;
- les procédures de reprise après incident.
Aucun outil de monitoring ne détectera ce risque.
Pourtant, il est bien réel.
L'ingénieur est en vacances. La production est arrêtée.
Imaginez la situation.
Vendredi soir.
Votre ingénieur infrastructure part en congés pour deux semaines.
Lundi matin.
Une panne de stockage provoque l'arrêt de plusieurs applications critiques.
L'équipe découvre rapidement que :
- personne ne maîtrise réellement l'architecture du SAN ;
- la documentation est incomplète ou obsolète ;
- le script de restauration se trouve uniquement sur l'ordinateur portable de l'ingénieur absent ;
- personne ne comprend pourquoi la réplication a été configurée de cette manière.
La panne n'a pas été provoquée par la technologie.
Elle a été provoquée par l'absence des connaissances nécessaires.
Les vacances n'ont fait que révéler une faiblesse qui existait depuis longtemps.
Les silos de connaissances se créent naturellement
Dans la majorité des cas, les silos de connaissances ne sont pas le résultat d'une mauvaise volonté.
Ils apparaissent simplement parce que chacun développe progressivement son domaine d'expertise.
Au fil des années, une personne devient naturellement :
- l'expert firewall ;
- le spécialiste VMware ;
- l'administrateur Linux ;
- le responsable des sauvegardes ;
- le développeur des scripts d'automatisation.
Chaque incident renforce cette spécialisation.
Puis une phrase finit par revenir systématiquement :
« Demande à Jean, c'est lui qui connaît ce système. »
Cette phrase devrait immédiatement alerter une équipe d'exploitation.
Le piège de la culture du "héros"
Beaucoup d'entreprises valorisent leurs "héros".
Ces ingénieurs sont capables de :
- résoudre tous les incidents complexes ;
- mémoriser chaque configuration ;
- restaurer les systèmes les plus critiques ;
- répondre à toutes les questions techniques.
Leur expertise est précieuse.
Mais une infrastructure qui dépend d'eux est fragile.
La culture du héros entraîne souvent les conséquences suivantes :
| Pratique | Risque à long terme |
|---|---|
| Une seule personne résout tous les incidents | Les autres n'apprennent jamais |
| La documentation devient secondaire | Les connaissances restent implicites |
| Les correctifs sont appliqués dans l'urgence | La dette technique augmente |
| Les systèmes deviennent "la propriété" d'un ingénieur | La résilience de l'équipe diminue |
Un excellent ingénieur ne devrait jamais être indispensable.
Son objectif devrait être de rendre toute son équipe plus compétente.
Documenter n'est pas une perte de temps
Certaines équipes considèrent encore la documentation comme une tâche administrative.
En réalité, c'est une mesure de sécurité opérationnelle.
Une bonne documentation permet à un autre ingénieur de :
- comprendre rapidement une architecture ;
- reproduire une configuration ;
- restaurer un service ;
- réaliser une maintenance sans risque ;
- résoudre un incident de manière cohérente.
On ne documente pas uniquement pour aujourd'hui.
On documente pour le jour où la personne qui connaît le système ne sera plus disponible.
Le partage des connaissances renforce la résilience
Les équipes d'exploitation les plus performantes cherchent volontairement à répartir les connaissances.
Elles mettent en place des pratiques comme :
- la rotation des astreintes ;
- les revues de changements entre pairs ;
- les maintenances réalisées à deux ;
- les ateliers techniques internes ;
- les sessions régulières de transfert de connaissances ;
- le travail en binôme sur les projets critiques.
L'objectif n'est pas que tout le monde devienne expert.
L'objectif est qu'aucun système critique ne dépende d'une seule personne.
Comment identifier vos SPOF humains ?
Posez ces questions à votre équipe :
- Qui est le seul capable de restaurer ce service ?
- Une autre personne pourrait-elle réaliser cette maintenance ?
- La documentation est-elle à jour ?
- Les procédures de reprise ont-elles déjà été exécutées par quelqu'un d'autre ?
- Les scripts d'automatisation sont-ils stockés dans un dépôt centralisé ?
- Les accès critiques sont-ils partagés de manière sécurisée ?
- Quelqu'un d'autre a-t-il déjà administré ce système récemment ?
Si toutes les réponses désignent la même personne, vous avez identifié un silo de connaissances.
Construire une équipe plus résiliente
Réduire les silos de connaissances ne signifie pas recruter davantage.
Il s'agit avant tout de mieux organiser la circulation de l'information.
Quelques bonnes pratiques :
- maintenir une documentation vivante ;
- versionner les procédures d'exploitation (Runbooks) ;
- documenter les décisions d'architecture ;
- formaliser les procédures de reprise ;
- organiser régulièrement des transferts de compétences ;
- favoriser le travail en binôme sur les projets critiques ;
- mettre à jour la documentation après chaque incident majeur.
Les connaissances doivent faire partie intégrante de l'infrastructure.
Elles ne doivent jamais dépendre exclusivement d'un individu.
Un serveur se remplace. L'expérience beaucoup moins.
Le matériel peut être remplacé.
Les machines virtuelles peuvent être recréées.
Les configurations peuvent souvent être restaurées.
Mais plusieurs années d'expérience opérationnelle disparaissent immédiatement lorsqu'un ingénieur quitte l'entreprise sans transmettre son savoir.
Remplacer un équipement prend quelques heures.
Reconstruire cette expertise peut demander plusieurs mois, voire plusieurs années.
Beaucoup d'organisations ne découvrent cette réalité qu'après le départ d'un collaborateur clé.
Conclusion
La haute disponibilité ne se construit pas uniquement avec des équipements redondants.
Elle se construit également avec des connaissances redondantes.
Les équipes d'exploitation les plus performantes ne sont pas celles qui possèdent un ingénieur indispensable.
Ce sont celles où plusieurs personnes sont capables de comprendre, administrer, maintenir et restaurer les systèmes critiques.
Car si votre infrastructure dépend d'une seule personne...
Elle n'est pas réellement résiliente.