AccueilđŸ‡«đŸ‡·Chercher

Gestion des incidents dans un centre de calcul

La gestion des incidents en centre de calcul est le processus utilisĂ© pour rĂ©pondre tout Ă©vĂ©nement qui perturbe, ou pourrait perturber, un service informatique. Ces processus sont pour la plupart issus d'ITIL qui est un ensemble d'ouvrages recensant les bonnes pratiques (best practices) du management du systĂšme d'information. Ces processus de gestion des incidents ont Ă©galement Ă©tĂ© adaptĂ©s par les grands acteurs du Cloud. Alors que les plans de continuitĂ© d’activitĂ© font partie des moyens pour limiter les interruptions de service, la prise en compte en amont des ressources nĂ©cessaires dans la construction des datacenters est un Ă©lĂ©ment primordial pour leur bon fonctionnement. L’impact des incidents peut avoir des consĂ©quences pour des millions d’utilisateurs Ă  travers le monde.

Enjeux de la gestion des incidents en centre de calcul (Datacenter)

Les donnĂ©es Ă©tant l’une des principales valeurs liĂ©es Ă  l’activitĂ© des entreprises; il est crucial de pouvoir y accĂ©der Ă  tout moment, et de veiller Ă  leur conservation. Le Cloud fournit des ressources informatiques, logiciel applicatif ou matĂ©rielles accessibles Ă  distance en tant que service[1]. Ces ressources sont hĂ©bergĂ©es dans des datacenters qui sont l’un des Ă©lĂ©ments nĂ©cessaires au traitement et stockage des donnĂ©es numĂ©riques. ConcrĂštement, il s’agit d’un lieu physique contenant les serveurs informatiques qui stockent les donnĂ©es numĂ©riques, et dans lequel les entreprises peuvent notamment louer un espace de stockage et ainsi Ă©viter la prĂ©sence de serveurs dans leurs locaux[2]. La disponibilitĂ© de ces ressources se traduit par un contrat appelĂ© Service Level Agrement (SLA) ou niveau de service. Il correspond au niveau de service garanti, c’est-Ă -dire aux engagements pris par le fournisseur[1]. La gestion des incidents a pour but de rĂ©tablir le service le plus rapidement possible et de rĂ©duire l’impact sur l'entreprise afin de rĂ©pondre Ă  l’accord sur les niveaux de services.

Les centres de calcul concentrent de plus en plus de puissance de calcul et de stockage et deviennent critiques pour les services (au sens ITIL[3] du terme); pour l'entreprise, ce sont des centaines de millions d’euros qui transitent chaque jour dans ces centres. À titre d’exemple, une panne de 5 minutes Ă©quivaut Ă  une perte de 2,9 millions de dollars chez Apple, 1,4 million de dollars chez Amazon, ou encore, 21 500 dollars chez Twitter (source Ivision.fr).

Documents de références sur la gestion des incidents

Expectation for Computer Security Incident Response

En juin 1998 la publication de la RFC 2350[4] dĂ©crit pour la premiĂšre fois de maniĂšre formelle l’organisation, la structure, les services et les modes opĂ©ratoires d’une structure de rĂ©ponse aux incidents[5].

National Institute of Standards and Technology

Le NIST[6] dĂ©taille un modĂšle d’organisation et de traitement lui aussi basĂ© sur le cycle de vie d’un incident dans le guide intitulĂ© Computer Security Incident Handling Guide initialement publiĂ© en 2004 et dont la derniĂšre rĂ©vision date de 2012[7]. Ce modĂšle, qui prend ses racines dans les travaux menĂ©s par l’US Navy puis par le SANS Institute[8], est semblable au modĂšle de l’ISO 27035:2011 au nombre de phases prĂšs, soit quatre phases sont identifiĂ©es au lieu de cinq, les deux phases post-incident de l’ISO Ă©tant regroupĂ©es en une seule :

  1. la phase ‘PrĂ©parer’ (Preparation) organisĂ©e autour de deux volets : prĂ©parer et Ă©viter les incidents.
  2. la phase ‘DĂ©tecter et Analyser’ (Detection and Analysis) contenant sept volets : les vecteurs d’attaque, les signes d’un incident, les sources d’information, l’analyse de l’incident, la documentation de l’incident, la gestion des prioritĂ©s et la notification de l’incident.
  3. la phase ‘Contenir, Eradiquer et Restaurer’ (Containment, Eradication and Recovery) prĂ©sentĂ©e en quatre volets : choisir une stratĂ©gie d’isolation, relever et gĂ©rer les Ă©lĂ©ments de preuve, identifier les systĂšmes attaquant, Ă©radiquer et restaurer.
  4. la phase ‘GĂ©rer l’aprĂšs-incident’ (Post-Incident Activity) scindĂ©e en trois volets : les leçons acquises, l’utilisation des donnĂ©es collectĂ©es et la conservation des Ă©lĂ©ments de preuve.

Il discerne l’existence d’un cycle entre les deux phases actives du traitement, les phases 2 et 3, lesquelles peuvent ĂȘtre dĂ©roulĂ©es alternativement pour affiner le traitement et ceci au fur et Ă  mesure de la progression dans l’analyse et de la connaissance que l’on acquiert de l’incident, de ses atteintes et de ses consĂ©quences[5].

European Union Agency for Cybersecurity

PubliĂ© fin 2010 par l'ENISA[9] et en anglais uniquement, le guide Good Practice Guide for Incident Management[10] traite de l’ensemble de la problĂ©matique de la mise en Ɠuvre d’une structure de gestion des incidents. Il propose Ă  ce titre, une organisation de la gestion des incidents autour des diffĂ©rents services susceptibles d’ĂȘtre offerts et dont le traitement d’un incident n’est qu’une composante. L’ENISA[9] s’inspire ici du modĂšle fondateur initiĂ© en 2004 par le CERT Carnegie Mellon[11] dans son document Defining Incident Management Processes for CSIRTs: A Work in Progress[12] :

  1. la détection.
  2. le triage.
  3. l’analyse.
  4. la réponse.

ISO 27035

En 2016, la norme ISO/IEC 27035-1:2016 Information Security Incident Management[13] prĂ©sente un modĂšle d’organisation de l’activitĂ© de rĂ©ponse aux incidents s’appuyant sur le cycle de vie d’un incident. Celui-ci se dĂ©compose en cinq phases :

  1. phase de planification et de préparation (Plan and prepare).
  2. phase de détection et de rapport (Detection and reporting).
  3. phase d’analyse et de dĂ©cision (Assessment and decision).
  4. phase de réponses (Responses).
  5. phase de retour d’expĂ©rience (Lessons learnt).

ITIL

PubliĂ© en 2019, la version 4 de l'ITIL est un ensemble de livres prĂ©sentant de nombreuses pratiques, procĂ©dures et mĂ©thodes utilisĂ©es dans la gestion des systĂšmes d’information. Le concept central est l’apport de valeur aux clients. La publication des premiers Ă©lĂ©ments par la CCTA[14] date de la fin des annĂ©es 1980. Depuis plusieurs versions ont Ă©tĂ© Ă©ditĂ©es : ITIL V2 (2001), ITIL V3 (2007 puis 2011), ITIL V4 (2019)[15]. Dans sa version la plus dĂ©ployĂ©e (V3), la gestion des services ITIL supporte ces transformations Ă  travers l’utilisation du cycle de vie des services qui comprend cinq Ă©tapes :

  1. Stratégie des services.
  2. Conception des services.
  3. Transition des services.
  4. Exploitation des services.
  5. Amélioration continue des services.

La gestion des incidents se situe au niveau de l’exploitation des services qui comprend Ă©galement la gestion des Ă©vĂ©nements, l'exĂ©cution des requĂȘtes, la gestion des problĂšmes, la gestion des accĂšs.

ITIL, un modĂšle pour la gestion des incidents

DĂ©finition, Ă©volution et convergence

DĂ©finition de l’ITIL

L’ITIL est un ensemble d’ouvrages recensant les bonnes pratiques de management des systĂšmes d’information. Ce rĂ©fĂ©rentiel, nĂ© dans les annĂ©es 1980, a su s’imposer au sein des DSI comme la rĂ©fĂ©rence concernant la gestion des services informatiques ITSM[16], ou IT Service Management) en permettant, grĂące Ă  une approche par processus clairement dĂ©finie et contrĂŽlĂ©e, d’amĂ©liorer la qualitĂ© des SI et des Services d'assistance aux utilisateurs.

Les quatre fondements de l’ITIL sont basĂ©s sur des processus dĂ©taillĂ©s et une documentation trĂšs lourde (plusieurs centaines de pages) :

  1. ITIL décrit avec détails les processus permettant une qualité de service robuste.
  2. La documentation est trÚs fournie. Les ouvrages ITIL sont composés de plusieurs centaines de pages.
  3. Passer des accords contractuels et respecter les accords de services (SLA, pour Service Level Management) est un des fondements d’ITIL.
  4. Certains processus peuvent se montrer inflexibles vis-à-vis du plan initialement prévu, comme le processus de gestion des changements nécessitant encore trÚs souvent un passage en CAB (Change Advisory Board, comité de validation des changements).

ITIL est structurĂ© autour du cycle de vie d’un service, rĂ©partit en 5 Ă©tapes :

  1. La stratĂ©gie du service dont l’objectif est de comprendre les clients IT, dĂ©finir l’offre rĂ©pondant aux besoins des clients, les capacitĂ©s et ressources nĂ©cessaires au dĂ©veloppement de service et identifier les moyens de succĂšs pour une exĂ©cution rĂ©ussie.
  2. La conception du service assure que les nouveaux services et ceux modifiĂ©s soient conçus efficacement, en termes de technologie et d’architecture, afin de satisfaire les attentes du client. Les processus sont aussi pris en considĂ©ration dans cette phase.
  3. La transition du service intÚgre la gestion du changement, le contrÎle des actifs et de la configuration, la validation, les tests et la planification de la mise en fonction du service afin de préparer la mise en production.
  4. L’exploitation du service fournit le service de maniùre continue et le surveille quotidiennement.
  5. L’amĂ©lioration continue du service permet au service Technologies de l'information et de la communication de mesurer et d’amĂ©liorer le service, la technologie ainsi que l’efficacitĂ© et l’efficience dans la gestion gĂ©nĂ©rale des services.

Le site ITIL France[17], devenu LaBoutique ITSM[16] depuis la sortie en français de la version 4 du rĂ©fĂ©rentiel ITIL, propose, outre, les archives de la version 3 (2007 puis 2011), ainsi qu’une prĂ©sentation de l’ITIL4.

L'ITIL se compose de cinq volumes qui décrivent l'intégralité du cycle de vie ITSM[16] conformément à la définition d'AXELOS[18]:

  1. volume "Stratégie des services" décrit comment concevoir, développer et implémenter la gestion des services en tant qu'actif stratégique.
  2. volume "Conception des services" décrit comment concevoir et développer des services et des processus de gestion des services.
  3. volume "Transformation des services" décrit le développement et l'amélioration des capacités pour transformer les services nouveaux et modifiés en opérations.
  4. volume "Fonctionnement des services" décrit les pratiques de gestion du fonctionnement des services.
  5. volume "Amélioration continue des services" dirige la création et la préservation des valeurs pour les clients.

En dĂ©cembre 2017, dans son article "ITIL : renaissance ou dernier soupir ?"[19], M. Alain Bonneaud Ă©crivait sur le blog de la transformation digitale, que l’ITIL commençait Ă  prendre de l’ñge. AXELOS, propriĂ©taire du rĂ©fĂ©rentiel, se dĂ©fendait en indiquant que l’ITIL est "l’approche la plus largement utilisĂ©e pour la gestion des Technologies de l'information et de la communication dans le monde". La sociĂ©tĂ© indiquait non seulement qu’il existait des millions de praticiens d’ITIL dans le monde, mais aussi que le rĂ©fĂ©rentiel Ă©tait utilisĂ© par la majoritĂ© des grandes organisations pour gĂ©rer leurs opĂ©rations informatiques.

MĂ©thode Agile et ITIL 4 : l’avĂšnement de l’IT Service Management Agile

L’agilitĂ© a su au fil du temps convaincre les DSI et imposer ses principes et ses mĂ©thodes afin de transformer en profondeur les façons de travailler. Les entreprises ont ainsi pu dĂ©livrer de façon plus rapide leurs projets tout en Ă©vitant l’effet tunnel que confĂšrent les mĂ©thodes plus traditionnelles et en restant focalisĂ© au maximum sur les besoins et attentes des clients. L’enjeu est de savoir “comment s’agiliser en respectant les bonnes pratiques d’ITIL ?”[20]

De façon historique, ITIL et les mĂ©thodes agiles ne sont rien d’autre que des bonnes pratiques appliquĂ©es respectivement Ă  la production Technologies de l'information et de la communication et au dĂ©veloppement IT. En effet, ITIL donne un cadre de rĂ©fĂ©rence au travers des processus dĂ©finis et fortement documentĂ©s, mais n’impose pas une maniĂšre particuliĂšre d’exĂ©cuter les tĂąches. L’agilitĂ© est, elle, avant tout un ensemble de pratiques et de mĂ©thodes de travail dont les principes aident Ă  la rĂ©activitĂ© et Ă  la flexibilitĂ©.

Et dans une organisation s’inspirant d’ITIL, les bonnes pratiques agiles arrivent Ă  coexister et Ă  s’adapter aux nouveaux modĂšles opĂ©rationnels.

ITIL 4 : La derniĂšre version d’ITIL qui s’adapte aux enjeux de l’agilitĂ©, du Lean et du DevOps

Axelos, l’organisme propriĂ©taire d’ITIL, a publiĂ© en 2019 la nouvelle version du rĂ©fĂ©rentiel ITIL, nommĂ©e ITIL 4 Edition. Cette nouvelle Ă©dition a redessinĂ© les principes dĂ©jĂ  bien Ă©tablis de l’ITSM[16] en prenant compte les nouveaux enjeux technologiques et les nouveaux modes de fonctionnements, tels que l’agilitĂ©, le Lean[21] ou encore DevOps[22] - [23]. Cette nouvelle version encourage les organisations Ă  casser les silos, Ă  favoriser la collaboration et la communication au sein-mĂȘme des organisations, et Ă  s’adapter aux nouvelles tendances IT. ITIL incite Ă©galement ses pratiquants Ă  conserver des pratiques simples et pragmatiques, ce qui peut se traduire par une reconnaissance du fait que trop d’organisations ont tentĂ© par le passĂ© de mettre en Ɠuvre ITIL au pied de la lettre, rendant l’ITSM[16] complexe et peu flexible.

Outre l’émergence de nouveaux concepts ou l’adaptation de notions dĂ©jĂ  existantes, la documentation a complĂštement Ă©tĂ© revisitĂ©e afin de la rendre plus synthĂ©tique et aisĂ©e Ă  la lecture. Elle est notamment accompagnĂ©e de nombreux exemples pratiques. L’ouvrage ITIL Foundation illustre mĂȘme en fil rouge les pĂ©ripĂ©ties d’une entreprise fictive vis-Ă -vis de ses pratiques ITIL.

Le Service Value System (SVS) : un systĂšme de cocrĂ©ation de valeur adaptĂ© aux concepts de l’agilitĂ©, du DevOps et du Lean

L’élĂ©ment cƓur d’ITIL 4 est le concept de Service Value System (SVS). Celui-ci dĂ©crit comment les composants et les activitĂ©s d’une organisation s’articulent dans le but de crĂ©er de la valeur. Ce systĂšme s’interface avec les autres organisations, formant tout un Ă©cosystĂšme pouvant Ă©galement dĂ©livrer de la valeur Ă  ces organisations et aux parties prenantes.

Pour supporter les activités de la Service Value Chain, des capacités appelées practices ont été définies comme des collections de ressources de différentes natures (appelées les 4 dimensions du service management), affectées par de multiples facteurs externes (politiques, technologiques, environnementaux etc.) :

  1. Organisations et personnes.
  2. Information & technologie.
  3. Partenaires & fournisseurs.
  4. Flux de valeurs & processus.

ITIL 4 propose un modĂšle d’amĂ©lioration continue pouvant s’appliquer Ă  l’ensemble des Ă©lĂ©ments du Service Value System (practices, SVC
). Ce modĂšle se veut reprĂ©senter un guide Ă  haut niveau pour accompagner les initiatives d’amĂ©lioration, en mettant un gros point d’attention sur la valeur client, et en assurant la cohĂ©rence avec la vision de l’organisation. Le modĂšle, s’inscrivant dans les principes de l’agilitĂ©, introduit une approche itĂ©rative et divise les tĂąches en objectifs pouvant ĂȘtre atteints de façon incrĂ©mentale.

Les principes directeurs ITIL 4

Pour guider toutes ces activitĂ©s, ITIL 4 pose des principes directeurs (guiding principles), dĂ©finis comme des recommandations qui guident une organisation en toute circonstance, indĂ©pendamment de ses objectifs, de sa stratĂ©gie ou de sa structure. Les principes directeurs d’ITIL 4 sont :

  1. Se concentrer sur la valeur, englobant notamment la prise en compte de l’expĂ©rience client et utilisateur.
  2. Commencer Ă  partir de l’existant, sans forcĂ©ment faire table rase de l’existant.
  3. Avancer de façon itérative, avec des feedbacks à chaque fin de cycle.
  4. Promouvoir la collaboration et la visibilité du travail accompli.
  5. Penser de façon holistique, afin de pouvoir coordonner les activités globalement.
  6. DĂ©livrer des choses simples et pratiques.
  7. Optimiser et automatiser, et concentrer les interventions des ressources humaines lĂ  oĂč elles dĂ©livrent rĂ©ellement de la valeur.

Ces principes directeurs peuvent s’appliquer Ă  tous les Ă©lĂ©ments du systĂšme, incluant la gouvernance du Service Value System.

L’ITSM Agile, ou la combinaison du meilleur des deux mondes

Appliquer la philosophie et les modes de fonctionnement ITSM[16] agiles au sein des productions informatiques est compatible avec les pratiques Ă©prouvĂ©es de l’IT Service Management. Les deux pratiques ont su montrer au fil du temps les gains qu’ils pouvaient apporter aux organisations, et leur synergie permet d’optimiser l’efficacitĂ© au sein des DSI. ITIL 4 vient asseoir cette proximitĂ© en offrant un cadre adaptĂ© aux rĂ©centes tendances que sont l’agilitĂ©, le Lean[21] IT, DevOps ou encore le Cloud computing. Il convient ainsi de s’appuyer sur la philosophie initiale d’ITIL : s’inspirer des bonnes pratiques et les appliquer afin qu’elles conviennent le mieux aux organisations.

ITIL et Facilities Management

Il y a deux mondes qui se cĂŽtoient dans les centres de donnĂ©es : les Ă©quipes de la DSI et celles du Facilities Management[24]. Leur pĂ©rimĂštre technique est assez bien dĂ©limitĂ©, leurs objectifs aussi
 Ces deux Ă©quipes auraient tout intĂ©rĂȘt Ă  se parler, se comprendre, agir en cohĂ©rence pour garantir l’orientation client.

ITIL est connu depuis 30 ans, et l’effort a Ă©tĂ© marquĂ© dans les annĂ©es 2007/2009 du cĂŽtĂ© des DSI. Plus que jamais, ITIL devrait ĂȘtre au centre des prĂ©occupations des managers et des directions de ces centres avant que le dĂ©ploiement des solutions matĂ©rielles et logiciel applicatif de FM des centres de donnĂ©es.
Avec les rĂ©sultats bien connus d’ITIL (les prioritĂ©s et les criticitĂ©s des Ă©vĂ©nements et incidents identifiĂ©s, des incidents Ă©vitĂ©s ou minimisĂ©s, les activitĂ©s organisĂ©es et planifiĂ©es, les informations remontĂ©es complĂštes et Ă©conomes
), de notables bĂ©nĂ©fices sont habituellement rĂ©alisĂ©s (un centre de coĂ»t qui peut Ă©voluer en centre de profit ; un profit et un CA qui croient aussi vite (ou plus) que le marchĂ© moyen, chaque € est investi Ă  bon escient, en termes de technologies, de personnels, de partenariats, un personnel impliquĂ© et motivĂ©, des clients rassurĂ©s et fidĂšles
).

Une approche pragmatique, adaptĂ©e, partielle et progressive d’ITIL au sein des dĂ©partements chargĂ©s du Facilities Management des centres de donnĂ©es, peut rester simple, rapide et pas chĂšre.

Gestion des incidents - Processus

Pour une meilleure appropriation du processus, il est intéressant de consulter la section "Gestion des incidents" du glossaire ITIL[25].

La Gestion des incidents[26] est un processus ITIL qui fait partie de la phase "Exploitation des services". Selon le rĂ©fĂ©rentiel ITIL, l'objectif du processus de Gestion des incidents est de rĂ©tablir le service le plus rapidement possible, en ayant un minimum d’impacts sur les opĂ©rations courantes.

« LaBoutique ITSM »[17] dĂ©taille trĂšs prĂ©cisĂ©ment La Gestion des incidents sous les items suivants : But ; Objectifs ; ActivitĂ©s ; Echelles de temps et modĂšle d'incident ; PrioritĂ© d’un incident ; Exemple de grille de calcul ; Types d'escalade ; SchĂ©ma du processus avec les diffĂ©rents niveaux de support ; Interfaces entre gestion des incidents et gestion des problĂšmes ; Apport de valeur pour l'entreprise et pour le fournisseur de services ; Perte de valeur avec l’absence d’un processus performant ; DĂ©fis classiques

Objectifs

Les objectifs du processus de Gestion des incidents sont :

  • Veiller Ă  ce que des mĂ©thodes et des procĂ©dures normalisĂ©es soient utilisĂ©es pour rĂ©pondre, analyser, documenter, gĂ©rer et suivre efficacement les incidents.
  • Augmenter la visibilitĂ© et la communication des incidents Ă  l'entreprise et aux groupes de soutien IT.
  • AmĂ©liorer la perception des utilisateurs par rapport Ă  l'IT via une approche professionnelle dans la communication et la rĂ©solution rapide des incidents lorsqu'ils se produisent.
  • Harmoniser les activitĂ©s et les prioritĂ©s de gestion des incidents avec ceux de l'entreprise.
  • Maintenir la satisfaction de l'utilisateur avec la qualitĂ© des services IT.

Champ d'application

La Gestion des incidents inclut tout événement qui perturbe, ou pourrait perturber, un service. Ceci inclut les événements communiqués directement par les utilisateurs, via le Centre de services[27], une interface web ou autrement.

MĂȘme si les incidents et les demandes de service sont rapportĂ©s au Centre de services, cela ne veut pas dire qu'ils sont de mĂȘme type. Les demandes de service ne reprĂ©sentent pas une perturbation de service comme le sont les incidents. Voir le processus ExĂ©cution des requĂȘtes pour plus d'information sur le processus qui gĂšre le cycle de vie des demandes de service.

Valeur

La valeur qu'apporte la Gestion des incidents est en lien direct avec la réduction des travaux non planifiés et des coûts causés par les incidents, autant pour l'entreprise que les ressources IT, la détection et la résolution efficace des incidents, améliore la disponibilité des services. cela contribue à l'alignement des activités Technologies de l'information et de la communication avec les priorités de l'entreprise ; la gestion des incidents inclut la capacité d'identifier les priorités d'affaires et d'allouer les ressources nécessaires, mais aussi à l'identification des améliorations potentielles des services ; on y arrive en comprenant mieux de quoi est constitué un incident et aussi en connaissant mieux les activités du personnel de l'organisation. Le Centre de service peut également, pendant le traitement des incidents, identifier des besoins additionnels en service ou en formation.

La Gestion des incidents est hautement visible Ă  l'entreprise ; il est par consĂ©quent plus facile de dĂ©montrer sa valeur en comparaison aux autres processus prĂ©sents dans la phase d'Exploitation des services. C'est la raison pour laquelle il est souvent le premier processus Ă  ĂȘtre implantĂ©.

DĂ©lais
Des dĂ©lais doivent ĂȘtre convenus pour les incidents selon leur prioritĂ© ; ceci inclut des cibles de rĂ©ponse et de rĂ©solution. Tous les groupes d'intervention doivent ĂȘtre avisĂ©s de ces cibles et des dĂ©lais. L'outil devrait ĂȘtre en mesure d'automatiser les dĂ©lais et d'escalader les incidents basĂ©s sur des rĂšgles prĂ©dĂ©finies.

ModĂšles d'incident
Un modĂšle d'incident est un gabarit qui peut ĂȘtre rĂ©utilisĂ© pour des incidents rĂ©currents. Il peut ĂȘtre pratique de prĂ©dĂ©finir des modĂšles d'incidents standard et de les appliquer lorsqu'ils surviennent, pour une saisie et un traitement plus rapides.

Incidents majeurs
Une procĂ©dures sĂ©parĂ©e, avec des dĂ©lais plus rapides et une urgence plus Ă©levĂ©e, doit ĂȘtre utilisĂ©e pour les incidents majeurs. Une dĂ©finition de ce qui constitue un incident majeur doit ĂȘtre convenue et incluse dans la structure de priorisation des incidents. Lorsque nĂ©cessaire, une Ă©quipe spĂ©ciale peut ĂȘtre invoquĂ©e par le gestionnaire des incidents afin de s'assurer que les ressources adĂ©quates et le focus soient fournis pour trouver une solution rapide.

Suivi du statut des incidents

Au cours du cycle de vie des incidents, cinq statuts différents interviennent.

  1. Nouveau : un incident est soumis, mais n'a pas été assigné à un groupe ou une ressource pour résolution.
  2. Assigné : un incident est assigné à un groupe ou une ressource pour résolution.
  3. En traitement : l'incident est en cours d'investigation pour résolution.
  4. Résolu : une résolution a été mise en place.
  5. Fermé : la résolution a été confirmée par l'utilisateur comme quoi le service normal est rétabli.
Processus de Gestion des incidents


En rĂ©sumĂ©, ITIL est largement utilisĂ© pour la gestion des Technologies de l'information et de la communication. Mais l’évolution rapide des technologies basĂ©es sur le Cloud, les nouvelles approches telles que DevOps et l’enracinement des mĂ©thodologies agiles ont remis en question bon nombre de mĂ©thodes, apparemment rigides et bureaucratiques, souvent associĂ©es Ă  ITIL[28]. D’autres mĂ©thodes ont vu le jour comme VeriSM[29] ou existent depuis des annĂ©es comme TOGAF[30]

Sur la partie gestion d’incident la version 4 d’ITIL adapte le processus aux nouveaux modĂšles opĂ©rationnels agiles dans lesquels les pratiques et processus ont Ă©tĂ© modifiĂ©s. La collaboration et les Ă©changes sont fluidifiĂ©s, et les Ă©quipes disposent de plus d’autonomie sur leurs pĂ©rimĂštres. Par exemple, lors d’un incident majeur, diffĂ©rentes parties prenantes sont mobilisĂ©es au sein d’une task force et collaborent ensemble, jusqu’à ce que l’entitĂ© la plus Ă  mĂȘme de rĂ©soudre l’incident soit identifiĂ©e. Pendant que les autres peuvent retourner Ă  leurs tĂąches habituelles, celle-ci est autonome et dispose de tous les moyens nĂ©cessaires pour rĂ©soudre l’incident majeur. Elle possĂšde Ă©galement toute la lĂ©gitimitĂ© de mobiliser diffĂ©rents acteurs de l’organisation au besoin[31].

Plan de ContinuitĂ© d’ActivitĂ© - Plan de Reprise d’ActivitĂ©

Le Plan de ContinuitĂ© d’ActivitĂ© (PCA) et le Plan de reprise d'activitĂ© (PRA) ont pour objectif de poursuivre ou de reprendre les activitĂ©s informatiques avec un temps d’interruption minimum des services. Les contraintes propres Ă  chaque entreprise sont gĂ©nĂ©ralement mesurĂ©es avec l’aide de deux indicateurs : le RTO (Recovery Time Objective) qui traduit le temps maximal admissible avant reprise[32], et le RPO (Recovery Point Objective) qui spĂ©cifie la fraĂźcheur minimale des systĂšmes restaurĂ©s. Une Ă©tude rĂ©alisĂ©e par le cabinet d’analyse Forrester et le Disaster Recovery Journal en 2017, donne un Ă©clairage intĂ©ressant sur le niveau de prĂ©paration des entreprises face Ă  une reprise sur sinistre un exemple avec l'incident Bull Chorus le 27/06/13[33]. Seulement 18 % des entreprises interrogĂ©es s’estiment parfaitement prĂ©parĂ©es au dĂ©clenchement des processus de reprise, plus de 45 % des organisations indiquent qu’elles ne disposent pas d’une coordination centrale des processus de reprise, seulement 19 % des entreprises sont en mesure de tester leurs processus de reprise plus d’une fois par an, et prĂšs de 21 % ne les testent jamais. Lors d’un sinistre, c’est bien le temps de rĂ©action de l’organisation, le fameux RTO qui va dĂ©terminer le niveau de l’impact sur les activitĂ©s mĂ©tier. Temps de dĂ©tection des problĂšmes, temps de prise de dĂ©cision, temps d’exĂ©cution des procĂ©dures de reprise, temps de contrĂŽle des systĂšmes aprĂšs reprise... la durĂ©e cumulĂ©e de toutes ces opĂ©rations doit ĂȘtre infĂ©rieure au RTO qui a Ă©tĂ© dĂ©fini dans le cadre du PRA.

Étapes essentielles Ă  la conception d’un plan de reprise d’activitĂ©

1. RĂ©aliser un audit de tous les risques de pannes possibles sur le systĂšme d’information et en identifier les causes probables : panne matĂ©rielle, panne logicielle, cyberattaque, coupures Ă©lectriques, incendie, catastrophe naturelle, erreur humaine, etc.

2. DĂ©tecter et Ă©valuer chaque risque afin d'identifier les applications mĂ©tiers qui ne pourront pas fonctionner en mode dĂ©gradĂ©. Il est donc nĂ©cessaire de bien apprĂ©hender et mesurer la tolĂ©rance aux pannes de l’ensemble du systĂšme d’information.

3. DĂ©finir la criticitĂ© des environnements applicatifs et les besoins de sauvegarde et rĂ©plication ainsi que de restauration qui devront s’appliquer. Devront ĂȘtre dĂ©finis ici le RTO (Recovery Time Objective) et le RPO (Recovery Point Ojective).

4. PrĂ©voir des sauvegardes automatiques Ă  une frĂ©quence correspondant au besoin de l’organisation.

5. Faire du « Crisis Management » (Attribution de rĂŽles et de tĂąches Ă  des personnes identifiĂ©es, qui auront la responsabilitĂ© d’intervenir le moment venu. Il s'agit donc d'organiser et de mobiliser ses Ă©quipes dans le but d'agir efficacement au moment du sinistre.)

6. DĂ©finir des prioritĂ©s et un coĂ»t de reprise d’activitĂ© : Évaluation des seuils d’indisponibilitĂ© des services, pour ensuite les prioriser afin de dĂ©finir le coĂ»t de remise en service de l’infrastructure. Dans certains cas, la reprise d’activitĂ© devra pouvoir s’effectuer en moins d’une minute. La mise en place nĂ©cessaire d’environnements synchrones peut alors rapidement Ă©lever les coĂ»ts.

7. DĂ©finir le choix de l’équipement de sauvegarde et de reprise d’activitĂ© ainsi que le budget qui y sera consacrĂ©. Dans certains cas, le doublement simple du matĂ©riel existant sur un site distant, peut ĂȘtre insuffisant. C'est pourquoi, le choix du matĂ©riel est important s'il doit supporter la charge d’une remise en service.

8. Tester rĂ©guliĂšrement le Plan de reprise d'activitĂ© : bien que le coĂ»t d’un test de Plan de reprise d'activitĂ© informatique soit consĂ©quent, il est impĂ©ratif d’évaluer rĂ©guliĂšrement sa fiabilitĂ© au moins deux fois par an.

9. Faire Ă©voluer le Plan de reprise d'activitĂ© en fonction des changements apportĂ©s Ă  un systĂšme d’information en constante Ă©volution.

10. Documenter prĂ©cisĂ©ment le PRA, par le retour d’expĂ©riences des acteurs garants de la fiabilitĂ© du Plan de reprise d'activitĂ©. Le partage de la connaissance du SI va directement affecter les performances d’un Plan de reprise d'activitĂ© informatique. Ainsi, les phases de tests ou les remontĂ©es d’échecs doivent ĂȘtre systĂ©matiquement documentĂ©es, ce qui est gĂ©nĂ©ralement peu souvent le cas.

11. Prendre en compte les contraintes rĂ©glementaires auxquels certaines typologies d’organisations doivent se conformer dans l’exĂ©cution de leurs activitĂ©s.

Le portail du MinistĂšre de l’économie et des finances met Ă  disposition une ressource documentĂ©e, intitulĂ©e "Informations sur la mĂ©thodologie d’un PCA[34]". Chaque entreprise avance diffĂ©remment dans sa stratĂ©gie de sauvegarde et de protection de ses donnĂ©es numĂ©riques. Certaines disposent dĂ©jĂ  d’un Plan de reprise d'activitĂ© associĂ© Ă  un PCA, d’autres ont initiĂ© des dĂ©marches prĂ©liminaires auprĂšs de prestataires spĂ©cialisĂ©s ou Ă©valuent simplement la pertinence d’un Plan de reprise d'activitĂ© / PCA pour leur organisation[35]. Parmi ces stades d’avancement autour d’un projet de Plan de reprise d'activitĂ© informatique, certaines interrogations doivent ĂȘtre levĂ©es en amont : quel pĂ©rimĂštre peut couvrir un prestataire dans la rĂ©alisation d’un Plan de reprise d'activitĂ© informatique ? Quels sont les Ă©lĂ©ments qui doivent ĂȘtre pris en charge par le prestataire et consignĂ©s dans le contrat de Plan de reprise d'activitĂ© ? En cas de panne, quelles sont les garanties de retrouver ses services, ses donnĂ©es et sous quels dĂ©lais ? Quelle sera la capacitĂ© du prestataire Ă  dĂ©tecter d’éventuels risques futurs et quelle sa rĂ©activitĂ© pour en alerter l’entreprise ? Que l’on parle d’un Plan de reprise d'activitĂ© sur site ou dans un datacenters, la transparence des informations et la nature des communications entre le prestataire et l’entreprise sont essentielles Ă  la tenue d’un Plan de reprise d'activitĂ© qui soit performant. La qualitĂ© du Plan de reprise d'activitĂ© repose Ă©galement sur la capacitĂ© d’une Ă©quipe technique Ă  remettre en cause rĂ©guliĂšrement la fiabilitĂ© de son infrastructure et ce, pendant toute la durĂ©e du contrat.

Les 3 dĂ©fis du RĂ©tablissement de l’ActivitĂ©

1. Les hommes

Le propre d’un sinistre est qu’il se produit toujours au moment oĂč on ne l’attend pas. Il convient donc rester prudent et rĂ©aliste, quant Ă  ses capacitĂ©s de rĂ©unir les bonnes compĂ©tences, au bon endroit, au bon moment. Des expĂ©riences comme une catastrophe naturelle, une Ă©pidĂ©mie de grippe, ont montrĂ© que les systĂšmes d’astreinte les plus Ă©laborĂ©s peuvent ĂȘtre dĂ©faillants. Lors d’incendies ou d’inondations majeures notamment, une partie significative des Ă©quipes impliquĂ©es dans l’exĂ©cution du Plan de reprise d'activitĂ© peuvent en effet ĂȘtre concernĂ©es par des Ă©vacuations obligatoires. Ces dĂ©fections imprĂ©visibles par nature peuvent ralentir les processus de reprise, faute d’avoir sous la main le spĂ©cialiste indispensable Ă  une opĂ©ration ou tout simplement le dĂ©tenteur d’un mot de passe.

2. Les changements

Le meilleur ennemi du PRA reste certainement les changements qui sont apportĂ©s aux infrastructures et applications postĂ©rieurement Ă  l’établissement du PRA. Ainsi, des inconsistances critiques peuvent apparaĂźtre dans les procĂ©dures de reprise, et mettre en Ă©chec le redĂ©marrage des activitĂ©s, si le plan n'est pas rĂ©guliĂšrement mis Ă  jour. Il est donc indispensable de centraliser ces changements dans le but de mettre Ă  jour les procĂ©dures du PRA. C’est une problĂ©matique qui dĂ©passe souvent les limites d’une gouvernance classique basĂ©e sur une CMDB, puisque l’on traite de procĂ©dures opĂ©rationnelles trĂšs granulaires, comme des scripts de nettoyage ou de redĂ©marrage. Le plus souvent dispersĂ©es dans l’ensemble du systĂšme d’information, ces procĂ©dures sont frĂ©quemment mal rĂ©fĂ©rencĂ©es. Une bonne pratique consiste Ă  jouer ces Plan de reprise d'activitĂ© de façon pĂ©riodique pour vĂ©rifier l’adĂ©quation Ă  l’architecture de production.

3. Les priorités

Focaliser ses ressources sur ce qui est rĂ©ellement important, est essentiel. Cela parait ĂȘtre une Ă©vidence car toutes les activitĂ©s de l’entreprise n’ont pas la mĂȘme valeur, pas la mĂȘme criticitĂ©. Pourtant les systĂšmes sont aujourd’hui de plus en plus complexes, interconnectĂ©s et dĂ©pendent les uns des autres comme cela n'avait jamais Ă©tĂ© envisagĂ© auparavant. Piloter efficacement les Ă©quipes techniques dans la pĂ©riode de stress intense que constitue une reprise d’activitĂ©, est donc nĂ©cessaire. Cette phase nĂ©cessite une parfaite visibilitĂ© sur l’ordonnancement et l’avancement des opĂ©rations, non seulement pour permettre de faire des choix judicieux mais aussi pour informer en continu les Ă©quipes de management.

L’automatisation du Plan de RĂ©tablissement d’ActivitĂ©

L’étude rĂ©alisĂ©e par Gartner en 2017 sur le recouvrement d’activitĂ©, indique que prĂšs de trois quarts des entreprises n’ont pas encore automatisĂ© les procĂ©dures de reprise impliquĂ©es dans le PRA. Ce sont donc des entreprises qui dĂ©pendent presque entiĂšrement du facteur humain pour redĂ©marrer leurs activitĂ©s. Pourtant l’automatisation reste une solution de choix pour pallier l’indisponibilitĂ© des Ă©quipes, centraliser les changements et gĂ©rer efficacement la priorisation des redĂ©marrages en fonction des dĂ©pendances entre systĂšmes, quelle que soit leur complexitĂ©. L’automatisation des processus permet en outre de soulager les diffĂ©rents intervenants des tĂąches manuelles et rĂ©pĂ©titives, offrant de meilleures perspectives pour tester rĂ©guliĂšrement les procĂ©dures de reprise. Face Ă  la multiplication des risques de toutes natures, les organisations informatiques doivent veiller Ă  assurer leur rĂ©silience. Si le Plan de reprise d'activitĂ© formalise les moyens et les objectifs, il ne faut pas nĂ©anmoins sous-estimer la difficultĂ© des aspects opĂ©rationnels dans un moment de grande tension. Comme souvent, l’automatisation y trouve toute sa place.

L'incidentologie en Datacenter

Les principales sources d'incidents en DataCenter

Publicly Reported Outages

L’Uptime Institute[36] a publiĂ© en mars 2019 son Publicly Reported Outages 2018-19[37].

En 2018 lors de la sortie du 8th Annual Industry Survey[38], l’Uptime Institute avait indiquĂ© qu’un tiers (30,8 %) des opĂ©rateurs de datacenters interrogĂ©s avaient subis une coupure ou une sĂ©vĂšre dĂ©gradation de service durant l’annĂ©e 2017. Le rapport 2019[39] basĂ© sur les incidents rendus publics dans des mĂ©dias montre une tendance Ă  la hausse avec prĂšs de 3 fois plus d’incidents en 2018 qu’en 2016. Ceci ne signifie pas nĂ©cessairement qu’il se soit produits plus d’incidents mais est plutĂŽt le signe d’une visibilitĂ© accrue dans les mĂ©dias ce qui a permis une amĂ©lioration de la collecte des donnĂ©es.

Outage distribution over providers and years.

L’enquĂȘte intitulĂ©e Systematic survey of public cloud service outage donne une volumĂ©trie d’incidents sur le top 5 des fournisseurs de Cloud public. Cette Ă©tude a Ă©tĂ© effectuĂ©e sur des incidents du Cloud public en utilisant l’approche SLR (Systematic Literature Review). Au total l’étude a collectĂ© 112 Ă©vĂšnements liĂ©s Ă  des pannes de service. Les donnĂ©es montrent que chacun des fournisseurs de Cloud ont subi des pannes sans oublier qu’il y a aussi les incidents n’ayant pas Ă©tĂ© dĂ©clarĂ©s[40].


Pour qualifier l’impact des incidents rendus publics, l’Uptime Institute a crĂ©Ă© une Ă©chelle de criticitĂ© Ă  5 niveaux[39] :

TypeClassementImpact de l'incident
Catégorie 1NégligeableIncident tracé mais avec peu ou pas d'impact évident sur le service, pas d'interruption de service
Catégorie 2MinimeInterruption de service. Effet minime sur les utilisateurs/clients et sur l'image de marque
Catégorie 3SignificatifInterruption de service pour les clients/utilisateurs, scope principalement limité en durée ou en effet. Effet financier minime ou nul. Quelques impacts sur l'image de marque ou sur des aspects juridiques.
Catégorie 4SérieuxInterruption de service et/ou d'opération. Conséquences incluant des pertes financiÚres, violation juridiques, dommage sur l'image de marque, atteinte à la sécurité. Perte de clients.
Catégorie 5SévÚreInterruption ou dommage majeur sur le service et/ou les opérations avec des conséquences incluant des pertes financiÚres importantes, des problÚmes de sécurité, des violations juridiques, des pertes de clients, des dommages sur l'image de marque

En 2018, la plupart des incidents rendus publics sont d’une sĂ©vĂ©ritĂ© basse Ă  moyenne. En regardant sur les trois annĂ©es on constate un changement significatif : La proportion des incidents de niveau 5 (sĂ©vĂšre, incidents critique pour le business) chute alors que le nombre d’incidents moins critiques enregistrĂ©s augmente[41].

Reported outages levels

Le rĂ©sultat de l’étude montre que les systĂšmes informatiques sont la cause la plus courante des pannes. Suivent le rĂ©seau et l’alimentation Ă©lectrique.

L’alimentation Ă©lectrique, le refroidissement, les incendies et leur extinction cumulĂ©es restent une cause importante des pannes (32 %)[42]. En plus, des coupures classĂ©es dans « systĂšmes informatiques (IT) » et rĂ©seau sont en fait causĂ©es par des problĂšmes d’alimentation au niveau d’un systĂšme ou d’une baie et ne sont pas classĂ©s comme des problĂšmes d’alimentation de l’ensemble du datacenters[43].

Causes of outages

Dans son Ă©tude triennale (2010,203,2016) intitulĂ©e Cost of Data Center Outages january 2016[44] du Ponemon Institute[45], les pannes d'alimentations Ă©lectriques arrivent en tĂȘte avec 25 % (2016).

Root causes of unplanned outages


La déclinaison du processus de gestion des incidents chez Google

Ce processus est dĂ©crit dans le document Google Cloud Whitepaper. Il rĂ©pertorie les diffĂ©rentes phases en dĂ©taillant le dĂ©roulement des actions et procĂ©dures liĂ©es Ă  la gestion d’incidents. Pour Google un incident liĂ© aux donnĂ©es dĂ©fini est comme une violation de la sĂ©curitĂ© qui entraĂźne, de maniĂšre accidentelle ou illĂ©gale, la destruction, la perte, l'altĂ©ration ou encore la divulgation non autorisĂ©e des donnĂ©es client sur des systĂšmes ou encore l'accĂšs non autorisĂ© Ă  ces donnĂ©es[46].

Identification

Le but de cette phase d’identification est de surveiller les Ă©vĂ©nements liĂ©s Ă  la sĂ©curitĂ© (journaux systĂšme et rĂ©seau, processus de dĂ©tection des intrusions, examens de la sĂ©curitĂ© logicielle et du code source, anomalies d'utilisation
) afin de dĂ©tecter et de signaler les Ă©ventuels incidents relatifs aux donnĂ©es. Des outils de dĂ©tection avancĂ©s, ainsi que des signaux et des mĂ©canismes d'alerte qui permettent d'identifier rapidement les incidents potentiels[47].

Incident response workflow

Coordination

Dans cette phase un chargĂ© d’incident va Ă©valuer la nature, la gravitĂ© de l’incident et de dĂ©ployer une Ă©quipe d'intervention adaptĂ©e. Un chef de produit et un responsable juridique sont chargĂ©s de prendre les dĂ©cisions clĂ©s concernant la marche Ă  suivre. Le chargĂ© d'incidents attribue les rĂŽles pour l'enquĂȘte et les faits sont rassemblĂ©s[48].

RĂ©solution

L’objectif de cette phase est multiple : Recherche de la cause premiĂšre, la limitation de l'impact de l'incident, la rĂ©solution des risques immĂ©diats Ă  la sĂ©curitĂ©, la mise en Ɠuvre des correctifs nĂ©cessaires dans le cadre de la rĂ©solution ainsi que la restauration des systĂšmes, donnĂ©es et services affectĂ©s. Un point important de la rĂ©solution est l’information des clients sur les incidents impactant leurs donnĂ©es[49].

ClĂŽture

AprĂšs la rĂ©solution, l'Ă©quipe de gestion des incidents capitalise sur les causes et son dĂ©roulement afin d’identifier les principaux points Ă  amĂ©liorer. En cas de problĂšmes critiques une analyse post-mortem peut ĂȘtre lancĂ©e par le chargĂ© d'incidents[50].

Amélioration continue

Incidents management and services

Les axes d’amĂ©lioration vont ĂȘtre trouvĂ©s grĂące Ă  l’exploitation des informations obtenues lors de l'analyse des incidents. Ces amĂ©liorations peuvent concerner les outils, les processus, les formations, le programme global de sĂ©curitĂ©, les rĂšgles de sĂ©curitĂ© et/ou les efforts de rĂ©ponse. Ces enseignements facilitent Ă©galement la hiĂ©rarchisation des dĂ©marches d'ingĂ©nierie Ă  mener et la conception de meilleurs produits[51].

Domaines de responsabilité suivant le type de service cloud

Suivant le type de service, les domaines de responsabilitĂ© pour la gestion d’incidents dĂ©pendent des offres souscrites auprĂšs du Cloud Service Provider (CSP). La figure ci_dessous illustre le partage de la responsabilitĂ© entre le client et Google en fonction de l'Ă©tendue des services gĂ©rĂ©s exploitĂ©s par le client. Lorsque le client passe de solutions sur site Ă  des offres de cloud computing IaaS, PaaS et SaaS, Google gĂšre une plus grande partie du service Cloud global, dĂ©chargeant d'autant le client en matiĂšre de responsabilitĂ©s de sĂ©curitĂ©[52].

Amazon Web Services et la gestion des incidents dans le cloud

Schéma intégration CAF.

Amazon Web Services (AWS) propose un large éventail de produits internationaux basés sur le Cloud : calcul, stockage, bases de données, analyse, mise en réseau, services mobiles, outils de développement, outils de gestion, Internet des objets, sécurité et applications d'entreprise[53].

AWS utilise l'infrastructure d'adoption du Cloud (Cloud Adoption Framework / CAF)[54] qui propose des directives complĂštes pour Ă©tablir, dĂ©velopper et exĂ©cuter des fonctionnalitĂ©s informatiques basĂ©es sur le Cloud. À l'instar de l'ITIL, la CAF organise et dĂ©crit les activitĂ©s et processus impliquĂ©s dans la planification, la crĂ©ation, la gestion et la prise en charge des Technologies de l'information et de la communication modernes.

Schéma CloudWatch.

Avec l’API Amazon CloudWatch, AWS prend en charge l'instrumentation en fournissant des outils pour publier et interroger les Ă©vĂšnements. L’API peut Ă©galement envoyer des notifications ou modifier des ressources automatiquement en fonctions de rĂšgles dĂ©finies par le client. Il est possible de superviser l’utilisation des processeurs, les Ă©critures disques des instances comme les machines viturelles, des mĂ©triques venant d’applications mĂ©tiers
 etc etc[55]

La gestion des incidents s’effectue grĂące Ă  des Ă©vĂšnements catĂ©gorisĂ©s comme des avertissements ou des exceptions qui peuvent dĂ©clencher des processus. Ces processus restaurent le fonctionnement normal des services aussi rapidement que possible et minimisent les impacts nĂ©gatifs sur les opĂ©rations mĂ©tier ou ĂȘtre orientĂ© vers le centre de services de l’entreprise cliente[56].

En complĂ©ment de CloudWatch, l’application Auto Scaling proposĂ©e par AWS peut permettre de contrĂŽle vos applications et l’ajustement automatique de la capacitĂ© Ă  maintenir des performances constantes et prĂ©visibles[57].



Incidents dans les datacenters : le top 7 des plus importantes pannes Cloud en 2019

Le Cloud (nuage) a sĂ©duit ces derniĂšres annĂ©es, grĂące Ă  ses nombreux avantages en termes de flexibilitĂ©, de simplicitĂ© et mĂȘme de coĂ»t, tant les entreprises que les particuliers. Le nuage permet ainsi d’accĂ©der Ă  ses fichiers et documents depuis n’importe quel appareil et depuis n’importe oĂč, et les entreprises n’ont plus besoin de dĂ©velopper leurs propres infrastructures, alliant ainsi simplicitĂ© et rĂ©duction des charges.

Cependant, les utilisateurs de Cloud font aussi le choix de confier la sĂ©curitĂ© et la sĂ»retĂ© de leurs donnĂ©es Ă  leurs fournisseurs. En migrant leurs donnĂ©es et applications sur les serveurs d’un fournisseur, plutĂŽt que sur leurs propres Data Centers, les entreprises acceptent de vouer une confiance aveugle Ă  leur prestataire. Or, de nombreuses pannes survenues en 2019 nous rappellent que le Cloud est loin d’ĂȘtre infaillible et d’ĂȘtre synonyme de sĂ©curitĂ©, et que la dĂ©pendance Ă  cette technologie comporte bien des risques, dĂ©montrant que le Cloud.

Les 7 plus importantes pannes Cloud qui ont secouĂ© l’annĂ©e 2019[58].

Amazon Web Services

En aoĂ»t 2019, un Data Center US-EAST-1 appartenant Ă  AWS et situĂ© en Virginie du Nord, a Ă©tĂ© frappĂ© par une panne d’électricitĂ©. L’interruption de service a Ă©tĂ© recensĂ©e par le site spĂ©cialisĂ© Downdetector[59]. Les gĂ©nĂ©rateurs de backup du centre de donnĂ©es sont donc tombĂ©s en panne. 7,5 % des instances Amazon Elastic Compute Cloud (EC2) et des volumes Amazon Elastic Block Store (EBS) sont restĂ©s temporairement indisponibles[60], d’une part, et d’autre part, aprĂšs que le courant ait Ă©tĂ© restaurĂ©, Amazon a annoncĂ© que certaines des donnĂ©es stockĂ©es sur le hardware endommagĂ© ne pourraient pas ĂȘtre rĂ©cupĂ©rĂ©es. Ainsi, des informations prĂ©cieuses ont donc Ă©tĂ© dĂ©finitivement perdues par certains clients.

Apple iCloud

En juillet 2019, de nombreux utilisateurs de l’iCloud d’Apple sont restĂ©s dans l’incapacitĂ© d’accĂ©der au service pendant plusieurs heures. Plusieurs services Apple tels que l’App Store, Apple Music, Apple TV, Apple Books et Apple ID ont Ă©tĂ© affectĂ©s. De mĂȘme, des fonctionnalitĂ©s telles que « Trouver mon iPhone » Ă©taient indisponibles durant l’incident. Apple a associĂ© cette panne Ă  un problĂšme de « BGP route flap » qui a provoquĂ© d’importantes pertes de donnĂ©es pour un grand nombre d’utilisateurs.

Cloudflare

En juillet 2019, les visiteurs de Cloudflare ont reçu des erreurs 502, erreurs causĂ©es par un pic d’utilisation de CPU sur le rĂ©seau, ce pic lui-mĂȘme causĂ© par un dĂ©ploiement de logiciel ratĂ© [61]. Durant 30 minutes, le service est restĂ© en panne jusqu’à ce que le dĂ©ploiement soit annulĂ©.

Facebook et Instagram

Bien qu’il ne s’agisse pas de services Cloud Ă  proprement parler, Facebook et Instagram reposent fortement sur le nuage. En 2019, un changement de configuration de serveur a provoquĂ© une panne de ces rĂ©seaux sociaux, pendant prĂšs de 14 heures (problĂšmes d’accĂšs et fonctionnalitĂ©s telles que la publication ou la messagerie Messenger inaccessibles).

Google Cloud

Google Cloud Platform a Ă©tĂ© victime de deux pannes majeures en 2019. En juillet, un problĂšme avec le Cloud Networking et le Load Balancing a contraint Google Ă  sĂ©parer les serveurs de la rĂ©gion US-east1 du reste du monde[62], causant des dommages physiques Ă  de multiples bundles de fibre concurrents servant les ponts rĂ©seau de la rĂ©gion. En novembre 2019, plusieurs services de la Google Cloud Platform (Cloud Dataflow, stockage Cloud, et Compute Engine) ont Ă©tĂ© affectĂ©s par d’importants problĂšmes[63], affectant de nombreux produits Ă  l’échelle mondiale.

Microsoft Azure

En mai 2019, une dĂ©lĂ©gation de nom de serveur incorrecte a affectĂ© la rĂ©solution DNS et la connectivitĂ© rĂ©seau de Microsoft Azure. Pendant plus d’une heure, les services Microsoft Office 365, Microsoft Teams ou encore Xbox Live sont restĂ©s inaccessibles. Il reste cependant Ă  noter que les enregistrements DNS des clients n’ont pas Ă©tĂ© affectĂ©s aprĂšs la restauration des services.

Salesforce

En mai 2019, le dĂ©ploiement d’un script de base de donnĂ©es sur le service Pardot Marketing Cloud de Salesforce a provoquĂ© un grave incident[64], accordant aux utilisateurs ordinaires des permissions d’un niveau supĂ©rieur. Afin d’éviter que les employĂ©s dĂ©robent des donnĂ©es sensibles Ă  leurs entreprises, Salesforce a dĂ» bloquer de nombreux utilisateurs puis bloquer l’accĂšs Ă  d’autres services tels que Sales Cloud et Service Cloud. Ainsi, pendant plus de 20 heures, les clients Ă©taient dans l’incapacitĂ© d’accĂ©der Ă  Pardot Marketing Cloud. Il aura fallu 12 jours pour que les autres services tels que Sales Cloud et Service Cloud soient dĂ©ployĂ©s. L’intĂ©gralitĂ© de l’infrastructure Cloud de Salesforce a donc Ă©tĂ© affectĂ©e par un simple script


Focus sur des incidents redoutables de type « cascade » dans un data center tels que vécu par OVHcloud en novembre 2017

OVHcloud et la loi de Murphy, situation improbable vĂ©cue par OVHcloud, jeudi 9 novembre 2017. Juste aprĂšs 7 heures, son data center de Strasbourg a perdu simultanĂ©ment ses deux alimentations Ă©lectriques principales. Deux groupes Ă©lectrogĂšnes, qui auraient dĂ» pallier ces ruptures d’alimentations Ă©lectriques EDF et prendre le relais sans coupure, n’ont pas dĂ©marrĂ©, et sont restĂ©s dĂ©sespĂ©rĂ©ment hors service. Moins d’une heure plus tard, les liaisons en fibre optique reliant un autre de ses data center Ă  Roubaix et plusieurs NƓud (rĂ©seau)|nƓuds d’interconnexions d’Internet[65], des lieux fondamentaux oĂč s’interconnectent les grands acteurs du secteur (fournisseurs d’accĂšs Ă  Internet, GAFAM, hĂ©bergeurs de contenus 
) cessaient de fonctionner. Par rĂ©percussions, les donnĂ©es hĂ©bergĂ©es par OVHcloud Ă  Roubaix ne pouvaient plus atteindre ces Ă©changeurs autoroutiers de l’Internet[66] - [67], environ 3 millions de sites web Ă©taient inaccessibles. Les effets de bords sont rapidement perçus et affectent les gĂ©ants du Net, les premiers Ă  s’enquĂ©rir de prendre des nouvelles chez OVHcloud sont les GAFAM, ils proposent mĂȘme leur aide Ă  OVHcloud. En effet, ces incidents ont des effets nĂ©gatifs sur des flux consĂ©quents de donnĂ©es qui transitent via leurs propres data center.

Deux pannes rares

RĂ©sultat de ces deux pannes combinĂ©es : des centaines de sites Internet hĂ©bergĂ©s chez OVHcloud ont Ă©tĂ© inaccessibles pendant plusieurs heures, le temps pour les Ă©quipes d’OVHcloud de redĂ©marrer les serveurs Ă  Strasbourg et de rĂ©tablir les liaisons optiques de Roubaix. La concomitance de ces deux pannes est exceptionnelle, voire improbables dans des scĂ©narios de PRA. Le PDG et fondateur d’OVHcloud, Octave Klaba[68] a fait part du dĂ©roulement des opĂ©rations au fil de l’eau sur Twitter dans la rĂ©solution des problĂšmes ainsi que la mise Ă  jour du portail Web travaux.OVHcloud.net[69] avec un rapport de clĂŽture de l'incident. Cette communication via Twitter permanente a Ă©tĂ© prĂ©pondĂ©rante dans cette gestion de crise aiguĂ« ; le capital de confiance et de crĂ©dibilitĂ© d’OVHcloud avait dĂ©jĂ  Ă©tĂ© Ă©cornĂ© lors d'un premier incident critique au mois de juin 2017[70].

Dans un premier bilan publiĂ© Ă  la mi-journĂ©e, OVHcloud a expliquĂ© que l’interruption des liaisons en fibre optique Ă©tait due Ă  un « bug logiciel », depuis corrigĂ©. AprĂšs rĂ©paration, la situation est rapidement revenue Ă  la normale sur ce front. À Strasbourg, le processus de redĂ©marrage des serveurs informatiques a pris plus de temps. Si l’électricitĂ© a Ă©tĂ© totalement rĂ©tablie, certains services Ă©taient encore en cours de rĂ©tablissement en dĂ©but d’aprĂšs-midi. L’entreprise ÉlectricitĂ© de Strasbourg (filiale d’EDF) qui alimente le centre de donnĂ©es alsacien d’OVHcloud a Ă©voquĂ© sans plus de prĂ©cisions un dĂ©faut physique sur le cĂąble souterrain qui alimentait le centre de donnĂ©es AprĂšs l’échec du dĂ©marrage des groupes Ă©lectrogĂšnes, l’entreprise a dĂ©ployĂ© en urgence un cĂąble de remplacement, rĂ©tablissant le courant vers OVHcloud aprĂšs trois heures et demie de coupure. Il n'existe pas Ă  ce jour de rapport post mortem sur cette panne Ă©nergĂ©tique.

Les ressources nécessaires pour les Datacenters

L’impact spatial et Ă©nergĂ©tique des datacenters sur les territoires

Face Ă  la croissance massive des Ă©changes de donnĂ©es et des besoins de stockage, l’impact spatial et Ă©nergĂ©tique des datacenters Centre de donnĂ©es va ĂȘtre de plus en plus structurant pour les territoires. Leur diversitĂ© d’usages, d’acteurs, de tailles et d’implantations rend aujourd’hui complexe la lecture de leurs dynamiques et de leurs effets spatiaux. En fĂ©vrier 2019, CĂ©cile Diguet et Fanny Lopez(dir.), ont proposĂ©, pour l'ADEME[71], un rapport intitulĂ© "L’Impact spatial et Ă©nergĂ©tique des datacenters sur les territoires"[72].

Le rapport s’attache Ă  donner une image du paysage des datacenters en Île-de-France et dans trois territoires des États-Unis, reprĂ©sentant chacun des situationsspatiales et Ă©nergĂ©tiques diffĂ©rentes(ville dense, espace pĂ©riphĂ©rique, rural). Facteur potentiel de dĂ©sĂ©quilibre des systĂšmes Ă©nergĂ©tiques locaux, objets dont l’accumulation urbaine et la dispersion rurale questionnent, les datacenters font dans ce rapport, l’objet d’une analyse approfondie pour mieux apprĂ©hender les nouveaux territoires numĂ©riques en construction, les solidaritĂ©s Ă©nergĂ©tiques Ă  construire et les alliances d’acteurs Ă  mettre en place.

Un focus est Ă©galement rĂ©alisĂ© sur les infrastructures numĂ©riques alternatives et citoyennes, qui se dĂ©veloppent aussi bien en Afrique, AmĂ©rique du Sud, que dans les territoires mal couverts en Europe ou aux États-Unis. DĂ©diĂ©es Ă  l’accĂšs Ă  Internet et de plus en plus, aux services d’hĂ©bergement et de Cloud, elles peuvent constituer une rĂ©ponse distribuĂ©e et pair-Ă -pair, dont l’impact Ă©cologique pourrait finalement se rĂ©vĂ©ler plus limitĂ© que les infrastructures centralisĂ©es de grande Ă©chelle car calibrĂ©es au plus prĂšs des besoins locaux, mais aussi plus rĂ©silientes car moins centralisĂ©es techniquement et moins concentrĂ©es spatialement. Elles constituent ainsi une option Ă  considĂ©rer, soutenir mais aussi Ă  mieux Ă©valuer, pour rĂ©duire les impacts spatiaux et Ă©nergĂ©tiques des datacenters.

Le rapport propose Ă©galement des visions prospectives qui combinent des tendances de fond et des signaux faibles pour imaginer les mondes numĂ©riques de demain, basĂ©s sur la croissance et l'ultracentralisation numĂ©rique, la stabilisation du SystĂšme Technique numĂ©rique et diversitĂ© infrastructurelle cela nĂ©cessite de traiter les aspects de rĂ©silience, mais aussi sur les bases du modĂšle actuel fondĂ© sur l'ultradĂ©centralisation numĂ©riques. Des recommandations sont proposĂ©es autour de trois axes, les acteurs et la gouvernance, l’urbanisme et l’environnement, et l’énergie. Des pistes d’approfondissement et d’études sont Ă©galement prĂ©sentĂ©es.

L'énergie consommée par les datacenters

La consommation des data centers à la base du réseau internet ne cesse de croßtre, au point de représenter 4 % de la consommation énergétique mondiale en 2015. La climatisation et les systÚmes de refroidissement représentent de 40 à 50 % de la consommation énergétique des data Centers[73]. Les data centers américains ont consommé 91 milliards de kilowatt-heure (kWh) en 2013 et 56 milliards en Europe (prévision : 104 milliards en 2020).

Le site Planetoscope, avec son "ConsoGlobe"[74], permet de suivre en direct cette consommation.

Localisation - Implantation du bĂątiment

Une entreprise australienne, Cloudscene[75] s’est donnĂ©e pour vocation de diffuser une information aussi exhaustive et transparente que possible sur les datacenters et fournisseurs de services Cloud : elle agrĂšge de l’information sur environ 4700 data centers et 4200 fournisseurs de service Cloud prĂ©sents dans 110 pays.

ORANGE avec l'ancrage de l'un de ses principaux datacenters Ă  Val-de-Rueil[76] s'est assurĂ© des meilleures garanties sur ses sources d'approvisionnement Ă©nergĂ©tiques, mais aussi sur la sĂ©curitĂ© du secteur d'implantation dans une zone gĂ©ographique tactique particuliĂšrement sous surveillance avec un centre de test stratĂ©gique des ArmĂ©es[77] dans son pĂ©rimĂštre ainsi qu'un centre de calcul EDF[78]. Le site d'EDF hĂ©berge entre autres des calculateurs scientifiques utilisĂ©s par la recherche et dĂ©veloppement mais aussi l’ingĂ©nierie nuclĂ©aire.

L'amĂ©nagement paysager du site vise souvent Ă  l’intĂ©grer au mieux dans le paysage environnant et Ă  respecter les prescriptions de rĂšglement de zone du plan local d'urbanisme (PLU).
L'implantation du bĂątiment est primordiale, tant pour lui-mĂȘme que pour l'environnement ; la prise en compte de la localisation dans un pĂ©rimĂštre "raisonnable" de distance avec les populations (minimum 500 mĂštres), en accord avec les paysages, les biens matĂ©riels, les patrimoines culturels et archĂ©ologiques, et bien sĂ»r, les donnĂ©es physiques et climatiques, et Ă©viter les zones oĂč le sismiques est non nĂ©gligeable (ou tout au moins prĂ©voir une conception antisismique (piliers sur amortisseurs)et Ă©quiper le bĂątiment de dĂ©tecteurs sismiques sur alarme), les zones inondables (ou prĂ©voir des constructions sur une butte (altitude 100 mĂštres), sur une zone non soumise au ruissellement et aux coulĂ©es de boue. Le terrain d'implantation d'un datacenters doit disposer d'un rĂ©seau d'Ă©vacuation sophistiquĂ© des eaux pluviales et de drains. La vĂ©gĂ©talisation du terrain doit Ă©galement participer Ă  minorer les risques d'inondations. Un datacenter peut Ă©galement ĂȘtre construit sur pilotis. En complĂ©ment de ces donnĂ©es, il convient de faire une Ă©tude en termes de sols et eaux souterraines (absence de nappe), eaux de surface, de qualitĂ© de l'air et odeurs, de niveaux sonores, de vibrations, d'Ă©missions lumineuses, limiter les risques sur le bĂątiment, Ă©viter qu'il soit situĂ© Ă  proximitĂ© d'un axe routier (une dĂ©flagration sur la route pourrait avoir un impact sur le bĂątiment), ou dans un couloir aĂ©rien, et privilĂ©gier les zones hors SEVESO[79]. Il faut Ă©galement tenir compte des espaces naturels, agricoles, forestiers et maritimes, de la faune et de la flore, des habitats naturels et Ă©quilibres biologiques, et de la continuitĂ© Ă©cologique.

Alimentation Ă©lectrique et climatisation

C'est de la fourniture continue de l’alimentation Ă©lectrique de Haute QualitĂ© des Ă©quipements informatiques et de la climatisation des salles informatiques, que dĂ©pend le fonctionnement correct des Ă©quipements informatiques. Ainsi, la conception d'un datacenters repose sur une certaine rĂ©pĂ©tition, redondance des infrastructures techniques au sein des bĂątiments techniques, des moyens de gĂ©nĂ©ration Ă©lectrique Haute QualitĂ© et de production froid (climatisation). Les bĂątiments techniques peuvent ĂȘtre Ă©quipĂ©s de moyens de production Ă©lectrique (groupes Ă©lectrogĂšnes), dispositifs de productions peuvent ĂȘtre eux-mĂȘmes redondĂ©s, ceci afin de parer une Ă©ventuelle perte des arrivĂ©es Ă©lectriques sur le site.

Les data centers stockant les donnĂ©es informatiques des clients sont soumis un dispositif composĂ© de rĂšgles importantes et indispensables Ă  leur bon fonctionnement (la tempĂ©rature, l’hygromĂ©trie et la qualitĂ© de l’air), un dispositif qui doit ĂȘtre constamment maĂźtrisĂ©.

En effet, les composants Ă©lectroniques des serveurs provoquant des dĂ©gagements de chaleur trĂšs importants, une tempĂ©rature Ă©levĂ©e peut entrainer non seulement un risque pour le bon fonctionnement des Ă©quipements, mais aussi une dĂ©gradation du matĂ©riel. La climatisation des locaux est une des solutions mise en place pour Ă©viter des problĂšmes de surchauffe des serveurs. En contribuant Ă  maintenir la tempĂ©rature ambiante des salles blanches, la climatisation influe donc sur la tempĂ©rature, sur la qualitĂ© de l’air ainsi que sur l’hygromĂ©trie, c’est-Ă -dire le taux d’humiditĂ© dans l’air.

Les Ă©quipements informatiques sont trĂšs sensibles Ă  la qualitĂ© de leur alimentation Ă©lectrique. Les infrastructures techniques doivent ĂȘtre conçues pour leur dĂ©livrer une Ă©nergie Ă©lectrique de Haute QualitĂ©, Ă  savoir une fourniture Ă©lectrique « propre », peu sensible aux variations de charge, dĂ©barrassĂ©e de toute perturbation ou anomalie et exempte de coupure ou microcoupure. Les onduleurs et les batteries assurent cette gĂ©nĂ©ration d’énergie Ă©lectrique Haute QualitĂ©. Des unitĂ©s de production Ă©lectrique (groupes Ă©lectrogĂšnes) prennent le relais, en cas d'une coupure Ă©lectrique prolongĂ©e sur le site.

Un datacenters doit pouvoir s'appuyer, au moins, sur des Ă©quipements tels que des onduleurs, des rĂ©serves d’énergie (batteries) et des groupes Ă©lectrogĂšnes, afin d’optimiser ces infrastructures techniques.

Dans le cadre du datacenters Val-de-Reuil[76], il est nĂ©cessaire de maintenir les serveurs informatiques Ă  une tempĂ©rature infĂ©rieure Ă  17–26 °C. C'est pourquoi, l’exploitation du site nĂ©cessite un systĂšme de refroidissement des installations. Des centrales de traitement de l’air (CTA) utilisant l’air extĂ©rieur, constituent essentiellement ce systĂšme. Cependant, il arrive que la tempĂ©rature de l’air extĂ©rieur soit trop Ă©levĂ©e pour garantir une tempĂ©rature suffisamment basse au niveau des serveurs (soit environ 15 Ă  20 % du temps) ; il convient alors de faire appel Ă  des groupes froids pour obtenir cette tempĂ©rature satisfaisante.
Pour le chauffage, la ventilation, et la climatisation (CVC) des bĂątiments informatiques : utilisation Ă  86 % du Free Cooling (ventilation avec de l’air sans utilisation des groupes froids). Lors de l’utilisation des groupes froids, production d’eau Ă  20/30 °C, ventilation double flux avec rĂ©cupĂ©ration de chaleur pour les communs.
Le Free Cooling permet de refroidir un bĂątiment en utilisant la diffĂ©rence de tempĂ©rature entre l’air extĂ©rieur et l’air intĂ©rieur. Le jour, le Free Cooling utilise l’air extĂ©rieur pour rafraĂźchir un bĂątiment, lorsque la tempĂ©rature extĂ©rieure est infĂ©rieure Ă  la tempĂ©rature intĂ©rieure.

Monitoring

Le monitoring est un ensemble de pratiques d'instrumentation des plates-formes de production, qui a pour objectif la production de mĂ©triques de performance. Il existe cinq niveaux distincts de monitoring pour rĂ©agir aux Ă©vĂ©nements qui surviennent dans les environnements de production. Ce sont gĂ©nĂ©ralement les mĂȘmes produits qui fournissent les services de mesure et de supervision. Les outils utilisĂ©s sont principalement des solutions d'Ă©diteurs de logiciels. Des solutions open source de qualitĂ© comme Nagios, Zenoss, ou plus rĂ©cemment depuis 2019 avec des versions stables Prometheus[80], voient leurs parts de marchĂ© progresser rĂ©guliĂšrement. Les cinq types de monitoring sont dĂ©clinĂ©s en cinq catĂ©gories de mĂ©triques :

  1. La disponibilité.
  2. Les temps de réponses.
  3. Temps de réponses détaillés.
  4. Activité métier.
  5. Expérience utilisateur.

Les offres de monitoring pour les services de disponibilitĂ© et les temps de rĂ©ponses sont nombreuses. Il n'en est pas de mĂȘme pour les temps de rĂ©ponses et de disponibilitĂ© des applications. Prometheus est une des solutions les plus en vue de l'Open source pour permettre de prendre en compte l'ensemble des mĂ©triques des catĂ©gories Ă  superviser.

Optimiser la gestion des incidents et en limiter l'impact : des solutions pour aujourd'hui et pour demain...

Le Cloud n’est donc pas toujours synonyme de sĂ©curitĂ©. Par ailleurs, les architectures informatiques traditionnelles ne sont plus du tout adaptĂ©s Ă  la rigueur du temps rĂ©el et donc de l’économie numĂ©riques actuelle. Mais mĂȘme les services Cloud - initialement mis en place pour remplacer les anciennes technologies "onsite" par des Ă©quivalents en ligne - pourraient ne plus suffire.

Des innovations en cours et Ă  venir se profilent, tant pour assurer la sĂ©curitĂ© du stockage des donnĂ©es, permettant d'optimiser la gestion des incidents et d'en limiter l'impact, mais Ă©galement pour maximiser et perfectionner le fonctionnement mĂȘme d'un datacenters.

La numĂ©risation de notre vie quotidienne gĂ©nĂšre une masse de donnĂ©es inimaginables et il va sans dire que notre dĂ©pendance vis-Ă -vis des datacenters qui traitent et stockent ces donnĂ©es ne fera que croĂźtre, tout comme le temps nĂ©cessaire pour en assurer la gestion. les entreprises se doivent de tirer parti de l’accroissement de ce volume de donnĂ©es tout en rĂ©duisant le temps consacrĂ© Ă  sa gestion sans pour autant perdre en efficacitĂ©.

Un datacenter autonome

Le défi de la complexité
Les organisations ont besoin de rationaliser le management de leurs datacenters et de s’attaquer aux manques d’efficacitĂ© qui peuvent exister en la matiĂšre. La gestion traditionnelle des datacenters implique beaucoup de travail pour les Ă©quipes d’exploitations, qui passent leurs journĂ©es (et parfois mĂȘme leurs nuits...) Ă  "bricoler" manuellement l’infrastructure afin de pouvoir gĂ©rer au mieux les Ă©vĂ©nements imprĂ©vus.
Tout ceci crée une perte colossale de temps et de ressources.
Avec la complexitĂ© croissante des technologies de stockage des donnĂ©es, cette situation prĂ©sente un risque de plus en plus important et ne peut ĂȘtre efficacement traitĂ©e avec des outils classiques de gestion des datacenters. Les entreprises ont dorĂ©navant besoin d’une nouvelle gĂ©nĂ©ration de solutions de management, d’outils d’automatisation et de traitement analytiques pour libĂ©rer les administrateurs de datacenters des travaux quotidiens fastidieux et leur permettre de se consacrer Ă  des activitĂ©s crĂ©atrices de valeur pour l’entreprise. En d’autres termes, les entreprises ont besoin d’un datacenter | datacenters autonome[81].

Une nouvelle génération de stockage vient de naßtre

Une infrastructure de datacenters dotĂ©e d’Intelligence artificielle (IA) permettrait de dĂ©passer les limites des approches traditionnelles, grĂące Ă  l’utilisation d’algorithmes intelligents qui traitent les donnĂ©es des capteurs installĂ©s sur les Ă©quipements et leur permettent de fonctionner de maniĂšre autonome. Avec l’IA, ce moteur intelligent pourra automatiquement dĂ©tecter les mauvais fonctionnements, les goulets d’étranglement ou encore les configurations incorrectes, et potentiellement apporter automatiquement les actions correctives ; ce qui rĂ©duira le temps allouĂ© aux interventions. L’IA est Ă©galement capable de dresser une liste des problĂšmes dĂ©jĂ  dĂ©tectĂ©s, afin d’éviter les rĂ©pĂ©titions et d’empĂȘcher les clients de se heurter Ă  des problĂšmes dĂ©jĂ  rencontrĂ©s.
L’utilisation de l’IA dans le datacenters peut non seulement dĂ©tecter et rĂ©soudre les problĂšmes, mais peut proactivement apporter des suggestions d’amĂ©lioration. En tirant parti des donnĂ©es et de la valeur qu’elles recĂšlent, l’IA peut identifier des opportunitĂ©s d’amĂ©lioration des systĂšmes et de leurs performances, ayant un impact positif sur les processus mĂ©tiers, l’efficacitĂ© des Ă©quipes Technologies de l'information et de la communication et finalement, sur l’expĂ©rience client.
Comment est-ce possible ?
Pour faire simple, l'IA dans le datacenters offre une supervision simultanĂ©e de tous les systĂšmes existants. Elle permet au systĂšme de comprendre l'environnement de fonctionnement idĂ©al pour chaque charge de travail et chaque application, puis d'identifier les comportements anormaux par rapport aux modĂšles rĂ©guliers des E/S sous-jacentes. Autrement dit, plus la richesse et le volume des donnĂ©es gĂ©nĂ©rĂ©s dans une entreprise augmentent, plus l'efficacitĂ© du systĂšme d'IA s’amĂ©liore en apprenant des modĂšles de donnĂ©es. La pĂ©rennitĂ© de l'IA s’en trouve Ă  son tour prolongĂ© car le systĂšme cherchera en permanence Ă  amĂ©liorer l’infrastructure informatique, soit en corrigeant les nouveaux problĂšmes qui Ă©mergent, soit en suggĂ©rant de nouvelles mĂ©thodes pour optimiser et amĂ©liorer les processus.
Le systĂšme peut utiliser des donnĂ©es mĂ©trologiques dĂ©taillĂ©es pour constituer un socle de base de connaissances et d’expĂ©riences, concernant chaque systĂšme en relation avec le moteur d’IA. La technologie des algorithmes de recherche comportementale permet d’analyser et de prĂ©voir si un autre Ă©quipement du datacenters est susceptible de rencontrer des problĂšmes similaires Ă  ceux dĂ©jĂ  traitĂ©s. De plus, cette capacitĂ© permet de modĂ©liser la performance des applications et de l’optimiser pour chaque nouvelle infrastructure d’accueil, en fonction de l’historique des configurations et des modĂšles de charge de travail, ce qui rĂ©duit les risques lors des dĂ©ploiements sur de nouvelles configurations, et diminue significativement les coĂ»ts de mise en Ɠuvre.

Une nouvelle approche prédictive voit le jour

En s’appuyant sur les outils d’analyse prĂ©dictive et la base de connaissances sur les moyens d’optimiser la performance des systĂšmes, l’IA peut suggĂ©rer des recommandations adaptĂ©es pour Ă©tablir un environnement de travail idĂ©al et appliquer de façon automatique les modifications en lieu et place des administrateurs IT. De plus, si l’automatisation des actions n’est pas souhaitĂ©e, des recommandations peuvent ĂȘtre proposĂ©es aux Ă©quipes d’exploitation par celle des dossiers de support. Cela libĂ©rera tout de mĂȘme les Ă©quipes d’exploitation des multiples recherches manuelles nĂ©cessaires Ă  l’identification des causes de dysfonctionnement, et leur Ă©viter Ă©galement des improvisations en matiĂšre de gestion de l’infrastructure.
L’utilisation d’un moteur d’analyse prĂ©dictive permet aux clients de rĂ©soudre 86 % des problĂšmes avant que ceux-ci n’affectent l’activitĂ© business. Dans les 14 % de cas restants, l’utilisateur possĂšde un accĂšs immĂ©diat Ă  des ingĂ©nieurs expĂ©rimentĂ©s pour trouver une solution le plus rapidement possible. De mĂȘme, des Ă©tudes menĂ©es par le cabinet d’analystes ESG rĂ©vĂšlent que 70 % des clients qui utilisent cette technologie peuvent rĂ©soudre des problĂšmes ou remĂ©dier Ă  de mauvais fonctionnements en moins d’une heure, et que plus de 26 % d’entre eux l’ont fait en moins de 15 minutes.
Avec une approche traditionnelle de la gestion des datacenters, il faut en moyenne 84 minutes Ă  un tiers (32 %) des utilisateurs pour qu’un problĂšme rencontrĂ© soit remontĂ© Ă  un ingĂ©nieur disposant du niveau d’expertise requis pour le rĂ©soudre.
En plaçant l’IA au cƓur des outils de gestion du datacenters, les organisations seront en mesure de prĂ©dire, d’éviter et de rĂ©soudre les incidents plus rapidement. Ceci peut amener des gains significatifs en termes d’efficacitĂ© et d’amĂ©lioration opĂ©rationnelle, tout en rendant l’infrastructure plus intelligente et plus rĂ©siliente. Plus important encore, les entreprises bĂ©nĂ©ficieront d’une rĂ©duction majeure des temps d’interruption de service et des dĂ©lais de rĂ©solution des problĂšmes IT. Ainsi, les Ă©quipes Technologies de l'information et de la communication pourront mieux se consacrer Ă  des tĂąches qui apportent rĂ©ellement de la valeur, et qui amĂ©liorent l’expĂ©rience client.

Le Cloud hybride

Une Ă©tude publiĂ©e par Nutanix en 2018 rĂ©vĂšle que 91 % des responsables Technologies de l'information et de la communication d’entreprises considĂšrent que le modĂšle idĂ©al est celui du Cloud hybride, qui marie les bienfaits du Cloud public avec ceux du Cloud privĂ©[82].

Cloud hybride - DĂ©finition

Dans le cas d’un Cloud privĂ©, les serveurs sont dĂ©diĂ©s Ă  une seule entreprise. Ces serveurs peuvent ĂȘtre sur site, ou hors-site. Dans le cas d’un Cloud public, les serveurs sont partagĂ©s entre les diffĂ©rents clients d’un fournisseur. Les serveurs sont toujours hors-site, puisqu’ils sont situĂ©s dans les Data Centers du fournisseur.

Selon Forrester Research, le Cloud hybride consiste Ă  connecter un ou plusieurs Clouds publics Ă  un Cloud privĂ© ou Ă  une infrastructure de Data Center sur site traditionnelle. Pour faire simple, il s’agit donc d’un savant mĂ©lange entre les ressources Technologies de l'information et de la communication sur site et hors site.

De maniĂšre plus Ă©laborĂ©e, le Cloud hybride est un environnement Cloud constituĂ© de ressources de Cloud privĂ© sur site combinĂ©es avec des ressources de Cloud public tiers connectĂ©es entre elles par un systĂšme d’orchestration.

Selon la dĂ©finition « officielle » du National Institute of Standards and Technology, le Cloud hybride est "une infrastructure Cloud composĂ©e de deux infrastructures Cloud distinctes ou plus pouvant ĂȘtre privĂ©es ou publiques et qui restent des entitĂ©s uniques, mais sont connectĂ©es par une technologie standard ou propriĂ©taire permettant la portabilitĂ© des donnĂ©es et des applications".

Cloud hybride - Les avantages

  1. Il permet de transfĂ©rer les workloads et les donnĂ©es entre le Cloud public et le Cloud privĂ© de façon flexible en fonction des besoins, de la demande et des coĂ»ts. Ainsi, les entreprises bĂ©nĂ©ficient d’une flexibilitĂ© accrue et d’options supplĂ©mentaires pour le dĂ©ploiement et l’usage des donnĂ©es.
  2. La flexibilitĂ© : dans le cas d’une infrastructure sur site, la gestion des ressources nĂ©cessite du temps et de l’argent. L’ajout de capacitĂ© requiert donc une planification en amont. Au contraire, le Cloud public est dĂ©jĂ  prĂȘt et les ressources peuvent ĂȘtre ajoutĂ©es instantanĂ©ment pour rĂ©pondre aux besoins de l’entreprise. Ainsi, en s’appuyant sur le Cloud hybride, une entreprise pourra exploiter des ressources du Cloud public lorsque ses besoins dĂ©passent les ressources disponibles sur Cloud privĂ©, par exemple lors de pics saisonniers. Le Cloud hybride permet donc de profiter d’une Ă©lasticitĂ© nĂ©cessaire pour faire face aux variations de la demande qui peuvent ĂȘtre liĂ©es Ă  de multiples facteurs.
  3. AccÚs rapide aux données les plus critiques ; il est donc possible de garder les données fréquemment utilisées sur site, et de transférer les données « froides » sur le Cloud.
  4. RĂ©duction des charges de l’entreprise grĂące aux faibles coĂ»ts des ressources Technologies de l'information et de la communication proposĂ©es sur le Cloud public. En effet, la plupart des fournisseurs de Cloud public proposent Ă  leurs clients de payer uniquement pour les ressources qu’ils consomment. Les dĂ©penses inutiles sont donc Ă©vitĂ©es.
  5. traitement de Big Data ; il est par exemple possible pour une entreprise d’utiliser le stockage Cloud hybride pour stocker ses donnĂ©es et d’effectuer des requĂȘtes analytiques sur le Cloud public oĂč les clusters Hadoop (ou autre) pourront ĂȘtre scalĂ©s pour s’adapter aux tĂąches de computing les plus exigeantes.

Cloud hybride - Les inconvénients

  1. Le Cloud hybride n’est pas adaptĂ© Ă  toutes les situations (ex : les petites entreprises disposant d’un budget Technologies de l'information et de la communication limitĂ©, prĂ©fĂšreront s'en tenir au Cloud public, les coĂ»ts liĂ©s Ă  l’installation et Ă  la maintenance de serveurs privĂ©s du Cloud hybride pouvant ĂȘtre trop Ă©levĂ©s).
  2. Une application nĂ©cessitant une latence minimale n’est pas toujours adaptĂ©e au Cloud hybride ; il peut ĂȘtre prĂ©fĂ©rable d’opter pour une infrastructure sur site.

L'intelligence artificielle et le machine learning

Lorsqu'elle est déployée stratégiquement et associée à une supervision humaine pertinente, l'Intelligence artificielle peut générer une foule de nouvelles fonctionnalités pour les datacenters de nouvelle génération par exemple avec Matlab[83].

Force est de constater que les entreprises qui ne parviendront pas à intégrer le potentiel révolutionnaire des technologies émergentes - du cloud computing et aux quantités de données volumineuses en passant par l'Intelligence artificielle (IA) - dans leur infrastructure de centre de données centre de données, pourraient bientÎt se retrouver distancées loin derriÚre leurs principaux concurrents.

En fait, Gartner[84] prévoit que plus de 30 % des centres de données qui ne se préparent pas suffisamment à l'IA, ne seront plus viables sur le plan opérationnel ou économique. Il incombe donc aux entreprises et aux fournisseurs tiers, d'investir dans des solutions qui les aideront à tirer le meilleur parti de ces techniques de pointe.

Voici trois façons proposées aux entreprises qui souhaitent exploiter l'IA pour améliorer les opérations quotidiennes de leur datacenters :

- Exploiter l'analyse prédictive pour optimiser la distribution de la charge de travail

Il fut un temps oĂč il relevait de la responsabilitĂ© des professionnels de l'informatique, d'optimiser les performances des serveurs de leur entreprise, en s'assurant que les charges de travail Ă©taient rĂ©parties de maniĂšre stratĂ©gique dans leur portefeuille de centres de donnĂ©es ; difficile cependant, eu Ă©gard aux contraintes de personnel et/ou des ressources devant surveiller la rĂ©partition des charges de travail 24 heures sur 24.

En adoptant un outil de gestion basĂ© sur l'analyse prĂ©dictive, il est dĂ©sormais possible de dĂ©lĂ©guer Ă  un ordonnanceur, la grande majoritĂ© des responsabilitĂ©s de l’équipe informatique, en matiĂšre de distribution de la charge de travail (optimisation du stockage, calcul de la rĂ©partition des charges de travail en temps rĂ©el).

Au-delĂ  de la simple autogestion, l’avantage est que les serveurs gĂ©rĂ©s par des algorithmes d'analyse prĂ©dictive gagnent en efficacitĂ© au fil du temps : au fur et Ă  mesure que les algorithmes traitent davantage de donnĂ©es et se familiarisent avec les flux de travail de l'entreprise, ils commencent Ă  anticiper la demande des serveurs avant mĂȘme que les requĂȘtes ne soient faites.

- Refroidissement piloté par des algorithmes d'apprentissage machine

Les centres de donnĂ©es consomment une Ă©norme quantitĂ© de puissance, pour les opĂ©rations de calcul et le stockage des serveurs d’une part, mais aussi pour les fonctions de refroidissement des centres informatiques. Cette consommation d'Ă©nergie peut rapidement devenir une charge financiĂšre importante.

Un systÚme de recommandation alimenté par l'IA pourrait réduire la consommation d'énergie, diminuer les coûts et rendre les installations plus durables sur le plan environnemental. Il est à noter que Google et DeepMind ont expérimenté l'utilisation de l'IA pour optimiser leurs activités de refroidissement ; ainsi, l'application des algorithmes d'apprentissage machine de DeepMind dans les centres de données de Google a permis de réduire de 40 % l'énergie utilisée pour le refroidissement, sans compromettre les performances des serveurs.

- Utilisation de l'IA pour atténuer les pénuries de personnel

L'émergence de nouvelles offres - généralement plus complexes - dans l'espace du Cloud computing a transformé le centre de données typique en un centre d'échange de haute technologie pour une variété de charges de travail critiques pour les entreprises.

Le besoin de professionnels des Technologies de l'information et de la communication avec les compétences requises pour ces centres de haute technologie est exponentiel ; pourtant, face à une pénurie de candidats suffisamment qualifiés, les équipes de gestion des centres de données sont donc confrontées à une grave pénurie de personnel qui pourrait un jour menacer la capacité des entreprises à entretenir correctement leurs actifs numériques.

Afin de permettre aux centres de données de prospérer en l'absence d'une surveillance humaine approfondie, la technologie d'IA offre la possibilité de prendre en charge une série de fonctions de serveur sans automatiser entiÚrement la gestion informatique, comme effectuer de maniÚre autonome des tùches de routine comme la mise à jour des systÚmes, les correctifs de sécurité et les sauvegardes de fichierss.

Les professionnels de l'informatique peuvent alors assumer des tùches plus nuancées et plus qualitatives, ou des rÎles de supervision de tùches qui nécessitaient auparavant leur attention minutieuse.

Pour les entreprises individuelles et les fournisseurs de datacenters tiers, cette approche basée sur le partenariat constitue un juste milieu entre l'automatisation pure et simple et le manque chronique de personnel. Ainsi, ce modÚle de gestion « hybride » sera probablement la norme dans l'ensemble du secteur des centres de données, cette « entraide » permettant le bon fonctionnement d'un centre de données.

La progression du "serverless"

Le " serveless", suite logique du cloud-native, en est encore à ses débuts, mais son développement progresse, et les premiers à avoir franchi le pas en voient déjà les avantages[85].

Ne pas refléchir aux limites et capacités des serveurs

La prochaine Ă©tape serait le serveless, qui ne nĂ©cessite pas de rotation ou de provisionnement des serveurs. Bien sĂ»r, le serveless repose toujours sur des serveurs, mais les dĂ©veloppeurs et professionnels Technologies de l'information et de la communication n’auront pas Ă  rĂ©flĂ©chir Ă  leurs limites et capacitĂ©s. Le serveless est « la suite logique du cloud-native », car il s’agit du modĂšle de calcul utilitaire le plus pur qui soit sur de nombreux points. Amazon propose en la matiĂšre sa solution AWS Lambda[86] ou Microsoft avec sa solution Cloud AZURE[87] permet d'analyser les problĂšmes d’intĂ©gritĂ©, suivre l’impact sur les ressources Cloud, obtenir des conseils et du support et transmettre des informations fiabilisĂ©es.

Une approche serveless est attrayante « en raison de la quantité limitée de personnel et de talents disponibles pour construire, gérer et maintenir la nouvelle génération de systÚmes numériques ». L'attrait du serveless augmentera également avec l'ajout de dispositifs IoT.

Avec la maturité vient le progrÚs

Pour un certain nombre d’organisations, le serveless est toujours un travail en cours, et beaucoup n’en voient pas encore les avantages, d’aprĂšs un rĂ©cent sondage. Quatre entreprises sur dix ont adoptĂ© le serveless, mais n’en voient pas encore les impacts positifs, comme le montre l'enquĂȘte menĂ©e auprĂšs de 1 500 cadres par O'Reilly. Cependant, pour ceux qui ont plus de trois ans d’expĂ©rience dans le domaine du serveless, 79 % estiment que leurs efforts sont « majoritairement fructueux » ou mieux, avec des avantages tels que la rĂ©duction des coĂ»ts d’exploitation et la mise Ă  l'Ă©chelle automatique, ou encore la possibilitĂ© d'Ă©viter les maintenances de serveur et la rĂ©duction des coĂ»ts de dĂ©veloppement.

Les avantages du Serverless :

  1. réduction des coûts d'exploitation ;
  2. mise Ă  l’échelle automatique ;
  3. absence de problÚmes liés aux maintenances de serveur ;
  4. réduction des coûts de développement ;

augmentation de la productivité des développeurs, et donc augmentation de la valeur de l'entreprise.

Les défis du serverless :

Il n'y a pas vĂ©ritablement de cursus de formation du personnel actuel (le serveless Ă©tant relativement rĂ©cent, il est difficile de trouver une formation officielle, il faut produire une documentation spĂ©cifique et il est difficile de trouver des Ă©tudes de cas dont on peut tirer des leçons). Le verrouillage des fournisseurs (Ă©crire du code pour une plateforme de fournisseur ne la rend pas amovible ou simple Ă  dĂ©placer ailleurs ; parce que le serverless architecture est un domaine naissant, il semble que le marchĂ© attend de voir ce qui va se passer en ce qui concerne la question de la portabilitĂ© entre les fournisseurs.). Il faut prendre en compte la difficultĂ© des tests d'intĂ©gration/dĂ©bogage (les tests sont plus complexes et demandent plus de travail pour les architectures serveless, avec plus de scĂ©narios Ă  traiter et diffĂ©rents types de dĂ©pendances - latence, dĂ©marrage, mocks - ce qui change le paysage de l'intĂ©gration). Les coĂ»ts imprĂ©visibles/variables (il semble que les coĂ»ts inattendus qui dĂ©coulent de l’utilisation du serveless reprĂ©sentent un obstacle, au mĂȘme niveau que la rĂ©duction des coĂ»ts reprĂ©sente un avantage. Ce paradoxe met en Ă©vidence les espoirs que peuvent porter le serveless, et justifier commercialement son adoption. Le risque survient plus tard, avec les coĂ»ts potentiels d’une fuite).


Qu’est-ce que l’ingĂ©nierie du chaos et comment la mettre en place ? Services Cloud, offres open source, Intelligence artificielle, Internet des objets
 Les infrastructures informatiques deviennent de plus en plus complexes, et dans ces conditions, assurer leur fiabilitĂ© en cas d’incident devient une vĂ©ritable gageure pour les DSI. C’est pourquoi certains services Technologies de l'information et de la communication ont tĂąchĂ© de dĂ©velopper des mĂ©thodes innovantes pour mettre Ă  l’épreuve leur systĂšme d’information. BaptisĂ©es “ingĂ©nierie du chaos”, il s’agit de mettre Ă  l’épreuve ses infrastructures avec le dĂ©clenchement volontaire d’incidents. InitiĂ©es par Netflix, ces mĂ©thodes ont Ă©tĂ© adoptĂ©es par des grands de l’IT tels qu'Amazon ou encore Microsoft. En France, c’est la SNCF avec son entitĂ© Technologies de l'information et de la communication VSC Technologies, qui expĂ©rimente actuellement le concept. Ivision vous prĂ©sente le concept de l’ingĂ©nierie du chaos et quelques recommandations utiles Ă  la mise en place de telles procĂ©dures au sein de votre SI.

L’ingĂ©nierie du chaos

L’ingĂ©nierie du chaos[88] est une discipline qui consiste Ă  Ă©prouver la rĂ©silience de tout ou partie d’une infrastructure informatique en gĂ©nĂ©rant volontairement et de façon contrĂŽlĂ©e des pannes dans un systĂšme en production.il s’agit de mettre Ă  l’épreuve ses infrastructures avec le dĂ©clenchement volontaire d’incidents. InitiĂ©es par Netflix avec le logiciel Chaos Monkey[89], ces mĂ©thodes ont Ă©tĂ© adoptĂ©es par des grands de l’IT tels que Amazon[90] - [91] ou encore Microsoft[92]. En France, c’est la SNCF avec son entitĂ© IT services informatiques VSC Technologies, qui expĂ©rimente actuellement le concept. Un test grandeur nature a dĂ©jĂ  Ă©tĂ© rĂ©alisĂ© en 2018 avec la simulation de la perte d’un datacenters[93]. ConcrĂštement, cela signifie qu’il faut se prĂ©parer d’une part, Ă  ce que les tests aient des rĂ©percussions sur le fonctionnement de l’entreprise[94], puisqu’il s’agit de tests rĂ©alisĂ©s en environnement de production, en conditions rĂ©elles, et auxquels il faut apporter de vrais rĂ©ponses, mais il faut Ă©galement se prĂ©parer, dans un deuxiĂšme temps, Ă  ce que les consĂ©quences de ces tests soient maĂźtrisĂ©s, pour Ă©viter Ă  l’entreprise des pertes ou des coĂ»ts inattendus.

Mettre en Ɠuvre un test d’ingĂ©nierie du chaos :

Pour bien mettre en Ɠuvre un test d’ingĂ©nierie du chaos[94], il faut tout d’abord avoir identifiĂ© un objectif prĂ©cis et mesurable. Avant de rĂ©aliser le test en production, une premiĂšre prĂ©caution est de le rĂ©aliser en environnement de test. Cela permet dans un premier temps de limiter les risques de voir Ă©chapper le contrĂŽle du test, sans toutefois Ă©carter toutes les possibilitĂ©s, puisque l’environnement de test ne sera jamais totalement identique Ă  l’environnement de production[95]. En amont du test en production, il est important de bien informer toutes les personnes susceptibles d’ĂȘtre affectĂ©es par l’expĂ©rience, toujours dans l’optique de limiter les effets de bord ou de rĂ©action en chaĂźne liĂ©es aux consĂ©quences de l’expĂ©rience.

Des exemples d’expĂ©rimentation possibles :

  1. Simuler une panne de datacenters
  2. Simuler une panne DNS
  3. Rendre inaccessibles certains services de façon aléatoire
  4. CrĂ©er des perturbations rĂ©seaux, problĂšmes d’accĂšs ou de lenteur
  5. Introduire des latences entre différents services, pour un pourcentage de trafic et un temps donné.

Vers de nouvelles solutions de stockage de données

Le stockage de donnĂ©es est l’ensemble des mĂ©thodes et technologies permettant d’entreposer et de conserver les informations numĂ©riques. D’ici 2025, selon IDC, le volume de donnĂ©es gĂ©nĂ©rĂ© par l’humanitĂ© sera multipliĂ© par cinq et atteindra 163 zettabytes. En consĂ©quence directe, nos besoins en espace de stockage vont augmenter de façon drastique. Il sera non seulement nĂ©cessaire d’augmenter la capacitĂ© des supports actuels, mais aussi d’en inventer de nouveaux.

Le projet Silica
Microsoft et Warner Bros ont collaborĂ© pour stocker le premier film Superman, sorti en 1978, sur un morceau de "verre", qui est en rĂ©alitĂ© du quartz. Une technologie innovante qui permettrait de restituer des fichiers sans altĂ©rer leur qualitĂ©, mais Ă©galement de stocker Ă  moindre coĂ»t de grandes quantitĂ©s de donnĂ©es. La premiĂšre validation du concept du Project Silica, menĂ© par Microsoft Research a Ă©tĂ© annoncĂ©e le 4 novembre 2019[96]. Le principe repose sur un laser femtoseconde qui encode les donnĂ©es dans le verre en crĂ©ant des couches d'indentations et dĂ©formations tridimensionnelles, Ă  diffĂ©rents angles et profondeurs, Ă  l'Ă©chelle nanomĂ©trique. Des algorithmes de machine learning peuvent ensuite lire les donnĂ©es en dĂ©codant les images et motifs crĂ©Ă©s lorsque de la lumiĂšre polarisĂ©e passe Ă  travers le verre. Cette surface de verre peut contenir jusqu’à 75,6 Go de donnĂ©es. Le principal bĂ©nĂ©fice : le quartz, composĂ© de silice (d'oĂč le nom du projet), peut supporter d'ĂȘtre trempĂ© dans l'eau bouillante, cuit dans un four, passĂ© au micro-ondes, ou d'ĂȘtre frottĂ© avec de la laine d'acier
 et les autres menaces environnementales. La rĂ©duction des coĂ»ts nĂ©cessaires au stockage de donnĂ©es, des coĂ»ts de stockage alimentĂ©s par la nĂ©cessitĂ© de transfĂ©rer de maniĂšre rĂ©pĂ©tĂ©e des donnĂ©es sur un nouveau support avant que les informations ne soient perdues. La conservation des donnĂ©es plus longue : contrairement Ă  un disque dur, qui a une durĂ©e de vie de trois Ă  cinq ans, ou Ă  une bande magnĂ©tique (cinq Ă  sept ans), le stockage sur quartz "permet de conserver les donnĂ©es pendant des siĂšcles" selon Microsoft. On obtient par ce procĂ©dĂ© une limitation de la dĂ©gradation des donnĂ©es : les donnĂ©es n’étant Ă©crites qu'une seule fois sur le quartz, elles ne subissent pas de dĂ©gradation comme lors de migration de donnĂ©es classique. Autre source de rĂ©duction des coĂ»ts et d’empreinte environnementale : le quartz n’a pas besoin, contrairement Ă  des datacenters par exemple, de systĂšme de climatisation ou d’aĂ©ration. Il existe un point d'amĂ©lioration Ă  Ă©tudier : la vitesse Ă  laquelle les donnĂ©es doivent ĂȘtre Ă©crites et lues.

Stockage de données à mémoires flash
Les entreprises sont de plus en plus nombreuses Ă  troquer leurs Ă©quipements traditionnels de stockage magnĂ©tique de donnĂ©es sur disques durs avec des solutions de stockage Ă©lectronique Ă  mĂ©moire flash. C’est le cas d’AG2R La Mondiale[97]. Le stockage primaire dans l’un de ses trois datacenters s’appuie dĂ©sormais exclusivement sur des puces Ă©lectroniques flash. Une expĂ©rience considĂ©rĂ©e comme une Ă©tape avant la conversion de l’ensemble de son infrastructure de stockage primaire Ă  cette technologie.

Les datacenter de proximité

La liste des objets connectés qui nous entourent est longue et en constante évolution : ordinateurs, téléphones, tablettes, bracelets, montres, casques, téléviseurs, mais aussi lunettes, valises, vélos, chaussures...

L’augmentation exponentielle des objets connectĂ©s soulĂšve la question du traitement des informations et du stockage des donnĂ©es que ne pourra plus Ă  terme assurer le rĂ©seau informatique tel que nous le connaissons aujourd’hui.

Il suffit de se tourner vers un phĂ©nomĂšne mondial, et l’engouement suscitĂ© par Pokemon GO dĂ©veloppĂ© par Niantic Labs, pour en avoir une idĂ©e plus prĂ©cise ; l'application tĂ©lĂ©chargĂ©e par 75 millions d'utilisateurs dans le monde a provoquĂ© de nombreuses pannes des serveurs en 2016[98] (application en tĂ©lĂ©chargement permanent ou messages d’erreur). Cet Ă©cueil technique n'est nullement insoluble, mais difficile Ă  rĂ©gler dans l’urgence : l’incapacitĂ© des datacenters traditionnels Ă  rĂ©pondre Ă  une demande inĂ©dite devenue trop forte.

PokĂ©mon GO reproduit un environnement de l’Internet des objets (IoT) oĂč de nombreux appareils transmettent des donnĂ©es Ă  un site central. Les exigences de performance soulignĂ©es par l’application phĂ©nomĂšne sont ainsi trĂšs comparables aux enjeux plus sĂ©rieux, qui attendent, demain, les fabricants d’objets connectĂ©s et les nombreux autres acteurs de l’économie numĂ©riques.

La rĂ©ponse la plus adaptĂ©e aux problĂšmes de latence (dĂ©lai entre le moment oĂč une information est envoyĂ©e et celui oĂč elle est reçue) ou de saturation des rĂ©seaux, est apportĂ©e aujourd’hui par le Edge Computing, qui se dĂ©finit comme la mise Ă  disposition de "ressources informatiques proches de l’utilisateur final ou de la source de donnĂ©es ".

Un serveur prĂšs de chez vous : Plusieurs micro- datacenters installĂ©s dans le pays pourraient par exemple prendre en charge les messages transmis aux joueurs, les statistiques et les scores. Ce n’est que de maniĂšre ponctuelle qu’il leur faudrait envoyer des donnĂ©es Ă  un datacenters "central", et uniquement des donnĂ©es choisies. Pareille configuration permettrait de rĂ©duire la latence mais Ă©galement le besoin en bande passante, de chaque aller-retour de maniĂšre significative. Les donnĂ©es ne seraient plus transmises du tĂ©lĂ©phone de tel utilisateur Ă  un datacenters situĂ© Ă  quelques centaines de kilomĂštres, mais Ă  un micro datacenters situĂ© Ă  proximitĂ©.

Ainsi, plus de Cloud en surcharge, plus de serveurs en panne ! Le Edge Computing va vĂ©ritablement changer la donne en permettant de gĂ©rer le flux d’informations reçues et transmises aux utilisateurs. Il semble souhaitable que cette approche trouve rapidement un Ă©cho auprĂšs des dĂ©cideurs pour que soient implĂ©mentĂ©es les infrastructures "micro-dc" permettant aux quelque vingt milliards d’objets connectĂ©s en 2020 (source Gartner), de mieux fonctionner, afin que les applications innovantes portĂ©es par le dĂ©veloppement des technologies puissent susciter plus d’engouement que de frustration dans les annĂ©es Ă  venir.

Vers des datacenters moins énergivores pour gagner en fiabilité

Les data centers font aujourd’hui partie des bĂątiments les plus Ă©nergivores dans le monde[99]. En 2016, ces derniers ont reprĂ©sentĂ© 5 % de la consommation mondiale d’électricitĂ© et exploitĂ© pas moins de 626 milliards de litres d’eau. L’un dans l’autre, ils ont Ă©tĂ© tenus responsables pour environ 3 % des Ă©missions de gaz Ă  effet de serre.

Les clés du refroidissement des datacenters confiées à des algorithmes
Google profite des avancĂ©es de Deepmind dans l'Intelligence artificielle pour gĂ©rer trĂšs finement la consommation Ă©lectrique et le refroidissement de ses centres de donnĂ©es, et piloter automatiquement la dissipation thermique des immenses fermes de serveurs qu'il exploite, ceci de façon autonome, sans assistance humaine[100]. Le principe est de faire travailler l'outil sur des instantanĂ©s pĂ©riodiques du systĂšme de refroidissement du centre de donnĂ©es. Toutes les cinq minutes, un « clichĂ© » du systĂšme est pris, Ă  partir de milliers de capteurs, puis envoyĂ© dans le Cloud de l’entreprise. De lĂ , il est traitĂ© par des algorithmes qui reposent sur des rĂ©seaux neuronaux profonds, la grande spĂ©cialitĂ© de DeepMind, qui ont Ă©tĂ© au cƓur de ses multiples percĂ©es. Google dit ainsi avoir obtenu des Ă©conomies d’énergie de 30 % aprĂšs seulement quelques mois d'exploitation du mĂ©canisme.

Refroidissement d'un datacenters, façon "Vingt mille lieues sous les mers"
Le français Naval Group apporte son savoir-faire de marinier à Microsoft pour développer et déployer un datacenters sous-marin de présérie[101] ; Microsoft Research poursuit son projet Natick en partenariat avec Naval Group pour tester les performances d'un centre de données placé sous l'eau[102]. Objectifs de ce datacenters immergé : diminuer drastiquement les besoins en refroidissement, qui représentent les principaux coûts énergétiques, permettre une construction plus rapide, et bénéficier d'un accÚs privilégié aux énergies renouvelables et des durées de latence réduites, la moitié de la population mondiale vivant à moins de 200 kilomÚtres d'une cÎte.

Immersion dans des cuves remplies d'un fluide ICE (Immersion Coolant for Electronics)
À l’occasion du salon Viva Technology en mai 2019, la start-up Immersion 4 a prĂ©sentĂ© sa solution visant Ă  placer les data center dans un systĂšme DTM (Dynamic Thermal Management)[103]. Dans les faits, ces cuves remplies d'un fluide ICE (Immersion Coolant for Electronics) sont capables de rĂ©duire drastiquement leur empreinte Ă©nergĂ©tique. "Il s’agit d’une nouvelle gĂ©nĂ©ration d'huile diĂ©lectrique 100 % synthĂ©tique, qui circule grĂące Ă  un dispositif que nous avons spĂ©cialement dĂ©veloppĂ©, baptisĂ© FlowHT et qui facilite la rĂ©cupĂ©ration calorifique. Les systĂšmes DTM permettent a l’électronique immergĂ©e de fonctionner en permanence au maximum de la puissance, voire d'augmenter la vitesse d’horloge [aussi appelĂ©e overclocking] sans pour autant avoir la dĂ©pense Ă©nergĂ©tique normalement associĂ©e lorsqu’elle est refroidie par l'air.

La technologie des datacenters repensée, pour plus d'efficacité et de sécurité, aux forts enjeux économiques...

Forum Teratec - Juin 2019 : quatre innovations pour accélérer sur le calcul à haute performance ( HPC)
Avec des donnĂ©es en augmentation constante — on parle "d'explosion de la donnĂ©e" —, l'enjeu est dĂ©sormais de bien savoir gĂ©rer ce flot d'informations. Pour rĂ©pondre Ă  cette problĂ©matique, Aldwin-Aneo, Atos, Activeeon et Ucit ont prĂ©sentĂ© leurs projets dans le domaine du Superordinateur[104].

  1. Tester des milliers de molĂ©cules : Aldwin-Aneo permet d'accĂ©lĂ©rer le dĂ©veloppement d’un nouveau mĂ©dicament, particuliĂšrement au moment du docking. Ce processus consiste Ă  tester la compatibilitĂ© des molĂ©cules en fonction des combinaisons spatiales de celles-ci. L’entreprise serait capable de faire passer la durĂ©e d'un docking de 68 ans Ă  une heure seulement grĂące Ă  la modĂ©lisation 3D, qui permet d'observer en temps rĂ©el la dynamique de la molĂ©cule, ainsi qu'au cloud computing. Cette mĂ©thode permet de rĂ©duire significativement le temps d'acquisition des rĂ©sultats tout en amĂ©liorant l'expĂ©rience utilisateur.
  2. Un chef d'orchestre pour la donnĂ©e : Activeeon, sociĂ©tĂ© spĂ©cialisĂ©e dans la planification de tĂąches et l'orchestration pour toutes les infrastructures, prend aussi en charge la gestion et l'automatisation d'applications comme de services complexes, multi-VM et multi-clouds. En partenariat avec l’Inria, la sociĂ©tĂ© a annoncĂ© en mars 2019 une accĂ©lĂ©ration consĂ©quente de l'analyse mĂ©tagĂ©nomique. En effet la sociĂ©tĂ© permet de traiter simultanĂ©ment un nombre d’échantillons pouvant atteindre et mĂȘme dĂ©passer plusieurs milliers d’unitĂ©s en rĂ©partissant la donnĂ©e entre 1 000 CPU (Central Processing Unit).
  3. Comprendre l'utilisation des clusters : Ucit a pour ambition de dĂ©mocratiser et de simplifier le calcul Ă  haute performance. À l'occasion du Forum Teratec, la sociĂ©tĂ© a dĂ©voilĂ© en avant-premiĂšre le logiciel Analyze-IT, qui analyse les logs des clusters. Ces donnĂ©es sont relatives Ă  leur utilisation afin de comprendre les usages, les comportements des utilisateurs et faire Ă©voluer les structures en consĂ©quence. Une fois les indicateurs analysĂ©s, les Ă©quipes accompagnent les clients pour optimiser leur utilisation en identifiant les ressources et capacitĂ©s nĂ©cessaires dans le futur, par exemple pour le passage vers l'hybride Superordinateur et le Cloud.
  4. Simulation des programmes quantiques : Atos a prĂ©sentĂ© le programme myQLM, lancĂ© le 16 mai 2019. Ce projet permet de dĂ©mocratiser la programmation quantique en fournissant un Ă©cosystĂšme de simulation. Il serait alors possible de simuler des programmes sur le poste de travail personnel, sans ordinateurs quantique, permettant ainsi aux professionnels mais aussi aux Ă©tudiants de se familiariser avec cette technologie. L'environnement Python permettra d’utiliser les langages AQASM (Atos Quantum Assembler) et pyAQASM pour tester les dĂ©veloppements. Atos assure Ă©galement l'interopĂ©rabilitĂ© avec d'autres solutions de calcul quantique en fournissant des traducteurs open source de myQLM vers d'autres environnements de programmation quantique.

Le développement de processeurs plus performants
Amazon Web Services (AWS) aurait dĂ©veloppĂ© en 2019, une seconde gĂ©nĂ©ration de processeurs pour ses datacenters. Toujours basĂ©e sur l’architecture ARM, elle serait 20 % plus performante que le premier modĂšle, Graviton, la premiĂšre gĂ©nĂ©ration de puce spĂ©cialisĂ© sortie en 2018[105]. Cette nouvelle gĂ©nĂ©ration permettrait aussi aux puces de s'interconnecter pour accĂ©lĂ©rer le traitement de certaines tĂąches comme la reconnaissance d’images. Les processeurs basĂ©s sur l'architecture ARM sont moins puissants que ceux d'Intel et AMD, qui utilisent l'architecture x86, mais ils sont aussi moins gourmands en Ă©nergie et beaucoup moins chers Ă  produire. Cela reprĂ©sente au bas mot une diffĂ©rence de plusieurs milliers d'euros par serveur. L'enjeu pour le gĂ©ant du Cloud serait de rĂ©duire sa dĂ©pendance vis-Ă -vis d'Intel.

Intel se muscle dans l'Intelligence artificielle en s'emparant d'Habana Labs pour 2 milliards de dollars
Fin 2019, Intel s'empare de la start-up israĂ©lienne Habana Labs, spĂ©cialisĂ©e dans les accĂ©lĂ©rateurs d'apprentissage profond programmable destinĂ©s aux datacenters, pour 2 milliards de dollars[106]. Habana commercialise Goya, un processeurs d'interfĂ©rence qui propose un dĂ©bit et des temps de latence en temps rĂ©el, et qui est trĂšs compĂ©titif au niveau de l'Ă©nergie, selon Intel. L'IsraĂ©lien dĂ©veloppe aussi Gaudi, un processeurs programmable destinĂ© Ă  l'IA pour les datacenters. Habana espĂšre que ce processeurs Gaudi, qui est dotĂ© d'un grand nombre de nƓuds, augmente jusqu'Ă  4 fois le dĂ©bit d'entrĂ©e et de sortie par rapport aux systĂšmes ayant un nombre Ă©quivalent de GPU.

Les ambitions de Lenovo
L’ambition du gĂ©ant chinois dans ce monde qui change est de devenir l’acteur numĂ©ro un du monde des datacenters, et sa stratĂ©gie est simple : combiner son hĂ©ritage d'excellence venu d'IBM avec son hĂ©ritage chinois qui lui permet de mieux rĂ©duire les coĂ»ts[107]. L’activitĂ© serveurs x86 d’IBM a Ă©tĂ© crĂ©Ă©e il y a 25 ans, Lenovo est donc dĂ©jĂ  trĂšs bien implantĂ©. L'entreprise possĂšde aussi 7 centres de recherche sur les datacenters, et 5 usines de fabrication Ă  travers le monde ; elle dĂ©clare fabriquer plus de 100 serveurs par heure Ă  Shenzhen. Pour rĂ©pondre aux exigences de ces clients trĂšs particuliers, Lenovo lance deux nouvelles marques : ThinkAgile et ThinkSystem. ThinkSystem est une architecture matĂ©rielle personnalisĂ©e, des serveurs complĂštement customisĂ©s suivant les besoins de ses clients. Lenovo peut se charger de l’installation sur site, soit directement soit via des partenaires. Une solution aux besoins de plus en plus spĂ©cifiques des Google et autres Facebook, qui conçoivent leur matĂ©riel eux-mĂȘmes.

Articles connexes

Références

  1. La Disponibilité : Un critÚre déterminant dans le choix d'un hébergement Cloud
  2. Data center : bienvenue dans les usines à données
  3. ITIL FRANCE
  4. (en) « Expectation for Computer Security Incident Response », Request for comments no 2350.
  5. CERT France 2019
  6. National Institute of Standards and Technology
  7. Computer SecurityIncident Handling Guide
  8. SANS Institute
  9. ENSI
  10. Good Practice Guide for Incident Management
  11. Carnegie Mellon University
  12. Defining Incident Management Processes for CSIRTs
  13. ISO 27035
  14. Central Computer and Telecommunications Agency
  15. ITIL France
  16. Increasing Information Systems Availabiliy Through Accuracy, Awareness, Completeness and Manageability of ITSM.
  17. ITIL France
  18. Gestion des Ă©vĂšnements ITIL ITIL dans le cloud
  19. ITIL : Renaissance ou dernier soupir
  20. Agile et ITIL ITIL 4 : l’avùnement de l’IT Service Management Agile
  21. Lean manufacturing: a process for all seasons.
  22. DevOps : l'évolution naturelle de l'agilité et du 'lean IT'
  23. Incorporation of Good Practices in the Development and Deployment of Applications through Alignment of ITIL and Devops
  24. ITIL et DATA CENTERS
  25. Glossaire ITIL ITIL
  26. Gestion des incidents : Processus ITIL
  27. Implementation of the Service Center according to best practices recommended by ITIL
  28. ITIL : Renaissance ou dernier soupir
  29. Service Management for the digital edge
  30. TOGAF The Open Group Architecture Framework
  31. ITIL : Agile et ITIL 4 : l’avùnement de l’IT Service Management Agile
  32. Risk and Data Center Planning, p. 8
  33. BULL Chorus
  34. Guide PCA
  35. DUMAS Thomas Tellier
  36. Uptime Institute
  37. Publicly Reported Outages 2018-19
  38. 8th annual Data Center Survey
  39. Publicly Reported Outages 2018-19, p. 3
  40. A systematic survey of public lcoud outage
  41. Publicly Reported Outages 2018-19, p. 4
  42. Risk and Data Center Planning
  43. Publicly Reported Outages 2018-19, p. 5
  44. Cost of Data Center Outages
  45. Ponemon Institute
  46. Google Cloud Whitepaper Data incident response process
  47. Google Cloud Whitepaper Data incident response process, p. 8
  48. Google Cloud Whitepaper Data incident response process, p. 9
  49. Google Cloud Whitepaper Data incident response process, p. 10
  50. Google Cloud Whitepaper Data incident response process, p. 11
  51. Google Cloud Whitepaper Data incident response process, p. 12
  52. Processus de gestion des incidents liés aux données
  53. Amazon Web Services
  54. Cloud Adoption Framework, p. 5
  55. AWS CloudWatch, p. 9
  56. AWS CloudWatch, p. 12
  57. AWS Auto Scaling
  58. Top 7 pannes 2019
  59. Problems at Amazon Web Services
  60. Amazon AWS Outage Shows Data in the Cloud is Not Always Safe
  61. Cloudflare outage
  62. Google Cloud Networking Incident #19016
  63. Google Compute Engine Incident #19008
  64. Salesforce
  65. Maillage de l'infrastructure Internet en France
  66. Travaux OVHcloud Fibre
  67. retour expérience OVH
  68. PDG OVH
  69. Travaux OVH
  70. Travaux OVH EMC
  71. Agence de l'Environnement et de la Maütrise de l'Énergie
  72. L’impact spatial et Ă©nergĂ©tique des data center sur les territoires
  73. Best Practices for Sustainable Datacenters
  74. Energie consommée par les data centers
  75. Cloudscene
  76. Orange - Construction d'un data center Val de Reuil
  77. DGA VDR
  78. Data Center EDF
  79. Directive SEVESO
  80. Prometheus
  81. Vivement le datacenter datacenters autonome, parce que vous avez déjà assez de problÚmes à gérer

  82. Cloud hybride : qu’est-ce que c’est et à quoi ça sert
  83. An Introduction to Matlab BT - Numerical Methods
  84. Gartner
  85. Cloud computing : la lourde tendance 2020, le "Serverless architecture serveless" progresse
  86. AMAZON WEB SERVICES Lambda
  87. AZURE
  88. Study on engineering cost estimation based on chaos theory and cost-significant theory
  89. NETFLIX CHAOS
  90. AWS CHAOS
  91. AWS CHAOS GameDay
  92. Inside Azure Search: Chaos Engineering
  93. L'ingénierie du chaos chez OUI.sncf
  94. Research on characteristics of chaos in enterprise strategic system and chaos management
  95. Security Chaos Engineering for Cloud Services: Work In Progress
  96. Project Silica : Pour Microsoft, le futur du stockage de données est... un morceau de verre
  97. AG2R La Mondiale se convertit au stockage de données à mémoire (informatique) mémoire flash
  98. Le phénomÚne Pokémon GO révÚle nos besoins en datacenter datacenters de proximité
  99. Energie consommée par les data centers
  100. IA : Google confie les clés du Méthodes de refroidissement pour ordinateur et refroidissement de ses datacenter datacenters à ses algorithmes
  101. Comment Naval Group aide Microsoft à créer et déployer un datacenter datacenters sous-marin
  102. Microsoft poursuit son projet fou de data center sous-marin avec Naval Group
  103. La start-up Immersion 4 rafraĂźchit les data centers
 et veut rĂ©utiliser l’énergie qu’ils dĂ©gagent
  104. Quatre innovations pour accélérer sur le calcul à haute performance (Superordinateur)
  105. AWS développerait un nouveau processeur , processeurs ARM et ARM (société) 20% plus performant pour ses datacenter datacenters
  106. Intel se muscle dans l'Intelligence artificielle en s'emparant d'Habana Labs pour 2 milliards de dollars
  107. Cloud, Superordinateur, Intelligence artificielle... Lenovo fait une démonstration de force dans les serveurs
  108. Grace Hopper
  109. L'origine du terme Bug
  110. Télégraphe Vibroplex
  111. Thomas Edison

Bibliographie

  • (en) J. Andreeva, P. Beche, S. Belov, I. Dzhunov et I. Kadochnikov, « Processing of the WLCG monitoring data using NoSQL », Journal of Physics, vol. 513,‎ , p. 36-43 (ISSN 1742-6588, DOI 10.1088/1742-6596/513/3/032048)
  • (en) K. Dahbur, B. Mohammad, A. Tarakji et A. Bisher, « A survey of risks, threats and vulnerabilities in cloud computing », ACM Press,‎ , p. 1-6 (DOI 10.1145/1980822.1980834)
  • (en) J. Molina-Perez, D. Bonacorsi, O. Gutsche, A. SciabĂ  et J. Flix, « Monitoring techniques and alarm procedures for CMS Services and Sites in WLCG », Journal of Physics: Conference Series, vol. 396, no 4,‎ , p. 042041 (ISSN 1742-6588, DOI 10.1088/1742-6596/396/4/042041)
  • (en) P. Saiz, A. Aimar, J. Andreeva, M. Babik et L. Cons, « WLCG Monitoring Consolidation and further evolution », Journal of Physics: Conference Series, vol. 664, no 6,‎ , p. 062054 (ISSN 1742-6588, DOI 10.1088/1742-6596/664/6/062054)
  • (en) B. Campana, A. Brown, D. Bonacorsi, V. Capone et D De. Girolamo, « Deployment of a WLCG network monitoring infrastructure based on the perfSONAR-PS technology », Journal of Physics: Conference Series, vol. 512, no 6,‎ , p. 062008 (ISSN 1742-6588, DOI 10.1088/1742-6596/513/6/062008)
  • (en) Z. Toteva, R Alvarez. Alonso, E Alvarez. Granda, M-E. Cheimariou et I. Fedorko, « Service management at CERN with Service-Now », Journal of Physics: Conference Series, vol. 396, no 6,‎ , p. 062022 (ISSN 1742-6588, DOI 10.1088/1742-6596/396/6/062022)
  • (en) C. Magherusan-Stanciu, A. Sebestyen-Pal, E. Cebuc, G. Sebestyen-Pal et V. Dadarlat, « Grid System Installation, Management and Monitoring Application », 2011 10th International Symposium on Parallel and Distributed Computing,‎ , p. 25-32 (DOI 10.1109/ISPDC.2011.14)
  • M. Fairouz, « Le calcul scientifique des expĂ©riences LHC - Une grille de production mondiale », Reflets de la physique,‎ , p. 11-15 (ISSN 1953-793X, DOI 10.1051/refdp/2010016)
  • (en) Rafael de Jesus. Martins, Luis Augusto Dias. Knob, Eduardo Germano. da Silva, Juliano Araujo. Wickboldt, Alberto. Schaeffer-Filho et Lisandro Zambenedetti. Granville, « Specialized CSIRT for Incident Response Management in Smart Grids », Journal of Network and Systems Management,‎ , p. 269-285 (ISSN 1064-7570, DOI 10.1007/s10922-018-9458-z)
  • (en) R. Trifonov, S. Yoshinov, S. Manolov, G. Tsochev et G. Pavlova, « Artificial Intelligence methods suitable for Incident Handling Automation », MATEC Web of Conferences, vol. 292,‎ , p. 01044 (ISSN 2261-236X, DOI 10.1051/matecconf/201929201044)
  • M. Hubert, « L'informatique en France de la seconde Guerre Mondiale au Plan Calcul. », Revue d'anthropologie des connaissances, vol. 5, 1, no 1,‎ , p. 155 (ISSN 1760-5393, DOI 10.3917/rac.012.0155)
  • (en) J. Andreeva, D. Dieguez Arias, S. Campana, J. Flix et O. Keeble, « Providing global WLCG transfer monitoring », Journal of Physics: Conference Series, vol. 396, no 3,‎ , p. 032005 (ISSN 1742-6588, DOI 10.1088/1742-6596/396/3/032005)
  • (en) J. Sigarch, D. Dieguez Arias, S. Campana, J. Flix et O. Keeble, « High Performance Computing, Networking, Storage and Analysis (SC) », Institute of Electrical and Electronics Engineers,‎ (ISBN 9781450307710)
  • (en) N. Simakov, J. White, R. DeLeon, A. Ghadersohi et T. Furlani, « Application kernels: HPC resources performance monitoring and variance analysis », Concurrency and Computation: Practice and Experience, vol. 27, no 17,‎ , p. 5238-5260 (DOI 10.1002/cpe.3564)
  • (en) J. Palmer, S. Gallo, T. Furlani, M. Jones et R. DeLeon, « Open XDMoD: A Tool for the Comprehensive Management of High-Performance Computing Resources », Computing in Science & Engineering, vol. 17, no 4,‎ , p. 52-62 (ISSN 1521-9615, DOI 10.1109/MCSE.2015.68)
  • (en) T. Furlani, M. Jones, S. Gallo, A. Bruno et CD. Lu, « Performance metrics and auditing framework using application kernels for high-performance computer systems », Concurrency and Computation: Practice and Experience, vol. 25, no 7,‎ , p. 918-931 (DOI 10.1002/cpe.2871)
  • (en) M. Wiboonrat, « Data center infrastructure management WLAN networks for monitoring and controlling systems », The International Conference on Information Networking 2014,‎ , p. 226-231 (DOI 10.1109/ICOIN.2014.6799696)
  • (en) Z. Li, M. Liang, L. O'Brien et H. Zhang, « The Cloud's Cloudy Moment: A Systematic Survey of Public Cloud Service Outage », International Journal of Cloud Computing and Services Science,‎ (DOI 10.11591/closer.v2i5.5125)
  • (en) K. Dahbur, B. Mohammad et A. Tarakji, « A survey of risks, threats and vulnerabilities in cloud computing », International Conference on Intelligent Semantic Web-Services and Applications,‎ , p. 1-6 (ISBN 9781450304740, DOI 10.1145/1980822.1980834)
  • (en) JG. Lou, Q. Lin, R. Ding, Q. Fu, D. Zhang et T. Xie, « Software analytics for incident management of online services: An experience report », IEEE/ACM International Conference on Automated Software,‎ , p. 475-485 (DOI 10.1109/ASE.2013.6693105)
  • (en) V. Munteanu, A. Edmonds, T. Bohnert et T. FortiƟ, « Cloud incident management, challenges, research directions, and architectural approach », IEEE/ACM 7th International Conference on Utility and Cloud Computing,‎ , p. 786-791 (ISBN 9781479978816, DOI 10.1109/UCC.2014.128)
  • (en) E. Karakoc et F. Dikbiyik, « Rapid migration of VMs on a datacenter under cyber attack over optical infrastructure », International Symposium on Smart MicroGrids,‎ , p. 54-58 (ISBN 9781509037841, DOI 10.1109/HONET.2016.7753450)
  • (en) A. Herrera et L. Janczewski, « Cloud supply chain resilience », Information Security for South Africa - Proceedings of the ISSA 2015 Conference,‎ , p. 54-58 (ISBN 9781479977550, DOI 10.1109/ISSA.2015.7335076)
  • (en) H. Liu, X. Wu, M. Zhang, L. Yuan, R. Wattenhofer et D. Maltz, « zUpdate: Updating data center networks with zero loss », SIGCOMM 2013 - Proceedings of the ACM,‎ , p. 411-422 (ISBN 9781450320566, DOI 10.1145/2486001.2486005)
  • (en) G. Carnino et C. Marquet, « Les datacenters enfoncent le cloud : enjeux politiques et impacts environnementaux d’internet », Zilsel, vol. 3, no 1,‎ , p. 19 (ISSN 2551-8313, DOI 10.3917/zil.003.0019)
  • (en) X. Wu, D. Turner, CC. Chen, D. Maltz, X. Yang, L. Yuan et M. Zhang, « NetPilot », ACM SIGCOMM 2012 conference,‎ , p. 419 (ISBN 9781450314190, DOI 10.1145/2342356.2342438)
  • (en) J. Maza, T. Xu, K. Veeraraghavan et O. Multu, « A Large Scale Study of Data Center Network Reliability », ACM Press,‎ , p. 393-407 (ISBN 9781450356190, DOI 10.1145/3278532.3278566)
  • (en) N. Shelly, B. Tschaen, KT. Forster, M. Chang, T. Benson et L. Vanbever, « Destroying networks for fun (and profit) », ACM Press,‎ , p. 1-7 (ISBN 9781450340472, DOI 10.1145/2834050.2834099)
  • (en) A. TaherMonfared et MG. TurnerJaatun, « Handling compromised components in an IaaS cloud installation », Journal of Cloud Computing, vol. 1, no 1,‎ , p. 16 (ISSN 2192-113X, DOI 10.1186/2192-113X-1-16)
  • (en) V. Munteanu, A. EDmonds, TM. Bohnert et TF. Fortis, « Cloud Incident Management, Challenges, Research Directions, and Architectural Approach », ACM International Conference on Utility and Cloud Computing,‎ , p. 786-791 (ISBN 978-1-4799-7881-6, DOI 10.1109/UCC.2014.128)
  • (en) X. Wu, BK. Raju et G. Geethakumari, « A novel approach for incident response in cloud using forensics », ACM India Computing Conference,‎ , p. 1-6 (ISBN 9781605588148, DOI 10.1145/2675744.2675766)
  • (en) A. Fox, E. Kiciman et D. Patterson, « Combining statistical monitoring and predictable recovery for self-management », ACM Press,‎ , p. 49-53 (ISBN 1581139896, DOI 10.1145/1075405.1075415)
  • (en) J. Villamayor, D. Rexachs, E. Luque et D. Lugones, « RaaS: Resilience as a Service », ACM International Symposium,‎ , p. 356-359 (ISBN 978-1-5386-5815-4, DOI 10.1109/CCGRID.2018.00055)
  • (en) H. Kurra, Y. Al-Nashif et S. Hariri, « Resilient cloud data storage services », ACM Cloud and Autonomic Computing Conference,‎ , p. 1 (ISBN 9781450321723, DOI 10.1145/2494621.2494634)
  • (en) H. Gunawi, M. Hao, RO. Suminto, A. Aksono, AD. Satria, J. Adityatame et KJ. Eliazar, « Why Does the Cloud Stop Computing? », ACM Symposium on Cloud Computing,‎ , p. 1-16 (ISBN 9781450345255, DOI 10.1145/2987550.2987583)
  • (en) X. Wu, D. Turner, CC. Chen, D. Maltz, X. Yang, L. Yuan et M. Zhang, « Power attack defense », ACM Press, vol. 44, no 3,‎ , p. 493-505 (DOI 10.1145/3007787.3001189)
  • (en) P. Huang, C. Guo, L. Zhou, JR. Lorch, y. Dang, M. Chintalapati et R. Yao, « Gray Failure - The Achilles' Heel of Cloud-Scale Systems », ACM Digital Library, vol. 292,‎ , p. 150-155 (ISBN 9781450350686, DOI 10.1145/3102980.3103005)
  • (en) HS. Gunawi, C. McCaffrey, D. Srinivasan, B. Panda, A. Baptist, G. Grider, PM. Fields, K. Harms, RB. Ross et A. Jacobson, « Fail-Slow at Scale », ACM Transactions on Storage, vol. 14, no 3,‎ , p. 1-26 (DOI 10.1145/3242086)
  • (en) P. Cichonski, T. Millar, T. Grance, M. Chang et K. Scarfone, « Computer SecurityIncident Handling Guide », National Institute of Standards and Technology Special Publication,‎ , p. 1-79 (DOI 10.6028/NIST.SP.800-61r2)
  • (en) J. Cusick et G. Ma, « Creating an ITIL inspired Incident Management approach: Roots, response, and results », IEEE / IFIP,‎ , p. 142-148 (DOI 10.1109/NOMSW.2010.5486589)
  • (en) A. Greenberg, J. Hamilton, D. Maltz et P. Patel, « The cost of a cloud », ACM, vol. 39, no 1,‎ , p. 68 (DOI 10.1145/1496091.1496103)
  • (en) C. Cao et Z. Zhan, « Incident management process for the cloud computing environments », IEEE,‎ , p. 225-229 (DOI 10.1109/CCIS.2011.6045064)
  • Pascal Grosjean et MĂ©dĂ©ric Morel, « Performance des architectures IT Ressource Ă©lectronique : Comprendre, rĂ©soudre et anticiper », Dunod,‎ (ISBN 978-2-10-056252-7)
  • (en) G. Lindfield et J. Penny, « An Introduction to Matlab BT - Numerical Methods », Academic Press, no 3,‎ , p. 1-66 (ISBN 9780123869883, DOI 10.1016/B978-0-12-386942-5.0000)
  • (en) V. Dinesh Reddy, Brian Setz, G. Subrahmanya, G.R. Gangadharan et Marco Aiello, « Best Practices for Sustainable Datacenters », IT Professional, vol. 20,‎ , p. 57-67 (ISSN 1941-045X, DOI 10.1109/MITP.2018.053891338)
  • (en) Alberto BelalcĂĄzar BelalcĂĄzar, « Incorporation of Good Practices in the Development and Deployment of Applications through Alignment of ITIL and Devops », IEEE,‎ (ISBN 978-1-5386-2645-0, DOI 10.1109/INCISCOS.2017.31)
    INSPEC Accession Number: 17661490
  • (en) P. Juliard, « Lean manufacturing: a process for all seasons », IEEE,‎ (ISBN 0-7803-3959-2, DOI 10.1109/EEIC.1997.651323)
    Conference Location: Rosemont, IL, USA, USA
  • (en) « Implementation of the Service Center according to best practices recommended by ITIL », IEEE, vol. 16, no 6,‎ , p. 1809 - 1816 (ISSN 1548-0992, DOI 10.1109/TLA.2018.8444403)
  • (en) Sergio Varga, Gilmar Barreto et Paulo D. Battaglin, « Increasing Information Systems Availabiliy Through Accuracy, Awareness, Completeness and Manageability of ITSM », IEEE,‎ (ISSN 2166-0727, DOI 10.23919/CISTI.2019.8760686)
  • (en) Duan Xiao-chen, Liu Jing-yan et Di Jie, « Study on engineering cost estimation based on chaos theory and cost-significant theory », IEEE,‎ (ISBN 978-1-4244-4247-8, DOI 10.1109/CCCM.2009.5267688)
    Conference Location: Sanya, China
  • (en) Kennedy A. Torkura, Sukmana Muhammad I.H., Feng Cheng et Meinel Christoph, « Security Chaos Engineering for Cloud Services: Work In Progress », IEEE,‎ (ISSN 2643-7929, DOI 10.1109/NCA.2019.8935046)
    Conference Location: Cambridge, MA, USA, USA
  • (en) Hao Zhang et Zhang Tie-nan, « Research on characteristics of chaos in enterprise strategic system and chaos management », IEEE,‎ (ISSN 2155-1847, DOI 10.1109/ICMSE.2008.4668945)
    Conference Location: Long Beach, CA, USA
  • (en) KJ. Engenmann et HE. Miller, « Risk and Data Center Planning », Engineering and Management of Data Centers. Service Science,‎ , p. 1-21 (DOI 10.1007/978-3-319-65082-1_4)

Liens externes

(en) « Uptime Institute » (consulté le )

(en) « ITIL Résultats », sur Uptime Institute (consulté le )

(en) « 2019 Annual Data Center Survey Results », sur Uptime Institute, (consulté le )

Centre de données

Cloud computing

(en) « NASA's Ames Research Cente » (consulté le )

« Directive SEVESO » (consulté le )

(en) « Swiss National Supercomputing Centre » (consulté le )

(en) « Centre Calcul IN2P3 » (consulté le )

(en) « CNRS IN2P3 » (consulté le )

(en) « Worldwide LHC Computing Grid » (consulté le )

(en) « WLCG Service Incident Reports » (consulté le )

(en) « Institut du developpement et des ressources en informatique scientifique » (consulté le )

(en) « European Advanced Computing Services for Research » (consulté le )

(en) « European Technology Platform for HPC » (consulté le )

(en) « Journal of grid computing. », sur Springer Science+Business Media. (consulté le )

(en) « TOP500 Supercomputer Sites » (consulté le )

(en) « ANSSI Agence Nationale de la Sécurité des SystÚme d'Information » (consulté le )

(en) « NIST National Institute of Standards and Technology » (consulté le )

(en) « Bulletin d’actualitĂ© CERTFR-2016-ACT-014 » (consultĂ© le )

(en) « ISO 27035 Information security incident management » (consulté le )

(en) « SANS Institute » (consulté le )

(en) « ENISA European Union Agency for cybersecurity » (consulté le )

(en) « Good Practice Guide for Incident Management » (consulté le )

(en) « Carnegie Mellon University » (consulté le )

(en) « Defining Incident Management Processes for CSIRTs » (consulté le )

(en) « Publicly Reported Outages 2018-19 » (consulté le )

(en) « 8th annual Data Center Survey » (consulté le )

« ITIL France » (consulté le )

« La Disponibilité : Un critÚre déterminant dans le choix d'un hébergement Cloud » (consulté le )

« Data center : bienvenue dans les usines à données » (consulté le )

« ITIL : Renaissance ou dernier soupir » (consulté le )

(en) « Service Management for the digital edge » (consulté le )

(en) « TOGAF The Open Group Architecture Framework » (consulté le )

« Agile et ITIL 4 : l’avĂšnement de l’IT Service Management Agile » (consultĂ© le )

(en) « AWS Auto Scaling » (consulté le )

« ITIL et DATA CENTERS » (consulté le )

« APL : Avis d'expert » (consulté le )

« Gestion des incidents : Processus ITIL » (consulté le )

« Un datacenter Google frappé par la foudre » (consulté le )

« Panne de Google Cloud : le gĂ©ant du web relativise l’incident » (consultĂ© le )

« Panne de Google Cloud : les faiblesses du Cloud mises en lumiÚre » (consulté le )

« Vérifier l'état actuel d'un service G Suite » (consulté le )

« Carte des pannes de Google » (consulté le )

« Processus de gestion des incidents liés aux données » (consulté le )

« IA : Google confie les clés du refroidissement de ses data centers à ses algorithmes » (consulté le )

« Incendie dans le datacenter : histoires vraies de PRA qui s'envolent en fumée » (consulté le )

« Guide sur le CloudComputing et les dataCenters Ă  l’attention des collectivitĂ©s locales » (consultĂ© le )

« Comment OVH évite le coup de chaud à ses datacenters » (consulté le )

« Energie consommée par les data centers » (consulté le )

« Incidents et Google Cloud Status Dashboard » (consulté le )

« Supervision d’un data center : Organisation et mĂ©thodologie (© 2012 Amadeus IT Group SA) » (consultĂ© le )

« Solution d'interconnexion de data centers » (consulté le )

« Google donne plus de détails sur l'incident de mise en réseau de ses services cloud » (consulté le )

« Google Cloud Status Dashboard » (consulté le )

« Pics de canicule : pourquoi les datacenters français tiennent le coup » (consulté le )

« ArrĂȘt de Chorus : les raisons de la panne du datacenter de Bull » (consultĂ© le )

« Pourquoi Google construit 12 nouveaux datacenters dans le monde ? » (consulté le )

« Plan de continuité informatique - Principes de base » (consulté le )

(en) « Failure Diagnosis for Datacenter Applications » (consulté le )

« Les gĂ©ants d’internet et du cloud disposent de 300 datacenters dans le monde » (consultĂ© le )

« Gestion des évÚnements ITIL dans le cloud » (consulté le )

« AMS exploite l’infrastructure AWS en faveur de clients d’entreprises et de partenaires » (consultĂ© le )

« AWS développerait un nouveau processeur ARM 20% plus performant pour ses data centers » (consulté le )

« Le calcul scientifique des expériences LHC - Résumé » (consulté le )

« DGA VDR » (consulté le )

NETFLIX CHAOS

« Le calcul scientifique des expériences LHC - Une grille de production mondiale » (consulté le )

« Travaux OVH » (consulté le )

« retour expérience OVH » (consulté le )

« Amazon passe à la vitesse supérieure dans la création des puces de son cloud » (consulté le )

« Cloud computing : la lourde tendance 2020, le "serverless" progresse » (consulté le )

« L’impact spatial et Ă©nergĂ©tique des data center sur les territoires » (consultĂ© le )

« Orange - Construction d'un data center Val de Reuil » (consulté le )

« Evaluation of Incident Detection Methodologies » (consulté le )

« L’intelligence artificielle est "dans l’impasse" » (consultĂ© le )

« Livre blanc : Approches contemporaines en hébergement et gestion de données » (consulté le )

(en) « Software analytics for incident management of online services : an experience report » (consulté le )

« Microsoft Cloud Infrastructure » (consulté le )

(en) « Inside a Google data center » (consulté le )

« Intel se muscle dans l'intelligence artificielle en s'emparant d'Habana Labs pour 2 milliards de dollars » (consulté le )

« Project Silica : Pour Microsoft, le futur du stockage de données est... un morceau de verre » (consulté le )

« Plus de 500 mĂ©ga datacenters opĂ©rĂ©s par les gĂ©ants d’internet et du cloud » (consultĂ© le )

« Avec 3 milliards d’euros investis dans ses data centers europĂ©ens, Google se pose en champion de la greentech » (consultĂ© le )

« Quatre innovations pour accélérer sur le calcul à haute performance (HPC) » (consulté le )

« La start-up Immersion 4 rafraĂźchit les data centers
 et veut rĂ©utiliser l’énergie qu’ils dĂ©gagent » (consultĂ© le )

« Vivement le datacenter autonome, parce que vous avez dĂ©jĂ  assez de problĂšmes Ă  gĂ©rer
 » (consultĂ© le )

« Comment Naval Group aide Microsoft à créer et déployer un datacenter sous-marin » (consulté le )

« Microsoft poursuit son projet fou de data center sous-marin avec Naval Group » (consulté le )

« Cloud, HPC, intelligence artificielle... Lenovo fait une démonstration de force dans les serveurs » (consulté le )

« AG2R La Mondiale se convertit au stockage de données à mémoires flash » (consulté le )

Maillage de l'infrastructure Internet en France

« Le phénomÚne Pokémon GO révÚle nos besoins en datacenters de proximité » (consulté le )

« Data Center Research : actualités des data center » (consulté le )

« L'origine du terme Bug » (consulté le )

(en) « Google Cloud Networking Incident #19009 » (consulté le )

Grace Hopper

Télégraphe Vibroplex

« Une panne du cloud d’Amazon met en panique tout l’internet mondial » (consultĂ© le )

« Top 7 pannes 2019 » (consulté le )

« Thomas Edison » (consulté le )

(en) « Ponemon Institute » (consulté le )

(en) « Cost of Data Center Outages » (consulté le )

« Cloud hybride : qu’est-ce que c’est et Ă  quoi ça sert » (consultĂ© le )

« Agence de l'Environnement et de la MaĂźtrise de l'Énergie » (consultĂ© le )

« AMAZON WEB SERVICES Lambda » (consulté le )

« AWS CHAOS GameDay » (consulté le )

« AWS CHAOS » (consulté le )

« AZURE » (consulté le )

« Infoq » (consulté le )

« Travaux OVH Fibre » (consulté le )

« Travaux OVH EMC » (consulté le )

« Gartner » (consulté le )

« Guide PCA » (consulté le )

« BULL Chorus » (consulté le )

« Prometheus » (consulté le )

« Agile et ITIL 4 : l’avĂšnement de l’IT Service Management Agile » (consultĂ© le )

« cloudflare outage » (consulté le )

(en) « Google Cloud Whitepaper Data incident response process » (consulté le )

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.