Die Meisten haben ein Problem damit zu scheitern. Natürlich gibt es Unternehmer*innen, die den Lean-Startup-Ansatz verfolgen und der Meinung sind, man könne nur durch Fehler lernen und dies forme den Charakter. Die meisten von uns versuchen allerdings, ein Scheitern zu vermeiden – und das in der Regel aus gutem Grund.
Wenn wir uns mit DevOps beschäftigen, kommen wir um das Thema Scheitern jedoch nicht herum. Denn das passiert bei dieser Methode ziemlich häufig. Sie haben vielleicht schon den einen oder anderen dieser Sätze gehört, wie zum Beispiel den von Zuckerberg:
„Move fast and break things.“ (auf Deutsch etwa: Sei schnell und brich Regeln.) Okay, das ist mittlerweile überholt. Selbst Facebook beruft sich nicht mehr darauf. Aber dieser Satz zeigt, wie manche Leute die moderne Softwareentwicklung immer noch sehen.
„Fail fast, fix fast“, heißt es. Fehler passieren, sollen aber schnell korrigiert werden. Mhm. Weniger kontrovers, aber irgendwie immer noch nicht zufriedenstellend. Es gibt definitiv viele Menschen, für die das untrennbarer Bestandteil von DevOps ist. Aber wollen wir Fehler von vornherein einplanen?
„Eine Kultur des ständigen Experimentierens und Lernens.“ Ah. Da hat aber jemand getrickst, um die drei Prinzipien von DevOps zu beschreiben. Denn wie sollen wir lernen, wenn wir keine Fehler machen dürfen? Und impliziert ständiges Lernen nicht, dass wir häufig scheitern? Nun, nicht unbedingt – siehe unten.
Ich bin mir sicher, dass es noch weitere Beispiele gibt, die in dieselbe Richtung gehen.
Aber was in diesem Kontext viel wichtiger ist: Was bedeutet diese Haltung für DevOps in SAP? Können wir es uns leisten zu akzeptieren, dass wir bei geschäftskritischen Systemen Fehler machen, wenn dadurch möglicherweise der Geschäftsbetrieb zum Erliegen kommt?
Nun, offensichtlich nicht. Aber ich bin der Meinung, dass dies der falsche Ansatz beim Umgang mit Fehlern ist. DevOps bedeutet nicht, dass wir es akzeptieren, ständig Fehler zu machen, weil wir glauben, dass bei Softwareauslieferungen Geschwindigkeit vor Qualität geht. Vielmehr geht es darum, eine Balance zwischen der Wahrnehmung von Risiken und der unternehmerischen Wertschöpfung zu schaffen. Es geht darum, wie wir Risiken steuern, um sie zu minimieren, und wie wir auf Worst-Case-Szenarien vorbereitet sind, wenn sie eintreten.
(Ich könnte auch argumentieren, dass es hier ohnehin keinen wirklichen Unterschied macht. Schließlich kommt es bei vielen (vielleicht sogar den meisten?) SAP-Implementierungen zu Problemen und Zwischenfällen, bevor der Begriff DevOps einem Basis-Manager überhaupt zu Ohren kommt. Aber das ist eine andere Geschichte.)
Anders ausgedrückt: Wie können wir schnell sein, ohne Regeln zu brechen, und wie können wir, falls Probleme auftreten, diese schnell beheben?
Ich habe da einige Tipps für Sie.
1. Erkennen Sie an, dass Fehler nicht immer technisch bedingt sind.
Behalten wir hierbei den DevOps-Ansatz im Hinterkopf. Spricht man mit Technikexpertinnen wie Entwickler*innen und Lösungsarchitekt*innen, geht man automatisch davon aus, dass es Probleme mit der Technik sind, wenn man von einem „Fehler“ spricht. Das ergibt durchaus Sinn, wenn man bedenkt, dass sich ein Großteil ihrer Arbeit um technische Probleme dreht.
Aber bei DevOps kann es bei Fehlern auch um Ergebnisse gehen, nicht nur um Code. Scheitern kann bedeuten, dass eine Funktion ausgeliefert wird, die nicht so funktioniert, wie die Anwenderinnen es erwarten. Oder nicht das gewünschte Ergebnis liefert. Oder nicht von den Anwenderinnen akzeptiert wird, weil sie kein optimales Benutzererlebnis bietet.
Bei solchen Szenarien kann – im Gegensatz zu „Move fast and break things“ – hinter „Fail fast; fix fast“ eine kundenorientierte Absicht stecken, da es nicht nur darum geht, Risiken abzuwägen. Durch die Fähigkeit, Probleme bei DevOps schnell zu beheben, können wir eine Kultur des ständigen Lernens und Experimentierens schaffen – für SAP-Projekte, aber auch überall sonst.
2. Schlüsseln Sie Ihre Anforderungen auf.
Wenn Sie DevOps einsetzen, sollten Sie dies ohnehin berücksichtigen, aber es ist allgemein ein gutes Prinzip, um schnell und sicher zu arbeiten. Wenn Sie versuchen, schneller und häufiger zu liefern, aber Ihre Anforderungen nicht entsprechend anpassen, werden Sie scheitern. Entweder Sie schaffen es nicht, rechtzeitig zu liefern (womit Sie das Ziel verfehlt haben), oder Sie werden zwar schnell vorankommen, aber dabei Regeln brechen.
Das ist nicht immer einfach, insbesondere wenn große Funktionseinheiten geliefert werden müssen. Viele Unternehmen arbeiten mit speziellen Backlog-Management-Tools wie Atlassian Jira, um diese neuen „User Stories“ effektiv und konsistent zu verwalten. Solche Tools sollten mit Ihrer DevOps-Automatisierungslösung für SAP-Systeme verknüpft sein, damit die SAP-Teams ebenfalls davon profitieren.
3. Stellen Sie sicher, dass die Qualität schon vor der Entwicklung stimmt.
Ich wollte hier nicht schon wieder „Shift Left“ erwähnen, denn wenn Sie sich mit dem Thema DevOps befassen, werden Sie diesen Begriff schon häufiger gelesen haben (auf dieser Website oder an anderer Stelle). Aber es ist nun mal ein wichtiger Bestandteil des DevOps-Ansatzes. Wenn Sie Probleme früher erkennen, können Sie sie nicht nur schneller und einfacher beheben, sondern darüber hinaus Verzögerungen vermeiden, die durch wiederholte Übergaben zwischen Entwicklungs-, Basis- und QS-Teams entstehen. Außerdem setzen Sie Ressourcen im QS-Team frei, so dass sich die Mitarbeiter*innen auf wichtige Aufgaben konzentrieren können!
Das bedeutet, dass Sie einige Änderungen an Ihrem Prozess vornehmen müssen. Obligatorische Peer-Reviews sind ein guter Anfang. Vielleicht sollten Sie eine testgetriebene Entwicklung in Betracht ziehen. Auch Komponententests bieten diverse Vorteile, und das Entwicklungssystem ist der ideale Ort, um die Codequalität und die Einhaltung von Standards zu überprüfen. Diese Liste lässt sich beliebig fortsetzen. Mit der richtigen DevOps-Automatisierungstechnologie für SAP-Systeme läuft Vieles davon automatisch ab und alles Weitere können Sie zumindest nachverfolgen.
4. Stellen Sie sicher, dass die richtigen Leute grünes Licht geben.
Der gesamte Shift-Left-Ansatz ist relativ sinnlos – oder wird zumindest untergraben –, wenn die Personen, die die Änderungen vornehmen, diese unabhängig von den Ergebnissen der von Ihnen integrierten Prüfungen genehmigen können. Erstaunlich häufig ist jedoch die Bereitstellung für QS-Systeme deutlich weniger streng reglementiert als Bereitstellungen im weiteren Prozessablauf. Dass Entwicklerinnen ihren eigenen Code genehmigen, ist nicht ungewöhnlich und sehr riskant, vor allem, wenn die Mitarbeiterinnen unter dem Druck stehen, im Rahmen des DevOps-Ansatzes schnell zu liefern.
Bei Genehmigungen in der gesamten SAP-Landschaft, auch in den Entwicklungssystemen, muss eine angemessene Funktionstrennung sichergestellt sein.
Darüber hinaus benötigen Sie einen Prozess, bei dem die richtigen Personen jede Änderung in jeder Phase je nach Projekt, Funktionsbereich, SAP-System usw. abzeichnen. Vielleicht gibt es sogar einen speziellen Prozess für Änderungen, die von Ihrer DevOps-Automatisierungslösung als riskant bewertet werden. Insbesondere bei Notfalländerungen (die ebenfalls sicher und geprüft sein müssen) spielt dies eine große Rolle. Für die beste Kombination aus Geschwindigkeit und Sicherheit müssen Sie benutzerdefinierte Workflows für verschiedene Arten von Änderungen entwickeln können, bei denen automatisch die richtigen Genehmigenden zugewiesen und entsprechend informiert werden.
5. Keine technischen Fehler mehr bei der Bereitstellung!
Überschreibungen, Überholvorgänge, Sequenzierung und Abhängigkeiten. Es gibt eine ganze Reihe von technischen Problemen bei Implementierungen, die dazu führen können, dass Produktivsysteme nicht mehr funktionieren, selbst wenn der gelieferte Code alle Qualitätsanforderungen erfüllt. Deshalb betreiben viele Unternehmen viel Aufwand, um diese Probleme in den Griff zu bekommen (und scheitern in der Regel bis zu einem gewissen Grad daran).
Wenn Sie aber schnell liefern möchten, können Sie es sich nicht leisten, stunden- oder gar tagelang über Tabellenkalkulationen zu brüten, um den Cutover möglichst sicher zu gestalten. DevOps – und insbesondere fortgeschrittene CI/CD-Pipelines – automatisiert diese Vorgänge. Kunden, die unsere DevOps-Automatisierungstechnologie verwenden, können ungeplante Ausfallzeiten nachweislich komplett vermeiden.
6. Sie sollten einen Plan B haben.
Manchmal ist es einfach so. Menschen machen Fehler. Die Konfiguration der Produktivsysteme ist zu komplex. Software wird fälschlicherweise hartkodiert. Auch mit den strengsten Prüfungen im Entwicklungs- und Bereitstellungsprozess können Dinge schief gehen, wenn auch viel, viel seltener.
Wenn Sie Software aber immer häufiger bereitstellen, steigt auch diese geringe Fehlerwahrscheinlichkeit. Daher sollte die MTTR (Mean Time to Restore) als DevOps-Kennzahl einen höheren Stellenwert haben als die MTTF (Mean Time to Failure). Wenn wir schnell vorankommen möchten, dürfen wir uns nicht von der Angst vor unbeabsichtigten Ergebnissen aufhalten lassen.
Wie können Sie also Fehlern in Ihrem DevOps-Prozess Rechnung tragen, wenn sich diese nicht vermeiden lassen? Sie müssen SAP-Produktionsimplementierungen schnell zurückzusetzen können, ähnlich wie bei Git-basierten Nicht-SAP-Pipelines, die auf den letzten guten Build zurückgreifen.
Automatisierung ist der Schlüssel zu effizientem Fehlermanagement
Wenn Sie bis hierher gekommen sind, ist Ihnen die Rolle der Automatisierung für Ihre Arbeit wahrscheinlich ziemlich klar. Es ist definitiv so, dass manuelle DevOps-Pipelines für Software höchst ungewöhnlich sind – das gilt auch für SAP. Sie benötigen die richtige SAP-spezifische Automatisierungstechnologie, wie ActiveControl von Basis Technologies. Wenden Sie sich an unsere Expert*innen, um zu besprechen, wie unsere Lösung Ihnen dabei helfen kann, Risiken zu verwalten und Fehler aller Art zu vermeiden bzw. zu beheben.
