Warum kümmern sich Ingenieure nicht um die Anwendungsüberwachung?

Alles mit Freitag! Freunde, heute setzen wir eine Reihe von Veröffentlichungen fort, die dem DevOps Practices and Tools- Kurs gewidmet sind, da der Unterricht in der neuen Gruppe des Kurses Ende nächster Woche beginnen wird. Also fangen wir an!



Die Überwachung ist einfach . Dies ist eine bekannte Tatsache. Heben Sie Nagios an, führen Sie NRPE auf dem Remote-System aus, konfigurieren Sie Nagios auf dem NRPE-TCP-Port 5666 und Sie haben die Überwachung.

Es ist so einfach, dass es nicht interessant ist. Jetzt haben Sie die grundlegenden Metriken für Prozessorzeit, Festplattensubsystem und RAM, die standardmäßig in Nagios und NRPE enthalten sind. In Wirklichkeit ist dies jedoch keine „Überwachung“ als solche. Dies ist nur der Anfang.

(Normalerweise installieren sie PNP4Nagios, RRDtool und Thruk, richten Benachrichtigungen in Slack ein und gehen direkt zu nagiosexchange, lassen es aber vorerst los).

Eine gute Überwachung ist eigentlich ziemlich kompliziert. Sie müssen wirklich die Interna der Anwendung kennen, die Sie gerade ansehen.

Ist die Überwachung schwierig?

Jeder Server, ob Linux oder Windows, erfüllt per Definition einen bestimmten Zweck. Apache, Samba, Tomcat, Dateispeicherung, LDAP - all diese Dienste sind in einer oder mehreren Punkten mehr oder weniger einzigartig. Jeder hat seine eigene Funktion, seine eigenen Eigenschaften. Es gibt verschiedene Möglichkeiten, Metriken und KPIs (Key Performance Indicators) abzurufen, die für Sie interessant sind, wenn der Server unter Last steht.


Foto von Luke Chesser auf Unsplash


(Ich möchte, dass meine Armaturenbretter in neonblauen Farben lackiert sind - träumerisch seufzend - ... hmm ...)

Jede Software, die Dienste bereitstellt, muss über einen Mechanismus zum Sammeln von Metriken verfügen. Apache verfügt über ein mod-status Modul, das die Server mod-status Statusseite anzeigt. Nginx hat stub_status . Tomcat verfügt über JMX- oder spezielle Webanwendungen, die wichtige Metriken anzeigen. MySQL hat den Befehl "globalen Status anzeigen" usw.
Warum binden Entwickler solche Mechanismen nicht in die von ihnen erstellten Anwendungen ein?

Tun Entwickler das nur?

Ein gewisses Maß an Gleichgültigkeit gegenüber dem Einbetten von Metriken ist nicht auf Entwickler beschränkt. Ich habe in Unternehmen gearbeitet, in denen ich Anwendungen mit Tomcat entwickelt habe, und keine meiner Metriken erstellt, keine Dienstaktivitätsprotokolle, außer allgemeinen Tomcat-Fehlerprotokollen. Einige Entwickler generieren eine Fülle von Protokollen, die für den Systemadministrator nichts bedeuten. Er hatte das Pech, sie um 3:15 Uhr morgens zu lesen.


Gepostet von Tim Gouw auf Unsplash

Systemingenieure, die die Freigabe solcher Produkte zulassen, sollten ebenfalls eine gewisse Verantwortung für die Situation tragen. Nur wenige Systemingenieure haben Zeit und Sorgfalt, um zu versuchen, aussagekräftige Metriken aus den Protokollen zu erhalten, ohne den Kontext dieser Metriken und die Fähigkeit, sie im Lichte der Anwendungsaktivität zu interpretieren. Einige verstehen nicht, welchen Nutzen sie daraus ziehen können, mit Ausnahme von Indikatoren wie "etwas ist derzeit (oder wird bald) falsch sein".

Eine Änderung des Denkens hinsichtlich des Bedarfs an Metriken sollte nicht nur bei Entwicklern, sondern auch bei Systemingenieuren auftreten.

Für jeden Systemingenieur, der nicht nur auf kritische Ereignisse reagieren, sondern auch deren Abwesenheit sicherstellen muss, ist das Fehlen von Metriken normalerweise ein Hindernis dafür.

Systemingenieure greifen jedoch normalerweise nicht in den Code ein und verdienen Geld für ihr Unternehmen. Sie benötigen führende Entwickler, die die Bedeutung der Verantwortung eines Systemingenieurs für die Erkennung von Problemen, die Sensibilisierung für Leistungsprobleme und dergleichen verstehen.

Diese Devops-Sache

Die Devops-Mentalität beschreibt die Synergie von Entwicklerdenken (Entwickler) und Ausbeutung (Ops). Jedes Unternehmen, das behauptet, "Devops zu machen", sollte:

1. um zu sagen, was sie wahrscheinlich nicht tun (ein Hinweis auf das Mem aus dem Film "Princess Bride" - "Ich glaube nicht, dass es bedeutet, was Sie denken, dass es bedeutet!")
2. eine Position der kontinuierlichen Produktverbesserung fördern.

Sie können ein Produkt nicht verbessern und wissen, dass es verbessert wurde, wenn Sie nicht wissen, wie es derzeit funktioniert. Sie können nicht herausfinden, wie ein Produkt funktioniert, wenn Sie nicht verstehen, wie seine Komponenten funktionieren, von welchen Dienstleistungen es abhängt, welche Hauptprobleme und Engpässe es hat.
Wenn Sie keine potenziellen Engpässe feststellen, können Sie beim Schreiben von Postmortem nicht die Five Why-Technik anwenden. Sie können nicht alles auf einem Bildschirm sammeln, um zu sehen, wie das Produkt funktioniert oder wie es „normal und glücklich“ aussieht.

Linksverschiebung, LINKS, sagte ich, NOOOOOOOO -

Für mich ist eines der Schlüsselprinzipien von Devops „Linksverschiebung“. Eine Verschiebung nach links bedeutet in diesem Zusammenhang eine Verschiebung der Fähigkeit ( nicht der Verantwortung , sondern nur der Fähigkeit), das zu tun, was Systemingenieure normalerweise interessieren, z. B. Leistungsmetriken zu erstellen, Protokolle effizienter zu verwenden usw., im Lebenszyklus der Softwarebereitstellung nach links (links). Software Delivery Life Cycle).


Foto von NESA von Makers auf Unsplash

Softwareentwickler sollten in der Lage sein, die Überwachungstools zu verwenden und zu kennen, mit denen das Unternehmen alle Formen, Metriken, Protokollierungen und Überwachungsschnittstellen überwacht und vor allem die Funktionsweise ihres Produkts in der Produktion beobachtet . Sie können Entwickler nicht zwingen, Zeit und Mühe in die Überwachung zu investieren, bis sie die Metriken sehen und beeinflussen können, wie sie aussehen, wie der Product Owner seine CTOs beim nächsten Briefing präsentiert usw.

Kurz gesagt

1. Bring das Pferd zum Wasser. Zeigen Sie den Entwicklern, wie viele Probleme sie für sich selbst vermeiden können, und helfen Sie ihnen dabei, die richtigen KPIs und Metriken für ihre Anwendungen zu ermitteln, damit der Product Owner, den der CTO anschreit, weniger schreit. Bringen Sie sie sanft und ruhig ans Licht. Wenn dies nicht funktioniert, bestechen, bedrohen und überzeugen Sie entweder sie oder den Eigentümer des Produkts, um diese Metriken schnell aus den Anwendungen zu erhalten, und zeichnen Sie dann Diagramme. Dies wird schwierig sein, da es nicht als Priorität angesehen wird und es viele einkommensschaffende Projekte geben wird, die auf die Umsetzung in der Produkt-Roadmap warten. Daher benötigen Sie einen Business Case, um den Zeit- und Geldaufwand für die Implementierung der Überwachung im Produkt zu rechtfertigen.
2. Helfen Sie den Systemingenieuren, genügend Schlaf zu bekommen. Zeigen Sie ihnen, dass die Verwendung einer Release-Checkliste für jedes Produkt gut ist. Wenn Sie überprüfen, ob alle Anwendungen in der Produktion mit Metriken abgedeckt sind, können Sie gut schlafen und Entwickler sehen, was funktioniert und wo es nicht funktioniert. Der richtige Weg, Entwickler, Produktbesitzer und CTO zu ärgern und zu verärgern, besteht darin, Stöcke in die Räder zu schieben und Widerstand zu leisten. Dieses Verhalten wirkt sich auf das Veröffentlichungsdatum eines Produkts aus, wenn Sie erneut bis zur letzten Minute warten. Wechseln Sie also erneut nach links und nehmen Sie diese Probleme so bald wie möglich in den Projektplan auf. Machen Sie sich bei Bedarf auf den Weg zu Produktbesprechungen. Tragen Sie einen falschen Schnurrbart und Filz oder so etwas, es scheitert nie. Berichten Sie über Ihre Bedenken, zeigen Sie offensichtliche Vorteile und evangelisieren Sie.
3. Stellen Sie sicher, dass sowohl Entwickler (dev) als auch operation (ops) die Bedeutung und die Konsequenzen des Verschiebens von Produktmetriken in die rote Zone verstehen. Lassen Sie den Betrieb nicht als einzigen Schutz für die Leistung des Produkts, sondern stellen Sie sicher, dass auch Entwickler daran teilnehmen (#productsquads).
4. Protokolle sind eine großartige Sache, aber auch Metriken. Kombinieren Sie sie und lassen Sie Ihre Protokolle nicht in einem riesigen, flammenden Ball der Sinnlosigkeit zu Müll werden. Erklären und zeigen Sie den Entwicklern, warum niemand außer ihnen ihre Protokolle versteht. Zeigen Sie ihnen, wie es sich anfühlt, um 3:15 Uhr morgens nutzlose Protokolle anzusehen.

Foto von Marko Horvat auf Unsplash

Das ist alles. Neues Material wird nächste Woche veröffentlicht. Wenn Sie mehr über den Kurs erfahren möchten, laden wir Sie zu einem Tag der offenen Tür ein , der am Montag stattfinden wird. Und jetzt warten wir traditionell auf Ihre Kommentare.