Comment fonctionne la sous-phase Stabilisation
Où cela s’inscrit
Les points de contrôle qu’un service numérique du GC doit franchir shows where Stabilization comes in the whole journey, checkpoint by checkpoint.
Les premières semaines sont de la lutte contre les incendies. La Stabilisation, c’est le travail qui mène au jour où il ne reste plus d’incendie à éteindre.
Deux choses changent le jour du lancement
- Le volume est réel. Toutes les personnes visées par le service peuvent l’atteindre : ce qui arrive est donc ce que le monde réel envoie, non ce qu’une séance de recherche avait organisé.
- Ce que les gens font compte désormais. Pendant la Création, quelqu’un remplissait un formulaire et rien ne se passait ensuite, parce que rien n’était censé se passer. Maintenant, une demande doit être reçue, évaluée par une personne, tranchée, consignée là où on peut la retrouver, et une réponse doit être donnée. Si une subvention a été promise, l’argent doit parvenir au compte de quelqu’un.
C’est donc la première fois que quiconque découvre si le service entier tient, et pas seulement le logiciel : si l’équipe qui traite les demandes est assez nombreuse pour le volume qui arrive, et si quelqu’un a été complètement oublié dans le dispositif.
Avant de commencer la Stabilisation
LA QUESTION DÉCISIVE
Convenir de la fin de la Stabilisation avant qu’elle commence
Un soutien renforcé donne un sentiment de sécurité, et c’est là son danger : une fenêtre sans critère de sortie ne se referme jamais, et les correctifs constants masquent les faiblesses qu’ils devraient corriger. Avant le jour du lancement, convenez de ce à quoi ressemblera la stabilité en chiffres, de qui décide que la fenêtre est close, et de ce qu’il advient de ce qui reste ouvert à sa fermeture. La décision revient au responsable opérationnel de l’application, prise à partir des preuves du tableau de bord.
Exploiter votre service pendant la Stabilisation
L’équipe qu’il vous faut
L’équipe de la Bêta rétrécit pour prendre la forme d’exploitation. Les rôles minimaux (une personne peut en cumuler plusieurs) :
- Exploitation garde le service en fonction et à jour, et met en production les correctifs.
- Responsable du soutien aide les gens à s’en sortir, et rapporte ce que disent les appels.
- Développeurs du fournisseur ou de l’interne corrigent les défauts tant que dure la garantie ou l’affectation, et transmettent la connaissance.
- Responsable opérationnel de l’application assume la décision que la Stabilisation est terminée.
Gardez la connaissance à mesure que les personnes changent : guides d’exploitation, erreurs connues et décisions consignés au fur et à mesure. La Stabilisation est courte : de quelques semaines à quelques mois est typique.
CAUTION
Quand la Stabilisation tourne mal
Le lancement a été traité comme la ligne d’arrivée : personne n’est responsable du service en exploitation.
L’ancienne façon est éteinte pendant que le nouveau service surprend encore les gens : il n’y a donc plus de voie de retour.
Le soutien est débordé, et ce qu’il entend ne parvient jamais à l’équipe.
Les personnes qui l’ont construit étaient parties le jour du lancement : aucune garantie, aucun transfert.
Le soutien renforcé ne se termine jamais, et les correctifs constants masquent les faiblesses qu’ils devraient corriger.
UN EXEMPLE RÉEL
Le jour du lancement, il n’y avait aucune voie de retour
Quand Phoenix a été mis en service, l’ancien système de paye a été éteint, et des centaines des conseillers en rémunération qui comprenaient la paye avaient déjà été remerciés. Alors quand les premières payes sont sorties erronées, il n’y avait aucun ancien système vers lequel se replier, et presque plus personne pour corriger un dossier de paye à la main.
Chaque défaut a atteint de vraies payes à plein volume, et la file des dossiers de paye brisés a grossi plus vite que quiconque pouvait l’écouler. La voie d’entrée de la Stabilisation existe à cause de lancements comme celui-là : l’ancienne façon encore en marche, avec un plan de retrait daté, et les personnes qui comprennent le service encore joignables.
Comment savoir que la Stabilisation est terminée
La Stabilisation est terminée quand le critère de sortie convenu avant le lancement est atteint et que le service est devenu ennuyeux : les incidents sont rares et courants, le volume de soutien s’est stabilisé pendant que l’utilisation continue de croître, le rendement tient sous pleine charge, et l’équipe d’exploitation règle et escalade sans les personnes qui l’ont construit.
Ce qui reste cassé est assumé et accepté
Ennuyeux ne veut pas dire parfait. Le critère de sortie tolère des défauts ouverts, pourvu que chacun soit diagnostiqué, ait un responsable nommé, et reste ouvert parce que quelqu’un a décidé qu’il pouvait l’être.
La règle applicable à la liste ouverte a été convenue avant le lancement, dans le cadre du critère de sortie. Appliquez-la à la clôture : ce qui est accepté passe à la liste des erreurs connues de l’équipe d’exploitation, et l’on nomme qui paiera sa correction éventuelle.
L’équipe de construction est libérée, et la connaissance est conservée
Pour une construction par un fournisseur, accepter la liste ouverte clôt la garantie, c’est-à-dire la période après le lancement pendant laquelle le fournisseur corrige les défauts sans frais additionnels. Chaque défaut restant est soit corrigé sous celle-ci, soit accepté avec un responsable nommé. La clore règle qui paie à partir de ce moment : les corrections gratuites cessent et les modalités de soutien prennent le relais.
Un service construit à l’interne n’a pas de garantie à clore. L’affectation des développeurs se termine une fois que l’équipe d’exploitation gère les incidents sans eux.
La connaissance reste avec l’équipe d’exploitation. Le guide d’exploitation et la liste des erreurs connues lui appartiennent à la clôture, et les incidents récents en sont la preuve : réglés sans un appel aux personnes qui l’ont construit.
quand il y a de vraies nouvelles capacités à construire.
quand le service a déjà la portée dont il a besoin. Tous les services ne croissent pas, et passer directement au long régime stable est un parcours normal.
Retour vers une reconstruction,
quand des semaines de correction n’arrivent pas à stabiliser le service et que le défaut est plus profond que des correctifs. C’est rare, et c’est une décision de l’ampleur d’une Création.
La fenêtre se referme sur des preuves. Avant de passer à la suite, ayez ceci prêt :
Les instruments officiels dans Stabilisation
Tout ce qui est officiel et à quoi il arrive quelque chose pendant Stabilisation, et ce que ce quelque chose est. L’étiquette dit à quelle étape l’instrument parvient ici, non qu’il soit terminé.
Placer un instrument dans une sous-phase est un choix éditorial propre à ce guide, ancré autant que possible sur une véritable échéance inscrite dans l’instrument lui-même. Le détail complet, y compris qui fait le travail et ce que le responsable opérationnel fait personnellement, se trouve dans le tableau complet des instruments.
- Soumettre
- Transmis, déposé, inscrit ou publié là où la règle l’exige.
- Tenir à jour
- Le service a changé, ou l’échéance est arrivée. Le refaire, le retester, ou actualiser le dossier.
Ce que signifient les étiquettes
Every service
- Analyse des répercussions sur les activités (ARA)ÉvaluationTenir à jour
L’exercice qui détermine la criticité du service, et qui produit quatre chiffres : la durée maximale d’interruption admissible, le niveau de service minimal, l’objectif de temps de reprise et l’objectif de point de reprise.
Mesuré pour la première fois contre de vrais incidents. Positionnement éditorial, justifié par ce que la sous-phase fait déjà.
Le registre pangouvernemental des services qui existent, des personnes qu’ils servent, de leur degré de numérisation, et du volume qu’ils traitent.
Inscrit une fois le service en fonction. Facile à oublier, parce que personne ne vient le réclamer.
- Gestion du portefeuille d’applications (GPA)InscrireSoumettre
Le registre des applications derrière les services, cotées selon la valeur opérationnelle, l’état technique, le coût de soutien et la criticité, et classées en tolérer, innover, atténuer ou éliminer.
Cotée une fois en fonction, y compris sa criticité.
Les dispositions de rétablissement propres à l’équipe du service : comment ce système se relève, dans quel ordre ses composants sont restaurés, et la preuve par les essais que la restauration fonctionne.
Les premiers incidents réels vérifient si la restauration fonctionne sous pression et si la cible de rétablissement est atteignable.
L’obligation de disposer d’un moyen de repérer, de contenir et de signaler un incident de cybersécurité avant qu’il survienne, et de le signaler dans la chaîne pangouvernementale quand il survient.
C’est le moment où cela sert. Les incidents sont signalés par la voie ministérielle, non gardés pour soi.
Only if it applies
- Plan de continuité des activités (PCA)PlanTenir à jour
Les dispositions écrites pour qu’un service essentiel continue d’être offert à un niveau minimal acceptable pendant une perturbation, et pour le rétablir ensuite.
Un incident réel est un essai en direct de dispositions qui avaient été écrites sur papier.
Applies when Seulement si l’analyse des répercussions sur les activités marque le service comme essentiel, c’est-à-dire qu’une perturbation causerait un préjudice élevé ou très élevé. Un ministère interprète cela comme devant se rétablir aux niveaux de service minimaux en 72 heures.
L’énoncé écrit du bien que ce projet est censé produire, et le rapport ultérieur confirmant ce qui a réellement été livré et si les avantages promis sont arrivés.
Le projet financé se termine par une clôture : ce qui a été livré, ce qu’il reste du budget, et le relevé de livraison.
Applies when Universel pour tout ce qui constitue un projet au sens de la directive sur les projets et programmes, sans seuil monétaire. La déclaration de référence au Bureau du contrôleur général commence à 25 millions de dollars.
- Rapport d’atteinte substantielle à la vie privéeDéclarationSoumettre
Le rapport qu’un ministère doit produire lorsque des renseignements personnels sont perdus, consultés ou communiqués d’une façon dont on pourrait raisonnablement s’attendre à ce qu’elle cause un préjudice grave.
Si cela se produit, c’est signalé. Positionnement éditorial : l’obligation est déclenchée par l’événement, non par une phase.
Applies when Seulement lorsqu’une atteinte visant des renseignements personnels est jugée substantielle, d’après la sensibilité de l’information, le nombre de personnes touchées, et le caractère systémique ou non du problème. Un incident de cybersécurité touchant des renseignements personnels peut déclencher à la fois celui-ci et la voie de signalement en cybersécurité.
Les hypothèses de cette page
Vous travaillez déjà selon les Normes relatives au numérique du gouvernement du Canada : concevoir avec les utilisateurs, itérer et améliorer fréquemment, travailler ouvertement, utiliser des normes et des solutions ouvertes, gérer les risques en matière de sécurité et de protection des renseignements personnels, intégrer l’accessibilité dès le début, permettre au personnel d’offrir de meilleurs services, être de bons gestionnaires de données, concevoir des services éthiques et collaborer largement, ainsi que selon la loi en matière de protection des renseignements personnels, de sécurité, de langues officielles et d’accessibilité. Les normes précisent comment le gouvernement travaille dans le monde numérique. Les six compétences numériques du gouvernement du Canada précisent ce que chaque fonctionnaire doit être capable de faire pour travailler ainsi, et la page sur l’équipe les présente. Le présent guide s’appuie sur elles.