Da die Winterferien schnell näher rücken, richten viele Einzelhandelsunternehmen ihren Fokus auf Hypercare, um sich darauf vorzubereiten, Waren und Dienstleistungen auf höchstem Niveau zu verkaufen. 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.

Der Schlüsselbegriff hierbei ist, dass Hypercare eine Phase ist, 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 verstärkten Supports durchlaufen können, einschließlich wichtiger Produktveröffentlichungen, Spieleveröffentlichungen, Nachrichtenzyklen und mehr. (Um zu vermeiden, dass Hypercare zu sehr mit dem Black Friday verknüpft 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 bereitstellen. Und das können Sie mit Konzepten aus den Bereichen Vorfallmanagement, Observability und Chaos Engineering tun.

Vorfallreaktionsmanagement ist wahrscheinlich das Erste, woran die meisten Leute denken, wenn sie anfangen, über Hypercare nachzudenken. Schließlich ist Hypercare eine erweiterte Unterstützung und ein Teil davon ist, schnell auf auftretende Situationen zu reagieren. Um MTTAs und MTTRs zu verbessern, sollten Organisationen jedoch so viele Begriffe und Prozesse wie möglich so weit im Voraus definieren.

Wenn Sie beispielsweise darlegen, was einen „Vorfall“, der einen Reaktionsprozess erfordert, von jedem anderen Problem in Ihren Systemen unterscheidet, können technische Helfer priorisieren, auf welche Warnmeldungen sie reagieren müssen, und so die Lösungszeit für größere Vorfälle verkürzen. Bei PagerDuty definieren wir einen Vorfall als „jede ungeplante Störung 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. Was die menschliche Reaktion betrifft, erfordern sie auch, dass Leute auf Abruf bereitstehen, um auf sie zu reagieren, wenn sie außerhalb der normalen Geschäftszeiten auftreten, und dass definierte Eskalationspfade für den Fall einer Verschlimmerung erforderlich sind. 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 vorliegt, die behandelt werden muss. Unsere Leitfaden zur Reaktion auf Vorfälle kann Ihnen dabei helfen, all diese Konzepte eingehender zu untersuchen. Darüber hinaus empfehle ich, vor dem Going Live simulierte Vorfälle zu üben (mehr dazu später). Dies ist insbesondere 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 finden, müssen Sie Daten an Ihre Vorfallmanagement- und Warnplattform(en) senden. Dazu benötigen Sie ein beobachtbares System. Was ist das? „Ein System ist genau dann beobachtbar, wenn Sie das Verhalten des Systems anhand seiner Ausgaben bestimmen können.“ (Aus Greg Poiriers Vortrag bei Monitorama 2016 .)

Wenn von Observability die Rede ist, dann ist damit in der Regel die Telemetrie . Diese werden als die „drei Säulen“ der Observability bezeichnet: Protokollierung, Überwachung/Metriken und Nachverfolgung. Für die Unterstützung von Hypercare ist es entscheidend, viele nutzbare Daten zu haben, denn nur so kann Ihr Team erfolgreich eine Triage durchführen und Fehler beheben, wenn es eine Benachrichtigung von Ihrer Vorfallmanagementplattform erhält.

Wenn Sie gerade erst in einem oder mehreren dieser Bereiche anfangen, geraten Sie nicht in Panik! Es gibt mehrere „Erste Schritte“-Anleitungen. 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 reich an Ressourcen 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 zur sicheren Protokollierung und die Auswahl eines Tracers.

Wenn Sie mit den wesentlichen Aspekten der drei Säulen vertraut sind, lesen Sie den Artikel von Honeycomb.io CTO Charity Major: „ Eine 3-Jahres-Retrospektive ”, in dem einige der Mängel der Beobachtbarkeit hervorgehoben werden, sowie Hinweise, wie diese behoben werden können.

Und nun zum letzten Teil: 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 über das Üben von Vorfällen vor dem Release-Tag erwähnt habe, um Ihrem Team bei der Vorbereitung auf Hypercare zu helfen. Je geübter sie im Umgang mit Situationen sind, die auftreten können und werden, desto geschickter werden sie mit ungeplanten Vorfällen umgehen.

Wenn Sie neu bei Chaos-Experimenten sind, führen Sie die Experimente auf jeden Fall zuerst außerhalb der Produktion durch. Dies gibt Menschen nicht nur die Möglichkeit, den Vorfallmanagementprozess zu üben, sondern ist auch eine großartige Gelegenheit, zu überprüfen, ob sich Ihre Tools wie vorgesehen verhalten, indem sie die richtigen Informationen im richtigen Umfang bereitstellen. Weitere Anleitungen finden Sie unter dieser Gremlin-Beitrag darüber, wie Sie Ihr erstes Chaosexperiment durchführen.

Wenn Sie mit Chaosexperimenten besser vertraut sind, können Sie Ihre Experimente aus der Nicht-Produktionsumgebung Ihrer Wahl in die Produktion verschieben. Bis Sie dies getan haben, sollten Sie in der Lage sein, Hypothesen aufzustellen, sie zu testen und die daraus resultierenden Störungen zu beheben. Sie sollten auch Anwendungen und Dienste auswählen, die ziemlich bis extrem kritisch sind, da diese diejenigen sind, die Sie bei der Inbetriebnahme am besten verstehen müssen.

Nutzen Sie außerdem die von Ihnen entwickelte Stakeholder-Kommunikation, um sicherzustellen, dass die relevanten Parteien wissen, dass Experimente in der Produktion laufen, damit niemand überrascht wird. (Dies dient teilweise auch dazu, zu verhindern, dass jemand in Panik gerät, wenn er eine Flut von Warnungen sieht.) Sie sollten nicht Stummschalten von Warnungen, da diese Teil des Tests sind und Ihnen dabei helfen, zu erkennen, ob sie 1) umsetzbar sind, 2) richtig weitergeleitet werden und 3) die richtigen Informationen enthalten. Wenn Sie Zweifel haben, lassen Sie sich von den Erfahrungen anderer leiten. Wir haben ein paar Blogbeiträge mit ausführlichen Details zu unserem Failure Friday S Modell. Sie können auch sehen, wie New Relic ihre Chaos-Experimente auf Sicherheit angewendet hat, Hier .

All das kommt Ihnen wahrscheinlich sehr viel vor, und das ist es auch, aber die wichtigste Erkenntnis ist, dass das Ziel von Hypercare darin besteht, Überraschungen zu vermeiden. Bei jedem der besprochenen Themen handelt es sich um technische Praktiken, die darauf abzielen, Überraschungen und ihre Auswirkungen zu reduzieren. Während Sie sich auf Ihr Hypercare-Szenario vorbereiten, sollten Sie unsere griffbereiten Checkliste zur Hypercare-Bereitschaft zur Verfügung, um Ihren Fortschritt zu verfolgen. Wenn Sie Fragen haben, besuchen Sie bitte unsere Community-Foren —wir helfen gerne!