Rolle
DevOps und Platform Engineering
Wie viele Menschen müssen etwas tun, damit eine Änderung in die Produktion gelangt? Wenn mehr als zwei, ist ein Deployment ein Ereignis und keine Tätigkeit - und deshalb passiert es selten.
Erstgespräch
Vier Fragen, mit denen wir beginnen würden
Wie viele Menschen fassen ein Deployment in die Produktion an?
Je mehr Hände, desto seltener deployen Sie, und je seltener Sie deployen, desto größer und riskanter wird jede Änderung.
Wie schnell erfahren Sie von einem Problem in der Produktion?
Wenn von einem Nutzer, misst die Überwachung etwas anderes als das, was tatsächlich kaputtgeht.
Woher wissen Sie, dass die Testumgebung zur Produktion passt?
Wenn aus einer Annahme, lassen sich manche Produktionsfehler nirgendwo anders reproduzieren.
Was tun Sie nicht, obwohl Sie wissen, dass es getan werden muss?
Meist: Sie räumen die Konfiguration nicht auf und prüfen die Infrastrukturkosten nicht. Immer, weil nichts brennt.
Wir übernehmen die repetitive Arbeit, Sie behalten die Entscheidungen über die Plattform
Umgebungskonfiguration, Deployment-Abläufe, das Sammeln von Kontext bei einem Vorfall und Kostenübersichten lassen sich vom Schreibtisch nehmen. Entscheidungen über den Plattformstandard und über die Reaktion auf einen Vorfall bleiben beim Engineer.
- Ein Deployment hört auf, ein Ereignis zu sein. - Ein wiederholbarer Ablauf mit Rollback macht häufigere, kleinere Änderungen sicherer als seltene, große.
- Ein Vorfall beginnt mit Kontext. - Was sich in den letzten Stunden geändert hat, was sonst reagiert hat, welche Dienste zusammenhängen - bevor jemand zu suchen beginnt.
- Der Standard ist sichtbar und eine Abweichung ist benannt. - Ein Team darf es anders machen, aber dann ist bekannt wo und warum, statt es während eines Ausfalls zu entdecken.
Umfang
Was sich aus einem Plattform-Team herausnehmen lässt
Zwanzig Aufgaben als Beispiel. Jede hat einen Punkt menschlicher Freigabe. Unten eine Auswahl; den Umfang passen wir an Ihren Stack an.
Umgebungen und ihre Konfiguration
- Die Umgebungskonfiguration beschrieben und reproduzierbar
- Ein Vergleich der Testumgebung mit der Produktion
- Ein Signal, wenn die Konfiguration auseinanderdriftet
- Ein Register der Abweichungen vom Standard (Entscheidung: der Engineer)
Deployments
- Ein wiederholbarer Deployment-Ablauf mit Rollback-Schritt, wo einer möglich ist
- Prüfungen vor dem Deployment als Startbedingung
- Ein Register der Deployments mit dem Änderungsumfang
- Ein Signal, wenn ein Deployment vom Ablauf abweicht (Einschätzung: der Engineer)
Überwachung und Alerts
- Eine Durchsicht der Alerts auf Nützlichkeit
- Hinweis auf Alerts mit hohem Anteil an Fehltreffern (Urteil über die Nützlichkeit: der Engineer)
- Verknüpfung eines Alerts mit einem Dienst und einem Verantwortlichen
- Ein Signal, wenn ein Dienst keine Überwachung hat
Vorfälle
- Kontext bei der Meldung: jüngste Änderungen und zusammenhängende Dienste
- Die Signale aus demselben Zeitfenster gemeinsam gesammelt
- Die Chronologie des Vorfalls, festgehalten, während er läuft
- Ein Entwurf der Analyse nach dem Vorfall (Inhalt: der Engineer)
Infrastrukturkosten
- Kosten, zugeordnet zu Diensten und Teams
- Hinweis auf Ressourcen, die nicht genutzt werden
- Kostenveränderungen gegenüber der Vorperiode
- Material für eine Entscheidung über eine Konfigurationsänderung (Entscheidung: der Engineer)
Ein Arbeitstag
Heute
- Die Umgebungskonfiguration lebt ihr eigenes Leben und driftet leise
- Ein Deployment braucht mehrere anwesende Menschen und einen guten Tag
- Bei einem Vorfall beginnen Sie damit, festzustellen, was sich zuletzt geändert hat
- Alerts kommen in Mengen, die die Aufmerksamkeit des Teams aufzehren
- Die Chronologie des Vorfalls rekonstruieren Sie hinterher, aus dem Gedächtnis
- Auf die Infrastrukturkosten schauen Sie, wenn die Rechnung kommt
Mit AI-Unterstützung
- Konfigurationsdrift zwischen den Umgebungen wird gemeldet
- Das Deployment hat einen wiederholbaren Ablauf und bei unumkehrbaren Änderungen Stufen
- Ein Vorfall beginnt mit der Liste der jüngsten Änderungen und zusammenhängenden Dienste
- Alerts, die nie zu einer Maßnahme führten, werden aufgezeigt
- Die Chronologie des Vorfalls hält sich selbst fest, während er läuft
- Die Kosten werden Diensten und Teams laufend zugeordnet
- Deployment-Frequenz
kleinere Änderungen häufiger statt großer selten
ein Deployment verlangt nicht, mehrere Menschen zu versammeln
- Zeit bis zur Wiederherstellung nach einem Vorfall
ein kürzerer Weg zur Ursache
der Kontext und die jüngsten Änderungen liegen bei der Meldung
- Umgebungen, die zusammenpassen
weniger Fehler, die sich außerhalb der Produktion nicht reproduzieren lassen
Konfigurationsdrift wird gemeldet
- Infrastrukturkosten
es ist sichtbar, was Geld kostet und wem es gehört
Kosten, zugeordnet zu Diensten und Teams
Wir beginnen mit den Deployments, weil ihre Frequenz alles Übrige beeinflusst.
- Schritt 1
Ein wiederholbarer Deployment-Ablauf
Mit Rollback-Schritt und Prüfungen vor dem Start. Für unumkehrbare Änderungen - vor allem Schema-Migrationen - gibt es kein Rollback und wir tun nicht so als ob; dort arbeitet man in Stufen und korrigiert nach vorn, und der Ablauf muss das berücksichtigen.
- Schritt 2
Umgebungen, die zusammenpassen
Ein Konfigurationsvergleich und ein Driftsignal.
- Schritt 3
Kontext bei einem Vorfall
Jüngste Änderungen, zusammenhängende Dienste, die Chronologie, festgehalten, während es läuft.
- Schritt 4
Alerts und Kosten
Eine Durchsicht der Alert-Nützlichkeit und die Zuordnung der Kosten. Zuletzt, weil es Daten aus mehreren Perioden voraussetzt.
Häufige Fragen
Fragen, die beim ersten Treffen aufkommen
Worin unterscheidet sich das von einem Systemadministrator?
Der Administrator betreut das, was bereits läuft - Server, Backups, Updates. Hier geht es um die Umgebungen, in denen Software gebaut wird, und um den Weg, den eine Änderung in die Produktion nimmt. In kleineren Unternehmen sind die Rollen oft zusammengelegt, aber die Probleme, die sie lösen, sind völlig andere.
Kann das Plattform-Team danach kleiner sein?
Plattform-Teams sind meist ein Engpass, kein Überschuss - jedes Produktteam steht bei ein oder zwei Menschen in der Schlange. Repetitive Deployments und das Sammeln von Kontext bei Vorfällen zu übernehmen verkleinert das Team nicht, es verkürzt diese Schlange. Das ist tatsächlich das Erste, was Produktteams bemerken.
Fällt das unter die KI-Verordnung?
Arbeit an der Infrastruktur ist keine Hochrisiko-Anwendung. Der einzige Punkt, der Sorgfalt braucht, ist, dass Daten über Deployments und Vorfälle der Verbesserung der Plattform dienen und nicht der Bewertung von Teams oder der Menschen, die eine Änderung ausgeliefert haben.
Ihre Frage steht nicht dabei? Gespräch vereinbaren
Nächster Schritt
Wie oft haben Sie im letzten Monat in die Produktion deployt?
Wir zeigen Ihnen, wie Plattformarbeit aussieht, wenn ein Deployment aufhört, ein Ereignis zu sein, und ein Vorfall mit Kontext beginnt.