Encadrer les mises à jour automatiques par des critères d’arrêt
L’automatisation exige des tests après installation. Définissez quand arrêter la suite du déploiement et qui décide de sa reprise.
Les mises à jour automatiques peuvent prendre en charge des tâches d’exploitation récurrentes. Une installation réussie ne dit toutefois pas encore si votre application et ses connexions fonctionnent toujours comme prévu. La décision de poursuivre nécessite donc un cas de test défini.
Le NIST inclut la priorisation, l’installation et la vérification de l’installation dans la gestion des correctifs. Pour votre exploitation, cela mène à une question concrète : quel parcours applicatif doit encore fonctionner après la modification ?
Contrôler une connexion critique
Dans cet exemple fictif, une routine automatique installe une mise à jour. Le service web démarre, mais la tâche de fond J-61 ne peut plus utiliser sa connexion au système associé. Le message d’installation est positif ; le parcours nécessaire reste interrompu.
Pour ce cas, l’équipe prévoit de tester la connexion et le résultat attendu avant de poursuivre le déploiement. Le test est préparé dans un environnement approuvé avec des données adaptées. Aucune mise à jour n’a été installée et aucun système associé n’a été contacté ici.
Définir la réaction à un test en échec
Observation dans l’exemple | Suite prévue | Condition avant de poursuivre |
|---|---|---|
L’installation et le parcours critique passent les tests convenus. | Poursuivre le déploiement prévu sous surveillance. | Les résultats des tests sont rattachés au système concerné. |
La connexion de la tâche de fond échoue. | Arrêter les étapes suivantes et attribuer l’investigation. | La cause ou une solution adaptée a été vérifiée ; la poursuite fait l’objet d’une décision. |
Un correctif de sécurité urgent exige une autre procédure. | Évaluer ensemble l’urgence, l’impact et le moyen de test disponible. | Une décision responsable et la surveillance ultérieure sont définies. |
Ce tableau est un modèle de planification, et non un déploiement effectué ici. Arrêter signifie décider de façon maîtrisée de la prochaine modification. Le correctif de sécurité nécessaire reste une tâche ouverte qui exige une suite définie.
Prévoir le retour en arrière et le travail restant
Le retour à l’ancienne version du logiciel doit être compatible avec l’état des données et les modifications déjà effectuées. Précisez à l’avance quelle méthode de retour a été testée pour cette mise à jour et qui peut l’exécuter. Un ancien fichier ne constitue pas à lui seul un retour en arrière testé.
Consignez enfin qui traite les contrôles en échec et quand les cas ouverts seront réévalués. L’automatisation suit ainsi la procédure convenue, tandis que les écarts disposent d’un circuit de décision avec un responsable identifié.
Sources
À lire aussi
Tous les articles
Cloud & exploitation avec ASES
Hébergement, déploiement, maintenance et suivi