DevOps – Grundlegende Fehler in bestehenden Prozessen

Natürlich – ihr wollt sofort wissen, was denn nun die 5 spannenden Tipps sind, die goldenen Regeln, das Salz in der Suppe, das große Geheimnis. Verstehen wir. Damit aber verstehen können, was richtig ist, müssen wir auch wissen, was falsch sein könnte – auch in Unternehmen und DevOps Teams, die sonst (fast) alles richtig machen.

Grundsätzlich für das Verständnis nötig ist der Gedanke, dass DevOps einerseits aus einem Entwicklerteam besteht, den „Devs“, und dem für die Operations zuständigen Team, den „DevOps“. Letztere stellen beispielsweise sicher, dass Software-Implementierungen vorgenommen, Supportanfragen gelöst, Optimierungen entwickelt und umgesetzt werden. Die Entwickler wiederum, nun, entwickeln – und das durchaus nach unterschiedlichen Maßstäben. Wo manche Entwickler komplexe Algorithmen schreiben, die zwar funktionieren, aber mäßig dokumentiert sind, entsteht bereits Fragebedarf zwischen zwei sonst eng kooperierenden Teilen des DevOps-Teams. Entwickelt der Developer beispielsweise einen Teil der finalen Software, hat aber keinen festen Prozess für den Umgang damit parallel entwickelt, kann es für das DevOps-Team schwierig werden, bei einer eingehenden Supportanfrage durch z.B. einen User, eine auf einem Prozess beruhende, klar definierte Lösung zu vermitteln – was Zeit, Effizienz und letztlich auch Ressourcen kostet, oftmals zu Lasten des End Users, den wir idealerweise zufriedenstellen wollen.  So können auch in routinierten und erfolgreichen DevOps-Teams Fehlerquellen entstehen, die nicht nur Aufwand verursachen und den geplanten ROI verwässern können (mehr Projekttage, mehr Personaleinsatz, mehr Ressourcenbedarf), sondern auch bei der Überführung von Legacy-Projekten in moderne Infrastruktur Folgefehler erzeugen können. Das bringt uns zu unserem ersten Tipp:

DevOps: Folge der Pipeline!

Ein starker USP sind also „Prozess-Pipelines“, in denen von Anfang bis Ende festgelegt ist, wie die entwickelte Software zu nutzen ist, in der Fehler ausführlich dokumentiert werden (und aus denen Handlungen abgeleitet werden können) sowie die Sicht des Users berücksichtigen. Dies ist ein elementarer Tipp für euch, der selbst in routinierten und großen DevOps-Teams nicht immer eingehalten wird. Gestaltet eure Prozesse von Beginn an sauber, eindeutig und gering interpretierbar, damit das Operations-Team aufkommende Probleme effizient und wiederholbar lösen kann. Nur so können Fehler schnell identifiziert und Vorgänge optimiert werden. Schluss mit individueller Aufarbeitung von Fehlertickets, Bahn frei für saubere Prozessgestaltung, aus der Rückschlüsse gewonnen werden können. Teilt eure Fehler in Level auf:

• Level 1 für klare, einfache Anfragen („Wo finde ich meinen Login? Wie kann ich den ändern?“), die das Operations-Team problemlos lösen kann.
• Level 2 für technische Anfragen, die Server, das Publishing oder die Infrastruktur betreffen, die das Operations-Team bisweilen allein oder bei Bedarf im Zusammenspiel mit dem Dev-Team beheben kann.
• Level 3 für Punkte, die noch keinen sauberen Prozess haben – das geht an die Entwickler, die das Problem lösen, sauber dokumentieren und daraus einen Prozess ableiten, der wiederum für künftige Fragen als Leitfaden dient.

Die Zeiten, in denen fähige Mitarbeiter nur auf eingehende Tickets warten, um diese und vergleichbare Tickets akribisch nach Lösungen zu durchsuchen, sind definitiv Vergangenheit.

DevOps: Behalte die Zukunft im Blick!

Wer kennt das nicht? Ein tolles Kundenprojekt mit großem Umfang, und mit Begeisterung zeigen euch die Stakeholder den Serverraum. Riesige, physische Rechner mit 16 Kernen und 128 GB RAM, richtige Könner sind das, nice. Alle User verbinden und tummeln sich mit uns auf diesen Rechnern, Kapazitäten werden genutzt, ausgelassen, ausgeschöpft. Und dann stürmen mehr User als erwartet den Rechner, und selbst die 128 GB im Server gehen in die Knie. Die Folge: Ruckelige Software, lange Ladezeiten, Unzufriedenheit. Eine Lösung könnte sein, mehr Serverkapazitäten zu schaffen, Rechner zu kaufen oder mehr Platz im Rechenzentrum anzumieten. Und dann zeigt das Monitoring, dass die Server nachts um 3 Uhr praktisch leer sind. Den Carbon Footprint – und den Geldbeutel der Unternehmen – interessiert das nicht, die On-Premise-Server ziehen Strom und arbeiten, auch wenn der Ansturm nachgelassen hat. Und das Problem? Das ist nicht mal dauerhaft gelöst, es ist nur teurer geworden – denn die neue Hardware schafft nun auch 15.000 User, statt der 10.000, die den Server eben noch lahmgelegt haben. Wenn nun aber 30.000 kommen, stehen Team und Auftraggeber vor dem gleichen Problem.

Im Rahmen des gesamtheitlichen Ansatzes starker DevOps-Teams ist der Blick nach vorne daher unerlässlich, und der zeigt deutlich auf, dass „die Cloud“ (also in der Regel die Platzhirsche AWS und Azure) ein unumgänglicher Lösungsansatz ist. Dabei gilt es aber, clever vorzugehen, statt schnell, wie auch Paul Hammond von Cognizant in seinem Artikel zur smarten Cloudmigration erklärt. Schließlich ändert sich die Infrastruktur, die gesamte Systemarchitektur der Cloud enorm, und das Buchen falscher oder überschüssiger Leistung in der Cloud ist schnell passiert – und stellt den ROI aufs Abstellgleis. Viele Kunden zeigen sich überrascht von den Kosten, die eine Cloud verursachen kann.

Liegt der Migration indes eine Strategie zugrunde, die auf die Erfordernisse des Projekts zugeschnitten ist, kann diese dringende Probleme lösen. Rechenkapazität kann on demand gebucht werden – nachts um 3 benötigen wir keine Server, mittags um 12 brauchen wir zwanzig Stück? Kein Problem in einer immer modularer und individueller werdenden Cloud. Statt 100 Server zu kaufen, die nur im Extremfall gebraucht werden, kann benötigte Rechenleistung gebucht werden, die immer dann einsetzt, wenn sie benötigt wird – und in den übrigen Zeiten keine Ressourcen verbraucht sowie oft klimaneutral arbeiten kann (was sich problemlos in eine Erfolgsbilanz einkalkulieren lässt).

Sicher – auch DevOps-Teams müssen etwaige Hindernisse bedenken. Einen Lock-In-Effekt gilt es zu vermeiden, bei dem sich Unternehmen von Einzel-Anbietern abhängig machen, es benötigt Phasen und Konzepte, auch für die Zeit nach der Migration, wenn der DevOps-Alltag wieder eingetreten ist. Prozesse, Baby, nicht vergessen – oder einen Schritt zurück zu Tipp 1.

DevOps – Es gibt kein Team ohne Team

Freilich – dass man Teams stärken muss, ist kein Geheimnis. Mitarbeiter gut behandeln, fair bezahlen, auf Augenhöhe teilhaben lassen, Expertise abfragen, alles Brot und Butter. Doch auch die Qualität der Arbeitsleistung ist relevant, vor allem, was deren Zukunftssicherheit angeht, und dies ist Aufgabe der Arbeitgeber: Mit dem Wandel in der Branche – ein Beispiel wäre die Migration von physischer Hardware in die Cloud – entstehen auch neue Herausforderungen. Wer nur On-Premise-Hardware einsetzt, muss sich keine Gedanken über Docker oder Kubernetes machen oder diese Technologien kompetent einsetzen. Wer in die Cloud möchte, sollte seine DevOps-Teams darin schulen lassen. Wer modern arbeiten möchte, wer althergebrachte Systemarchitekturen hinter sich lassen und mit echtem Long Term Business Value arbeiten mag, kommt nicht umhin, das Knowledge im Team stets up do date zu halten. Ein scheinbar einfacher Tipp, aber noch immer arbeiten viele DevOps-Teams in physischen Umgebungen und sind von neuen Tasks mitunter überfordert. Auch das lässt sich zwar fast immer auf mangelnde Prozesse und Strategien zurückführen, aber auch das Aktivieren, Weiterbilden und Motivieren der Mitarbeiter ist für DevOps elementar. Alle Teile der Prozesskette müssen hochfunktional sein oder werden sich alternativ immer am schwächsten Glied der Kette orientieren.

Kenne deine Infrastruktur – und mach sie mit DevSecOps sicher!

Vor dem Projekt ist nach dem Projekt – und hierbei geht es gar nicht um wirtschaftliche Aspekte wie einfach nur nachfolgende Aufträge, oder um Lessons Learned. Um ein Projekt zum erfolgreichen Abschluss zu bringen und um sich aus der DevOps Landschaft hervorzutun, ist die Kenntnis der auf das Team zukommenden Infrastruktur unerlässlich. Denn die gesamte Entwicklungsumgebung muss nicht nur so produktiv wie möglich sein: Sie muss auch so sicher sein wie möglich. Der Begriff „DevSecOps“ (der nun also „Development“, „Security“ und „Operations“ vereint) ist daher auf dem Vormarsch und soll helfen, Testing, E-Testing, Integration und ähnlich wichtige Teilbereiche rundum abzusichern, und zwar schon in der Pipeline. Sicher (no pun intended): Das Testen direkt im Build wird auch weiterhin praktiziert werden und kann auch seine Berechtigung haben, aber wie bereits festgestellt, ist die Integration des Testings in die Prozess-Pipeline nicht nur effektiver, sondern eben auch sicherer. Problemstellungen lassen sich so früher erkennen und innerhalb der DevOps-Landschaft und der vorgegebenen Prozesse lösen – das spart Zeit, Nerven und Kosten.

Die Infrastruktur betreffend liest sich die Geschichte ähnlich: Wo der Output grundsätzlich unterschiedlich ist und sich mit Infrastruktur-Mustern und Libraries befasst, mit Server-Builds, auf denen mitunter dediziert getestet wird, lassen sich dennoch Vorgehens-Templates erstellen. Arbeiten nun also weitere Entwickler auch auf einer dedizierten, außerhalb der Prozess-Pipeline liegenden (Server-)Landschaft, lassen sich dennoch gemeinsame Ressourcen und Prozesse nutzen und sicher gestalten. Die Optimierung solcher Vorgehensmethoden erfordert eine hohe Kenntnis der Infrastruktur-Muster: Soll das Projekt in eine Hyperscaler-Umgebung wie Azure oder AWS migrieren (und die Gefahr eines Lock-Ins mit sich bringen), oder wäre das Terraforming des Projekts in eine unabhängige System-Landschaft eine Lösung? Entscheidungen, die langfristig Effizienz und somit auch den Kosteneinsatz optimieren können.

Ein Wort noch zum Buzzword „DevSecOps“: Das Erschaffen einer sicheren Entwicklungsumgebung kann aufwendig sein, und das freie Testing mitunter erschweren. Ist aber das Tooling aber von Beginn an secure integriert, sind die Apps der Anbieter schon von Beginn an darauf ausgerichtet (Anbieter wie IBM bieten hierzu spezielle Leistungspakete an). DevSecOps ist also kein komplett neuer Ansatz in Sachen Sicherheit, der herkömmliche DevOps Projekte als „unsicher“ brandmarkt. Es ist eher ein Label, ein Standard, der schon im Code beginnt, in der kompletten Pipeline-Absicherung endet und das Zünglein an der Waage bildet. Sind die gesamte Toolchain und Testlandschaft vollständig abgesichert, trägt dies zu einem sicheren und rundum getesteten Endprodukt bei –ist aber auch meist eine Frage des Budgets und der spezifischen Vorstellung des Auftraggebers. Ebenfalls hervorzuheben ist, dass sich unser Artikel auf die Automotive-Branche bezieht. In Bereichen wie dem Finanzsektor oder dem Gesundheitswesen ist der Sicherheitsstandard auch in klassischen DevOps Projekten bereits so hoch, dass kein separates DevSecOps erforderlich ist. In der Automobilbranche verhält sich dies insofern anders, als dass Regularien wie die UN ECE R155 (und 156) erfordern und somit begünstigen, dass Sicherheitsaspekte von Tag 1 an von höchster Wichtigkeit sind, eine Entwicklung nach DevSecOps Standard also zu bevorzugen ist.

Der beste Tipp von allen: Denke von Beginn an die Core Ability deiner Lösung – und bewege sie

Da ist es wieder: Die besten Tipps sind oft die ganz einfachen, und ist es nicht erstaunlich, wie oft genau diese einfachen Grundregeln außer Acht gelassen werden? Bereits vor dem ersten Buchstaben, der in jeglichen Code getippt wird, muss natürlich klar sein, welches Produkt, welche Lösung am Ende des Projekts stehen soll. Doch was soll diese können? Was ist der besondere Punkt, was soll besonders gut abgewickelt werden, und wie erreichen wir das? Jedes Mal, bei jedem Problem, jeder Anwendung?

Hier beobachten wir im Rahmen der vielen Cognizant Mobility Projekte, aus denen unsere Ansprechpartner aus den Fachabteilungen berichteten, einen gewissen Lock-In-Effekt, der sich indes gar nicht nur auf die technische Projektlandschaft bezieht und sich einer Beantwortung mit „Open Source ist die Lösung“ entzieht. Vielmehr ist es eine Art Tunnelblick, ein Fokus auf die Lösung des nächsten kleinen Schritts, des Baus der nächsten Pipeline, der Entwicklung des nächsten Stückchen Codes bis zum kommenden Sprint Meeting. Oft sind DevOps Entwickler konzentriert und voll im Fokus auf das nächste Stück der Anwendung, so dass das große Ganze, die Bewegungsfähigkeit des Endprodukts ein wenig aus den Augen geraten kann. Für jedes Team, ob erfahren oder neu in der Projektwelt, ist es daher unerlässlich, sich immer wieder gemeinsam zu fragen? Was bauen wir, wofür? Eine neue Anwendung, einen neuen Container? Können wir diesen wieder verwenden, womöglich sogar in anderen Projekten, Stichwort Low Code / No Code? Und wie können wir die fertige App optimal einsetzen? Können wir diese beispielsweise komplett fertig bauen und entwickeln, und wird sie genauso gut funktionieren, wenn wir sie umziehen? Eine Anwendung in einer bestimmten Umgebung zu bauen und sie später in AWS oder TCP shiften zu können, ist eine Kernkompetenz. Können wir in Kubernetes programmieren und unser systemisches Öko-System darum aufbauen? Diese Frage zu beantworten sollte zu den Kernfähigkeiten dynamischer Entwicklungs-Teams gehören, um Projekte langfristig effektiv zu halten und somit auch Alleinstellung auf einem wachsenden Markt zu generieren. Zusätzlich sollten wir erwähnen, dass dies kein seltenes „“What If“ Szenario ist – Anwendungen ziehen um, häufig, zwischen verschiedenen Anbietern und Systemlandschaften. Populär ist sicherlich von On-Premise in die Cloud, aber auch andersherum kennt man, ebenso wie das Bauen vollständig eigener Open Source Lösungen oder Hybrid-Projekte; weshalb wir die Teameigenschaft zur Kenntnis der plattformunabhängigen Lösungsfähigkeit der Anwendung oder des Produkts als finalen, goldenen Tipp empfehlen, den ihr unbedingt beachten solltet.

DevOps – Das Fazit: Lass doch mal reden

Mit unseren 5 goldenen Regeln für erfolgreiche DevOps Projekte öffnen wir den Blick auf eine umfangreiche und komplexe Entwicklungsarchitektur und geben euch Denkanstöße an die Hand, die ihr auf eure eigenen Projekte anwenden könnt. Die Reihenfolge erschien uns sinnvoll, indes, Prioritäten können unterschiedlich sein. Vielleicht sind alle Tipps für euch effektiv, vielleicht dreht ihr aber auch erstmal an kleineren Stellschrauben. Vor allem große Projektteams sind oft in bestehenden Methoden und Prozessen ein wenig eingefahren, und hier ist es eher die behutsame Hand, die Erfolge nach und nach erzielt, statt eilig viele Dinge zu ändern. DevOps ist stets ein Organismus, der in sich funktional bleiben muss, um funktionieren zu können, und wie in jedem effizienten Öko-System geht sinnvolle Evolution langsam vonstatten.

Meldet euch gerne bei uns über das Kontaktformular auf dem Blog oder unserer Firmenwebsite, schreibt uns einen netten Kommentar bei LinkedIn oder schickt uns eine E-Mail, wenn ihr Fragen habt, Anregungen – oder über euer nächstes Dev(Sec)Ops Projekt mit uns sprechen mögt: Wir freuen uns auf euch!