Quand votre seul administrateur système part, sécurisez d’abord les accès, obtenez ensuite un audit écrit de l’environnement, puis choisissez qui l’opère. Les quatre choix réalistes sont une embauche de remplacement, un contractuel, un fournisseur d’opérations infogérées qui opère l’environnement en place, ou une migration vers quelque chose de plus simple. Dans la plupart des cas, de nouvelles personnes peuvent quand même opérer ou migrer un environnement non documenté, à condition que l’entreprise puisse récupérer l’accès administratif.
Un administrateur système est la personne qui monte et opère les serveurs, les comptes cloud, les sauvegardes et la supervision. Le risque lié à une personne clé est l’exposition que porte une entreprise quand une seule personne détient un savoir ou des accès que personne d’autre n’a. Un runbook est une procédure écrite pour une défaillance connue ou une tâche de routine. Cet article s’adresse à un dirigeant ou à un responsable de l’ingénierie qui a maintenant la charge d’un environnement de production qu’il n’a pas bâti.
Que faire la première semaine après le départ de votre seul administrateur système ?
La première semaine après le départ d’un administrateur système sert à reprendre le contrôle et à sécuriser l’environnement, et rien de cela n’exige de comprendre comment il fonctionne. Trois décisions passent en premier, dans cet ordre.
- Confirmez que l’entreprise contrôle chaque compte. Dressez la liste du registraire de domaines, du fournisseur du système de noms de domaine (DNS), du compte d’hébergement ou de cloud, des connexions aux serveurs, des sauvegardes et de la supervision. Chaque compte devrait appartenir à une identité de l’entreprise, et au moins deux personnes en poste devraient pouvoir s’y connecter. Renouvelez les identifiants que détenait la personne partie, comme le veut toute procédure normale de départ, quelles qu’en soient les circonstances.
- Suspendez les changements non essentiels. Reportez les mises à niveau, le ménage et les réductions de coûts jusqu’à ce que quelqu’un ait un portrait écrit de ce qui dépend de quoi. Un correctif de sécurité urgent fait exception, et il devrait être appliqué par une personne capable aussi d’effectuer le retour arrière.
- Nommez qui répond aux alertes de production. Décidez qui est joignable si le site ou l’application tombe cette nuit, et ce que cette personne a le droit de faire.
Si l’administrateur système est encore en période de préavis, consacrez ce temps à la passation : une visite guidée enregistrée, une liste de chaque compte et de chaque tâche planifiée, et les parties fragiles connues. Pour la troisième décision, la base de connaissances explique comment mettre en place une rotation de garde pour une équipe qui n’en a jamais eu.
Pourquoi obtenir un audit écrit avant que quiconque change l’environnement ?
Un audit écrit précède tout changement parce qu’un environnement non documenté cache des dépendances qui ne se révèlent qu’au moment où quelque chose est déplacé ou retiré. Un audit désigne ici une lecture écrite de ce qui tourne, de l’endroit où cela tourne, de ce qui dépend de quoi et de l’endroit où se trouve le risque. C’est un document, et sa production ne devrait rien changer en production.
Un audit utile d’un environnement hérité répond à ces questions :
- Quels serveurs, services, bases de données et tâches planifiées existent, et à quoi sert chacun ?
- Qui et quoi détient un accès, et lesquels de ces comptes ne sont plus nécessaires ?
- Des sauvegardes existent-elles, où sont-elles conservées, et une restauration a-t-elle déjà été testée ?
- Quel est le retard des correctifs du système d’exploitation et des logiciels ?
- Qu’est-ce qui est supervisé, qui reçoit les alertes, et quelles alertes sont du bruit ?
- Quels risques passent en premier, et la recommandation est-elle de documenter, de stabiliser ou de migrer ?
Les petits détails non documentés comptent. Dans un scénario type, une application Web vieille de dix ans est passée à une plateforme infogérée, et un réglage local non documenté, laissé dans un fichier du serveur, a causé un accroc pendant la bascule. La bascule est le moment où le trafic passe au nouvel environnement.
Pour aller plus loin sur le plan technique, la base de connaissances traite de la détection de la dérive de configuration, c’est-à-dire des changements faits en production que personne n’a déclarés. Elle décrit aussi l’audit de reprise d’un serveur cPanel. cPanel est un panneau de contrôle d’hébergement répandu.
Qui peut reprendre vos serveurs après le départ d’un administrateur système ? Quatre options comparées
Quatre types de successeurs peuvent opérer un environnement hérité, et ils diffèrent par la couverture, la continuité et le risque que chacun laisse derrière lui.
| Option | Ce qu’elle vous apporte | Choisissez-la quand | Évitez-la quand | Risque principal |
|---|---|---|---|---|
| Embauche de remplacement | La connaissance du produit et un responsable présent le jour | Le poste représentait un emploi à temps plein fait de travail régulier | Vous attendez d’une seule personne qu’elle couvre chaque nuit | La même dépendance à une personne clé, reconstruite |
| Contractuel ou pigiste | Une expertise rapide et délimitée | Le travail est un audit, de la documentation ou une réparation définie | Vous avez besoin d’une couverture continue ou de continuité | Le savoir repart à la fin du contrat |
| Fournisseur d’opérations infogérées, en place | Une équipe, un périmètre écrit et une fenêtre de couverture définie | Le manque se situe dans la couverture, la continuité et la routine, et l’architecture est saine | L’empreinte est minuscule, ou le vrai problème vient de défauts applicatifs | Un périmètre qui s’arrête avant ce que vous aviez supposé |
| Migration vers quelque chose de plus simple | Un environnement documenté sur une plateforme prise en charge | L’installation actuelle est fragile, n’est plus prise en charge ou est bien plus complexe que la charge ne l’exige | Personne n’a encore audité l’environnement | Des surprises le jour de la bascule |
Les quatre options se combinent, par exemple un audit écrit suivi d’une couverture intérimaire pendant le recrutement.
Quand faut-il embaucher un administrateur système de remplacement ?
Embauchez un administrateur système de remplacement quand la personne partie occupait un emploi à temps plein fait de travail d’infrastructure régulier, ou quand l’infrastructure est le produit que vous vendez. Un collègue apprend l’application d’une façon qu’une partie externe atteint rarement.
Deux conditions font réussir l’embauche la deuxième fois. La documentation fait partie de la description de poste. La couverture hors des heures de travail se décide séparément, parce qu’une seule personne ne peut pas porter les alertes de production chaque nuit et pendant toutes les vacances.
Le recrutement prend du temps, et un contractuel ou un fournisseur peut assurer l’intérim. Un contractuel convient aussi à un travail délimité comme l’audit lui-même. Un pigiste seul reste toutefois une seule personne, et les livrables devraient donc être des documents qui appartiennent à l’entreprise. Si un successeur compétent est déjà embauché, un projet ponctuel d’audit et de documentation est peut-être toute l’aide externe dont vous avez besoin. L’article sur le choix entre embaucher un ingénieur DevOps et impartir les opérations compare les deux voies selon la couverture, la continuité et les coûts. DevOps est la contraction de développement et d’opérations.
Quand un fournisseur d’opérations infogérées devrait-il opérer l’environnement en place ?
Un fournisseur d’opérations infogérées convient quand le manque se situe dans la couverture, la continuité et la routine d’exploitation, et que le travail ne remplit pas un poste à temps plein. Les opérations infogérées signifient qu’un fournisseur opère la couche infrastructure selon un périmètre écrit : supervision, correctifs, sauvegardes et réponse aux incidents. Le contrat qui énonce les engagements du fournisseur est un accord de niveau de service (SLA).
Opérer l’environnement en place signifie que le fournisseur l’opère là où il se trouve aujourd’hui. Votre compte d’hébergement ou de cloud reste le vôtre, et aucune migration n’est nécessaire pour commencer. Demandez à tout fournisseur de confirmer ces conditions :
- Le mandat commence par un audit, et rien ne change en production avant la remise de l’audit.
- Le fournisseur travaille au moyen d’accès que vous accordez et que vous pouvez révoquer, jamais au moyen des anciens identifiants de la personne partie.
- Le périmètre nomme la fenêtre de couverture : heures ouvrables, heures étendues ou 24/7.
- Les runbooks et un diagramme d’architecture sont des livrables que vous conservez si le contrat prend fin.
- Le périmètre dit où il s’arrête. Les défauts de votre code applicatif restent normalement à vos développeurs.
Sur Amazon Web Services (AWS), un fournisseur peut opérer un compte AWS existant au moyen d’un rôle d’accès dédié, et les identifiants racine restent à l’entreprise. L’article sur qui peut gérer l’infrastructure AWS de votre entreprise décrit cette passation, et la base de connaissances énumère les signes qu’un environnement AWS a dépassé son équipe.
Un fournisseur d’opérations infogérées est le mauvais choix dans trois situations :
- Toute l’empreinte tient dans un serveur et un compartiment de stockage, de sorte qu’un contrat serait démesuré.
- Deux ingénieurs ou plus sont encore responsables de l’exploitation et s’en acquittent bien, de sorte que la solution est la documentation.
- La plupart des incidents viennent de défauts applicatifs, qui demandent du temps d’ingénierie et non un nouvel opérateur.
Quand la migration vers quelque chose de plus simple est-elle la bonne décision ?
La migration est la bonne décision quand l’audit montre que l’installation actuelle est le problème. Les raisons typiques sont des logiciels qui ne reçoivent plus de mises à jour de sécurité, un serveur unique sans voie de reprise, ou une conception bien plus complexe que la charge ne l’exige.
La migration est un mauvais premier geste. Déplacer un environnement que personne ne comprend transporte les inconnues jusqu’au jour de la bascule, quand le trafic passe au nouvel environnement. L’audit passe en premier, et il conclut parfois qu’aucun déplacement n’est nécessaire.
Dans un scénario type, une entreprise de logiciels en techno juridique d’environ 35 personnes dépendait d’un seul administrateur système et d’un développeur pour son savoir de production, et rien n’était écrit. L’audit a conclu que l’architecture « convenait à la charge » et n’a proposé aucune reconstruction. L’entreprise est restée sur AWS, et dix runbooks ont été rédigés pendant les quatre premières semaines de ce mandat.
Quels facteurs déterminent le coût de chaque option ?
Les quatre options n’ont pas les mêmes facteurs de coût. Comparez-les donc sur la même période et pour les mêmes heures de couverture.
- Embauche de remplacement. Le salaire et les avantages sociaux, l’effort de recrutement, la période d’intégration dans un environnement non documenté, l’outillage, et le coût du poste vacant tant qu’il reste vide.
- Contractuel. Le travail contractuel est habituellement facturé au temps. La découverte d’un environnement non documenté est difficile à estimer. Demandez donc un prix fixe pour l’audit et un devis distinct pour toute réparation.
- Fournisseur d’opérations infogérées. Le nombre et la classe des environnements, la complexité de l’architecture, la fenêtre de couverture, les cibles de réponse du SLA, le nombre d’actifs supervisés, et tout travail de stabilisation que l’audit met en évidence.
- Migration. Le nombre de sites ou de charges, la taille des données, la complexité des dépendances, la tolérance à l’indisponibilité pendant la bascule, les besoins de résidence des données, et la durée de la fenêtre de soutien après le lancement.
Le coût de l’attente se mesure aussi. Dressez la liste des tâches que seule la personne partie pouvait accomplir. Estimez ensuite ce que coûte une journée de panne en commandes perdues, en pénalités contractuelles et en temps du personnel. L’article sur la façon dont l’hébergement cloud infogéré est tarifé explique les structures de prix courantes.
Comment réduire le risque lié à une personne clé dans une infrastructure de production ?
Le risque lié à une personne clé dans une infrastructure de production diminue quand le savoir et les accès sont partagés et consignés par écrit, peu importe qui opère l’environnement. Cinq mesures font l’essentiel du travail :
- Chaque compte appartient à l’entreprise, et au moins deux personnes ou parties détiennent un accès fonctionnel.
- Un diagramme d’architecture à jour montre où tourne chaque élément et ce qui dépend de quoi.
- Des runbooks existent pour les défaillances courantes et les tâches de routine, et ils sont mis à jour après chaque incident.
- Les restaurations sont testées selon un calendrier, et le résultat est consigné.
- La documentation est un livrable nommé dans la description de poste ou dans le contrat du fournisseur.
La base de connaissances montre comment rédiger une entrée de runbook pour une alerte récurrente.
Que faut-il décider dans les 30 premiers jours ? Une liste de vérification
Répondez par écrit à ces sept questions pendant les 30 premiers jours qui suivent le départ.
- L’entreprise contrôle-t-elle chaque compte, et les identifiants de la personne partie ont-ils été renouvelés ?
- Qui répond à une alerte de production cette nuit, et que peut faire cette personne ?
- Qui rédigera l’audit, et pour quelle date ?
- Une sauvegarde a-t-elle été restaurée avec succès depuis le départ ?
- Le poste représentait-il un emploi à temps plein fait de travail régulier, ou quelques heures par semaine et des urgences ?
- À quels moments vos clients sont-ils actifs, et quelles heures faut-il couvrir ?
- Peu importe qui opérera l’environnement, quels documents appartiendront à l’entreprise à la fin ?
Un travail régulier à temps plein oriente vers une embauche de remplacement, avec la documentation dans la description de poste. Une couverture mince et une architecture saine orientent vers un fournisseur qui opère l’environnement en place. Une plateforme fragile ou qui n’est plus prise en charge oriente vers une migration planifiée après l’audit.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) canadien pour les environnements de production, dont le siège est à Montréal. L’entreprise sert des PME et des agences d’environ 5 à 200 personnes qui opèrent des systèmes de production sans avoir leur propre équipe d’opérations 24/7. Sa clientèle comprend des entreprises de logiciel-service (SaaS), des agences et des éditeurs.
La page des solutions de Stack Harbor indique que « La majorité des engagements sont des reprises », et la première phase est une évaluation de ce que vous opérez et de l’endroit où se trouve le risque. Stack Harbor rédige cette évaluation dans le cadre de la consultation initiale, et son site précise : « Vous repartez avec l’évaluation, que vous nous engagiez ou non. »
L’exploitation continue est vendue sous le nom Opérations Cloud, une offre qui se déroule en quatre phases : auditer, stabiliser, opérer et améliorer. Stack Harbor opère des environnements sur AWS, Azure, Google Cloud, OVH, DigitalOcean, des serveurs dédiés et cPanel/WHM. L’entreprise opère aussi sa propre infrastructure canadienne, dans deux centres de données à Montréal. Elle n’exige aucune migration. Ce qu’elle peut faire dépend des accès que vous accordez, de la joignabilité réseau et de l’état de l’environnement.
Pour un compte AWS existant, l’offre Opérations AWS passe par un rôle dédié dans AWS Identity and Access Management (IAM), le service de gestion des identités et des accès d’AWS, et le compte racine reste chez le client. Quand l’audit oriente vers un déplacement, les Services de migration commencent par la découverte, un petit mandat de cadrage payant qui produit un plan de migration écrit et un devis fixe. À la question de savoir si Stack Harbor peut migrer un hébergement après le départ de la personne qui l’a monté, la page de migration répond : « C’est le point de départ le plus fréquent. »
La couverture du service Gestion, supervision et soutien est cadrée en heures ouvrables, en heures étendues ou en 24/7. Une rotation de garde formée exécute des runbooks conçus par des ingénieurs seniors, et les ingénieurs seniors sont responsables des incidents de gravité 1 (Sev-1), c’est-à-dire une production en panne.
Chaque mandat livre un runbook écrit et un diagramme d’architecture, des livrables que vous conservez. Stack Harbor ne publie pas de prix. L’entreprise remet un périmètre et un devis fixes après l’évaluation, comme l’explique la page Comment nous cadrons les mandats. Cette page énumère aussi les cas où un mandat est le mauvais achat.
