Operability ist kein Add-On: Erst im Betrieb wird eine Software zum Produkt

Mit modernen Frameworks, Cloud-Stacks und KI-Unterstützung entwickeln wir heute Software schneller denn je. Doch zwischen „fertig entwickelt” und „wirklich betreibbar” liegt ein gefährlicher blinder Fleck. Viele Anwendungen bestehen Tests, Demo-Szenarien und Go-Lives mit bravour – stolpern dann aber im Betrieb über die Realität.

In diesem Talk geht es um genau diese Lücke: Warum Operability so oft fehlt, obwohl niemand sie bewusst weglässt. Warum Projekte auf Features optimieren, aber auf Betriebsfähigkeit angewiesen sind. Und warum Software – wenn sie zum Produkt wird – nicht nur irgendwie läuft, sondern sich selbst schützt, erklärt und auch mal zur Vorsorge geht.

https://talks.cosee.biz/talk/82e636c3-1bf1-450c-9ace-afe9e232165c

Transcript

2. Wir alle entwickeln heute So ft ware schneller denn je mit ‣ Modernen Frameworks ‣ Cloud Platforms ‣ KI Unterstützung ‣ Vibe Coding Aber heißt “fertig entwickelt” auch “betreibbar”? Und wie erkennen wir mangelnde Betriebsfähigkeit / Operability?
3. Betriebs(un)fähigkeits BINGO “Das kann nur Martin machen, der ist gerade im Urlaub.” “Warte… ich hatte da irgendwo mal ein Script.” “Ich kann die App nicht bauen.” “Komisch, letzte Woche lief die Pipeline mit dem gleichen Commit noch.” “Die Pipeline ist rot, aber das ist normal.” “Wir deployen nur Mittwochs, wenn alle da sind.” “Hilfe! Die DB Migration ist auf Production fehlgeschlagen.” “Bevor wir upgraden können müssen wir erst XYZ fi xen.” “Der Container‚ läuft wieder OOM. Ich verdoppeln nochmal den RAM.” “Wir nutzen einfach den staging Cluster für das production Env.” “Unser SSL Zerti fi kat ist am Wochenende abgelaufen.” “Ich hab den Alerts Channel gemutet. Da kommt so viel Spam.” “Den Report darfst du nie klicken. Der killt Prod!” “Der Kunde hat angerufen. Die App ist down.” “Die Logs haben wir leider nur solange der Container läuft.” “Natürlich haben wir Backups, aber keine Ahnung, wie der Restore geht.”
4. Betriebs(un)fähigkeits BINGO “Das kann nur Martin machen, der ist gerade im Urlaub.” “Warte… ich hatte da irgendwo mal ein Script.” “Ich kann die App nicht bauen.” “Komisch, letzte Woche lief die Pipeline mit dem gleichen Commit noch.” “Die Pipeline ist rot, aber das ist normal.” “Wir deployen nur Mittwochs, wenn alle da sind.” “Hilfe! Die DB Migration ist auf Production fehlgeschlagen.” “Bevor wir upgraden können müssen wir erst XYZ fi xen.” “Der Container‚ läuft wieder OOM. Ich verdoppeln nochmal den RAM.” “Wir nutzen einfach den staging Cluster für das production Env.” “Unser SSL Zerti fi kat ist am Wochenende abgelaufen.” “Ich hab den Alerts Channel gemutet. Da kommt so viel Spam.” “Den Report darfst du nie klicken. Der killt Prod!” “Der Kunde hat angerufen. Die App ist down.” “Die Logs haben wir leider nur solange der Container läuft.” “Natürlich haben wir Backups, aber keine Ahnung, wie der Restore geht.” Ich habe übrigens alle davon in Projekten erlebt. 🥲
5. Strukturelles Problem in der Branche ‣ Features werden gefeiert ‣ Betriebsfähigkeit ist unsichtbar – bis sie fehlt ‣ KPIs wie Velocity oder Time-To-Market verzerren Prioritäten ‣ Go-Live ist o ft das Ziel – dann geht Betrieb aber erst richtig los und Betriebsprobleme nehmen Einfluss auf die Entwicklung Aber was gehört alles zu Operability? Und was motiviert uns dazu?
6. Operability als Risiko-Management ‣ Wir beschreiben Ziele im Betrieb mit SLOs ‣ Welche Risiken bedrohen diese SLOs? ‣ Mit welchen Praktiken können wir Risiken minimieren? ‣ Manche Praktiken benötigen andere Praktiken, um umgesetzt zu werden
7. Das wird ganz schön kompliziert. Wer soll wissen, was wir davon wirklich brauchen? 🤔
8. You build it, you run it Was ich damit nicht meine: ‣ Das Dev-Team muss auf jeden Fall auch den Betrieb übernehmen ‣ Wer nachts on-call ist, gibt sich mehr Mühe während der Entwicklung ‣ Nur wer Betriebsverantwortung hat, ist ein richtiger Dev Sondern: ‣ Devs, die wissen, wie sich Probleme im Betrieb anfühlen, tre ff en in der Entwicklung andere Entscheidungen
9. Wer Logs liest, loggt anders Statt: logger.error(“an error occurred!”) Wie müssen Logs aussehen, damit sie auch helfen? ‣ Kontext, requestId, tracingId, userId ‣ Strukturierte Json Logs mit Metadaten ‣ Log Management Tool kann Logs korrekt parsen und hat sinnvolle Retention ‣ Wenig Noise, mehr Signal generated with AI
10. Wer viel deployed hat, deployed anders Statt: Deployment Job lief durch, passt! 👋 Jedes Deployment ist ein Risiko. Sollten wir das Risiko weiter minimieren? ‣ Rollbacks ‣ Health Checks, Smoke Tests, Uptime Monitoring ‣ Progressive Rollout, Canary Deployments ‣ Feature Flags
11. Kann KI uns im Betrieb retten? ‣ KI kann das verstärken, was schon da ist ‣ Wenn wir strukturierte Observability Daten haben, kann uns KI sagen: “80% der Fehler sind Android User aus Asien” ‣ Eine KI ohne Datenbasis (Observability, Tests und Automatisierung) ist schlimmer als ein Autopilot ohne Sensoren • KI rät schnell und selbstbewusst und verstärkt das vorhandene Chaos ‣ Tipp💡: KI als Gesprächspartner, um Lücken in der Operability zu identifizieren
12. Operability in Dienstleister-Projekten ‣ Fokus auf Operability während Entwicklung kann schwer zu rechtfertigen sein • Kunden sehen nur bei Features direkten Mehrwert für User • In den Anforderungen steht nur sowas wie: “Es gibt Logs. Es gibt Tests.” ‣ Aber: Der Kunde muss irgendwann für Operability bezahlen • Entweder geplant während der Entwicklung oder unkontrolliert danach • Eine Anwendung mit allen Anforderungen ohne Operability auszuliefern ist die teuerste Art, So ft ware zu bauen
13. Erkenntnisse ‣ Features und Prototypen entwickeln ist nicht mehr schwer • Erst im Betrieb kann daraus ein Produkt werden das Wert sti ft et • Bei mangelnder Operability kann man Betriebs-Risiken aufzeigen ‣ Gute So ft ware hält sich fit und geht zur Vorsorge: Updates, Maintenance, Observability ‣ Schlechte So ft ware ru ft nachts an, meldet sich krank und droht irgendwann arbeitsunfähig zu werden generated with AI