Das Problem mit DevSecOps ... eine Geschichte von Drachen, Bränden und Bussen

Wir kennen die vielen Vorteile von DevSecOps. Wenn es um den Lebenszyklus der Entwicklung geht, sind die DevSecOps-Prinzipien und -Praktiken sehr gefragt. Aber obwohl es leicht ist, sie zu preisen, stimmt etwas nicht in der Welt von DevSecOps: Es sollte einfacher sein.

Drachen (hier sein)

Die Unternehmen rennen um die Wette, um die Vorteile von DevSecOps zu nutzen. Bei diesem Wettlauf stoßen viele Unternehmen jedoch auf eine Menge organisatorischer Reibungen, wenn sie versuchen, DevSecOps zu integrieren und erfolgreich einen Mehrwert zu schaffen.

Ein erstes Problem ist, dass es bei DevSecOps nicht nur um Technologie geht und dass es keinen klaren Fahrplan gibt. Wer sich auf diese Reise begibt, ohne die richtige Einstellung und vielleicht einen sachkundigen Führer zu haben, findet sich schnell in unbekannten, manchmal gefährlichen Gewässern wieder. Die zunehmende Komplexität  Landschaft der DevSecOps-Werkzeuge veranschaulicht, wie leicht man sich zu Beginn des DevSecOps-Abenteuers verirren kann.

Brände

Der Weg zu DevSecOps kann tückisch sein und eine Vielzahl von Hindernissen mit sich bringen. Wo es Drachen gibt, gibt es mit Sicherheit auch Feuer, und diese Brände können sich auf den Gewinn auswirken. Ohne die richtige Planung, die richtigen Tools oder das richtige Personal sind Unternehmen nicht darauf vorbereitet, die entstehenden Brände zu bekämpfen:

• "Die Produktion wurde eingestellt, und wir wissen nicht, wann und warum!"
• "Widersprüchliche Migrationen jagen sich gegenseitig durch den Master-Datenbankring und verhindern die Lesereplikation so lange, dass unsere Caches ablaufen und die Inhalte auf keiner unserer Websites bereitgestellt werden können.
• "Eine Fehlerkorrektur, die zwei Minuten dauern sollte, brauchte vier Tage, um in Produktion zu gehen.
• "Die Bereitstellung hing von einer Datenbankmigration ab, die in der Datenbank der QA-Umgebung erfolgreich war, aber die SQL-Migration scheiterte in der Produktion aufgrund von Datenspezifika, so dass die Dinge in einem schlechten Zustand waren.

Brände können jederzeit und aus einer Vielzahl von Gründen entstehen. Aber das Vertrauen der Kunden in ein Produkt oder in das Unternehmen als Ganzes geht in Flammen auf, wenn ein Unternehmen schlecht für die Brandbekämpfung gerüstet ist. Der Ausbruch von Bränden oder auch nur die Gefahr von Bränden kann ausreichen, um das Vertrauen eines Unternehmens in den DevSecOps-Umwandlungsprozess zu erschüttern. Daher ist es absolut wichtig, dass das gesamte Unternehmen an Bord ist und sich langfristig engagiert. Es ist von entscheidender Bedeutung, dass die Erwartungen von Beginn des Projekts an gesteuert werden. Und wenn kleine Feuer ausbrechen, müssen zimperliche Stakeholder vielleicht daran erinnert werden: "Keine Sorge, wir haben Sie gewarnt, dass dies passieren könnte, es ist alles Teil des Prozesses."

Busse

Qualifizierte DevSecOps-Experten sind sehr gefragt, so dass es einen Mangel an qualifizierten Talenten gibt. Leider hat dies dazu geführt, dass DevSecOps-Teams manchmal vor dem Rest der technischen Organisation "geschützt" und, schlimmer noch, isoliert werden mussten. Was eigentlich ein hoch integrierter agiler Teamansatz mit gemeinsamer Verantwortung hätte sein sollen, wurde einfach aus dem Fenster geworfen, oder besser gesagt, über den Zaun geworfen. Das klingt sehr nach der Saga von Software Engineering vs. IT-Infrastruktur.

Da es immer schwieriger wird, qualifiziertes Personal zu finden, sind Unternehmen auf der Suche nach DevSecOps gezwungen, sich ernsthafte Gedanken über die Bus-Faktor. Führungskräfte und andere Beteiligte befinden sich in der stressigen Situation, dass sie komplexe Szenarien in Betracht ziehen und angehen müssen:

• "Wenn unser einziger Ingenieur, der sich mit diesen Dingen auskennt, uns verlässt, sind wir am Ende."
• "Tut mir leid. Joanna kümmert sich darum, und sie ist derzeit im Urlaub. Sie werden warten müssen, bis sie zurückkommt."
• "Es ist weder dokumentiert noch automatisiert, also müssen Sie wohl den Code durchgehen und es selbst herausfinden."

Und was machen Sie?

Der Beginn einer DevSecOps-Reise kann entmutigend sein. Aber wie bei allen großen Abenteuern ist die richtige Planung der Schlüssel zum Erfolg. Und für diejenigen, die sich bereits mit großen Ambitionen auf diese Reise begeben haben, aber einen wichtigen DevSecOps-Ingenieur verloren haben und durch den Busfaktor aufgehalten werden, können Sie Schritte unternehmen, um wieder auf den richtigen Weg zu kommen.

Bevor Sie beginnen, sollten Sie sich Zeit nehmen, um das Gesamtbild zu analysieren. Identifizieren Sie Engpässe, ermitteln Sie deren Ursache und bewerten Sie deren Automatisierungspotenzial. Vergessen Sie nicht die organisatorische Bewertung - haben wir die kollektive Mentalität von DevSecOps? Messen Sie Ihr Risiko an jedem Punkt und analysieren Sie die personellen Abhängigkeiten, die entlang des kritischen Pfades bestehen könnten. Goldratt's  Theorie der Sachzwänge ist hier sehr treffend. Er besagt, dass es am wichtigsten ist, Ihre größte Einschränkung (z.B. Ihren meistbeschäftigten DevOps-Ingenieur) kontinuierlich zu identifizieren und zu neutralisieren. Stellen Sie sicher, dass Ihre relevanten Teams richtig integriert sind und legen Sie Wert auf Cross-Training und Wissensaustausch. Dies ist nicht nur wichtig, damit DevSecOps wie beabsichtigt funktioniert, sondern trägt auch zum Aufbau von Vertrauen innerhalb des Teams bei. Der Aufbau von Prozessen und einer Kultur, die die DevSecOps-Ingenieure dazu ermutigt, einen größeren Teil ihrer Zeit für den Wissenstransfer an andere Ingenieure zu verwenden (z.B. durch Pairing), ist von außerordentlichem Wert. Es mag kontraintuitiv erscheinen, insbesondere bei einem DevSecOps-Ingenieur, der ohnehin schon zu beschäftigt ist, aber der Wissenstransfer ist der effektivste Weg, um langfristig Zeit freizusetzen.

Versuchen Sie auf keinen Fall, das gesamte Unternehmen über Nacht zu verändern. Fangen Sie klein an, wählen Sie einen einzelnen Wertstrom, bei dem die Risiken gering und der Nutzen hoch ist. Projekte auf der grünen Wiese sind ein guter Startpunkt. Versuchen Sie, schnell einen greifbaren Nutzen zu demonstrieren, damit alle an Bord bleiben. Gehen Sie dann zum nächsten Wertstrom über und wiederholen Sie dies nach Bedarf. Bei jeder dieser Mini-Transformationen werden Sie lernen und sich verbessern. Sie werden einen Katalog von fehlgeschlagenen Experimenten und erfolgreichen Transformationen aufbauen, den Sie als Referenz verwenden können, so dass es mit der Zeit einfacher werden sollte.

Niemand hat behauptet, die DevSecOps-Reise sei einfach. Aber sie muss auch nicht erschütternd sein, und Sie müssen sie auch nicht allein antreten. Es ist immer empfehlenswert, eine zweite Meinung zu Ihrem geplanten Kurs einzuholen. Dieser objektive Gesundheitscheck kann potenzielle Probleme aufdecken, die Ihr Team übersehen hat, und Ihnen ein besseres Gefühl für Ihren Ansatz geben. Und natürlich ist die Hilfe sachkundiger, erfahrener Berater ein todsicherer Weg, um die unbekannten DevSecOps-Gewässer sicher zu navigieren und Ihr Ziel sicher und erfolgreich zu erreichen.