DevOps-Guidelines

Wir freuen uns, ein weiteres erfolgreich abgeschlossenes Projekt vorstellen zu können: Die Erstellung von DevOps-Guidelines für die Basler Verkehrs-Betriebe (BVB). Im Rahmen des Beratungsmandates war es unsere Aufgabe, eine effiziente und agile Umgebung für die Softwareentwicklung und Bereitstellung (DevOps) zu schaffen, die den Bedürfnissen der BVB entspricht.

Die Analyse der IT-Landschaft der BVB wurde in drei Abschnitte unterteilt, um einerseits einen vollständigen Überblick über den aktuellen Zustand (IST-Zustand) zu erhalten und andererseits einen klaren Zielzustand (SOLL-Zustand) zu definieren, auf dessen Grundlage die Guidelines erarbeitet werden konnten.

Im ersten Abschnitt wurden mehrere Meetings und Workshops sowie Besprechungen durchgeführt, um die internen IT-Systeme der BVB, ihre Anforderungen und Ziele zu verstehen. In enger Zusammenarbeit mit der BVB wurde der gewünschte SOLL-Zustand für die IT-Infrastruktur festgelegt. Atticode erhielt dabei einen ganzheitlichen Blick auf die aktuelle IT-Organisation, um den Aufwand und die Kriterien für die Guidelines bestmöglich einschätzen zu können.

Im zweiten Abschnitt wurden weitere Workshops, Analysen, Interviews und Betriebsbesichtigungen durchgeführt, um zusätzliche Daten zusammenzutragen und ein möglichst detailliertes Bild des momentanen IST-Zustandes zu erhalten. Die acht Phasen des DevOps-Lifecycles (Planung, Code, Build, Test, Release, Deploy, Operate und Monitoring) wurden innerhalb der BVB isoliert untersucht und abhängig von den Anforderungen unterschiedlich detailliert beschrieben. Auf diese Weise konnte der aktuelle Zustand der IT-Landschaft als Ganzes relativ genau erfasst werden.

Im dritten Abschnitt wurde nun das geplante Ergebnis erarbeitet. Das entstandene Dokument enthält Systemanalyse, Risikobewertung sowie Richtlinien und Empfehlungen inklusive umfangreichem Massnahmekatalog, um eine erfolgreiche Transformation in den SOLL-Zustand zu gewährleisten. Das Dokument ist modular aufgebaut und mit grafischen Ausdrucksformen versehen, um die Guidelines kurz, prägnant und selbsterklärend zu gestalten.

Unser Ziel war es, der BVB ein effizientes Werkzeug für die Umsetzung einer standardisierten jedoch dynamischen DevOps-Umgebung zur Verfügung zu stellen. Das Dokument beschreibt Richtlinien, Workflows, Tools, Technologien, Prozesse, Rollen usw. nach Best-Practice der IT-Industrie als ganzheitliches und agiles Vorgehensmodell für den DevOps-Lifecycle der BVB. Die Guidelines sind so aufgebaut, dass sie gemäss dem DRY- («Don’t repeat yourself») und KISS-Prinzip («Keep it simple (and) stupid») aus der Softwareentwicklung einfach und praktisch anwendbar sind. Unsere Experten haben ihr Wissen und ihre Erfahrung genutzt, um sicherzustellen, dass die BVB die besten DevOps-Praktiken implementieren und so ihren Software-Entwicklungsprozess optimieren können.

DevOps ist eine Kombination aus "Development" (Entwicklung) und "Operations" (Betrieb), die eine agile und kollaborative Herangehensweise an die IT-Entwicklung und -Betriebsführung darstellt. DevOps zielt darauf ab, die Entwicklung und Bereitstellung von Software zu beschleunigen, indem die Zusammenarbeit und Kommunikation zwischen Entwicklern und Betriebsführern verbessert wird.

Traditionell arbeiten Entwickler und Betriebsführer getrennt voneinander und haben unterschiedliche Ziele und Prioritäten. DevOps versucht, diese Lücke zu schliessen, indem es den Entwicklungs- und Bereitstellungsprozess durch Automatisierung und Standardisierung optimiert und so sicherstellt, dass Software schneller und zuverlässiger bereitgestellt werden kann.

DevOps beinhaltet eine Kombination aus kulturellen, organisatorischen und technischen Veränderungen. Dazu gehören unter anderem kontinuierliche Integration, kontinuierliche Bereitstellung, Testautomatisierung, Infrastrukturautomatisierung und eine verbesserte Zusammenarbeit zwischen den verschiedenen Teams in einem Unternehmen. Die DevOps-Philosophie ist ein wichtiger Bestandteil der IT-Industrie und wird von vielen Unternehmen eingesetzt, um die Effizienz und Qualität ihrer DevOps-Pipeline zu verbessern.

Die DevOps-Philosophie hat in den letzten Jahren in der IT-Branche stark an Bedeutung gewonnen. Bei der Einführung dieser agilen Methode müssen jedoch viele Entscheidungen getroffen werden, die den Erfolg eines DevOps-Projekts beeinflussen können. Atticode hat sich darauf spezialisiert, Unternehmen dabei zu unterstützen, den optimalen DevOps-Lifecycle zu finden und umzusetzen.

Unsere Argumentation für die Bewertung der internen IT-Landschaft basiert auf dem GAMAB-Prinzip zur Risikominimierung. GAMAB steht für "Globalement au moins aussi bon" (generell mindestens so gut) und besagt, dass das Risiko eines neuen Systems mindestens so sicher bzw. risikoarm sein sollte wie das eines bereits existierenden vergleichbaren Systems. Dieses Prinzip setzt den derzeitigen Sicherheitsstandard als Mindestanforderung fest. Neue Systeme müssen diesen Standard mindestens erfüllen oder sogar übertreffen. Es geht davon aus, dass das Risiko eines vergleichbaren Produktivsystems als akzeptiert gilt und ist damit ein intuitives, aber auch gebräuchliches Risikoakzeptanzkriterium. Interessanterweise ist GAMAB im Wesentlichen dasselbe wie Best Practice, auf das wir schliesslich aufbauen wollen.

Weiterhin ist zu bemerken, dass bei der Implementierung von IT-Systemen zunehmend Methoden des Risikomanagements eingesetzt werden, um der Komplexität und der damit verbundenen Fehleranfälligkeit von Software-Produkten gerecht zu werden. Aspekte des Risikomanagements sollten über die gesamte DevOps-Pipeline hinweg berücksichtigt werden, von der Planung und Entwicklung bis hin zum Monitoring des Systems.

Unser Ziel ist jedoch nicht, ein vollständiges Risikomanagement durchzuführen. Vielmehr möchten wir den Ansatz der Risikobeurteilung teilweise anwenden und uns dabei an den Prozessen der Risikoidentifikation, -analyse und -bewertung orientieren.

Unsere Risikobeurteilung zielt darauf ab, Abweichungen vom Best-Practice-DevOps-Ansatz zu ermitteln. Dabei geht es darum, festzustellen, wie gross die Unterschiede zwischen einer vollständig umgesetzten DevOps-Pipeline und den Prozessen, Tools und Technologien im Bereich der Software-Entwicklung und des Betriebs sind. Diese Abweichungen können als Indikatoren für Risiken betrachtet und dazu verwendet werden, den Handlungsbedarf in den jeweiligen IT-Bereichen zu definieren. Denn je grösser die Differenz zur Best-Practice ist, desto näher ist ein System dem Bereich der "Worst Practice" und damit einem höheren Risiko für technische, personelle und finanzielle Schwierigkeiten ausgesetzt.

Mit anderen Worten nutzen wir Best-Practice aus dem DevOps-Bereich als Standard und bestimmen die Differenz zur spezifischen DevOps-Umsetzung innerhalb des Betriebs. Damit kann das aktuelle Risiko bewertet werden und es ist gleichzeitig bekannt, welche Schritte zum Standard noch fehlen um das Risiko optimal zu minimieren.

Best-Practice ist die allgemeine Bezeichnung für die beste existierende Lösung eines Problems. In der Betriebswirtschaft steht der Begriff im Zusammenhang mit Benchmarking und bezeichnet das pragmatische Vorgehen, systematisch von den vorhandenen Erfahrungen anderer, erfolgreicherer Organisationen zu profitieren, indem deren Lösungsansatz (ihre "Best-Practice") zur Verbesserung der eigenen Prozesse oder Produkte genutzt wird.

Wenn bewährte Methoden nicht ohne weiteres auf die bestehenden Gegebenheiten eines Unternehmens anwendbar sind, können die wichtigsten Elemente der Best-Practice auch nur teilweise übernommen und mit den vorhandenen Prozessen in Einklang gebracht werden. Bei der Verwendung von Best-Practice muss das Rad nicht neu erfunden werden, sondern vorhandene Lösungsansätze können einfach übernommen werden.

Im letzten Jahrzehnt hat sich auch im IT-Bereich eine Best-Practice für Softwareentwicklung und -Betrieb etabliert. Die Evolution von agilen Methoden hat gezeigt, dass Unternehmen mit einer holistischen Sicht auf ihren komplexen Software-Lifecycle erfolgreicher sind als die Konkurrenz. Daraus ist der DevOps-Ansatz hervorgegangen, der mittlerweile nicht mehr nur Best-Practice, sondern der de facto-Standard erfolgreicher Softwareunternehmen ist.

Da die IT als sehr schnelllebiger Bereich gilt, werden State-Of-The-Art-Technologien entsprechend schnell in die Best-Practice übernommen. Durch das hohe Tempo bei der Weiterentwicklung des IT-Bereichs entstehen jedoch auch viele Trends und Hypes, die sich später als Irrwege erweisen können. Gerade "Early Adopter" müssen daher darauf achten, keine vermeintlichen Best-Practice zu adaptieren. Nach einer gewissen Zeitspanne können jedoch anhaltende IT-Trends mit Sicherheit als "Good Practice" betrachtet werden.

Nachdem unsere Experten eine detaillierte Analyse des IST-Zustands der IT-Systemlandschaft durchgeführt haben, wurde diese in drei Bereiche aufgeteilt: Wir nennen sie exemplarisch Internet of Things (IoT), Cloud Computing und Machine Learning. Jeder Bereich wurde weiter nach 13 spezifischen Kriterien bewertet. Dazu gehören Kriterien wie Fehlerquote, Technologie, Nutzerzufriedenheit, Security, Ausfallrate, Wartbarkeit, Monitoring und Skalierbarkeit usw. Nach der Auswertung konnten wir allfälligen Handlungsbedarf definieren und Empfehlungen für die jeweiligen Bereichen festlegen.

Daraufhin haben wir ein umfassendes Massnahmepaket zur Transformation der IT-Landschaft erstellt. Hierbei haben wir uns an Best-Practice und DevOps-Methoden orientiert und spezifische technische Empfehlungen zu den 13 Bewertungspunkten gegeben. Unsere Empfehlungen sind spezifisch auf die BVB zugeschnitten. Wir haben Tools, Technologien und Methoden empfohlen und eine ausführliche DevOps-Checkliste für interne Software-Projekte erstellt. Dabei haben wir offene DevOps-Guidelines verwendet, um flexibel auf zukünftige Veränderungen reagieren zu können.

Nebst dem umfangreichen Massnahmekatalog (inklusive vorgeschlagenem Handlungsbedarf für die 13 Bereiche) haben wir generell die Überführung in eine Microservice-Architektur, Datenflussoptimierungen und Behandlung drohender Legacy-Probleme empfohlen. Ausserdem haben wir durch die Identifikation und Dokumentation von kritischen Systemen dazu beigetragen, das Bewusstsein für deren Schutz zu schärfen. Die detaillierten Ergebnisse können aus Gründen der Vertraulichkeit nicht bekannt gegeben werden.

Die Guidelines von Atticode sind schlussendlich ein modularer DevOps-Baukasten, der als Empfehlung, nicht aber als Vorschrift verstanden werden darf. Die Flexibilität der Agilen-Prinzipien steht dabei im Vordergrund. Atticode bietet somit Unternehmen eine ideale Lösung, um DevOps-Lifecycles zu optimieren und Projekte erfolgreich umzusetzen.

Wir bei Atticode sind überzeugt davon, dass die Erstellung von DevOps-Guidelines ein entscheidender Schritt ist, um die Qualität und Effizienz der Softwareentwicklung zu steigern und die Agilität von Unternehmen zu erhöhen. Wir freuen uns, Teil dieses Prozesses zu sein und den Basler Verkehrs-Betrieben geholfen zu haben, das Potenzial ihrer ICT-Systeme weiter zu entfalten.

Wenn Sie auch auf der Suche nach Experten sind, die Ihnen helfen können, Ihre IT-Landschaft in eine zukunftsorientierte, standardisierte und risikominimierte Umgebung zu transformieren, dann kontaktieren Sie uns gerne.