L'un des premiers principes fondamentaux du cloud computing était que « vous êtes propriétaire de votre propre disponibilité L'idée étant que les fournisseurs de cloud public mettent à votre disposition une infrastructure, et que votre organisation doit décider quoi et comment l'utiliser pour atteindre ses objectifs. Les fournisseurs de cloud n'ont aucune connaissance de vos applications ni de leurs indicateurs clés de performance (KPI).

Ces dix dernières années, de plus en plus d'organisations se sont tournées vers le cloud et d'autres fournisseurs SaaS pour de nombreuses fonctions essentielles de leur infrastructure technique. C'est une excellente chose ! Les équipes peuvent ainsi se concentrer sur les fonctionnalités clés qui créent de la valeur et génèrent des revenus, sans se soucier des aspects techniques plus fastidieux.

Cette dépendance a engendré des risques. Les fournisseurs de services cloud ont subi des pannes dues à… erreurs de configuration , attaques par déni de service distribué (DDoS), et même incendies catastrophiques .

Comment une équipe doit-elle gérer un incident lié à un fournisseur en amont ? Que pouvons-nous tirer de notre expérience dans la gestion de nos propres incidents ?

Nous ne pourrons pas résoudre ce type d'incidents seuls. De nombreuses équipes devront patienter et attendre que le problème se résolve de lui-même. D'autres évalueront le coût d'une migration ou d'un basculement, et certaines l'auront déjà fait avant même que nous nous apercevions du problème.

Qui est responsable de la relation avec le fournisseur pendant un incident ?

La gestion des relations avec les fournisseurs incombe souvent aux équipes des achats, des finances ou du service juridique. Elle repose en grande partie sur les contrats, les modalités de paiement et les SLA. Toutefois, en cas d'incident fournisseur, les équipes qui utilisent directement les produits du fournisseur doivent être informées des communications avec ce dernier.

Si votre fournisseur d'infrastructure cloud rencontre une panne, votre équipe SRE sera probablement en charge des notifications et des mises à jour d'état. Si votre fournisseur de facturation est impliqué, ce sera sans doute l'équipe qui gère le traitement des paiements. Les équipes en charge des outils de développement ou de l'expérience développeur surveilleront les problèmes liés aux systèmes de contrôle de version, aux processus de compilation et de déploiement, ou aux systèmes de surveillance.

Il est important de savoir à l'avance quelles équipes sont responsables de quelles relations avec les fournisseurs afin de pouvoir vérifier si votre organisation est ou non impactée par un incident chez un fournisseur, de savoir quand l'incident a été entièrement résolu et le service entièrement rétabli, et de déterminer l'impact de l'incident sur vos utilisateurs.

Conservez ces informations à portée de main et assurez-vous qu'elles soient à jour dans le cadre de votre préparation aux incidents. Dans PagerDuty, vous pouvez même définir un service Représenter un fournisseur et ajouter des informations de contact, des manuels d'exploitation et d'autres données à la définition du service pour faciliter votre réponse, ainsi qu'une politique d'escalade qui notifie l'équipe qui interagit avec le fournisseur.

Obtenez vos informations à la source

En cas d'incidents majeurs ou de pannes importantes, ces événements font souvent la une de l'actualité technologique. L'information est relayée par les médias traditionnels, les réseaux sociaux et les listes de diffusion spécialisées dédiées à certains produits, ou simplement par d'autres médias. pannes en général.

Pour vos principaux fournisseurs – les services qui contribuent à votre productivité ou à la génération de revenus – vérifiez s'ils hébergent un page d'état et leur emplacement. Il est recommandé que ces pages d'état soient hébergées sur un domaine autre que le nom de domaine principal de l'entreprise ; vous ne les trouverez donc pas forcément à l'adresse entreprise.com/statut. L'entreprise peut également disposer de comptes dédiés sur les réseaux sociaux pour la mise à jour de l'état de ses services.

S'ils n'ont pas de page d'état, ils ont peut-être une liste de diffusion par courriel pour les notifications clients à laquelle vous devrez vous abonner.

La plateforme de chat de votre organisation permet probablement aussi à votre équipe de s'intégrer aux pages d'état de vos fournisseurs, offrant ainsi un autre moyen aux membres de l'équipe de déterminer si un incident se produit chez le fournisseur.

De plus, il existe désormais un certain nombre de plateformes de signalement tierces qui fournissent des informations supplémentaires :

• détecteur de vers le bas , Prêt pour tout le monde ou juste pour moi Ces outils, ainsi que d'autres, permettent de suivre les pannes des grands sites commerciaux et des opérateurs mobiles. Ils sont très intuitifs et utiles pour les personnes qui ne savent pas si le problème rencontré provient de leur seul réseau ou s'il est plus général.
• Le Carte météo Internet Des rapports sur la latence du réseau à l'échelle mondiale. Utile si vos clients sont répartis dans le monde entier. Destiné aux experts en réseaux.

Votre guide fournisseur

En cas d'incident chez un fournisseur, vous aurez besoin d'informations à portée de main en tant que client. Établissez un guide de procédures pour vos principaux fournisseurs afin de savoir qui contacter et comment.

Notez les informations clés dans votre manuel d'exploitation :

• Veuillez indiquer les numéros de compte ou les identifiants de votre organisation afin que nous puissions les mentionner lors de vos prises de contact avec le support.
• Adresses électroniques ou coordonnées de vos gestionnaires de compte et de l'équipe d'assistance du fournisseur.
• Les informations contractuelles, telles que les forfaits et les fonctionnalités que vous avez achetés, ainsi que votre niveau d'assistance, le cas échéant. Si vous bénéficiez d'un forfait d'assistance avancé, il est important d'en être informé ; celui-ci peut inclure des interlocuteurs spécifiques.
• Statut de votre compte et date de renouvellement. Veuillez vérifier que votre compte n'a pas expiré avant de signaler un problème.
• Toute exigence de rapport spécifique au fournisseur, comme les codes d'erreur ou les traces de pile, qu'il pourrait être utile de recueillir.

Notez également dans votre manuel d'exploitation des fournisseurs si vous avez une idée des situations où il sera important de les contacter. Lors de pannes majeures affectant des centaines, voire des milliers de clients, il est possible que vous n'ayez pas besoin de contacter le fournisseur et que vous préfériez vous fier aux informations publiques disponibles. En revanche, pour les incidents qui ne laissent pas présager d'un impact important, vos équipes souhaiteront prendre contact avec le fournisseur.

Pendant que vous attendez

Les incidents publics peuvent être extrêmement intéressants pour les membres de votre organisation. Ils sont spectaculaires ! Ils font la une des journaux ! Tout le monde est distrait !

Les incidents peuvent engendrer une perte de temps considérable au sein de votre organisation. Si vos collaborateurs ont l'impression de ne pas pouvoir travailler efficacement en raison d'un incident chez un fournisseur, votre équipe a besoin d'un plan de communication pour les tenir informés.

Vos procédures de gestion des incidents majeurs peuvent vous aider à minimiser les distractions, même lorsque votre équipe ne gère pas activement une opération de résolution.

• Désignez un interlocuteur interne. Permettez à un membre de l'équipe en charge de la relation de rester en contact avec le fournisseur ou de suivre l'état d'avancement de la situation. Si l'incident persiste, transférez cette responsabilité à une autre personne après quelques heures.
• Définissez les modalités de diffusion de l'information. Utilisez vos canaux de communication habituels avec les parties prenantes afin que votre équipe n'ait pas à chercher l'information ailleurs.
• Si un incident chez un fournisseur a des répercussions sur vos clients, prenez contact avec vos équipes de support pour les notifications clients et vos propres mises à jour de statut.

De nombreux incidents liés aux fournisseurs sont résolus assez rapidement. Les grands systèmes complexes comme AWS, Azure et même GitHub connaissent régulièrement des incidents mineurs affectant certains sous-systèmes. Il est généralement possible d'attendre que ces incidents se résolvent d'eux-mêmes, même s'ils peuvent impacter votre productivité. Voici quelques points à prendre en compte concernant ces incidents :

• Déterminez si votre équipe doit décider de geler les déploiements et à quel moment, et qui aura l'autorité pour prendre cette décision, y compris le soutien de la direction.
• Déterminez où se déroulera la communication interne. Assurez-vous que chacun soit informé.
• Désignez un membre de l'équipe chargé de surveiller le statut du fournisseur et de donner le feu vert.

Pour les incidents plus importants, plus étendus ou plus longs, votre plan de reprise après sinistre (PRA) pourrait s'avérer nécessaire. Espérons que vous l'avez mis en pratique récemment !

Il est peu probable que votre plan de reprise d'activité vous offre une couverture complète. Il est rare de disposer d'une redondance totale chez tous vos fournisseurs, du moins à court terme. Changer de fournisseur de système de contrôle de version ou déployer des solutions, même lors de pannes prolongées, s'avère complexe et coûteux.

Les plans de reprise après sinistre (PRA) pour l'infrastructure et les données sont plus courants et correspondent à ce que beaucoup d'entreprises ont en tête lorsqu'elles souhaitent assurer leur propre disponibilité. Votre PRA peut inclure diverses fonctionnalités, mais voici quelques éléments essentiels à retenir :

• Sachez quand déclarer un sinistre et déclencher un basculement. Définissez des seuils pour l'impact sur les clients, l'impact sur le chiffre d'affaires et d'autres indicateurs clés.
• Établir les responsabilités et les communications de la direction.
• Déclenchez une procédure d'incident majeur, ou une procédure de reprise après sinistre si vous en avez une, afin que toutes les équipes soient en alerte.
• Préparez des tests de réussite et d'assurance qualité prédéterminés.

Votre revue post-incident fournisseur

Suite à un incident majeur avec un fournisseur, votre équipe sera en mesure de déterminer si ce dernier a perdu votre confiance en tant que client. À ce stade, vos services achats, finances ou juridiques devront être consultés afin de déterminer si les accords de niveau de service (SLA) ont été violés et si votre entreprise a droit à un avoir ou à un remboursement de la part du fournisseur.

Les équipes utilisant ce fournisseur doivent évaluer si l'incident a eu un impact suffisamment important pour justifier un changement de fournisseur. L'analyse comparative du coût de l'incident (ou des incidents) avec les coûts de migration et les fonctionnalités disponibles doit être effectuée une fois l'incident résolu, lorsque l'équipe peut pleinement évaluer la manière dont le fournisseur l'a géré du début à la fin.

Comme pour tout PIR, déterminez si vos actions ont été efficaces et apportez les mises à jour nécessaires à votre manuel d'exploitation des fournisseurs :

• Vos informations étaient-elles toutes à jour ?
• Vos méthodes de communication, tant de la part du fournisseur qu'en interne à vos équipes, ont-elles été efficaces ?
• Avez-vous pu rétablir les fonctionnalités lorsque le fournisseur a affirmé que le service était restauré, ou d'autres actions ont-elles été nécessaires ?
• Y a-t-il eu autre chose qui a ralenti votre prise de conscience de l'incident ou votre rétablissement par la suite ?

Conclusion

Les incidents liés aux fournisseurs sont source de stress, non seulement en raison de leur impact potentiel sur nos organisations, mais aussi souvent à cause du sentiment d'impuissance que ressentent nos équipes d'intervention lorsque les problèmes ne dépendent pas d'elles. Anticiper ces incidents permettra de tenir vos équipes informées et d'accélérer la résolution des problèmes.

Vérifier cette liste de contrôle exhaustive conçu pour vous aider à identifier et à combler les lacunes critiques de votre processus de gestion des incidents.