Die vier Stufen der DevOps Maturity

Ich habe über die Jahre mit vielen SAP-Kunden gesprochen und dabei vier Reifegrade herausgearbeitet. Die schlechte Nachricht: SAP DevOps führt schon so lange ein Schattendasein, dass die meisten Kunden über den ersten Grad nicht hinausgekommen sind. Die gute Nachricht: Wird man sich dessen erst einmal bewusst, lässt sich Abhilfe schaffen.

Bereits vor ein paar Wochen habe ich mich an dieser Stelle mit dem Thema SAP-Betrieb befasst und gefragt, warum SAP in Sachen DevOps-Automatisierung dem Markt so hinterherhinkt.

Als SAP 2002 den Solution Manager einführte, war dies der richtige Schritt in die Zukunft. Natürlich gab es schon Unternehmen wie SolarWinds, aber die Idee, Enterprise-Software-Systeme in einer zentralen verwalteten Umgebung zusammenzubringen, war schon ziemlich revolutionär.

Um das Jahr 2007 herum nahmen die Dinge dann meiner Meinung nach eine unglückliche Wendung: SAP führte mit dem Maintenance Optimizer ein Tool zur Steuerung von Upgrades ein und zwang seine Kunden zum Einsatz des Solution Managers, indem man den Maintenance Optimizer zur Voraussetzung für die Implementierung neuer Softwareversionen machte.

Kleiner Spoiler: Im Jahr 2019 muss eine Software den Kunden mit ihrem Funktionsumfang überzeugen können. Es gehört sich einfach nicht, dem Kunden schlicht keine andere Wahl zu lassen. Ich bin auf diesen Artikel aus dem Jahr 2010 gestoßen, der seitdem nichts von seiner Aktualität eingebüßt hat: Solution Manager ist zu komplex, zu teuer und zu aufwändig in der Implementierung. Es gibt nicht genug Fachkräfte am Markt und der ROI ist gleich Null.

Mittlerweile sind zehn lange Jahre vergangen, wir schreiben das Jahr 2019 und es haben sich einige interessante Änderungen ergeben.

Zum einen setzen viele Unternehmen heute für den Betrieb ihrer Software auf Platform-as-a-Service (PaaS), was das Thema Operations für den Kunden mehr oder weniger irrelevant macht. Mit PaaS dreht es sich beim Betrieb nur noch um Ihre Service Level Agreements (SLAs) oder die Integration mit anderen Unternehmenslösungen.

Zum anderen zieht SAP mit seiner neuesten ERP-Generation – S/4HANA – auch weiterhin ein traditionelles Software-Modell einem SaaS-Modell vor. Natürlich gibt es auch eine SaaS-Version von S/4HANA, aber es ist unwahrscheinlich, dass sich große Unternehmen dafür entscheiden werden. Dies ist aber hauptsächlich Ausdruck der komplexen Geschäftsprobleme, die mit SAP gelöst werden.

Ich habe über die Jahre mit vielen SAP-Kunden gesprochen und dabei vier Reifegrade herausgearbeitet. Die schlechte Nachricht: SAP DevOps führt schon so lange ein Schattendasein, dass die meisten Kunden über den ersten Grad nicht hinausgekommen sind. Die gute Nachricht: Wird man sich dessen erst einmal bewusst, lässt sich Abhilfe schaffen.

Grad 1: Reaktiv

Der erste Grad ist schnell erklärt. Es gibt ein Problem, das Problem macht sich in der Fachabteilung bemerkbar, es wird ein Ticket eröffnet und ein Mitglied des Betriebsteams macht sich auf die Fehlersuche. Das kann ganz abhängig von der Qualifikation des Mitarbeiters Minuten, Stunden aber auch Tage in Anspruch nehmen.

Veranschaulichen wir das. In einem Gespräch mit der SAP-Leiterin eines Fortune 100-Kunden sagte sie mir: „Ich möchte morgens nicht von meinem COO mit der Nachricht geweckt werden, dass wir unsere Produkte wegen eines SAP-Problems nicht ausliefern können.“ Dieses Problem betrifft also nicht nur kleinere Unternehmen.

Ein reaktives Unternehmen lässt sich daran erkennen, dass das Betriebsteam stets am Limit arbeitet. Erst vor Kurzem erhielt ich folgende E-Mail von einem Kunden: „Wir versuchen, ein Treffen mit unserem Basis-Team zu organisieren, aber sie sind durch unsere vielen Probleme zu beschäftigt.“

Wenn Ihr Betriebsteam ständig keine Zeit hat, ist es höchstwahrscheinlich reaktiv tätig.

Grad 2: Proaktiv

Ich hab vor Kurzem einen interessanten Artikel gelesen. Darin ging es um jemanden, der bereits seit fünf Jahren bei einem Unternehmen arbeitete, das ihn zur Erstellung von täglichen Berichten eingestellt hatte. Stattdessen schrieb er gleich in den ersten Wochen Excel-Makros. Diese sammelten an seiner Stelle die Daten, formatierten sie und versandten dann täglich zu einem zufällig gewählten Zeitpunkt zwischen 15:00 und 15:30 eine E-Mail mit dem Bericht. Er selbst verbrachte seinen Arbeitstag beim Surfen im Netz.

Vielleicht nicht unbedingt ein Paradebeispiel für gute Arbeitsmoral, aber auf jeden Fall ein Beispiel für einen Mitarbeiter, der seine Zeit proaktiv hätte einsetzen können.

Sie setzen in Ihren SAP-Umgebungen auf eine ganz ähnliche Methode? Dann wird es Zeit, proaktiv zu werden. So könnten Sie als einfaches Beispiel ein System implementieren, das erkennt, wenn eine Bankenschnittstelle ausgefallen ist. Dieses Wissen reicht schon aus, um sofort eine Warnmeldung mit einer Aufforderung zur Fehlerbehebung zu übermitteln. Mehr braucht es gar nicht, um dem Problem einen Schritt voraus zu sein, bevor die Kosten aus dem Ruder laufen.

Derartige Warnmeldungen sind aber auch mit Vorsicht zu genießen, denn viele Tools produzieren jeden Tag tausende unwichtige Meldungen. Das führt schnell zu einem Phänomen, das im Englischen als „Alert Fatigue“ bekannt ist: Verantwortliche werden mit Warnmeldungen geradezu überflutet und wissen sich nicht mehr anders zu helfen, als sie irgendwann schlicht zu ignorieren. Ein proaktives System sollte sich auf wirklich relevante Warnmeldungen beschränken.

Woran erkennen Sie, ob Sie bereits proaktiv vorgehen? Sie haben Zeit, mit Ihrem Team über die richtige Priorisierung von Projekten zu sprechen.

Grad 3: Automatisch

Ist der Übergang von reaktiv auf proaktiv erst einmal geschafft, können Kunden anfangen, sich mit dem Thema Automatisierung auseinanderzusetzen. Durch Automatisierung wird es möglich, eine Reihe von Aktionen automatisch ablaufen zu lassen.

Vor gut 15 Jahren machte sich ein Freund von mir daran, eine Reihe von Skripten zur automatischen Aktualisierung von 1.000 Oracle-Datenbankservern einer britischen Regierungsbehörde zu schreiben. Das Ergebnis? 1.000 ausgefallene Oracle-Datenbankserver.

Doch mittlerweile sind wir tatsächlich in der Lage, auch komplexere Szenarien zu automatisieren. Ein einfaches SAP-Szenario ist zum Beispiel die Automatisierung von Wartungsfenstern: Benutzer benachrichtigen, System sperren, System und alle abhängigen Systeme abschalten, Kernel aktualisieren, System wieder hochfahren und Plausibilitätsprüfungen abschließen.

Und das ist nur ein Beispiel von vielen.

Woran erkennen Sie, ob Sie bereits auf Automatisierung umgestiegen sind? Ihr Betriebsteam verbringt seine Zeit damit, Systeme zu beobachten, anstatt ständig auf der Tastatur zu tippen.

Grad 4: Selbstheilend

Oracle hat viel Aufhebens um die selbstheilenden Funktionen seiner Datenbanken gemacht. Das Vorgehen ist tatsächlich recht einfach und durch und durch sinnvoll: Man setzt auf Daten, um automatisierte Entscheidungen darüber zu treffen, was als nächstes zu tun ist. Programmieren lässt sich dies über KI-Verfahren (auch bekannt als Algorithmen).

Das könnte im Falle von SAP wie folgt aussehen: Wird ein Datenspeicher langsam zu voll? Handelt es sich dabei um den Datenspeicher, auf dem TemSe Spool-Daten speichert? Haben wir in letzter Zeit einen Job zur TemSe-Bereinigung laufen lassen? Nein? OK, dann sollten wir das jetzt tun. Ja? Dann sollten wir den Datenspeicher erweitern und den Verantwortlichen benachrichtigen.

Denken wir das Ganze noch einen Schritt weiter. Für SAP wurde ein kritischer Kernel-Patch veröffentlicht. Wurde der Patch auf allen Systemen eingespielt? Nein? Nutzen wir unsere automatisierten Abläufe, um ihn über Nacht automatisch auf allen Dev-/Test-Systemen zu installieren. Danach führen wir unsere automatischen Regressionstest durch, stoßen den Genehmigungsworkflow für die verantwortlichen Manager an und installieren das Update dann am Patch Tuesday auch auf den Produktivsystemen ganz automatisch.

Woran erkennen Sie, ob Ihre Systeme bereits selbstheilend sind? Ganz einfach, Ihr Betriebsteam treibt Innovationen voran, um die Selbstheilung und den Geschäftsbetrieb immer besser zu machen.

Fazit

Selbstheilende Unternehmen sind definitiv nur noch eine Frage der Zeit. Schon heute liegt dank PaaS und SaaS die Verantwortung für den Betrieb immer seltener beim Kunden. Für die Anbieter dieser Dienste geht es darum, die Betriebsabläufe immer einfacher zu machen und ihre Gewinnmargen zu steigern.

Glücklicherweise gelten proaktives Handeln und Automatisierung schon heute vielen CIOs als strategische Prioritäten, die durch Investitionen in Tools wie ServiceNOW und RedHat Ansible vorangetrieben werden. Unglücklicherweise wird SAP vielerorts aber immer noch als „Black Box“ wahrgenommen, was dazu führt, dass es bei derartigen Initiativen komplett außer Acht gelassen wird.