Dix étapes clés pour le PRA-PCA
Si aucun permis de conduire ne peut se garantir du succès d’un plan de reprise d’activités informatiques, en revanche une méthode de conduite de projet s’avère néanmoins essentielle. Les administrateurs systèmes, réseaux et applications ont beau anticiper plusieurs scénarios, les pannes et incidents surviennent toujours là où on ne les attend pas. Chargés de l’exploitation des outils informatiques, ils mesurent des seuils pour être prévenus à temps, c’est à dire avant que les disques durs ou les segments de réseau n’atteignent leur limite de capacité ou encore avant que les batteries des onduleurs soient périmées. Mais, si la plupart des risques sont évalués, une partie d’entre eux seulement est atténuée à grand renfort de procédures et avec quelques astuces en guise de trousse de secours.
La plupart des méthodes d’exploitation (ITIL) suggèrent de consigner le moindre changement et de procéder à des examens et tests réguliers. On progresse ainsi par boucles d’améliorations, une approche qui a déjà fait ses preuves dans les démarches qualité ainsi que dans la sécurité physique des accès.
Efficace, mais pas imparable. Or, les PRA-PCA (plans de reprise ou de continuité d’activités) doivent prévoir toutes les bascules nécessaires en cas d’incident ou de catastrophe naturelle. Ils aident l’exploitation à s’engager sur un délai de reprise d’activités. Ce faisant, ils redonnent confiance à l’ensemble des utilisateurs, du client final jusqu’à la direction générale.
On distingue généralement une dizaine d’étape dans la mise en oeuvre d’un tel plan. Trois des dix étapes résumées dans le tableau ci-dessous méritent une attention particulière.
A chaque changement organisationnel majeur, (phase 3 du tableau), il convient de déterminer les applications critiques et les données cruciales pour l’entreprise. Les pannes applicatives et leurs conséquences pour l’entreprise doivent être parfaitement connues, c’est à dire identifiées et classées par sévérité et par probabilité du risque. Cet effort permet de cibler les serveurs - physiques ou virtuels - à basculer en priorité.
A chaque changement technique majeur (phase 7 du tableau), le site principal et le site de repli doivent reconsidérer l’infrastructure en place - régler les paramètrages d’administration le plus souvent - afin de délivrer des bascules adaptées.
Le budget consacré aux outils de surveillance informatique s’avère déterminant, même si des logiciels gratuits ou Open Source tel Nagios contribuent de plus en plus à bâtir une solution sur-mesure et à moindre frais. Il n’est pas rare de rencontrer, dans les plus vastes infrastructures, une grande diversité de plate-formes de supervision afin de gérer l’héritage des problèmes rencontrés. Dans ce cas, attention à l’interopérabilité des outils d’administration au moment du crash. A ce stade, une solution de bascule par réplication complète des serveurs critiques s’avère préférable.
Dernier point, une à deux fois par an, l’équipe IT doit tester ses mécanismes et procédures de rétablissement de la production. Cette simulation concerne aussi les mouvements du personnel qui peut être amené à travailler dans un autre local, provisoirement.
# |
Etape clé |
Site de repli impliqué |
Fréquence |
Observations |
1 |
Se poser les bonnes questions pour la reprise d’activités IT |
Non |
une ou deux fois par an |
lister les risques, leur sévérité, leur probabilité |
2 |
Définir les priorités selon la probabilité et la sévérité des risques rencontrés |
Eventuellement |
une ou deux fois par an |
faire le tri des risques |
3 |
Déterminer les applications critiques et les données cruciales pour l’entreprise |
Non |
à chaque changement organisationnel majeur |
atténuer les risques majeurs en pesant leurs conséquences |
4 |
Quelle tolérance pour les données perdues (1 h, 1 j) ? |
Non |
une ou deux foispar an |
préciser ses objectifs de sauvegarde |
5 |
Quelle tolérance d’inactivité ? |
Eventuellement |
une ou deux fois par an |
préciser ses objectifs de reprise |
6 |
Rédiger un cahier des charges PRA-PCA |
Oui |
une ou deux fois par an |
lister les avancées attendues |
7 |
Choisir les outils de l’infrastructure et d’administration des bascules adaptés |
Oui |
à chaque changement organisationnel ou technique majeur |
gérer l’héritage et documenter les rôles de chacun (personnes à contacter en cas d’incident...) |
8 |
Préparer et entraîner les équipes à la reprise d’activités |
Eventuellement |
une ou deux fois par an |
impliquer les utilisateurs |
9 |
Tester les mécanismes de bascule et de rétablissement de la production IT |
Oui |
une ou deux fois
par an |
simuler l’incident |
10 |
Mettre à jour le PRA-PCA |
Oui |
à chaque changement organisationnel ou technique majeur |
reprendre le processus à l’étape #1 le cas échéant |
|
|
L’incontournable automatisation
Le facteur clé de succès du PRA consiste à l’éprouver pour de bon. Un “split brain” test vérifie le bon redémarrage des serveurs, maître et esclave, en examinant l’absence de perte d’informations, au niveau des gestionnaires de données. Pour le réaliser, il suffit de couper le lien entre les deux serveurs. Autre procédure indispensable, la coupure d’alimentation d’un serveur critique au business de l’entreprise permet de vérifier que la fenêtre de maintenance ne dépasse pas ce qui est prévu dans le plan ou dans le contrat de service d’externalisation. Ce laps de temps - il s’éternise alors pour l’administrateur - ne devrait pas dépasser quelques minutes avec les solutions de bascule automatisée, par réplication complète des serveurs. Faute d’avoir investi dans un tel logiciel de sauvegarde pour les serveurs critiques, l’entreprise doit s’attendre à plusieurs heures d’interruption par plate-forme. En effet, les opérations de secours consistent à connecter un serveur de repli, puis à le configurer avant de remonter la dernière sauvegarde de données. Lorsqu’on doit redémarrer l’ensemble des services applicatifs, cela représente souvent plus d’une journée d’inactivité.
|
|
