Einer der ersten Grundprinzipien des Cloud Computing war: „Sie besitzen Ihre eigene Verfügbarkeit Die Idee dahinter war, dass die öffentlichen Cloud-Anbieter Ihnen die Infrastruktur zur Verfügung stellten und Ihr Unternehmen entscheiden musste, was und wie es diese nutzte, um seine Unternehmensziele zu erreichen. Die Cloud-Anbieter haben keine Kenntnis von Ihren Anwendungen oder deren KPIs.

In den letzten zehn Jahren sind immer mehr Unternehmen für viele Kernfunktionen ihres technischen Stacks auf Cloud-Computing und andere SaaS-Anbieter angewiesen. Das ist großartig! Teams können sich auf die Kernfunktionen konzentrieren, die Mehrwert schaffen und dem 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 , verteilte Deno-of-Service-Angriffe (DDOS) und sogar katastrophale Brände .

Wie sollte ein Team mit einem Vorfall umgehen, der bei einem Upstream-Anbieter liegt? Welche Erfahrungen können wir aus der Bewältigung eigener Vorfälle mitnehmen?

Wir werden solche Vorfälle nicht allein beheben können. Viele Teams müssen abwarten, bis das Problem auftritt. Andere wägen die Kosten einer Migration oder eines Failovers ab, und manche haben dies bereits getan, wenn wir anderen das Problem bemerken.

Wer ist während eines Vorfalls für die Lieferantenbeziehung verantwortlich?

Die Verwaltung von Lieferantenbeziehungen obliegt häufig den Beschaffungs-, Finanz- oder Rechtsabteilungen. Im Lieferantenmanagement dreht es sich vor allem um Verträge, Zahlungsbedingungen und SLAs. Bei einem Lieferantenvorfall müssen die Teams, die direkt mit den Produkten des Lieferanten arbeiten, über die Lieferantenkommunikation informiert sein.

Wenn Ihr Cloud-Infrastrukturanbieter einen Ausfall hat, ist Ihr SRE-Team möglicherweise über Benachrichtigungen und Statusaktualisierungen informiert. Wenn Ihr Abrechnungsanbieter beteiligt ist, ist dies wahrscheinlich das Team, das Ihren Zahlungsabwicklungsfluss verwaltet. Entwicklertools oder Developer Experience-Teams halten möglicherweise Ausschau nach Problemen mit Versionskontrollsystemen, Build- und Bereitstellungs- oder Überwachungssystemen.

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 festzustellen, 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 aktuell sind. In PagerDuty können Sie sogar eine 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 Ausfällen sind die Ereignisse oft die wichtigsten technischen Nachrichten des Tages. Informationen finden sich in den Mainstream-Medien, in sozialen Medien und auf speziellen Mailinglisten, die sich auf bestimmte Produkte beziehen, oder einfach Ausfälle im Allgemeinen.

Informieren Sie sich bei Ihren Hauptanbietern – also bei Diensten, die Ihre Produktivität oder Ihren Umsatz steigern –, ob sie eine Statusseite und wo sie gespeichert sind. Best Practices empfehlen, diese Statusseiten außerhalb der Hauptdomäne zu hosten, sodass Sie sie möglicherweise nicht unter company.com/status finden. Möglicherweise verfügen sie auch über dedizierte Social-Media-Konten für Servicestatus-Updates.

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

Die Chat-Plattform Ihres Unternehmens ermöglicht Ihrem Team wahrscheinlich auch die Integration mit den Statusseiten Ihres Lieferanten, wodurch Ihren Teammitgliedern eine weitere Möglichkeit geboten wird, 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 , Unten für alle 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 nur bei ihnen auftritt oder weiter verbreitet ist.
• Der Internet-Wetterkarte Berichtet über Netzwerkverzögerungen weltweit. Hilfreich, wenn Ihre Kunden weltweit verteilt sind. Eher für Netzwerk-Nerds.

Ihr Vendor Runbook

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

Notieren Sie wichtige 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 Account-Manager und des Support-Teams des Anbieters.
• Vertragsinformationen wie die von Ihnen erworbenen Pakete und Funktionen sowie gegebenenfalls Ihr Support-Level. Wenn Sie ein erweitertes Support-Paket haben, sollten Sie dies beachten; 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 Fehlercodes oder Stapelverfolgungen, deren Erfassung hilfreich sein könnte.

Notieren Sie in Ihrem Lieferanten-Runbook, wann Sie überhaupt Kontakt mit dem Lieferanten aufnehmen müssen. Bei größeren Ausfällen, die Hunderte oder sogar Tausende von Kunden betreffen, ist eine Kontaktaufnahme mit dem Lieferanten möglicherweise nicht erforderlich oder wünschenswert. Stattdessen verlassen Sie sich auf die öffentlichen Statusinformationen. Bei Vorfällen ohne Anzeichen größerer Auswirkungen sollten Ihre Teams Kontakt aufnehmen.

Während Sie warten

Öffentliche Vorfälle können für die Mitarbeiter 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 Mitarbeiter das Gefühl haben, dass sie ihre Arbeit nicht erledigen können, weil ein Vorfall bei einem Lieferanten auftritt, benötigt Ihr Team einen Kommunikationsplan, um die Mitarbeiter auf dem Laufenden zu halten.

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

• Legen Sie einen internen Ansprechpartner fest. Bestimmen Sie eine Person aus dem für die Beziehung zuständigen Team, die mit dem Lieferanten in Kontakt bleibt oder dessen Status überwacht. Geben Sie diese Verantwortung nach einigen Stunden weiter, wenn der Vorfall weiterhin besteht.
• Legen Sie fest, wie Informationen weitergegeben werden. Nutzen Sie Ihre bestehenden Kommunikationskanäle für Stakeholder, damit Ihr Team nicht an unerwarteten Stellen nach Informationen suchen muss.
• Wenn ein Vorfall bei einem Lieferanten Auswirkungen auf Ihre Kunden hat, wenden Sie sich an Ihre Supportteams, um Kundenbenachrichtigungen und Ihre eigenen Statusaktualisierungen zu erhalten.

Viele Lieferantenvorfälle werden relativ zeitnah behoben. Große, komplexe Systeme wie AWS, Azure und sogar GitHub weisen relativ regelmäßig kleinere Vorfälle mit einigen Subsystemen auf. Diese lassen sich zwar problemlos abwarten, können aber Ihre Produktivität beeinträchtigen. Folgendes sollten Sie bei diesen Vorfällen beachten:

• Entscheiden Sie, wann oder ob Ihr Team einen Bereitstellungsstopp ausrufen soll und wer die Befugnis hat, diese Entscheidung zu treffen, einschließlich der Unterstützung auf 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!

Ein DR-Plan deckt wahrscheinlich nicht die gesamte Bandbreite ab. Die vollständige Redundanz aller Anbieter ist selten, zumindest kurzfristig. Der Wechsel des Versionskontrollsystem-Anbieters oder die Erstellung und Bereitstellung von Anbietern ist selbst bei längeren Ausfällen schwierig und teuer.

Infrastruktur- und Daten-DR-Pläne sind gängiger und werden von vielen Nutzern im Auge behalten, wenn sie ihre eigene Verfügbarkeit gewährleisten möchten. Ihr DR-Plan kann zahlreiche Funktionen umfassen, aber einige grundlegende Punkte sollten Sie beachten:

• Wissen Sie, wann Sie einen Notfall melden und ein Failover einleiten müssen. Legen Sie Schwellenwerte für die Auswirkungen auf Kunden, Umsatz und andere wichtige Kennzahlen fest.
• Schaffen Sie Führungsverantwortung und Kommunikation.
• Leiten Sie einen schwerwiegenden Vorfall oder einen DR-Vorfall ein, falls Sie einen haben, damit alle Teams in Alarmbereitschaft sind.
• Halten Sie vorab festgelegte 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. Zu diesem Zeitpunkt sollten Ihre Mitarbeiter aus Einkauf, 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 prüfen, ob der Vorfall schwerwiegend genug war, um einen Anbieterwechsel auszulösen. Die Abwägung der Kosten des Vorfalls bzw. der Vorfälle gegen die Wechselkosten und die verfügbaren Funktionen sollte nach Abschluss des Vorfalls erfolgen, wenn das Team die gesamte Vorgehensweise des Anbieters im Detail beurteilen kann.

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

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

Abschluss

Lieferantenvorfälle sind belastend, nicht nur wegen ihrer potenziellen Auswirkungen auf unser Unternehmen, sondern oft auch wegen des Gefühls der Hilflosigkeit, das unsere Helfer empfinden, wenn die Probleme außerhalb ihrer Kontrolle liegen. Durch frühzeitige Vorbereitung auf Lieferantenprobleme bleiben Ihre Teams auf dem Laufenden und die Wiederherstellung wird effizienter.

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