Elément concerné : le système dans son ensemble ainsi que son interaction avec les écosystèmes connexes
L'objectif de cette partie des spécifications fonctionnelles est de définir le Plan de Reprise d'Activité (PRA) pour l'application CANEL2. Ce plan de reprise de l'activité (PRA) vise à s'assurer de la continuité opérationnelle de l'application en cas d'incidents majeurs (pannes, sinistres, ou toute autre situation nécessitant la restauration rapide des services).
Périmètre du PRA
Le Plan de Reprise d'Activité couvre l'ensemble de l'application, à savoir les fonctionnalités :
d'invocation d'API,
de saisie dans l'IHM,
de stockage de données,
de mise à disposition d'informations, via accès l'IHM ou par invocation d'une API.
Les interactions avec les applications tierces de gestion du SI sont également incluses dans le périmètre du PRA.
Objectifs du PRA
Les objectifs du Plan de Reprise d'Activité pour l'application référentielle sont :
réduire au minimum le temps d'indisponibilité de l'application en cas d'incident majeur.
de garantir l'intégrité des données stockées dans l'application pendant et après la reprise.
de restaurer les fonctions essentielles, à savoir les services d'invocation des contenus utiles aux applications tierces interfacées avec le référentiel.
d'assurer une reprise coordonnée avec les applications tierces consommant le services du référentiel.
Stratégie de Reprise
Scénarios d'Incidents
panne du service (defaillance ou déterioration : le service est actif mais ne répond plus aux sollicitations, )
incident sur l'hebergement (sinistre ou panne materielle, défaillance de l'hebergeur)
Définir les scénarios d'incidents potentiels, tels que les pannes matérielles, les défaillances logicielles, les sinistres, etc., qui pourraient impacter l'application référentielle.
Détection de l'incident
Le service doit être supervisé.
Certains incidents peuvent être identifiés de manière automatique (healthcheck, test de sollicitation des API, captation des code erreurs retournés).
Certains incidents doivent être récupérés de l'environnement sur lequel l'application repose (statut des environnements de l'application, statut de service d'hebergement)
Actions liées à la détection de l'incident
Selon le cas de figure identifié, la reprise peut être automatique ou nécessiter une action humaine de diagnostic.
Dans cas de déterioration du service, la suppression / restauration des données à un état précédent, avec suppression du contexte et réinstallation de l'application puis réouverture du service sera fera automatiquement via les services de l'orchestrateur.
Dans le cas d'une deterioration avec persistence de la panne suite a restauration automatique, l'action humaine sera nécessaire.
Dans le cas d'une détérioration des services de l'hebergeur, les équipes en charge de l'application doivent être mobilisés. Une action manuelle de restauration de l'ensemble sera peut-être nécessaire, selon l'intensité de la panne.
Actions liées a la resilience du service
Sauvegarde Régulière : une sauvegarde régulière des données de l'application référentielle et de sa configuration doit être mise en oeuvre. Cette sauvegarde doit être réalisée tous les soirs. le resultat de cette sauvegarde devra être notifiée.
Restauration du service : Si le service d'hebergement le permet, l'orchestrateur recréé l'environnement tombé, restaure l'application et la fourniture du service.
La restauration doit être testée (check de l'integrité de la base, invocation de l'API et vérification des retours, verification d'accessibilité des IHM, verification des interactions avec les systèmes tiers consommateurs)
Le resultat de restauration doit être notifié.
Communication et Notification
En cas de panne, le consommateur du service (utilisateurs du portail ou consommateur de l'API) et l'équipe en charge de son exploitation doivent être alertés. Un message d'erreur clair doit être adressé indiquant la nature de la panne.
Toute action de restauration sur l'environnement et le resultat de celui-ci, incluant les resultats des tests automatiques doivent être notifiés à l'équipe en charge de son exploitation.
En cas de continuité de la panne après restauration, le statut doit être notifié et visible par l'equipe de supervision.
Etat : en cours
Elément concerné : le système dans son ensemble ainsi que son interaction avec les écosystèmes connexes
L'objectif de cette partie des spécifications fonctionnelles est de définir le Plan de Reprise d'Activité (PRA) pour l'application CANEL2. Ce plan de reprise de l'activité (PRA) vise à s'assurer de la continuité opérationnelle de l'application en cas d'incidents majeurs (pannes, sinistres, ou toute autre situation nécessitant la restauration rapide des services).
Périmètre du PRA
Le Plan de Reprise d'Activité couvre l'ensemble de l'application, à savoir les fonctionnalités :
Objectifs du PRA
Les objectifs du Plan de Reprise d'Activité pour l'application référentielle sont :
Stratégie de Reprise
Scénarios d'Incidents
Détection de l'incident
Le service doit être supervisé. Certains incidents peuvent être identifiés de manière automatique (healthcheck, test de sollicitation des API, captation des code erreurs retournés). Certains incidents doivent être récupérés de l'environnement sur lequel l'application repose (statut des environnements de l'application, statut de service d'hebergement)
Actions liées à la détection de l'incident
Selon le cas de figure identifié, la reprise peut être automatique ou nécessiter une action humaine de diagnostic. Dans cas de déterioration du service, la suppression / restauration des données à un état précédent, avec suppression du contexte et réinstallation de l'application puis réouverture du service sera fera automatiquement via les services de l'orchestrateur. Dans le cas d'une deterioration avec persistence de la panne suite a restauration automatique, l'action humaine sera nécessaire. Dans le cas d'une détérioration des services de l'hebergeur, les équipes en charge de l'application doivent être mobilisés. Une action manuelle de restauration de l'ensemble sera peut-être nécessaire, selon l'intensité de la panne.
Actions liées a la resilience du service
Sauvegarde Régulière : une sauvegarde régulière des données de l'application référentielle et de sa configuration doit être mise en oeuvre. Cette sauvegarde doit être réalisée tous les soirs. le resultat de cette sauvegarde devra être notifiée.
Restauration du service : Si le service d'hebergement le permet, l'orchestrateur recréé l'environnement tombé, restaure l'application et la fourniture du service.
La restauration doit être testée (check de l'integrité de la base, invocation de l'API et vérification des retours, verification d'accessibilité des IHM, verification des interactions avec les systèmes tiers consommateurs) Le resultat de restauration doit être notifié.
Communication et Notification
En cas de panne, le consommateur du service (utilisateurs du portail ou consommateur de l'API) et l'équipe en charge de son exploitation doivent être alertés. Un message d'erreur clair doit être adressé indiquant la nature de la panne. Toute action de restauration sur l'environnement et le resultat de celui-ci, incluant les resultats des tests automatiques doivent être notifiés à l'équipe en charge de son exploitation. En cas de continuité de la panne après restauration, le statut doit être notifié et visible par l'equipe de supervision.