Politique de gestion des incidents clients

Comprenez comment Cloudflare gère les incidents impactant son environnement de production et les moyens utilisé par Cloudflare pour communiquer la nature et l’impact de ces incidents aux clients Enterprise.

​​ Dans cet article

• Objectif Open external link
• Champ d’application Open external link
• Contexte Open external link
• Définitions Open external link
• Rôles et Responsabilités Open external link
• Procédure d’exploitation standard Open external link
• Gestion d’incident Open external link
• Communications d’incident Open external link
• Analyse post mortem Open external link
• Analyse des problèmes Open external link

​​ Objectif

Chez Cloudflare, nous pensons que l’ouverture et la transparence sont inhérentes à la fourniture de notre service et nous consacrons nos efforts à établir un lien de confiance entre nos clients et la communauté internet en général.  Cloudflare exploite un réseau mondial qui impacte la vie et la prospérité de centaines de millions de personnes. Par conséquent, nous sommes très attentifs à cette responsabilité.

Cette procédure d’exploitation standard (SOP) définit comment Cloudflare traite tous les incidents et les problèmes qui impactent son environnement de production et les moyens par lesquels Cloudflare communique la nature et l’impact de ces incidents aux clients Enterprise, qu’ils soient planifiés ou non, quelle que soit leur gravité.  Cette procédure spécifie comment ces efforts sont suivis de manière uniforme afin de

• maximiser le temps d’activité de l’environnement,
• minimiser l’impact pour le client,
• réduire le temps de réparation, et
• partager les informations avec nos clients et la communauté internet.

​​ Domaine d’application

Cette SOP s’applique aux clients et services clients Cloudflare, tels qu’ils sont utilisés par les clients. La SOP s’applique à tous les environnements de production client chez Cloudflare y compris :

• Le site web public de Cloudflare www.cloudflare.com Open external link )
• Les API (Interfaces de programmation d’applications) de Cloudflare
• Les interfaces sortantes de tiers (par exemple, les autorisations de carte de crédit, etc.)
• L’infrastructure réseau détenue ou gérée par Cloudflare ou ses services de production
• Les logiciels de fournisseurs, le matériel et les services en lien avec toute partie de la production de Cloudflare

​​ Contexte

Cloudflare veut construire un internet meilleur. Afin d’offrir une expérience améliorée à des millions d’utilisateurs internet, les opérations internes de Cloudflare doivent suivre des procédés et des procédures de fourniture de service irréprochables.  Les procédures de Cloudflare respectent par conséquent les bonnes pratiques des normes du secteur, dont certaines suivent spécifiquement les modèles de l’Information Library Infrastructure Technology (ITIL)  Cette SOP se conforme aux bonnes pratiques de la méthodologie de gestion des problèmes de l’ITIL.

​​ Définitions

Catégories des termes d’incidents-clés :  Tous les évènements constituent des conditions pouvant générer des alertes. Certaines alertes sont des incidents qu’il convient de noter (et d’autres non). Tous les incidents doivent être triés (parfois de manière automatisée, parfois par le biais de l’analyse humaine). Certains incidents sont des problèmes, certains sous-ensemble de problèmes sont « majeurs » et provoquent des mises à jour de la page de statut. Certains incidents majeurs ont un niveau de priorité élevé (P1) qui nécessite la rédaction d’un Rapport d’incident.

Terminologie-clé :

​​ Rôles et Responsabilités 

​​ Les rôles et les responsabilités qui suivent sont associés à la gestion des incidents au sein de Cloudflare : 

​​ Procédure d’exploitation standard

Cette section détaille les procédures pour la gestion des incidents et des problèmes.  À un niveau élevé, ces procédures se définissent de la manière suivante :

• Gestion d’Incidents :  Désigne la procédure générale pour l’observation et la réponse aux alertes, y compris l’évaluation de l’impact et de la gravité d’un incident, la classification de l’incident en problème, l’attribution d’une priorité au problème ou le rejet de l’incident comme évènement non impactant si la condition d’un problème ne peut pas être identifiée.

• Gestion de problème :  Désigne la procédure d’identification de la portée et de l’étendue du problème, l’attribution d’un niveau de gravité approprié (P0, P1, P2, P3), les actions pour résoudre le problème et revenir à état optimal pour les services de production optimal, et la communication du problème au parties appropriées.

• Gestion de la résolution :  Le processus qui consister à enquête sur les causes et les conditions qui ont provoqué un problème, à rendre compte de la manière générale dont un problème a été géré et résolu, et à effectuer toute analyse postérieure visant à empêcher la reproduction des conditions et des causes d’un problème à l’avenir.  

​​ Gestion d’incident

Le but principal de la Gestion d’incident est d’identifier et de réagir à des problèmes potentiels le plus rapidement possible pour minimiser l’impact sur les services de production et offrir les meilleurs niveaux possibles de qualité et de disponibilité des services.  Les meilleurs niveaux possibles de qualité et de disponibilité des services signifieraient que tous les services fonctionnent exactement comme prévu 100 % du temps et soient disponibles et accessibles 100 % du temps.

Parce que nous acceptons qu’un ensemble de forces sous notre contrôle et de forces en dehors de notre contrôle finiront par avoir un impact sur l’intégrité du service, nous définissons des Objectifs de niveau de service (SLO) et des Accords de niveau de service (SLA) pour décrire quelles dégradations de l’intégrité du service sont acceptables pour les divers services du réseau Cloudflare.   Les SLA et SLO sont exprimés en pourcentage de période (en mois et en année).

Le niveau d’information donné concernant un incident peut varier mais les informations suivantes doivent être recueillies avant qu’un incident ne soit classifié et priorisé :

• Source de l’auteur (alerte de surveillance ou autre source)
• Client(s) (le cas échéant)
• Système ou application (et nom d’hôte, le cas échéant)
• Moment de l’alerte
• Portée de l’impact : estimation du nombre de systèmes, utilisateurs ou régions impactés
• Type d’impact : portée générale de la détérioration du service (par exemple, perte de tous les accès, performance dégradée, applications dépendantes impactées, impact observé sur les clients)

Tous les Incidents qui sont classifiés comme problème qui ont une priorité P0 ou P1, indépendamment de la source, seront consignés dans le système de tickets de Cloudflare, JIRA.  Certaines alertes indiqueront des conditions qui n’impacteront peut-être pas immédiatement les niveaux de service et seront classées si besoin comme problèmes avec une priorité P2 ou P3.   

Le système JIRA est un système d’enregistrement de toutes les informations relatives aux incidents, et toutes les autres sources de documentation concernant un problème (par exemple, historique d’alertes, copies d’écran, journaux de travail, conversations de chat) sont joints au ticket JIRA original créé en réponse à l’incident.

​​ Classifications des incidents

Après avoir acquitté une alerte, le SRE triera immédiatement l’alerte en la plaçant dans une catégorie et en lui attribuant un niveau de priorité.  En créant de nouveaux tickets JIRA pour des problèmes de priorité élevée (P0 et P1), le SRE s’assurera que chaque ticket est classifié correctement en incluant sa Catégorie et son Niveau de priorité.

​​ Niveau de priorité :

Tous les tickets seront classifiés selon les 4 niveaux de priorité suivants.  Les critères énumérés sont des lignes directrices générales.   Les conditions décrites ci-dessous doivent explicitement décrire un niveau de priorité. Cependant, à la discrétion du SRE ou de la direction de Cloudflare, les problèmes peuvent être assignés selon les besoins à un niveau de priorité plus élevé.

​​

Catégorie

Aux fins d’un suivi et de communications corrects, les problèmes de priorité élevé (P0 et P1) seront attribués à des catégories. Ces catégories (étiquettes de ticket) correspondent aux catégories communiquées publiquement qui sont énumérées sur la Page de statut publique de Cloudflare.   

Les tickets de niveau de priorité bas (P2 et P3) peuvent être classifiés en utilisant des étiquettes et une nomenclature spécifiques aux différentes équipes techniques et non techniques de Cloudflare.  Ces différentes étiquettes et catégories ne sont pas indiquées dans ce document.  

​​ Incidents de sécurité

Vous devez comprendre que les incidents qui sont classifiés dans la catégorie Sécurité requièrent un traitement et des procédures spéciales.  Les incidents doivent être consignés ici et suivre les procédures d’Incident de sécurité, définies par l’équipe de Sécurité des informations de Cloudflare.

​​ Incidents de gravité ou de priorité élevée

Les Incidents P0 et P1 ont évidemment plus d’impact sur l’activité commerciale. Par conséquent, ils font l’objet en amont d’exigences particulières pour nous assurer qu’ils seront traités dans les délais les plus courts possibles.

​​ Gestionnaire d’incident

Pour les problèmes de types P0 et P1, Les gestionnaires d’incident d’astreinte doivent être contactés immédiatement.  Un calendrier des gestionnaires d’incident sera publié pour s’assurer que le SRE sait qui contacter à un moment spécifique.  Le gestionnaire d’incident est un responsable de ressources critiques pour ce qui suit :

• La validation de la gravité d’un problème
• Le suivi du problème de sa soumission à sa résolution
• Le respect du plus grand intérêt des clients
• La consignation de toutes les actions et délais
• La conduite du personnel vers la résolution la plus rapide du problème
• S’assurer que les clients et la direction interne sont notifiés du statut dans les délais prédéterminés (ou de changements de statut)
• Effectuer des escalades au client, en interne ou à des tiers quand les délais sont dépassés ou en l’absence de progrès appropriés
• Veiller à ce qu’une explication cohérente soit appliquée au ticket au moment de la résolution
• S’assurer que celui qui a soumis le ticket accepte que le problème soit résolu avant que le ticket ne soit refermé 

​​ Communications d’incident

Les communications externes au cours d’un incident sont importantes pour pouvoir :

• Aviser les parties concernées que Cloudflare est au courant du problème et que nous cherchons une solution
• Rassurer les clients et leur dire que le problème est en cours de traitement et que Cloudflare veille à leurs intérêts
• Veiller à ce que les problèmes ne traînent pas et que les escalades appropriées soient effectuées
• Informer les parties concernées internes principales des incidents importants

Les principaux types de communications pendant un incident sont les suivants :

La Page de statut sera créée en utilisant les modèles des membres de l’équipe d’astreinte CSUP dès qu’un incident sera identifié.

​​ Évaluations post mortem 

Cloudflare pense que tous les problèmes critiques ne devraient jamais se produire.  À cet effet, tous les problèmes de type P0 donneront lieu à la publication d’un Rapport d’incident (RI), qui inclura une Analyse des causes profondes (RCA) du problème ainsi que les facteurs généraux qui ont conduit à cet incident. Toutes les publications de RI seront suivies d’une réunion d’évaluation post mortem, durant laquelle les ingénieurs et les gestionnaires examineront et se mettront d’accord sur les détails du RI, les conclusions du RCA et toutes les mesures de correction qui seront prises pour veiller à ce que le problème ne se reproduise plus.

​​ Gestion de problème et post mortem

La gestion de problème est différente de la Gestion d’Incident. En effet, son but principal est de détecter les causes sous-jacentes d’un incident ainsi que les mesures prises pour sa résolution et éviter qu’il ne se reproduise.

​​

Analyse des causes profondes et correction

​​ Ticket de problème

Un RCA est un rapport d’Analyse des causes profondes.  Un ticket de problème JIRA est le fait de consigner et de suivre les évènements justifiant un RCA.  C’est une procédure dans laquelle des experts en la matière (SME) examineront le problème P0 ou P1 en cherchant la cause sous-jacente du problème.  Une fois cette cause déterminée, les SME devront créer un plan de correction pour régler la ou les causes.  Le produit final est un ticket bien documenté pour suivre la correction jusqu’à son terme et, si nécessaire, un rapport d’incident bien rédigé sera envoyé à une équipe interne et/ou au client.

Les points exposés ci-dessus restent applicables même s’il s’agit d’un prestataire ou d’un fournisseur ou vendeur tiers qui fournit l’RCA.  Une fois les informations du RCA reçues de la part du tiers, nous devons nous assurer que le ticket de problème est mis à jour et qu’il comprend toutes les informations pertinentes, dont les corrections en suspens qu’il est nécessaire de suivre.  

​​ Rapport IR

Le Rapport d’Incident (« RI ») est la méthode principale de communication avec le client en cas de problème et peut contenir tout ou partie de ce qui est écrit sur le ticket.  

Le rédacteur du rapport ne sera pas le même en fonction de la gravité du problème et le service responsable.  Une fois le rapport préliminaire établi, il est important de veiller à ce que ce rapport soit examiné par la direction Cloudflare qui prendra connaissance de son contenu, des engagements et de la présentation professionnelle.  Une fois le rapport approuvé, il pourra être remis au client.

​​ Examen des problèmes

Les sections ci-dessus détaillent la gestion de l’incident et la procédure de cause profonde pour s’assurer que la correction est permanente.  La dernière de la procédure de gestion de l’incident et du problème est de s’assurer que les métriques, les tendances et les rapports importants sont effectués, afin de s’assurer que la procédure est bien suivie, que les SLA sont respectés et que les problèmes sous-jacents ne perdurent pas.

​​ Rapports

Les critères des tickets qui doivent faire l’objet d’un rapport pour les tickets ouverts et fermés sont les suivants :

• Gravité
• Catégorie/sous-catégorie
• Groupe responsable
• Âge/Nombre de jours ouvert

Dans la mesure du possible, ces données doivent être présentées sous forme graphique pour faire ressortir les tendances visibles.  Ces rapports doivent être publiés en interne à l’intention des responsables Cloudflare et des propriétaires de zones

​​ Analyse et responsabilités

Chaque propriétaire de zone sera responsable de veiller non seulement à ce que ses tickets soient fermés dans les délais prescrits ou dans un laps de temps raisonnable, mais également d’examiner les rapports pour déceler des tendances, les sujets de préoccupation et les problèmes récurrents.  En se basant sur cette analyse, d’autres tickets Problem seront ouverts pour corriger tout problème qui n’aurait pas été décelé par un P0 ou un P1.  Cela nous permettra d’apporter des améliorations continues et, à terme, de réduire le nombre de nouveaux tickets en nous penchant de plus près sur les causes profondes.

​​ Réunions d’examen de la gestion des incidents (Post-mortem)

Lors de toutes les réunions de personnel des services, les responsables de groupe doivent examiner les rapports sur les tickets ouverts et les tendances en ayant en tête les objectifs suivants :

• Discuter des réussites ou des difficultés rencontrées
• Examiner les opportunités d’amélioration par les propriétaires de zones
• Se mettre d’accord sur les problèmes qui justifient l’ouverture d’un nouveau ticket pour permettre le suivi de la résolution