Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.

La mise en place d’un Plan de Continuité Informatique est souvent vue comme un poste de coût supplémentaire, une forme d’assurance pour couvrir des évènements rares. Dès lors, le bon sens conduit souvent à vouloir en réduire les coûts et donc à favoriser le secours sur des serveurs existants « hors production »  (développement, recette, qualification, intégration, test, formation, pré-production) et notamment ceux de pré-production (plus proches de l’environnement réel).

Mettre ainsi à profit des ressources qu’on ne juge pas essentielles en cas de crise semble permettre d’optimiser leur usage – et au final les coûts du PCI. Cette assertion mérite cependant d’être confrontée au contexte de chaque organisation. Un tel secours est-il vraiment une source d’économie ? Réellement plus simple à mettre en œuvre ? Éligible pour toutes les applications ?

Prendre en compte les contraintes applicatives pour évaluer la complexité de mise en œuvre

Les environnements « hors-production » peuvent présenter des enjeux aussi forts pour les Métiers que leur environnement de production, notamment lorsque :

• les applications doivent évoluer rapidement ou régulièrement,
• les incidents applicatifs nécessitant correctifs sont fréquents.

Ces besoins métiers entrent ainsi en concurrence avec ceux liés à la mise en place du secours (construction du PCI, recette, tests, etc.). Si le métier est en charge de définir les priorités d’utilisation de ces environnements, il y a fort à parier que le planning de mise en œuvre du PCI devra être défini en fonction des plages d’usage laissées vacantes par les autres besoins.

Autant dire que pour les applications évoluant souvent ou victimes d’incidents à répétition, le projet de secours sera complexifié ; les phases de construction et de test du secours ne pouvant être déroulées, le métier exigeant la disponibilité de ces ressources pour d’autres besoins plus prioritaires à ses yeux. Contrainte d’autant plus forte dans un contexte au sein duquel la mise en production (MEP) ne serait pas complètement industrialisée.

Dès lors, la mise en œuvre d’un secours sur pré-production ne peut être envisagée sereinement que pour des organisations au sein desquelles la DSI priorise seule l’accès et l’utilisation des ressources hors-production. Il conviendra alors de privilégier les applications les mieux maîtrisées et les plus stables, afin de réduire au maximum les conflits avec les chantiers d’évolution applicative ou de correction de problèmes.

Ne pas conclure trop vite à une économie substantielle en évaluant les coûts cachés

Si le secours sur pré-production est considéré comme moins coûteux, c’est qu’il réduit le volume des investissements et la mise en œuvre de serveurs. Mais cette vision apparaît réductrice dès qu’on identifie les autres coûts à prendre en considération.

En effet, la majeure partie des coûts d’un projet de secours informatique réside souvent dans le pilotage, les études, les travaux d’infrastructures et le secours des données. Au final, les serveurs ne représentent parfois que 10 à 20% de l’investissement total. L’économie réalisée n’est donc pas nécessairement conséquente.

Par ailleurs, le secours sur pré-production peut également impliquer des coûts spécifiques. Bien souvent il s’agira de déménager les serveurs de pré-production, en général situés à proximité de ceux de production, et de les mettre à niveau en termes de configuration avec ces derniers. Il s’agira également d’études techniques complémentaires (ex : comment faire cohabiter des environnements de pré-production et de secours sur un même serveur?) pouvant nécessiter des enveloppes de charges supplémentaires. Enfin, en cas de coordination avec les métiers pour prise en compte de leurs contraintes (application en cours d’évolution, correction de bugs récurrents, …), des charges de gestion de projet complémentaires sont à prévoir.

Autant de points pouvant rendre le secours sur pré-production aussi voire plus onéreux qu’une solution dédiée de secours. Il convient donc de bien évaluer son coût en fonction de ces différents paramètres et de le comparer aux coûts des autres solutions envisagées.

Ne pas réduire le secours sur pré-production à sa composante économique

« La solution du bon sens est la dernière à laquelle songent les spécialistes » citait l’éditeur Bernard Grasset.

Nous l’avons vu, et contrairement à ce que le bon sens nous le laissait imaginer, le secours sur pré-production n’est pas une garantie d’économie.

Cette solution est à privilégier dans des contextes matures (maîtrise forte du processus de mise en production et des environnements hors production par la DSI), pour des applications stables (n’évoluant pas ou peu) et des environnements techniques adaptés.

Autant d’éléments à prendre en compte avant d’acter ou non la mise en œuvre de cette solution, notamment à l’aide de projets de virtualisation des environnements…

Cet article La pré-production constitue-t-elle la meilleure solution de continuité informatique ? est apparu en premier sur RiskInsight.

Préparer les dispositions RH applicables en anticipant les changements des conditions de travail en situation de crise

Au-delà du sinistre lui-même et de ses éventuelles conséquences sur les personnes physiques, qui réclament naturellement un accompagnement particulier des Ressources Humaines, la Continuité d’Activité appelle une contribution importante de leur part.

Il est en effet primordial de retenir le postulat suivant : le déclenchement d’un PCA entraîne très souvent des modifications des conditions de travail des collaborateurs de l’organisation sinistrée ; repli sur un lieu différent du site habituel, maintien à domicile de collaborateurs, pic d’activité ou réaffectation de personnels sur des activités, etc. Ces modifications nécessitent d’être anticipées, a minima préparées et idéalement validées par la filière RH.

Plusieurs thématiques, le plus souvent liées au contrat de travail des collaborateurs, sont à traiter. En voici quelques illustrations :

Nouveau lieu d’exercice d’activité pour les collaborateurs

La continuité d’activité peut être assurée au travers d’un dispositif de repli sur un site alternatif plus ou moins éloigné du site nominal, auquel cas les problématiques de lieu de travail (prévues ou non dans le contrat de travail), de transport, de gestion de frais (liés au déplacement, à la restauration et à l’hébergement des collaborateurs mobilisés), d’assurance et d’éloignement vis-à-vis des familles doivent être abordées et arbitrées.

Ex : On pourra envisager, pour les fonctions considérées comme « critiques », l’intégration de clauses spécifiques à la continuité d’activité au sein des fiches de poste ou des contrats de travail concernés.

Solution de travail à distance depuis le domicile

Dans des circonstances exceptionnelles évoquées par l’article 46 de la Loi Poisson cette solution ne relève plus du « télétravail » et de ses conditions d’exercice très encadrées. Néanmoins, le décret d’application associé n’étant jamais paru, les RH sont pertinentes pour adresser les aspects juridiques de cette solution.

Modification du temps de travail

L’exercice d’une activité secourue, parfois en mode dégradé, amène le plus souvent une modification du temps de travail. La prise en compte de ces changements est une attente forte des collaborateurs concernés et doit être anticipée (primes exceptionnelles, paiement des heures supplémentaires, etc.).

Interruption d’activité prolongée

Par construction, le PCA n’assure le maintien que des activités les plus critiques. Dès lors, des activités resteront interrompues de manière plus ou moins prolongées. Les personnels concernés seront de fait sans activité, à moins d’avoir été mobilisés sur d’autres activités. Se posent les questions du maintien de salaire, de l’exploitation des mécanismes de RTT ou de congés payés, du recours au chômage partiel dans des conditions parfaitement définies, etc. Là encore, les RH seront force de proposition sur les dispositions à appliquer et sur les conditions de leur mise en œuvre.

Construire la boite à outils RH du PCA

Une bonne pratique consiste à constituer, pour et avec les acteurs des Ressources Humaines embarqués dans la gestion de crise, une « boîte à outils » regroupant toutes les informations utiles à la mise en œuvre les dispositions RH d’accompagnement du PCA.

Sous la forme de fiches pratiques, de procédures et de modèles types, cette « boîte à outil RH » vise à accroître l’efficacité et la sensibilité des acteurs RH et de leurs suppléants et, plus largement, à renforcer le dispositif de continuité élaboré :

• Procédures de mise à jour des intranets, extranets, numéros verts sous la responsabilité de la filière RH, dans le cadre de la communication de crise
• Procédures d’extraction et des coordonnées personnelles des collaborateurs
• Liste et coordonnées des partenaires sociaux, IRP
• Liste et coordonnées des partenaires externes et conseils RH
• Démarche de mise en place d’une cellule de soutien psychologique
• Courriers, lettres de mission et modèles d’avenants types
• Support type pour les communications auprès des IRP
• Procédures dérogatoires types à communiquer à l’Inspection du Travail ou aux IRP
• Etc.

Impliquer et sensibiliser le management et les instances représentatives du personnel (IRP)

Au regard des impacts potentiels des différentes dispositions RH envisageables, il convient de présenter et d’arbitrer avec le management les modes de réponse à retenir dans le contexte de l’organisation. Par ailleurs, la substance de ces dispositions devra être évoquée aux Instances Représentatives du Personnel (IRP) afin de clarifier les principes RH pressentis en cas de déclenchement du PCA.

Ces présentations constituent pour le Responsable PCA une très belle opportunité de sensibilisation au PCA et à ses enjeux, étant entendu qu’il ne s’agit pas de modifier les conditions de travail mais d’identifier les ajustements provisoires déployés pour contribuer à assurer la survie de l’organisation. L’expérience montre que, même si les collaborateurs font souvent preuve de compréhension et d’empathie lors de sinistres, l’anticipation et la préparation des situations facilitent le traitement de la crise.

In fine, la mobilisation de la filière RH permet d’affiner si nécessaire la stratégie de continuité en l’alignant avec la règlementation et les pratiques RH de l’organisation mais surtout de la légitimer auprès de l’ensemble des collaborateurs. Enfin, cette contribution doit s’inscrire dans la durée, en impliquant la filière RH dans la gouvernance dela Continuitéd’activité.

Cet article Continuité d’activité : n’oubliez pas d’impliquer les ressources humaines ! est apparu en premier sur RiskInsight.

La panne logicielle : un incident complexe à diagnostiquer et à traiter

Les pannes logicielles sont difficiles à diagnostiquer du fait d’interconnexions toujours plus importantes au sein des systèmes d’information, d’une supervision plus complexe et plus « spécifique » que pour les problèmes matériels ainsi que d’impacts plus diversifiés et difficilement prévisibles.

Le PRA se focalise bien souvent sur les pannes matérielles, dont le traitement suit un principe simple : un matériel de secours remplace, de façon plus ou moins automatique, un matériel défaillant.

Ce principe n’est généralement pas applicable pour les pannes logicielles, plus complexes à traiter, à différents niveaux de la chaîne de liaison applicative :

• Données : la réplication fréquemment utilisée pour traiter des pannes matérielles entraîne la propagation rapide de données corrompues vers les infrastructures de secours. Afin de s’en prémunir, des mécanismes de réplication logicielle peuvent être mis en place afin de pouvoir revenir à des états cohérents exempts de données corrompues. En dernier ressort, la restauration de clones ou de sauvegardes (plus longue) peut être utilisée.
• Systèmes applicatifs : développés en interne par l’entreprise ou par des éditeurs tiers, ils visent à répondre à certains besoins métiers précis. Leur déploiement peut ainsi être limité, ce qui réduit les expertises existantes et le nombre de tests conduits lors des changements, pour raisons économiques. Les premiers à migrer en font parfois les frais ! Par ailleurs, le fait de les placer sur des infrastructures de haute-disponibilité de type cluster ne change pas le problème : si le logiciel dysfonctionne, ce sera sur l’ensemble de l’infrastructure, car il n’est souvent pas possible de faire cohabiter plusieurs versions d’un logiciel sur un même cluster.
• Frontaux : ils utilisent souvent des logiciels largement répandus, extrêmement stables, et sont assez peu souvent à l’origine de problèmes logiciels. Des effets de bord sur les systèmes applicatifs peuvent néanmoins apparaître.

Toutefois, l’entreprise n’est pas totalement démunie face à ce type d’incidents, et peut en réduire le nombre en respectant quelques principes évoqués ci-après.

Porter une grande attention à la gestion des changements critiques

Les incidents récents le confirment une nouvelle fois : la majorité des pannes logicielles majeures interviennent lors de changements. Outre les bonnes pratiques généralement évoquées (tester largement et sur des infrastructures proches de la production, préparer le retour arrière sur les aspects techniques et organisationnels, renforcer les équipes et définir des astreintes, …), l’entreprise doit porter une attention particulière aux changements critiques. Elle doit ainsi :

• Identifier ces changements et les partager largement au sein des équipes ;
• Réduire le nombre de changements critiques simultanés (a fortiori s’ils présentent des interdépendances), afin de ne pas accroître les risques et complexifier le diagnostic ;
• Renforcer le contrôle des opérations très sensibles (deux personnes pour une même manipulation par exemple).

Privilégier les architectures asynchrones

Une certaine dichotomie existe pour le traitement des pannes matérielles et logicielles. Si les architectures synchrones sont bien adaptées aux premières, un asynchronisme peut grandement faciliter le traitement des pannes logicielles.

Les architectures asynchrones permettent en effet de ne pas propager immédiatement les erreurs et de revenir plus facilement dans des états cohérents, puis de rejouer les transactions jusqu’à l’instant de la panne. Le découpage du SI qu’elles induisent permet également d’éviter la panne globale des systèmes, en rendant possible l’interruption de certains composants sans impact immédiat pour les autres.

Se mettre en capacité de gérer les erreurs de manière pro-active

L’incident d’Orange l’a montré : les pannes logicielles peuvent se produire de manière progressive, en surchargeant peu à peu le SI.

La mise en place de systèmes de mesure et de supervision, la définition de valeurs de charges et de temps de réponse normatifs et leur comparaison régulière avec l’état actuel des systèmes peut permettre de prévenir les incidents avant que des indisponibilités majeures ne surviennent.

Orange a en ce sens, contrairement à ce qu’évoquent certains observateurs, bien assuré sa gestion de crise. Nombre de ses ingénieurs ont été mis en alerte après les premiers signes de fléchissement du réseau, et la communication qui a accompagné et suivi la panne a été bien maîtrisée.

Utiliser des méthodes de validation formelle ?

Des méthodes reposant sur la preuve formelle permettent d’assurer la sûreté logicielle. Elles nécessitent des expertises pointues et un processus de développement bien plus lourd et long que les méthodes traditionnelles, et restent aujourd’hui confinées aux systèmes embarqués critiques.

Leur utilisation pour d’autres usages pourra être envisagée, mais le compromis entre coûts de développement et couverture de risques s’avèrera difficile à trouver !

Cet article Pannes logicielles : la zone d’ombre du PRA (Plan de Reprise d’Activité) est apparu en premier sur RiskInsight.