L’un des premiers principes clés du cloud computing était que « vous possédez votre propre disponibilité ', l'idée étant que les fournisseurs de cloud public mettaient l'infrastructure à votre disposition et que votre organisation devait décider quoi utiliser et comment l'utiliser afin d'atteindre les objectifs de votre organisation. Les fournisseurs de cloud n'ont aucune connaissance de vos applications ou de leurs KPI.

Au cours des dix dernières années, de plus en plus d'organisations sont devenues de plus en plus dépendantes des installations de cloud computing et d'autres fournisseurs SaaS pour de nombreuses fonctions essentielles de leur pile technique. C'est formidable ! Les équipes peuvent se concentrer sur les fonctionnalités métier essentielles qui créent de la valeur et fournissent des revenus à une entreprise individuelle sans se soucier de nombreuses exigences plus banales de leur pile technologique.

Cette dépendance a entraîné des risques. Les fournisseurs de cloud ont connu des pannes en raison de 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 impliquant un fournisseur en amont ? Que pouvons-nous apprendre de notre propre expérience dans la gestion de nos propres incidents ?

Nous ne serons pas en mesure de résoudre ce type d'incidents seuls. De nombreuses équipes devront attendre que le problème soit résolu. D'autres évalueront le coût d'une migration ou d'un basculement, et certaines l'auront déjà fait au moment où le reste d'entre nous remarquera qu'il y a un problème.

À qui appartient la relation avec le fournisseur lors d’un incident ?

La gestion des relations avec les fournisseurs incombe souvent à une équipe chargée des achats, des finances ou du service juridique. La gestion des fournisseurs repose en grande partie sur les contrats, les conditions de paiement et les accords de niveau de service. Cependant, en cas d'incident avec un fournisseur, les équipes qui s'intègrent directement aux produits du fournisseur doivent être informées des communications avec ce dernier.

Si votre fournisseur d'infrastructure cloud subit une panne, votre équipe SRE sera peut-être au courant des notifications et des mises à jour de statut ; si votre fournisseur de facturation est impliqué, il s'agira probablement de l'équipe qui gère votre flux de traitement des paiements. Les équipes chargées des outils de développement ou de l'expérience des développeurs peuvent être à l'affût de problèmes avec les systèmes de contrôle de version, de création et de déploiement ou de surveillance.

Il est important de savoir à l’avance quelles équipes sont responsables de quelles relations avec les fournisseurs pour pouvoir vérifier si votre organisation est ou non impactée par un incident avec un fournisseur, savoir quand l’incident a été entièrement atténué et le service complètement restauré, et pour déterminer l’impact de l’incident sur vos utilisateurs.

Gardez ces informations à portée de main et assurez-vous qu'elles sont à jour dans le cadre de votre préparation aux incidents. Dans PagerDuty, vous pouvez même définir un service représentant un fournisseur et ajoutant des informations de contact, des cahiers d'exécution et d'autres données à la définition de service pour faciliter votre réponse, ainsi qu'une politique d'escalade qui avertit l'équipe qui s'interface avec le fournisseur.

Obtenez vos informations à la source

En cas d'incidents majeurs ou de pannes majeures, les événements constituent souvent l'actualité technologique principale du jour. Les informations seront diffusées dans les médias grand public, sur les réseaux sociaux et sur des listes de diffusion spécialisées dédiées à des produits particuliers, ou simplement pannes en général.

Pour vos principaux fournisseurs (services qui se trouvent dans vos chemins de productivité ou de génération de revenus), sachez s'ils hébergent un page d'état et où il se trouve. Les bonnes pratiques suggèrent que ces pages d'état soient hébergées hors de leurs noms de domaine principaux, vous ne les trouverez donc peut-être pas sur company.com/status. Ils peuvent également avoir des comptes de médias sociaux dédiés aux mises à jour de l'état du service.

S'ils n'ont pas de page de statut, ils peuvent avoir une liste de courrier électronique de notification client à laquelle vous devrez vous abonner.

La plateforme de chat de votre organisation permet probablement également à votre équipe de s'intégrer à vos pages de statut de fournisseur, offrant ainsi un autre moyen aux coéquipiers de déterminer si un incident se produit sur 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 panne , Pour tout le monde ou juste pour moi , et d'autres – suivez les pannes des grands sites commerciaux ainsi que des fournisseurs de téléphonie mobile. Ces outils sont très conviviaux et utiles pour les personnes qui ne savent pas si le problème qu'elles rencontrent se situe uniquement de leur côté ou s'il est plus répandu.
• Le Carte météo sur Internet Rapports sur le décalage du réseau à l'échelle mondiale. Utile si vos clients sont répartis dans le monde entier. Plus pour les passionnés de réseau.

Votre livre d'exécution des fournisseurs

En cas d'incident avec un fournisseur, vous devez, en tant que client, disposer de certaines informations. Établissez un manuel d'exploitation pour vos principaux fournisseurs afin de savoir qui contacter et comment.

Notez les informations clés dans votre livre d’exécution :

• Les numéros de compte ou identifiants de votre organisation afin qu'ils puissent être référencés lorsque vous contactez le support.
• Adresses e-mail ou coordonnées de vos gestionnaires de compte et de l'équipe d'assistance du fournisseur.
• Informations contractuelles telles que les packages et les fonctionnalités que vous avez achetés, ainsi que le niveau d'assistance dont vous disposez, le cas échéant. Si vous disposez d'un package d'assistance de niveau supérieur, vous devez en être conscient ; il peut inclure des points de contact spéciaux.
• Statut de votre compte et date de renouvellement. Assurez-vous que votre compte n'est pas expiré avant de signaler un problème.
• Toutes les exigences de rapport spécifiques au fournisseur, comme les codes d'erreur ou les traces de pile qui pourraient être utiles à collecter.

Notez également dans votre livret d'exécution des fournisseurs si vous avez une idée du moment où il sera important de contacter le fournisseur. En cas de pannes importantes qui affectent des centaines, voire des milliers de clients, vous n'aurez peut-être pas besoin ou envie de contacter le fournisseur, mais vous vous fierez aux informations d'état publiques. Pour les incidents qui ne présentent pas d'indications d'impact plus important, vos équipes voudront le contacter.

En attendant

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

Les incidents peuvent être une perte de temps considérable pour votre organisation pour ces raisons. Si les employés ont l'impression qu'ils ne peuvent pas travailler parce qu'un fournisseur est victime d'un incident, votre équipe a besoin d'un plan de communication pour les tenir informés.

Vos flux de travail d'incident majeur peuvent vous aider à réduire les distractions au minimum, même lorsque votre équipe ne gère pas activement une correction.

• Établissez un point de contact interne. Désignez une personne de l'équipe en charge de la relation pour rester en contact avec le fournisseur ou pour surveiller son statut. Transférez cette responsabilité après quelques heures si l'incident persiste.
• Déterminez la manière dont les informations seront partagées. Utilisez vos canaux de communication existants avec les parties prenantes afin que votre équipe ne soit pas obligée de rechercher des informations dans des endroits inattendus.
• Si un incident impliquant un fournisseur a des répercussions sur vos clients, contactez vos équipes d'assistance pour recevoir des notifications client et vos propres mises à jour de statut.

De nombreux incidents liés aux fournisseurs sont résolus relativement rapidement. Les systèmes complexes et de grande taille comme AWS, Azure et même GitHub connaissent assez régulièrement des incidents plus petits autour de certains sous-systèmes. Il est assez facile d'attendre que ces incidents se produisent, même s'ils peuvent avoir un impact sur votre productivité. Voici quelques éléments à prendre en compte pour ces incidents :

• Décidez quand ou si votre équipe doit appeler à un gel du déploiement, et qui aura l'autorité pour prendre cette décision, y compris le soutien au niveau exécutif.
• Déterminez où se déroulera la communication interne. Assurez-vous que tout le monde sait ce qui se passe.
• Désignez un membre de l’équipe pour surveiller le statut du fournisseur et donner le feu vert.

Pour les incidents plus importants, plus répandus ou de plus longue durée, votre plan de reprise après sinistre (DR) peut être nécessaire. J'espère que vous l'avez mis en pratique récemment !

Il est peu probable que vous ayez une couverture complète pour un plan de reprise après sinistre. Il est rare de disposer d'une redondance complète de tous vos fournisseurs, du moins à court terme. La possibilité de changer de fournisseur de système de contrôle de version ou de créer et de déployer des fournisseurs, même pendant des pannes de longue durée, est difficile et coûteuse.

Les plans de reprise après sinistre pour les infrastructures et les données sont plus courants et sont ce que beaucoup de gens ont en tête lorsqu'ils gèrent leur propre disponibilité. Votre plan de reprise après sinistre peut inclure un certain nombre de fonctionnalités, mais voici quelques principes de base à garder à l'esprit :

• Sachez quand déclarer un sinistre et lancer un basculement. Établissez des seuils pour l'impact sur les clients, l'impact sur les revenus et d'autres indicateurs clés.
• Établir la responsabilité exécutive et les communications.
• Déclenchez un incident majeur, ou incident DR si vous en avez un, afin que toutes les équipes soient en alerte.
• Ayez des tests de réussite et d'assurance qualité prédéterminés prêts à être exécutés.

Votre évaluation après incident avec un fournisseur

Après un incident important avec un fournisseur, votre équipe sera en mesure de déterminer si le fournisseur a perdu votre confiance en tant que client. À ce stade, vos équipes des achats, des finances ou du service juridique doivent être impliquées pour déterminer si les accords de niveau de service ont été violés et si votre entreprise a droit à un crédit ou à un remboursement de la part du fournisseur.

Les équipes qui font appel au fournisseur doivent évaluer si l'incident a eu un impact suffisant pour déclencher un changement de fournisseur. La mise en balance du coût des incidents par rapport aux coûts de changement et aux fonctionnalités disponibles doit être effectuée une fois l'incident terminé, lorsque l'équipe peut évaluer pleinement la manière dont le fournisseur a géré l'incident 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 livre de procédures fournisseur :

• Toutes vos informations étaient-elles à jour ?
• Vos méthodes de communication avec le fournisseur et en interne avec vos équipes ont-elles été efficaces ?
• Avez-vous pu récupérer les fonctionnalités lorsque le fournisseur a déclaré que le service était restauré, ou d'autres actions étaient-elles nécessaires ?
• Y a-t-il eu autre chose qui a ralenti votre perception de l’incident ou votre rétablissement par la suite ?

Conclusion

Les incidents avec les fournisseurs sont source de stress, non seulement en raison de leur impact potentiel sur nos organisations, mais aussi souvent en raison du sentiment d'impuissance que ressentent nos intervenants lorsque les problèmes échappent à leur contrôle. Se préparer à l'avance aux problèmes avec les fournisseurs permettra de tenir vos équipes informées et de rendre la reprise plus efficace.

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