Dies ist der erste Teil einer mehrteiligen Blogserie. Im nächsten Blog stellen wir einen Vorlagenjob vor, der Vergängliche Kubernetes-Container um Beweise von Anwendungen zu erfassen, die in Kubernetes ausgeführt werden.

Jeder liebt einen guten Mystery-Thriller. Ok, nicht jeder – aber Hollywood tut es auf jeden Fall. Ob Sherlock Holmes oder Hercule Poirot, das Publikum genießt eindeutig eine spannende Handlung, in der es darum geht, den Täter eines abscheulichen Verbrechens zu jagen. Viele Leute, mich eingeschlossen, bevorzugen den Mystery-Thriller, bei dem das Rätsel am Ende der Geschichte „gelöst“ ist. Während Cliffhanger Ihre Fantasie anregen können, um über die möglichen Ausgänge nachzudenken (erinnern Sie sich an das Ende von Chris Nolans Inception?), bevorzuge ich bei Detektivgeschichten zugegebenermaßen die Antwort auf die Frage „Wer war’s?“.

Quelle: https://www.dazeddigital.com/artsandculture/article/24949/1/christopher-nolan-explains-the-spinning-top-in-inception

Damit ein Krimi zu einem vollständigen Abschluss kommt, müssen die Beweise für das Verbrechen idealerweise kristallklar und detailliert dargelegt sein, sodass der wahre Täter entdeckt und hoffentlich vor Gericht gestellt werden kann.

In der Welt des technischen Betriebs und der Aufrechterhaltung der Verfügbarkeit kritischer Dienste entsteht ein klarer Konflikt, der dem Hollywood-Krimi ähnelt. Wenn kritische Anwendungen unter Leistungseinbußen leiden – oder schlimmer noch, wenn es zu einem vollständigen Ausfall kommt –, beeilen sich die Ingenieure, die (scheinbare) Ursache des Vorfalls zu finden, damit sie das Problem so schnell wie möglich beheben können. Die Teams verwenden die ihnen zur Verfügung stehenden Tools, um die überlastete Rechenressource, die hängende Abfrage oder die überfüllte Warteschlange aufzuspüren und zu isolieren und schnell Maßnahmen zu ergreifen, um das Problem zu beheben.

Wie sich jedoch herausstellt, ist dies nur der Anfang des Krimis. Dies ist die Art von Krimi, bei dem die Zeugen den Täter als die Person wahrnehmen, die zufällig zur falschen Zeit am falschen Ort war. Doch je mehr Beweise aufgedeckt werden, desto klarer wird, dass der „wahre Täter“ ein böser Drahtzieher war, der aus der Ferne einen größeren Plan ausheckte. Unglücklicherweise für unsere „Detektiv“-Ingenieure besteht bei der Beseitigung der (scheinbaren) Grundursache eine hohe Wahrscheinlichkeit, dass sie [un]wissentlich Beweise eliminiert haben, die auf den eigentlichen Täter hinweisen: Durch den Neustart eines Dienstes oder die Neubereitstellung eines Pods werden wertvolle forensische Beweise eliminiert.

Man kann sich vorstellen, wie sich der Chefinspektor die Haare rauft, wenn er erkennt, dass der Regen zum ungünstigsten Zeitpunkt die Fingerabdrücke weggespült hat, die ihm die stärkste Spur geliefert hätten.

Quelle: https://www.defendyourcase.com/criminal-defense-blog/2020/february/are-fingerprints-at-the-crime-scene-enough-evide/

Heutzutage kämpfen Entwickler und Betriebsingenieure mit demselben Seiltanz: Sie wollen die Dienste so schnell wie möglich wiederherstellen, ohne dabei wichtige Beweise zu verlieren, die ihnen bei der Ermittlung der Grundursache ihrer Vorfälle auf Codeebene helfen würden.

Aber Moment mal – sind Überwachungstools nicht genau dafür da? Die Antwort lautet: manchmal. Je nach Problem können Konfigurations- oder Codefehler mithilfe ausgefeilter Beobachtungstools aufgespürt werden. Entwickler benötigen jedoch häufig noch detailliertere Daten, die von Überwachungstools nicht erfasst werden – einfach, weil diese Daten auf Debugebene nicht für Warnmeldungen oder die Wiederherstellung von Diensten benötigt werden. Daten wie Heap-, Thread- und TCP-Dumps, Datenbankabfragen mit dem höchsten Ressourcenverbrauch und Stacktraces werden verwendet, um den „wahren Schuldigen“ zu identifizieren, werden jedoch meistens nicht benötigt, um den Dienst wiederherzustellen. Das Sammeln dieser Daten nimmt Zeit in Anspruch und wir alle wissen, dass bei einem Vorfall die Wiederherstellung der Dienstverfügbarkeit Vorrang vor allem anderen hat.

Leider hat die Einführung und Verbreitung von containerisierten Anwendungen und Container-Orchestrierung dieses Tauziehen aus zwei Hauptgründen nur noch verschärft:

1. Microservice-Architekturen bieten schnellere Methoden zur sicheren Wiederherstellung der Verfügbarkeit, etwa die erneute Bereitstellung eines Pods.
2. In diesen Umgebungen stehen weniger Debugging-Dienstprogramme zur Verfügung, da Entwickler und Betriebsingenieure die Oberfläche ihrer Container-Images minimieren möchten.

Um den gegensätzlichen Kräften in diesem Tauziehen entgegenzutreten, ist eine Lösung erforderlich, die in „Sofortreaktion“ greift, sodass Beweise erfasst und aufbewahrt werden können – und gleichzeitig der Dienst danach sofort wiederhergestellt werden kann:

Eine solche Lösung wird mit der Operations Cloud von PagerDuty bereitgestellt. Durch die Nutzung von Runbooks, die sofort ausgelöst werden, wenn ein Problem erkannt wird, können Beweise auf Debug-Ebene erfasst und an einen dauerhaften Speicherdienst – wie S3 – gesendet werden, und Dienste können mithilfe bekannter Fixes wiederhergestellt werden. Mit einer großen Bibliothek vorgefertigter Integrationen für sowohl lokale als auch Cloud-Umgebungen und einer wachsenden Liste von Runbook-Vorlagen können PagerDuty -Benutzer dieses scheinbar kühne Ziel erreichen, sowohl die MTTR als auch den Zeitaufwand für die Replizierung von Fehlern zur Lösung von technischen Schuldentickets zu verkürzen. Bestehende PagerDuty -Kunden können eine Testversion von Runbook Automation anfordern Hier , während neue Benutzer mit PagerDuty Incident Response beginnen können Hier .

Schauen Sie sich außerdem unbedingt unsere Lösungshandbuch zur automatisierten Diagnose um einige dieser Beispiel-Runbooks anzuzeigen.

Dies ist der erste Teil einer mehrteiligen Blogserie. Im nächsten Blog stellen wir einen Vorlagenjob vor, der Vergängliche Kubernetes-Container um Beweise von Anwendungen zu erfassen, die in Kubernetes ausgeführt werden.

Bleiben Sie neugierig, liebe Detektivkollegen.