Einer der ersten Grundprinzipien des Cloud Computing war: „Sie besitzen Ihr eigenes Verfügbarkeit “, die Idee dahinter war, dass die öffentlichen Cloud-Anbieter Ihnen Infrastruktur zur Verfügung stellten und Ihr Unternehmen entscheiden musste, was und wie es verwendet werden sollte, um die Ziele Ihres Unternehmens zu erreichen. Die Cloud-Anbieter haben keine Kenntnis von Ihren Anwendungen oder deren KPIs.

In den letzten 10 Jahren sind immer mehr Unternehmen für viele Kernfunktionen ihres technischen Stacks zunehmend auf Cloud-Computing-Einrichtungen und andere SaaS-Anbieter angewiesen. Das ist großartig! Die Teams können sich auf die Kerngeschäftsfunktionen konzentrieren, die Wert schaffen und einem einzelnen Unternehmen Umsatz bringen, ohne sich um viele der eher banalen Anforderungen ihres Tech-Stacks kümmern zu müssen.

Diese Abhängigkeit bringt Risiken mit sich. Cloud-Anbieter haben Ausfälle erlebt aufgrund Konfigurationsfehler , Distributed-Density-Angriffe (DDOS) und sogar katastrophale Brände .

Wie sollte ein Team mit einem Vorfall umgehen, der bei einem vorgelagerten Anbieter liegt? Was können wir aus unseren Erfahrungen im Umgang mit unseren eigenen Vorfällen mitnehmen?

Wir werden diese Art von Vorfällen nicht allein beheben können. Viele Teams müssen abwarten, bis das Problem auftritt. Andere werden die Kosten einer Migration oder eines Failovers abwägen, und manche werden dies bereits getan haben, wenn der Rest von uns bemerkt, dass ein Problem vorliegt.

Wer ist im Falle eines Vorfalls für die Lieferantenbeziehung verantwortlich?

Die Verwaltung von Lieferantenbeziehungen obliegt häufig einem Beschaffungs-, Finanz- oder Rechtsteam. Beim Lieferantenmanagement dreht es sich vor allem um Verträge, Zahlungsbedingungen und SLAs. Bei einem Lieferantenvorfall müssen jedoch die Teams, die direkt mit den Produkten des Lieferanten zusammenarbeiten, über die Lieferantenkommunikation auf dem Laufenden gehalten werden.

Wenn bei Ihrem Cloud-Infrastrukturanbieter ein Ausfall auftritt, ist Ihr SRE-Team möglicherweise über Benachrichtigungen und Statusaktualisierungen auf dem Laufenden. Wenn Ihr Abrechnungsanbieter betroffen ist, ist es wahrscheinlich das Team, das Ihren Zahlungsabwicklungsfluss verwaltet. Entwicklertools oder Developer Experience-Teams halten möglicherweise nach Problemen mit Versionskontrollsystemen, Build- und Bereitstellungs- oder Überwachungssystemen Ausschau.

Um überprüfen zu können, ob Ihr Unternehmen von einem Lieferantenvorfall betroffen ist oder nicht, um zu wissen, wann der Vorfall vollständig behoben und der Dienst vollständig wiederhergestellt wurde, und um zu ermitteln, welche Auswirkungen der Vorfall auf Ihre Benutzer hatte, ist es wichtig, im Voraus zu wissen, welche Teams für welche Lieferantenbeziehungen verantwortlich sind.

Halten Sie diese Informationen griffbereit und stellen Sie sicher, dass sie im Rahmen Ihrer Notfallvorsorge auf dem neuesten Stand sind. In PagerDuty können Sie sogar einen Service Vertritt einen Anbieter und fügt der Servicedefinition Kontaktinformationen, Runbooks und andere Daten hinzu, um Ihre Antwort zu erleichtern, sowie eine Eskalationsrichtlinie, die das Team benachrichtigt, das mit dem Anbieter kommuniziert.

Holen Sie sich Ihre Informationen von der Quelle

Bei großen Vorfällen und großen Ausfällen sind die Ereignisse oft die wichtigsten technischen Nachrichten des Tages. Informationen werden in den Mainstream-Medien, in sozialen Medien und auf speziellen Mailinglisten veröffentlicht, die sich auf bestimmte Produkte beziehen, oder einfach Ausfälle Im Algemeinen.

Informieren Sie sich bei Ihren Hauptanbietern – also bei Diensten, die Ihre Produktivität oder Ihren Umsatz steigern –, ob sie eine Statusseite und wo es sich befindet. Die beste Vorgehensweise besteht darin, diese Statusseiten außerhalb ihrer Hauptdomänennamen zu hosten, sodass Sie sie möglicherweise nicht unter company.com/status finden. Sie verfügen möglicherweise auch über dedizierte Social-Media-Konten, die für Servicestatusaktualisierungen vorgesehen sind.

Wenn sie keine Statusseite haben, verfügen sie möglicherweise über eine E-Mail-Liste mit Kundenbenachrichtigungen, bei der Sie sich anmelden müssen.

Die Chat-Plattform Ihres Unternehmens ermöglicht Ihrem Team wahrscheinlich auch die Integration mit Ihren Lieferantenstatusseiten, sodass Teammitglieder eine weitere Möglichkeit haben, festzustellen, ob beim Lieferanten ein Vorfall vorliegt.

Darüber hinaus gibt es mittlerweile eine Reihe von Reporting-Plattformen von Drittanbietern, die zusätzliche Informationen bereitstellen:

• Downdetektor , Für alle da oder nur für mich und andere – verfolgen Ausfälle bei großen kommerziellen Websites sowie bei Mobilfunkanbietern. Diese sind äußerst benutzerfreundlich und hilfreich für Leute, die sich nicht sicher sind, ob das Problem, das sie sehen, nur bei ihnen auftritt oder weiter verbreitet ist.
• Der Internet-Wetterkarte Berichtet über Netzwerkverzögerungen weltweit. Hilfreich, wenn Ihre Kunden weltweit sind. Eher für Netzwerk-Nerds.

Ihr Vendor Runbook

Wenn bei einem Lieferanten ein Vorfall auftritt, möchten Sie als Kunde bestimmte Informationen zur Hand haben. Erstellen Sie ein Runbook für Ihre wichtigsten Lieferanten, damit Sie wissen, wen Sie wie kontaktieren müssen.

Notieren Sie die wichtigsten Informationen in Ihrem Runbook:

• Die Kontonummern oder IDs Ihrer Organisation, damit Sie bei der Kontaktaufnahme mit dem Support darauf verweisen können.
• E-Mail-Adressen oder Kontaktinformationen Ihrer Kundenbetreuer und des Supportteams des Anbieters.
• Vertragsinformationen wie Pakete und Funktionen, die Sie erworben haben, sowie ggf. Ihr Support-Level. Wenn Sie ein erweitertes Support-Paket haben, sollten Sie sich dessen bewusst sein; es kann spezielle Kontaktpunkte enthalten.
• Status Ihres Kontos und Verlängerungsdatum. Stellen Sie sicher, dass Ihr Konto nicht abgelaufen ist, bevor Sie ein Problem melden.
• Alle anbieterspezifischen Berichtsanforderungen, wie etwa Fehlercodes oder Stapeltraces, deren Erfassung hilfreich sein könnte.

Notieren Sie in Ihrem Lieferanten-Runbook auch, ob Sie wissen, wann es wichtig sein wird, den Lieferanten überhaupt zu kontaktieren. Bei großen Ausfällen, die Hunderte oder sogar Tausende von Kunden betreffen, müssen oder wollen Sie den Lieferanten möglicherweise nicht kontaktieren, sondern verlassen sich auf die öffentlichen Statusinformationen. Bei Vorfällen, bei denen es keine Anzeichen für größere Auswirkungen gibt, werden Ihre Teams Kontakt aufnehmen wollen.

Während du wartest

Öffentliche Vorfälle können für die Leute in Ihrer Organisation äußerst interessant sein. Sie sind dramatisch! Sie sind in den Nachrichten! Alle sind abgelenkt!

Aus diesen Gründen können Vorfälle in Ihrem Unternehmen eine enorme Zeitverschwendung sein. Wenn die Mitarbeiter das Gefühl haben, dass sie ihre Arbeit nicht erledigen können, weil bei einem Lieferanten ein Vorfall auftritt, braucht Ihr Team einen Kommunikationsplan, um die Leute auf dem Laufenden zu halten.

Mithilfe Ihrer Workflows für schwerwiegende Vorfälle können Sie Ablenkungen auf ein Minimum beschränken, selbst wenn Ihr Team nicht aktiv mit der Behebung eines Problems beschäftigt ist.

• Richten Sie einen internen Ansprechpartner ein. Bestimmen Sie jemanden aus dem Team, der für die Beziehung verantwortlich ist, um mit dem Lieferanten in Kontakt zu bleiben oder seinen Status zu überwachen. Geben Sie diese Verantwortung nach ein paar Stunden weiter, wenn der Vorfall weiterhin besteht.
• Legen Sie fest, wie Informationen weitergegeben werden. Nutzen Sie Ihre vorhandenen Kommunikationskanäle für Stakeholder, damit Ihr Team nicht an unerwarteten Stellen nach Informationen sucht.
• Wenn ein Vorfall bei einem Lieferanten Auswirkungen auf Ihre Kunden hat, wenden Sie sich für Kundenbenachrichtigungen und Ihre eigenen Statusaktualisierungen an Ihre Supportteams.

Viele Lieferantenvorfälle werden relativ zeitnah gelöst. Bei großen, komplexen Systemen wie AWS, Azure und sogar GitHub kommt es relativ regelmäßig zu kleineren Vorfällen mit einigen Subsystemen. Diese kann man leicht abwarten, sie können sich jedoch auf Ihre Produktivität auswirken. Einige Dinge, die bei diesen Vorfällen zu beachten sind:

• Entscheiden Sie, wann oder ob Ihr Team einen Bereitstellungsstopp ausrufen soll und wer die Autorität hat, diese Entscheidung zu treffen (einschließlich der Unterstützung durch die Führungsebene).
• Legen Sie fest, wo die interne Kommunikation stattfinden soll. Stellen Sie sicher, dass jeder weiß, was passiert.
• Beauftragen Sie ein Teammitglied, den Status des Lieferanten zu überwachen und Entwarnung zu geben.

Bei größeren, weitreichenderen oder länger andauernden Vorfällen kann Ihr Disaster Recovery-Plan (DR) erforderlich sein. Hoffentlich haben Sie ihn kürzlich geübt!

Sie werden wahrscheinlich keinen vollständigen Schutz für einen DR-Plan haben. Es ist selten, dass alle Ihre Anbieter vollständig redundant sind, zumindest kurzfristig. Die Möglichkeit, den Anbieter des Versionskontrollsystems zu wechseln oder Anbieter zu erstellen und bereitzustellen, selbst bei längeren Ausfällen, ist schwierig und teuer.

Infrastruktur- und Daten-DR-Pläne sind häufiger anzutreffen und das, was viele Leute im Sinn haben, wenn sie ihre eigene Verfügbarkeit verwalten. Ihr DR-Plan kann eine beliebige Anzahl von Funktionen enthalten, aber einige grundlegende Dinge, die Sie beachten sollten, sind:

• Wissen Sie, wann Sie einen Notfall erklären und ein Failover einleiten müssen. Legen Sie Schwellenwerte für Kundenauswirkungen, Umsatzauswirkungen und andere wichtige Kennzahlen fest.
• Legen Sie Führungsverantwortung und Kommunikation fest.
• Leiten Sie einen schwerwiegenden Vorfall oder DR-Vorfall ein, falls vorhanden, damit alle Teams in Alarmbereitschaft sind.
• Halten Sie vorbestimmte Erfolgs- und QA-Tests bereit.

Ihre Überprüfung nach einem Lieferantenvorfall

Nach einem schwerwiegenden Vorfall mit einem Lieferanten kann Ihr Team entscheiden, ob der Lieferant Ihr Vertrauen als Kunde verloren hat. An diesem Punkt sollten Ihre Mitarbeiter aus den Bereichen Beschaffung, Finanzen oder Recht einbezogen werden, um festzustellen, ob SLAs verletzt wurden und Ihr Unternehmen eine Gutschrift oder Rückerstattung vom Lieferanten zusteht.

Die Teams, die den Anbieter nutzen, sollten beurteilen, ob der Vorfall so schwerwiegend war, dass er einen Anbieterwechsel auslöste. Die Kosten des Vorfalls bzw. der Vorfälle sollten nach Abschluss des Vorfalls gegen die Wechselkosten und die verfügbaren Funktionen abgewogen werden, wenn das Team vollständig beurteilen kann, wie der Anbieter den Vorfall von Anfang bis Ende gehandhabt hat.

Bestimmen Sie wie bei jedem PIR, ob Ihre Maßnahmen wirksam waren, und nehmen Sie die erforderlichen Aktualisierungen an Ihrem Vendor-Runbook vor:

• Waren alle Ihre Angaben aktuell?
• Waren Ihre Kommunikationsmethoden mit dem Anbieter und intern mit Ihren Teams effektiv?
• Konnten Sie die Funktionalität wiederherstellen, als der Anbieter eine Wiederherstellung des Dienstes ankündigte, oder waren andere Maßnahmen erforderlich?
• Gab es sonst etwas, das Ihre Kenntnisnahme des Vorfalls bzw. Ihre anschließende Genesung verzögert hat?

Abschluss

Lieferantenvorfälle sind stressig, nicht nur wegen ihrer möglichen Auswirkungen auf unsere Organisationen, sondern oft auch wegen des Gefühls der Hilflosigkeit, das unsere Helfer verspüren, wenn die Probleme außerhalb ihrer Kontrolle liegen. Wenn Sie sich im Voraus auf Lieferantenprobleme vorbereiten, bleiben Ihre Teams auf dem Laufenden und können die Wiederherstellung effizienter gestalten.

Kasse diese umfassende Checkliste wurde entwickelt, um Ihnen dabei zu helfen, kritische Lücken in Ihrem Vorfallmanagementprozess zu identifizieren und zu beheben.