Da die Winterferien schnell näher rücken, konzentrieren sich viele Einzelhandelsunternehmen auf Hypercare, um Waren und Dienstleistungen in Spitzenzeiten zu bewegen. Aber was ist Hypercare? Hier bei PagerDuty verwenden wir die folgende Arbeitsdefinition:

Hypercare ist der Zeitraum, in dem ein erhöhtes Maß an Support verfügbar ist, um die reibungslose Einführung oder den reibungslosen Betrieb eines Systems sicherzustellen.

Das Schlüsselkonzept hierbei ist, dass Hypercare eine Phase der geplant Support – mit anderen Worten, es ist für Black Fridays und Cyber Mondays gedacht, aber nicht für DDoS-Angriffe. Es ist auch wichtig zu wissen, dass Hypercare nicht nur für den Einzelhandel gedacht ist; es betrifft beliebig Unternehmen, die eine Phase intensiver Unterstützung durchlaufen können, einschließlich wichtiger Produktveröffentlichungen, Spieleveröffentlichungen, Nachrichtenzyklen und mehr. (Um zu vermeiden, dass der Black Friday zu sehr mit Hypercare in Verbindung gebracht wird, verwende ich die branchenüblichen Begriffe „Go Live Day“ oder „Release Day“.)

Wie können Unternehmen bei einer so großen Reichweite Hypercare unterstützen? Ganz einfach: Um Hypercare zu unterstützen, müssen Sie die Teams unterstützen, die den technischen Support leisten. Dies können Sie mit Konzepten aus den Bereichen Incident Management, Observability und Chaos Engineering erreichen.

Vorfallreaktionsmanagement ist wahrscheinlich das Erste, woran die meisten Menschen denken, wenn sie an Hypercare denken. Schließlich bedeutet Hypercare erweiterten Support und beinhaltet die schnelle Reaktion auf auftretende Situationen. Um MTTAs und MTTRs zu verbessern, sollten Unternehmen jedoch möglichst viele Begriffe und Prozesse so früh wie möglich definieren.

Wenn Sie beispielsweise darlegen, was einen „Vorfall“, der einen Reaktionsprozess erfordert, von einem anderen Problem in Ihren Systemen unterscheidet, können technische Helfer die zu behandelnden Warnmeldungen priorisieren und so die Lösungszeit für größere Vorfälle verkürzen. Bei PagerDuty definieren wir einen Vorfall als „jede ungeplante Unterbrechung oder Verschlechterung des Dienstes, die die Fähigkeit der Kunden, unsere Produkte oder Dienste zu nutzen, aktiv beeinträchtigt“.

Vorfälle haben Schweregrade und Prioritäten. In Bezug auf die menschliche Reaktion erfordern sie außerdem Bereitschaftspersonal, um auf sie zu reagieren, wenn sie außerhalb der normalen Geschäftszeiten auftreten, und definierte Eskalationspfade für den Fall einer Verschlimmerung. Genau wie der Vorfall selbst müssen all diese im Voraus definiert werden, um sicherzustellen, dass Sie am Release-Tag keine wertvolle Zeit verlieren, wenn eine Situation behandelt werden muss. Unsere Leitfaden zur Reaktion auf Vorfälle kann Ihnen helfen, all diese Konzepte eingehender zu untersuchen. Darüber hinaus empfehle ich, vor dem Go-Live simulierte Vorfälle zu üben (mehr dazu später). Dies ist besonders wichtig, wenn Sie Änderungen an Ihren Prozessen oder Definitionen vornehmen, damit die Teams diese im Voraus üben und gut verstehen können.

Um die zu verwaltenden Vorfälle zu identifizieren, müssen Sie Daten an Ihre Vorfallmanagement- und Alarmierungsplattform(en) senden. Dazu benötigen Sie ein beobachtbares System. Was ist das? „Ein System ist genau dann beobachtbar, wenn man sein Verhalten anhand seiner Ausgaben bestimmen kann.“ (Von Greg Poiriers Vortrag auf der Monitorama 2016 .)

Wenn von Observability die Rede ist, bezieht man sich typischerweise auf die Telemetrie . Diese werden als die „drei Säulen“ der Observability bezeichnet: Protokollierung, Überwachung/Metriken und Tracing. Für die Unterstützung von Hypercare ist es entscheidend, über viele nutzbare Daten zu verfügen, da Ihr Team nur so erfolgreich eine Triage durchführen und Fehler beheben kann, wenn es eine Benachrichtigung von Ihrer Incident-Management-Plattform erhält.

Wenn Sie gerade erst in einem oder mehreren dieser Bereiche anfangen, geraten Sie nicht in Panik! Es gibt mehrere Anleitungen für den Einstieg. Das Wichtigste in der Anfangsphase ist nicht welche Werkzeug, aber Was Daten. Je mehr Sie über Ihre Systeme wissen, desto besser können Sie die Best Practices, die Sie finden, um beispielsweise Kubernetes zu überwachen, an Ihre spezifischen Bereitstellungen anpassen.

Einer unserer Partner, Datadog, hat eine hervorragende dreiteilige Serie über effektive Überwachung , Und dieser TechBeacon-Beitrag ist ressourcenreich und enthält Links zu Artikeln über verschiedene Anwendungen und Systeme, die überwacht und protokolliert werden können, z. B. Netzwerkprotokollierung, die Unterschiede zwischen den Säulen, die Verwendung von OWASP für sichere Protokollierung und die Auswahl eines Tracers.

Wenn Sie mit den Grundlagen der drei Säulen vertraut sind, werfen Sie einen Blick auf den Artikel von Honeycomb.io CTO Charity Major: „ Eine 3-Jahres-Retrospektive ”, in dem einige der Mängel der Beobachtbarkeit hervorgehoben werden und auch erläutert wird, was getan werden kann, um diese zu überwinden.

Und nun zum letzten Stück: Chaos-Engineering Chaos Engineering ist die Praxis des Experimentierens in der Produktion, um echte Ausfälle zu vermeiden. Dies knüpft an das an, was ich zuvor erwähnt habe: Das Üben von Vorfällen vor dem Release-Tag, um Ihr Team auf Hypercare vorzubereiten. Je geübter sie im Umgang mit möglichen und zukünftigen Situationen sind, desto geschickter werden sie ungeplante Vorfälle bewältigen.

Wenn Sie noch keine Erfahrung mit Chaos-Experimenten haben, sollten Sie diese unbedingt zunächst außerhalb der Produktion durchführen. Dies bietet nicht nur den Menschen die Möglichkeit, den Incident-Management-Prozess zu üben, sondern auch eine hervorragende Gelegenheit, zu überprüfen, ob Ihre Tools wie vorgesehen funktionieren, indem sie die richtigen Informationen im richtigen Umfang bereitstellen. Weitere Informationen finden Sie unter dieser Gremlin-Beitrag darüber, wie Sie Ihr erstes Chaos-Experiment durchführen.

Wenn Sie mit Chaos-Experimenten besser vertraut sind, können Sie Ihre Experimente aus der Nicht-Produktionsumgebung Ihrer Wahl in die Produktion verlagern. Anschließend sollten Sie in der Lage sein, Hypothesen aufzustellen, diese zu testen und die daraus resultierenden Probleme zu beheben. Wählen Sie außerdem Anwendungen und Dienste aus, die relativ kritisch bis extrem kritisch sind, da Sie diese beim Go-Live am besten verstehen müssen.

Nutzen Sie außerdem die von Ihnen entwickelte Stakeholder-Kommunikation, um sicherzustellen, dass die relevanten Parteien über die laufenden Experimente in der Produktion informiert sind, damit niemand unvorbereitet ist. (Dies dient auch dazu, Panik zu vermeiden, wenn viele Warnmeldungen auftreten.) Sie sollten nicht Stummschalten von Warnungen, da diese Teil des Tests sind und Ihnen helfen zu erkennen, ob sie 1) umsetzbar sind, 2) korrekt weitergeleitet werden und 3) die richtigen Informationen enthalten. Im Zweifelsfall können Sie sich an den Erfahrungen anderer orientieren. Wir haben ein Paar Blogbeiträge mit Einzelheiten zu unserem Failure Friday S Modell. Sie können auch sehen, wie New Relic seine Chaos-Experimente auf die Sicherheit angewendet hat, Hier .

Das alles erscheint Ihnen wahrscheinlich viel, und das ist es auch. Die wichtigste Erkenntnis ist jedoch, dass das Ziel von Hypercare darin besteht, Überraschungen zu vermeiden. Jedes der besprochenen Themen umfasst technische Praktiken, die darauf abzielen, Überraschungen und deren Auswirkungen zu reduzieren. Während Sie sich auf Ihr Hypercare-Szenario vorbereiten, sollten Sie unsere griffbereit halten. Checkliste zur Hypercare-Bereitschaft zur Verfügung, um Ihren Fortschritt zu verfolgen. Wenn Sie Fragen haben, schauen Sie bitte bei uns vorbei Community-Foren – wir helfen Ihnen gerne!