Operatives Bewusstsein
Damit wir mit der Überwachung der Zuverlässigkeit beginnen können, müssen wir vorher noch einen Schritt vollziehen. Zunächst müssen wir sicherstellen, dass wir über ein angemessenes Maß an operativem Bewusstsein verfügen.
Am einfachsten lässt sich dies so ausdrücken: Um die Zuverlässigkeit von Systemen in der Produktion zu verbessern, müssen wir zunächst ein gutes Verständnis dieser Systeme und ihrer Funktionsweise in der Produktion haben.
Sammeln von Informationen über die vorhandene Konfiguration
Auch wenn es seltsam klingen mag, lautet in vielen Umgebungen die erste Frage, die beantwortet werden muss: „Was genau wird in der Produktion ausgeführt?“. Unsere Produktionsumgebungen und die Verfahren zur Bereitstellung in diesen Umgebungen sind heutzutage so komplex, dass es nicht unüblich ist, dass man zunächst ein wenig nachforschen muss. Wie lauten die Komponententeile in einer bestimmten Anwendung? Welche Teile kommunizieren mit anderen Teilen? Was sind die offensichtlichen (und weniger offensichtlichen) Abhängigkeiten bei dieser Anwendung?
Sammeln von Informationen zur normalen und früheren Leistung
Sobald wir diese Informationen haben, können wir versuchen, eine Baseline für die Leistung und das „normale“ Verhalten des Systems zu bestimmen. Es gibt viele Gründe, aus denen wir diese Informationen benötigen können. Nicht zuletzt lautet eine davon, dass sie uns beim Lösen von Problemen mit der Anwendung helfen. Inmitten eines Ausfalls ist ein schlechter Zeitpunkt, um herauszufinden, ob der Betrieb der Datenbankserver mit einer CPU-Auslastung von 80 % gut oder schlecht ist.
Im Rahmen der Schaffung dieser Baseline sollten wir uns mit der Betrachtung der bisherigen Leistung befassen. Obwohl die Aussage, dass die frühere Leistung keine Garantie für künftige Ergebnisse ist, stimmt, kann dies manchmal hilfreich sein, um unsere Erwartungen zu kalibrieren. Wenn wir Zugriff auf Informationen zu früheren Ausfällen oder Problemen mit einem Dienst haben, können wir uns außerdem zumindest einen Eindruck von möglichen Fehlermodi verschaffen, die wir in unser Denken rund um die Zuverlässigkeit integrieren müssen.
Sammeln von Kontextinformationen
Und schließlich ist es hilfreich, kontextbezogene Kenntnisse zu einem System zu erhalten. Der Kontext kann sehr vielseitig sein, wobei ein Großteil davon soziotechnischer Natur ist. Beispielsweise möchten wir aus der Sozio-Perspektive gute Informationen zu den Projektbeteiligten sammeln, die einem Dienst oder einer Anwendung zugeordnet sind.
Sie denken vielleicht, dass es offensichtlich ist, wer sich um eine bestimmte App / einen bestimmten Dienst kümmert, aber in Unternehmenssituationen oder anderen komplexen Organisationen kann dies viel schwieriger zu bestimmen sein, als es klingt.
Die traurige Wahrheit ist, dass wir bei der Zuverlässigkeit eines Systems nicht weiterkommen werden, wenn wir nicht genau wissen, wer die Beteiligten sind (aus Gründen, die später bei der Diskussion über SLIs und SLOs deutlich werden).
Auf der technischen Seite der Kontextfrage ist es wirklich hilfreich für uns, auf technische Fragen zu achten, z. B. auf die Frage: „Wie kam die Anwendung in die Produktionsumgebung?“. Wurde sie während einer "epischen" Bereitstellung manuell bereitgestellt, oder wurde sie über eine automatisierte CI/CD-Pipeline mit einer Vielzahl von Komponententests bereitgestellt?
Diese Information kann vieles beeinflussen, unter anderem, wie einfach es sein wird, die Iterationen zu durchlaufen, die nötig sind, wenn die Zuverlässigkeit optimiert werden soll. Es ist möglicherweise auch ein nützlicher Indikator für die Arbeit, die wir durchführen könnten, um wirklich etwas zu bewirken.
Azure-Tools für operatives Bewusstsein
Das Erlangen eines operativen Bewusstseins ist oft nicht einfach, aber sehen wir uns einige der von Azure bereitgestellten Tools an, die uns bei dem Prozess unterstützen können. Dies wird eine sehr oberflächliche Betrachtung sein: Am Ende dieses Moduls beziehen wir Verweise auf andere Microsoft-Lernmodule und Dokumentationen ein für den Fall, dass Sie Punkte detaillierter durchdringen möchten.
Application Insights
Die ersten Tools, die wir betrachten werden, können uns bei der Frage „Was wird tatsächlich ausgeführt?“ helfen. Für operative Mitarbeiter ist es nicht ungewöhnlich, mit einer Anwendung zu arbeiten, die bereits in der Produktion ausgeführt wird. Im Idealfall wären wir Teil des gesamten Lebenszyklus der Software, beginnend bei der Entwurfsphase. Dies ist jedoch nicht immer (oder möglicherweise nicht häufig) der Fall. Wenn dies so ist, vor allem bei komplexeren mehrstufigen oder auf Microservices basierenden Anwendungen, kann es sehr mühsam sein, zu verstehen, was all die beweglichen Teile tun.
Ein Tool, mit dem dieser Aufwand reduziert werden und das Informationen über das Verhalten der Anwendung in der Produktion liefern kann, ist Application Insights. Mit minimalem Aufwand können Entwickler ihre Anwendung so instrumentieren, dass sie automatisch Telemetriedaten an die in Azure ausgeführten Collectors sendet. Mit diesen Informationen kann Application Insights eine visuelle Karte der Komponenten der Anwendung und der Kommunikation zwischen diesen Komponenten erstellen.
Ein Beispiel:
In der vorstehenden Abbildung sehen Sie nicht nur die Komponenten der Anwendung, sondern auch die Kommunikation zwischen diesen Komponenten. Wenn wir eine der Verbindungen zwischen Komponenten vergrößern, sehen wir die Anzahl Aufrufe zwischen den Komponenten und die durchschnittliche Wartezeit (Latenz) für diese Aufrufe. Sie können auch eine Darstellung der Anzahl erfolgreicher und fehlgeschlagener Aufrufe einsehen. Wenn Sie auf eines dieser Kartenelemente klicken, können Sie in Application Insights einen Drilldown-Vorgang zu den Informationen ausführen, um detaillierte Statistiken zur Leistung und zu Erfolgs-/Fehlermetriken für diese Aufrufe anzuzeigen. Dies kann eine gute Methode sein, um als Baseline das große Ganze der Anwendungskomponenten und deren Funktion zu verstehen. Zur Erinnerung; Machen Sie sich unbedingt mit ihrer Anwendungsübersicht und allem vertraut, was Application Insights bieten kann – und zwar, bevor es zu einem Ausfall kommt.
Azure Resource Graph
Application Insights ist hervorragend geeignet, um ein gewisses operatives Bewusstsein für eine Anwendung zu erhalten. Was ist jedoch, wenn Sie sie genauer betrachten und alle Ressourcen anzeigen möchten, die in Azure in einem Abonnement für Sie verfügbar sind? In der Vergangenheit mussten Sie Berichte herunterladen oder PowerShell-Skripte schreiben, um diese Informationen zu sammeln, aber jetzt gibt es einen viel einfacheren Weg.
Azure Resource Graph-Explorer bietet direkt im Azure-Portal eine interaktive Abfrageumgebung für die von Ihnen benötigten Daten. Sie können beliebige Abfragen ausführen, die basierend auf den aktuell verwendeten Ressourcen Antworten in Echtzeit zurückgeben. Wenn beispielsweise alle virtuellen Computer angezeigt werden sollen, die momentan ausgeführt werden, können wir die folgende Abfrage ausführen:
Daraufhin erhalten Sie eine vollständige, detaillierte Liste der VMs, die in unserem Abonnement verwendet werden:
Die in dieser Umgebung verwendete Abfragesprache ist Kusto Query Language (KQL). Wir werden sie später in diesem Modul ausführlicher erörtern, wenn wir auf Azure Monitor Log Analytics eingehen.
Dashboards
Das gängigste operative Tool für das operative Bewusstsein ist das ehrwürdige Dashboard. Wenn wir an Menschen denken, die operativ tätig sind, stellen wir uns oft vor, dass sie sich vor großen Monitoren befinden und intensiv Dashboards voll mit Diagrammen, Tabellen und Zählern überwachen. In diesem Modul wird nicht erläutert, wie Sie Dashboards erstellen, bearbeiten und verwenden. Dies geschieht größtenteils durch das Anheften von Inhalten aus anderen Stellen im Portal und das anschließende Verschieben nach Bedarf.
Sehen Sie sich stattdessen zwei Dashboardfeatures an, die weniger häufig verwendet werden und für Sie wirklich von Vorteil sein könnten. Diese Features finden Sie oben in jedem Dashboard.
Mit den beiden markierten Pfeilen können Sie JSON-Darstellungen von Dashboards hochladen und exportieren.
Beginnen Sie zunächst mit der Exportfunktion. Wenn Sie Exportieren und dann Herunterladen auswählen, wird eine JSON-Datei, die das aktuelle Dashboard darstellt, auf Ihren Computer heruntergeladen. Wenn Sie möchten, können Sie dies jetzt ausprobieren. Melden Sie sich dazu beim Portal an, wählen Sie im Produkt-Menü Dashboard aus, und wählen Sie dann Exportieren>Herunterladen.
Es gibt mindestens zwei Vorgänge, die wir mit dieser Datei ausführen können und die Sie möglicherweise nützlich finden:
Wir könnten diese Datei in das Quellcodeverwaltungssystem einchecken. Dies ermöglicht es uns, unsere verschiedenen Versionen von Dashboards nachzuverfolgen und anderen Benutzern Zugriff darauf zu gewähren, wenn sie unser Dashboard verwenden möchten. Mitunter wird dies als „Dashboards als Code“ bezeichnet.
Diese Datei kann als Grundlage für ein neues Dashboard dienen. Im Folgenden finden Sie ein konkretes Beispiel, auf das wir später in diesem Lernpfad erneut eingehen: Angenommen, Sie müssen einem Kollegen zeigen, wie ein bestimmtes Dashboard während eines Ausfalls, der in der letzten Woche aufgetreten ist, eine Stunde lang ausgesehen hat. Sie könnten Ihr Dashboard veröffentlichen und ihn bitten, die genaue Zeit und Zeitspanne auszuwählen. Noch viel einfacher und weniger fehleranfällig wäre jedoch das Herunterladen unserer Dashboard-Einrichtung, und zwar genau dann, wenn Sie diese JSON-Datei benötigen und freigeben. Wenn Sie einen zweiten Zeitraum aus demselben Dashboard hervorheben möchten, etwa eine Stunde in der Zukunft, kann die JSON-Datei auf einfache Art bearbeitet werden.
Dies ist die Exportfunktion. Nun konzentrieren Sie sich auf die Verwendungsmöglichkeiten für die Uploadfunktion. Neben dem Laden der versionsgesteuerten oder bearbeiteten Dateien aus dem letzten Abschnitt können Sie die Upload-Funktionalität verwenden, um die sorgfältige Arbeit anderer Personen beim Erstellen von Dashboards zu nutzen.
Sehen wir uns das abschließende Beispiel für diesen Abschnitt an, in dem zwei der Ideen dieser Einheit miteinander kombiniert werden. Wenn Sie die JSON-Datei
auf Ihren Computer herunterladen und dann auf ein Dashboard hochladen, sieht die Anzeige ähnlich wie die folgende aus:
Sie verfügen jetzt über ein Live-Dashboard mit einem recht umfangreichen Bestand an Ihren in einem Abonnement verwendeten Ressourcen. Die Daten aus diesem Dashboard stammen aus derselben Quelle wie der Azure Resource Graph-Explorer, den wir zuvor betrachtet haben. Wenn Sie eine der Kacheln auswählen, können Sie die genaue Abfrage sehen (und bei Bedarf bearbeiten), die ausgeführt wird, um die in diesem Quadrat angezeigten Informationen zu erhalten. Ausgezeichnet, oder?
Mit dieser Unterstützung unseres operativen Bewusstseins möchten wir nun genauer untersuchen, was wir überwachen sollten, um unsere Zuverlässigkeit zu optimieren.