L'environnement d'exécution dessous, reconstructible depuis les sources.

• Une infrastructure montée à la main une fois et que seule une personne comprend désormais.
• Un processus de déploiement assez effrayant pour que les versions soient regroupées, ce qui rend chacune plus risquée que la précédente.
• Un environnement qui ne peut pas être recréé, de sorte que la préproduction et la production ont discrètement divergé.
• Un produit qui va bientôt avoir besoin de plus d'une seule machine, où la prochaine étape doit être décidée plutôt qu'improvisée.
• Un historique d'incidents dont le thème récurrent est que rien n'a remonté tant qu'un utilisateur ne l'avait pas signalé.

Une architecture de référence, c'est-à-dire la forme sur laquelle le travail est conçu, et non un relevé de systèmes livrés. Elle nomme des couches et des responsabilités, jamais des produits : ce qui tourne à une couche donnée est une décision prise avec vous pendant le cadrage, pas ici à l'avance.

• Un provisionnement en code, pour qu'un environnement soit défini dans le dépôt plutôt que dans une console.
• Une mise en place des conteneurs et de l'environnement d'exécution, avec les limites de ressources et le comportement en cas de défaillance rendus explicites.
• Des pipelines CI/CD : ce qui s'exécute à chaque commit, ce qui conditionne une version, et ce qui l'arrête.
• Un chemin de déploiement et de retour arrière, le retour arrière étant éprouvé plutôt que supposé.
• Une journalisation, des métriques et une observabilité visant les défaillances que ce système a réellement.
• Une liste de contrôle de déploiement et de retour arrière, pour que la procédure survive à la personne qui l'a écrite.

• Un environnement que personne ne peut reconstruire, où la seule copie de la configuration est le système en cours d'exécution.
• Découvrir pendant un incident que le chemin de retour arrière était théorique.
• Un processus de livraison si risqué que les versions sont regroupées, ce qui aggrave le risque qu'il cherchait à éviter.
• La défaillance silencieuse : un système qui se déclare sain pendant que le travail derrière lui s'accumule.
• Une infrastructure qui vit dans le compte d'un fournisseur plutôt que dans le vôtre, de sorte que l'accès est quelque chose que vous devez demander.

• Une astreinte permanente 24 h/24, 7 j/7, ou un contrat d'infogérance. Cela construit la plateforme et la remet ; ce n'est pas un contrat de support.
• Une migration vers le cloud choisie pour elle-même, sans problème à résoudre. Elle est cadrée d'abord comme une décision, et la réponse est souvent de ne pas migrer.
• Kubernetes parce que c'est attendu. L'environnement d'exécution doit correspondre aux modes de défaillance que le produit a réellement, et c'est souvent quelque chose de plus petit qui convient.
• Une mission de réduction des coûts où le chiffre cible est fixé avant que quiconque ait regardé ce qui tourne.
• Un travail d'infrastructure dans un compte auquel nous ne pouvons pas recevoir un accès correctement délimité. Des identifiants permanents et étendus ne sont pas une solution de contournement.

1. 01

   Tout dans vos comptes

   L'infrastructure tourne dans des comptes que vous possédez dès le départ. Rien n'est hébergé chez nous puis migré plus tard : il n'y a donc ni bascule ni dépendance à notre pérennité.

2. 02

   La configuration dans le dépôt

   Le provisionnement en code signifie que l'environnement a une définition que votre équipe peut lire, relire et modifier. Reconstruire, c'est exécuter le code, pas reconstituer un souvenir.

3. 03

   Une procédure de livraison qui a été exécutée

   Le chemin du commit à la production, les contrôles qui le jalonnent et les étapes exactes pour annuler une version, éprouvés pendant la mission plutôt que documentés et espérés.

4. 04

   Les conditions qui déclenchent un retour arrière

   Pas seulement comment annuler une version, mais quand le faire : ce qu'il faut surveiller après un déploiement, et quelle valeur signifie qu'il faut s'arrêter. Un jugement écrit pendant qu'il est frais.

• RéalisationUn gestionnaire d'affichage à privilèges séparésLe niveau le plus bas qu'atteigne une réalisation : des parties indépendantes amenées à démarrer comme un seul système, et à continuer de démarrer après une mise à jour.
• DocumentsExemples de livrablesLa liste de contrôle de déploiement et de retour arrière, présentée comme le format avec ce qu'il consigne et le risque qu'il écarte.
• ServiceSécurité et profondeur systèmeLes frontières d'accès et la gestion des identifiants qui accompagnent le travail sur l'environnement d'exécution.