Une plateforme peut disposer de conteneurs et d’une pipeline verte tout en dépendant d’une seule personne pour se relever d’un incident. L’orchestrateur ne définit ni l’autorité de déploiement, ni la restauration de la base, ni la réponse à une alerte. La préparation opérationnelle consiste à modifier, observer et récupérer le service dans les contraintes réelles de l’organisation.
Suivre une modification jusqu’au service
Pour un service, relier la source revue à l’artefact déployé et à sa configuration. Identifier l’approbateur, les vérifications et les signes que le parcours utilisateur fonctionne. Inclure identité, réseau, certificats, secrets, migrations et personnes autorisées à intervenir.
| Question | Preuve utile | Substitut trompeur |
|---|---|---|
| Quelle version fonctionne ? | Révision, artefact et environnement | Étiquette « latest » |
| Qui peut la modifier ? | Accès limités et responsabilité de validation | Mot de passe administrateur partagé |
| Peut-on récupérer ? | Restauration chronométrée et vérifiée | Sauvegarde marquée réussie |
| Comment détecter le problème ? | Signal du parcours utilisateur et action prévue | CPU seul |
| Qui assure le service ? | Responsable, procédure et attentes de support | Numéro personnel du développeur |
Rendre les livraisons explicables
Le relevé de version relie source, contrôles, artefact, configuration et migrations. Les vérifications correspondent au risque : accès interdit pour une modification de droits, compatibilité pour une migration, parcours métier pour un workflow. Un contrôle obligatoire en échec doit être compris et corrigé.
Le retour arrière concerne aussi les données
L’ancienne application peut être incompatible avec le nouveau schéma. Restaurer une base peut perdre des opérations récentes légitimes. Avant la livraison, distinguer extension compatible, changement de comportement et nettoyage destructif. Déterminer si la réponse sera un retour arrière, une correction en avant ou une restauration.
Tester une restauration isolée en mesurant durée, dernier état récupérable et complétude. Les objectifs RPO et RTO sont des décisions métier à convenir et à démontrer. La protection des sauvegardes contre la suppression et les accès non autorisés fait partie de la conception.
Observer le résultat et sa cause
Relier les signaux aux parcours : acceptation d’une demande, approbation ou fraîcheur d’un rapport. Les métriques internes permettent d’expliquer les échecs. Pour une plateforme d’approbation, examiner l’âge de la notification la plus ancienne, les soumissions en erreur et la dernière publication complète. Chaque alerte urgente a un responsable et une première action.
Justifier la complexité supplémentaire
Une orchestration plus élaborée devient pertinente face à des besoins mesurés de placement, d’isolation, de capacité ou de livraison indépendante. Inclure mises à jour, réseau, stockage, droits et compétences d’incident dans le coût. Une ambition de croissance ne suffit pas à dimensionner toute l’infrastructure future.
- Démontrer une livraison reproductible et une restauration.
- Attribuer responsabilités, accès et attentes de support.
- Mesurer la contrainte actuelle.
- Comparer une amélioration simple à l’investissement proposé.
- Piloter avec des critères d’acceptation et de sortie.
Le premier livrable peut être une évaluation de préparation et un plan opérationnel priorisé. Il doit expliquer les capacités actuelles, les risques et les preuves qui justifieraient l’étape suivante.