Wie DevOps bei mir läuft, mit einem Teilzeit-Engineer

Lange Zeit war ich die Ops-Abteilung. Ein paar Cloud-Server, geplante Jobs, Domains, DNS, ein paar APIs, von denen andere Dinge abhingen. Nichts davon war für sich schwer. Zusammen waren es ein Dutzend bewegliche Teile, und bewegliche Teile gehen um drei Uhr nachts kaputt. Ich habe einen toten Job im Halbschlaf repariert und bis zum Mittag vergessen, was ich getan hatte. Beim nächsten Ausfall lebte die Lösung nirgendwo.

Ein Ops-Team stand nie zur Debatte; die Firma ist mit Absicht klein. Was ich brauchte, war eine sorgfältige Person und eine Arbeitsweise, die nicht davon abhängt, dass wir beide zur gleichen Zeit wach sind.

Die Idee

Diese Person ist Ammar. Er arbeitet in Teilzeit, aus einer anderen Zeitzone, und unsere Live-Calls könnte ich an einer Hand abzählen. Alles andere läuft über ein Repository.

Das Repo ist der einzige Ort, an dem Arbeit den Besitzer wechselt. Es enthält eine To-do-Datei, und diese Datei ist sein Posteingang. Wenn ich etwas brauche, schreibe ich es dort hinein, mit dem Kontext, den er braucht, und damit, wie fertig aussieht. Er nimmt es sich, wenn sein Tag beginnt, hakt es ab und hinterlässt darunter eine Notiz. Fragen stehen in derselben Datei, direkt neben der Aufgabe, damit Frage und Antwort zusammenbleiben.

Neben der To-do-Datei liegt ein Inventar: was wo läuft, wofür es da ist, was davon abhängt. Wenn etwas kaputtgeht, ist die erste Frage beantwortet, bevor jemand anfängt zu tippen.

Secrets reisen nie durch den Chat. Sie liegen in einem Passwort-Manager, das Repo verweist nur mit dem Namen darauf, und ein kleines Skript zieht sie zur Laufzeit hinein. Niemand hat je einen Schlüssel in eine Nachricht kopiert, also musste nie jemand wegen einer Nachricht einen rotieren.

Und jede Änderung ist ein Commit. Eine neue Cron-Zeile, ein DNS-Eintrag, ein Dienst, der auf eine andere Maschine umzieht: Es landet in git mit einer kurzen Nachricht, die sagt, warum. Nichts lebt in einem Kopf. Wenn Ammar im Urlaub ist, oder ich, steckt der Zustand von allem in der Historie, nicht in einer Person.

Sechs Monate später

Ruhig. Das ist die ehrliche Beschreibung. Ich bekomme noch immer eine Nachricht, wenn etwas bricht, aber von einer Sonde, nicht von einem Kunden, und an den meisten Morgen sind in der To-do-Datei ein oder zwei Punkte abgehakt, die ich am Abend davor geschrieben hatte. Was früher ein Drei-Uhr-nachts-Problem war, ist jetzt eine Zeile in einer Datei, erledigt in jemandes Arbeitszeit.

Überrascht hat mich nicht die Verfügbarkeit. Überrascht hat mich, wie viel ruhiger ich wurde, sobald ich das Inventar nicht mehr im Kopf herumtrug. Du merkst das Gewicht erst, wenn es in einer Datei liegt.

Was es kostet

Vor allem Haltung. Die Regel ist kurz und streng: Was nicht aufgeschrieben ist, existiert nicht. Eine Korrektur, die du von Hand auf einem Server machst und nicht committest, macht das nächste Deploy rückgängig, und daran ist niemand schuld außer der Hand. Eine Aufgabe, die nebenbei erwähnt wird, ist keine Aufgabe. Im ersten Monat ist das unbequem, weil Aufschreiben langsamer ist als Machen. Danach kannst du dir keine andere Arbeitsweise mehr vorstellen.

Es kostet auch ein wenig Vertrauen. Asynchron heißt, ich sehe ihm nicht bei der Arbeit zu. Ich lese die Commits und die Notizen, und das hat sich ohnehin als der bessere Blick erwiesen.

Wenn du den Drei-Uhr-Teil wiedererkennst

Du brauchst keine Ops-Abteilung. Du brauchst eine sorgfältige Person, ein Repo, das sie als einzige Quelle der Wahrheit behandelt, eine To-do-Datei, ein Inventar, einen Passwort-Manager und die Gewohnheit, alles zu committen. Das ist kein raffinierter Aufbau, und genau deshalb funktioniert er weiter.

Es ist außerdem eines der Dinge, die ich für andere einrichte. Wenn du eine kleine Firma führst und deine Server noch ein Drei-Uhr-nachts-Problem sind, schau dir die Entwicklungsleistungen an oder schreib mir einfach.