Dienstqualität verbessern, ohne die Innovation auszubremsen: die Herausforderungen des CSDO

Ich habe im Frühjahr 2017 als Chief Service Delivery Officer (CSDO) bei OVH angefangen. Daraufhin ist das gesamte Run-Team beim Vorstand erschienen, um die Qualität der bereitgestellten Dienste zu besprechen. Natürlich hatte dieses Thema in der Strategie von OVH schon vorher hohe Priorität. Mit Run wird in der Informatik die Ausführung einer Routine oder eines Programms bezeichnet. Im übertragenen Sinne bezeichnen wir bei OVH damit auch die Teams, die für die Industrialisierung zuständig sind und dafür, sämtliche vom Unternehmen angebotenen Dienste am Laufen zu halten, nachdem diese von unseren F&E-Teams entwickelt und nach der 1-10-100-1000-Regel getestet wurden. Das heißt, sie werden zuerst (meist intern) von einer kleinen Gruppe von Personen getestet, dann verbessert und in Form eines geschlossenen Beta-Tests für einige Kunden freigeschaltet (PoC), dann schließlich in einer öffentlichen Beta-Version in den OVH Labs... Das geht so lange, bis eine kritische Zahl von Anwendern erreicht ist, um so festzustellen, ob das Produkt einem echten Bedarf entspricht, und um die Bedingungen für die Industrialisierung zu erörtern.

Von links nach rechts: Dominique Michiels, Tammy Ledbetter, Boris Gougeon, Aurélien Daquino und Yaniv Fdida Industrialisierung: Herzstück des OVH Modells Wenn ein Dienst die verschiedenen Etappen störungsfrei durchläuft (bei Problemen wird er ins Ausgangsstadium zurückversetzt oder schlichtweg fallen gelassen), übergeben die Teams aus der Abteilung Forschung & Entwicklung an die Kollegen des Run-Teams. Diese sind dann für die Industrialisierung des Dienstes verantwortlich, d. h. dass alle Vorgänge möglichst automatisiert ablaufen sollen, um so die Notwendigkeit menschlicher Eingriffe bei Bereitstellung und Wartung zu minimieren. Diese spezielle Philosophie ist eine wichtige Besonderheit von OVH und trägt auch dazu bei, dass unsere Innovationen erschwinglich bleiben. Sie macht sie dabei auch zuverlässiger.

Allerdings ist die Arbeit des Run-Teams hier noch lange nicht erledigt. Wenn der Dienst geliefert wurde, ist Run dafür verantwortlich, Qualität, Stabilität und Kundenzufriedenheit sicherzustellen. Wenn nötig arbeitet das Team auch eng mit dem technischen Support zusammen an der Lösung von Störungen, und das immer mit dem gleichen Ziel: Industrialisierung. Dabei besteht das Ziel unserer Engineers nicht darin, eine Störung oberflächlich und möglichst einfach zu „fixen“, sondern sie wollen bis zur Root Cause vordringen und die Fehlfunktion direkt an der Wurzel beheben. Wenn ein Problem in dem einem Bereich auftritt, dann wird es mit hoher Wahrscheinlichkeit später auch woanders, in einem anderen Bereich auftauchen. Deshalb ist es besser, direkt die Ursache zu ermitteln, auch wenn es verführerisch ist, nur schnell zu „patchen“ – auf lange Sicht würde man damit aber eine schwer kontrollierbare Infrastruktur aufbauen, bei der die vielen Sonderfälle und Patches die Durchführung von Updates riskant oder sogar unmöglich machen würden. Ebenso wollen wir keine „Normal Errors“ mehr hinnehmen, also harmlose Fehler im Code. Diese sind nicht kritisch, weil schlussendlich jeder weiß, wie sie zu umgehen sind. Aber auch wenn sie einzeln betrachtet harmlos sind, können diese „Normal Errors“ insgesamt zu einem Risikofaktor werden. Jede für sich genommen scheinen diese Maßnahmen auf der Hand zu liegen.

Die eigentliche Herausforderung besteht aber darin, sie wirklich jeden Tag umzusetzen in einem Umfeld, in dem alles schnell geht, in dem die technologische Innovation das Tempo vorgibt. Eine hohe Dienstqualität gewährleisten Seit Ende 2017 hat sich das Team vergrößert und konzentriert sich auf die Stärkung unserer Grundlagen. Wir arbeiten eng zusammen mit dem Bereich Forschung & Entwicklung, der die technische Gesamtausrichtung vorgibt, mit der Abteilung Customer Care, die den Kundensupport managt, und mit der Produktion, die unsere Rechenzentren aufbaut und wartet, in denen die Dienste betrieben werden. Auch wenn die Verfügbarkeitsrate unserer Dienste im Gesamtschnitt schon bei 99,996 % liegt, müssen wir uns trotzdem noch in einigen Punkten verbessern. Zuerst einmal müssen wir bei der Analyse früherer Störungen ausreichend in die Tiefe gehen und dabei gleichzeitig das Wachstum unterstützen, für das es per definitionem ungünstig ist, einen Schritt zurück zu gehen. Genau wie es in anderen Branchen, etwa der Automobilindustrie, üblich ist, müssen wir jegliche Störungen und ihren Ursprung langfristig beobachten und unsere Schwachstellen sachlich identifizieren. Deshalb führen wir systematisch umfassende Post-mortem-Analysen durch, um die Ursache von Störungen, deren Lösung und Verbesserungsmaßnahmen zur Vermeidung einer Wiederholung zu ermitteln.

Dabei sind Letztere das Ergebnis der engen Zusammenarbeit aller betroffenen Teams. Parallel dazu haben wir für alle verwalteten technischen Bereiche ein System zur Erfassung technischer Kennzahlen eingerichtet. Die so erfassten Daten werden in einem Data Lake gesammelt, um die positiven Effekte von durch die CSDO-Abteilung durchgeführten Maßnahmen anhand von Trendanalysen sichtbar zu machen. Insbesondere haben wir die betrieblichen Abläufe in den Rechenzentren angepasst, um die Wiederherstellungszeit (MTTR) zu reduzieren. Alle diese Schritte sind Teil eines größeren Plans, der darin besteht, einen Katalog von Best Practices für die Verwaltung unserer Infrastrukturen auf Grundlage des ITIL-Modells einzurichten. Bald werden wir sehen, wie OVH ITIL in einer agilen Umgebung umsetzt.