Betrieb, das Ops in DevOps - hier entstehen klassischerweise 75% der Kosten

Betrieb ist der Sinn des Lebens einer Software. Hier quittiert der Kunde unsere Mühen endlich mit Geldflüssen. Hier entscheidet der Kunde darüber, welche Fehler WIR 🙄 während des Requirements‑Engineering gemacht haben, indem wir ihm weder die richtigen Fragen gestellt, noch die Antworten richtig erfasst haben. Egal, wie es wirklich lief. Aufgrund seiner Erfahrungen im Betrieb entscheidet der Kunde auch, ob er mit neuen Aufträgen gerne wieder zu uns kommt, nur notgedrungen (Lock‑In) oder gar nicht. Ist das User‑Erlebnis nicht zufriedenstellend, wird es schwierig. Hier hilft die sog. „Ingenieurpsychologie“, eine etwas missweisende Bezeichnung für die Wissenschaft der Gestaltung von HMIs (Human‑Machine‑Interfaces) und einer guten UI (User Experience).

Gerade das V‑Modell visualisiert prägnant, dass Probleme auf dem rechten Ast typischerweise ihre Ursache auf gleicher Höhe der linken Seite haben. Schwierigkeiten im Betrieb weisen also auf Unzulänglichkeiten im Requirements‑Engineering hin, auch wenn dies auf den ersten Blick nicht auffällt.

Sollten Sie Kunde von Software‑Entwicklungsleistungen sein, wundern Sie sich vielleicht über mysteriöse Probleme und die hohen Kosten von Anpassungen. So schwierig kann eine neue Schnittstelle ja doch wohl nicht sein, oder? Doch. Und der Fehler hat System:

Möglicherweise hat Ihr Software‑Anbieter bereits in der Phase der Anforderungsanalyse (Requirements Engineering) die (erlernbaren) Basiskompetenzen der Kommunikation nicht praxistauglich eingesetzt: 80 Fragetechniken, qualifiziertes Zuhören, interessiertes Nachfragen und fachlich sauberes Feedback. Es könnte so einfach sein. Isses aber nich'. Vielleicht haben Sie auch vergessen, beispielsweise eine hohe Modularisierung, einen hohen Zusammenhalt der Module und geringe Kopplung und damit eine Microservice‑Architektur zu vereinbaren. Auch könnten Sie es versäumt haben, eine hohe Dichte semantisch bedeutsamer Kommentarzeilen (und die vielen anderen Dinge) im Quellcode zu fordern. Daraufhin könnte Ihr Zulieferer der Einfachheit halber eine sog. „Monolithische Softwarearchitektur“ entwickelt haben und die Verwendung globaler Variablen für ok, rekursive Strukturen und Zeigerarithmetik für cool halten und dazu noch ohne Beachtung unsicherer Anweisungen gemäß aktuellem Security‑Stand der öffentlichen Listen programmiert haben. Von Security‑by‑Design gar nicht zu reden. Oder Sie haben im Service Level Agreement SLA eine hohe Verfügbarkeit vertraglich vereinbart. Was dann dazu führte, dass man sehr konservativ mit dem Einspielen von Updates ist und sich lieber 17‑mal absichert, bevor eine Downtime riskiert wird. Sinnvolle Änderungen bleiben nach Möglichkeit aus, nur das Nötigste erfolgt. „Never change a running System“ kann auf diese Weise zu einem verborgen gelebten Prinzip und Problem werden.

Schnelles bis hektisches Coden mit KI, schnelles bis hektisches ans Laufen bringen, die Probleme werden entspannt auf später verschoben: Hohe Angreifbarkeit durch Hacker, anspruchsvoll und aufwändig zu pflegen oder zu ergänzen, nicht sauber zu testen und für neu hinzukommende Entwickler kaum zu durchblicken. Leider haben viele Entwickler ihr Handwerk autodidaktisch gelernt und nicht im Rahmen eines Informatikstudiums... und durch KI‑Vibe‑Coding verschärft sich diese Problematik zügig: so ziemlich jeder kann heute in Sekunden lauffähigen Code mit auf den ersten Blick hoher Qualitätsanmutung in einer beliebigen Software‑Sprache erzeugen. Nur mit dem Abfangen von potenziellen Fehlern, der Anwendung tauglicher Testmetriken z.B. nach ISO 29119 oder Seidl und Freigabeprozesse z.B. nach SPICE sowie der langfristigen Tauglichkeit hapert es.

Für Anbieter von Software‑Leistungen könnte die beschriebene Situation luxuriös sein: Lock‑In des Kunden mit der Erstentwicklung und später Goldesel. In der Praxis wird das Prinzip dennoch durch Konflikte eher unangenehm in der dauerhaften Umsetzung. Im Folgenden einige Blitzlicht‑Punkte zur ersten Orientierung der Technik:

• Die Dynamik der Lastverteilung im Betrieb, der Unterschied zwischen Serverlangeweile und Peaks, ist ein Designelement: automatische Skalierung, Cloud‑Native mittels Containern?
• Bei der Planung auch dabei: das Infrastrukturteam, das Betriebsteam, die Admins, die Data‑Engineers, die Produktmanager
• Deadlocks vermeiden: wenn etwa das Betriebsteam das Basis‑OS nur aktualisieren kann auf neuen Servern - und das Infrastrukturteam nur neue Server einrichten kann, wenn zuvor die alten außer Betrieb genommen wurden.
• Zweckgebundene Server: keine Flexibilität bei wechselnden Lasten
• Gegenseitige Schuldzuweisungen: das Betriebsteam sieht sich angesichts mieser Dokumentation nicht in der Lage, das System zu betreiben. Es ist laut Entwickler aber einfach nur zu dumm dazu.
• Ob wohl Admins gerne während dünn bezahlter Bereitschaft aus dem Nachtschlaf geweckt werden? Man darf es bezweifeln. Fluktuation ist ein reales Risiko.
• Hosting: Bare Metal im eigenen Keller oder bei Hostern? Oder doch flexible, virtualisierte Räume? Mit Noisy Neighbours?
• Orchestrierung, Kubernetes, Docker: die Einarbeitung ist aufwendig.
• Cloud: Infrastrctute as a Service (Iaas), Platform as a Service (Paas) und Software as a Service (SaaS) und wie kombiniert?
• Cloud‑Native‑Software: für die Cloud entworfen, bietet sie Container‑Parallelisierung für Skalierbarkeit je nach Last, Microservices, Elastizität, Flexibilität. Risiko: Schnelllebigkeit der Anbieter, Breaking‑Changes, anschauen: cncf.io
• [...]

Es wird in Ansätzen deutlich, dass der Betrieb mehr ist als einfaches Knöpfchen drücken und AEG (Ausschalten, Einschalten, Geht wieder). In DevOps ist zentral der Gedanke verankert, durch Integration von Dev und Ops (und Test, und Security, und...) elegantere Prozesse zu ermöglichen. Da größere Gruppen die natürliche Neigung zur Subgruppenbildung zeigen, ist für eine gelingende Umsetzung wirtschaftspsychologische Fachkompetenz gefragt. Gleiches gilt für die Durchführung von Root Cause Analysen (RCAs), die nach der Integration konstruktiv ablaufen (sollten). Das regelmäßig geforderte Einreißen der Mauern zwischen den Silos ist schnell gesagt und geschrieben, in der Praxis jedoch nicht trivial.

Vermutlich ist es insgesamt für Alle eine gute Idee, das V‑Modell samt DevOps und damit den gesamten Lebenszyklus SDLC stets einzubeziehen. Und das beginnt mit einem kompetent betriebenen Requirements‑Engineering, gefolgt von durchdachten Architekturen der Daten und Programme. Vielleicht ist ein introvertierter Entwickler ja doch nicht der Beste, um während der Anforderungsanalyse gemeinsam mit Kunden maximale Reichhaltigkeit zu erzeugen? Einen Gedanken ist es sicher wert.

„Erst Grübeln, dann Dübeln“
Altbewährte Handwerkerweisheit

Reden wir jetzt darüber!