Vendredi 20 octobre 2017
NASDAQ : 6629.0532 23.9863   nasdaq0.36 %
RECHERCHE
OK
 
NEWSLETTER
newsletter
Abonnez-vous gratuitement
à notre newsletter
hebdomadaire - Cliquez ICI
Indexel
  • DOSSIERS
  • PRATIQUE
pub Publicité
 

INFRASTRUCTURE

Plan de reprise d'activité : proportionner les moyens aux besoins

Imprimer Envoyer à un ami Contacter la rédaction
Par Thierry Lévy-Abégnoli le 17/01/2005 - indexel.net
 

Un plan de reprise d'activité vise à assurer la continuité de service des applications en cas de panne majeure ou de sinistre. Les scénarios techniques doivent être proportionnés aux pertes potentielles.

 

Toute entreprise souhaiterait que ses applications restent en ordre de marche, même en cas de panne ou de sinistre. Mais une telle exigence a un coût exorbitant. On choisit en pratique d'assurer un redémarrage plus ou moins rapide en fonction des contraintes économiques et business, dans le cadre d'un plan de reprise d'activité (PRA).

 

"Il y a deux ou trois ans, beaucoup d'entreprises se contentaient d'envisager de mettre en place un tel plan. Depuis, nombreuses sont celles qui ont franchi le pas. En outre, au lieu de se faire application par application, leur réflexion devient globale, incluant matériels, logiciels, locaux et ressources humaines", constate Geoffroy Allaire (photo), directeur technique Ile-de-France chez APX Computer.

 

Evaluer les pertes de données et le temps d'indisponibilité acceptables

 

La définition d'un PRA commence par l'analyse des besoins qui comprend deux volets bien distincts. "Premièrement, il faut évaluer, en fonction de leur criticité, le volume des données que l'on peut se permettre de perdre définitivement. Deuxièmement, on devra apprécier combien de temps on acceptera d'être privé de l'accès aux données préservées, ce qui revient à parler du temps d'indisponibilité des applications", explique Geoffroy Allaire (photo). Même assistée d'une société de conseil, l'entreprise doit mener elle-même cette réflexion. Ignorant bien souvent le coût des solutions techniques, elle aura souvent tendance à surévaluer ses besoins. C'est pourquoi plusieurs allers-retours sont nécessaires entre leur analyse et le choix de scénarios.

 

Pannes ou sinistres : un vaste éventail de scénarios

 

Certains scénarios sont indirectement liés au PRA. Par exemple, il peut être nécessaire de consolider plusieurs serveurs et de réduire le nombre de systèmes d'exploitation. Il est en effet plus facile de secourir une seule grosse machine qu'un parc hétérogène. Quant aux scénarios davantage liés au PRA, ils ne sont pas les mêmes selon que l'on veut se mettre à l'abri des pannes ou des sinistres. La tolérance aux pannes peut être obtenue sur un seul site, par exemple avec une architecture en cluster et une baie de disques dont tous les éléments sont doublés.

 

La reprise de l'activité est alors immédiate et automatique. "Synonyme de doublement des serveurs, un cluster n'est pas toujours nécessaire. Certaines entreprises se contentent d'un contrat de délai de remise en marche sous quatre ou six heures", fait remarquer Benoît Maillard (photo), responsable marketing produits chez HP.

 

Pour reprendre une activité après un sinistre, le strict minimum est de réaliser des sauvegardes et de les mettre régulièrement à l'abri sur un autre site. C'est suffisant lorsque l'on peut accepter de perdre, par exemple, une journée de commandes clients. Et si la durée supportable d'indisponibilité des applications est de trois jours, il sera inutile de prévoir une procédure de reprise sur un centre informatique appartenant à l'entreprise. On pourra, pour un coût bien plus faible, souscrire un contrat de secours à froid. "Pour 5 000 à 100 000 euros, nous proposons de reprendre sous 48 heures les applications et données d'un client sinistré sur des systèmes que nous livrons ou qui restent chez nous", propose ainsi Gilles Maquin (photo ci-dessous), directeur du développement pour BCRS (Business Continuity and Recovery Services) chez IBM.

 

Des décisions de bon sens

 

Si les pertes acceptables de données se comptent en dizaines de minutes, leur réplication pratiquement en temps réel sur un site distant devient obligatoire. Là encore, l'entreprise n'a pas forcément besoin de déployer elle-même un tel site. Une réplication asynchrone (donc techniquement peu contraignante) peut être réalisée vers un prestataire qui, seulement en cas de sinistre, reprendra la production des applications donnant accès à ces données. Lorsque le volume acceptable de données perdues correspond à seulement quelques secondes d'activité (soit une poignée de transactions), une réplication dite synchrone (dont les exigences en termes de temps de latence et de débit gonflent la facture) vers un site appartenant à l'entreprise s'impose.

 

Dans un PRA, certaines décisions relèvent du bon sens. Par exemple, deux centres se secourant mutuellement doivent être assez éloignés l'un de l'autre pour ne pas risquer d'être touchés de concert par une inondation ou un incendie. De plus, il faut prévoir les ressources humaines - pas seulement celles liées à l'informatique - nécessaires à la reprise, ainsi que les locaux et les postes de travail, là encore fournis par des prestataires comme IBM. Enfin, il est impératif de tester le PRA au moins une fois par an et de prévoir son évolution en fonction de celle du système d'information.

 

 
Partager :
 
pub Publicité

CloudStack by IkoulaCloudStack by Ikoula

Cloud Computing : Atouts et freins, acteurs du marché, conseils et témoignages