Une intervention présente toujours un certain niveau de risque. Un vieux dicton dit :

“Si ça marche, ne touche à rien !”

Même lorsque l'intervention est sensée corriger un défaut où un dysfonctionnement antérieur. Une intervention mal gérée peut conduire à un fonctionnement encore plus dégradé. Notre expérience de plusieurs dizaines de milliers d'opération sur nos site clients ont permis de déterminer, à l'arrivée, et dans l'optique de l'exploitant, plusieurs niveaux de risque qui affectent la combinaison de l'étendue du désordre avec le temps d'indisponibilité.

Un risque est toujours associé à une probabilité d'apparition. Un risque cataclysmique plausible doté d'une probabilité d'apparition de 0 n'est plus à considérer.

Les risques sont énoncés du plus critique au moins critique :

L'intervention a provoqué une rupture technologique majeure (mélange de versions, incompatibilité avec l'environnement système). La probabilité d'un tel risque est proche de 0 lorsque :

• Le projet est géré dans un outil de versionnemment.
• Le projet est géré avec mise en oeuvre d'une instance de pré-qualification.
• Le projet dispose d'une politique de sauvegarde régulière.
• Les interventions “à risque” respectent l'obligation de sauvegarde complète préalable.

L'intervention a causé un dysfonctionnement total à un emplacement non identifié (c'est-à-dire non lié à une modification notoirement répertoriée et réversible). L'effet de l'apparition du risque peut être long, car il nécessite une recherche pas à pas

L'intervention cause par effet de bord un dysfonctionnement partiel rapidement constatable sur une autre partie de l'application ou un autre cas d'usage. La résolution de ce type d'incident secondaire est dans la plupart de cas très rapide lorsque la livraison est ponctuelle. Elle peut être exceptionnellement plus longue lorsque :

• La livraison a concerné un large périmètre de composants.
• Le défaut secondaire provient d'une incohérence architecturale

L'effet de bord n'est pas immédiatement perceptible, mais concerne des cas d'usage qui ne seront révélés que plus tard (voire bien plus tard), en général, sur des fonctionnalités peu ou rarement utilisés, ou sur des données dont la représentation à l'utilisateur ne permet pas un contrôle de cohérence immédiat.

• Totale : La plate-forme ne fonctionne plus du tout. Cas typique : Serveur off, DNS off, Page blanche (fatal error, erreur de compilation), rupture d'authentification.
• Centrale : La plate-forme présente un fonctionnement correct sur la page d'accueil (fonctions techniques du service en marche), mais une fonction centrale arrête tous les utilisateurs avant qu'ils accèdent à leur service. Cas typique : Erreur fatale sur la page d'accès aux cour, erreur fatale sur le tableau de bord personnel, perturbation des droits d'accès et rôles.
• Locale critique : Le dysfonctionnement présente un caractère local (une fonctionnalité précise), mais celle-ci bloque un processus métier clef du client. Cas exemple : La génération des statistiques de temps d'usage est essentiel pour un organisme de formation continue subventionné.
• Locale non critique : Le dysfonctionnement affecte une fonctionnalité secondaire (n'est pas clef dans les processus métier) ou un accessoire contournable (on peut faire autrement).

• Très longue : plusieurs semaines
• Longue : un à plusieurs jours
• Courte : Quelques heures
• Très courte : inférieur à une heure

Retour à l'index Qualité de services - Revenir au catalogue - Revenir à l'index des plugins