Gewohnheit Nr. 2: Wir stellen sicher, dass Sicherheit und Compliance am Ende eines jeden Projekts erledigt sind

DevOps sieht in jedem Unternehmen anders aus. Was in der Theorie eine gute Idee zu sein scheint, führt in der Praxis manchmal zu Hindernissen und Redundanzen. In dieser Blogserie packen wir sieben dieser Szenarien aus, damit Unternehmen lernen können, wie sie DevOps richtig einsetzen. Diese Woche befassen wir uns mit der Frage, warum Sicherheit und Compliance oft als Belastung empfunden werden.

Sicherheit und Compliance werden oft wie ein nachträglicher Gedanke behandelt. Wie Sie sich vorstellen können, führt diese Arbeitsweise zu Problemen. Warum also tun Unternehmen dies? Die Antwort ist einfach: Sie stecken in ihren alten Gewohnheiten fest.

Hier ist ein Beispiel dafür, wie das in der Praxis aussieht. Ein Softwareentwicklungsteam erhält ein neues Projekt und beginnt den Entwicklungsprozess mit der Prüfung der Anforderungen des Kunden. Ein Product Owner bewertet dann die Machbarkeit der Umsetzung dieser Anforderungen und beginnt mit der Funktionsanalyse dessen, was das Team entwickeln möchte. Das Team arbeitet agil an der Entwicklung der Software. Wenn der letzte Knopf gedrückt werden muss, um den Quellcode in die Produktion zu überführen, werden Sicherheit und Compliance hinzugezogen, um ihre Arbeit zu überprüfen.

Dann fangen die Probleme an - die falsche Infrastruktur wurde verwendet, es wird ein anderer Authentifizierungsmechanismus benötigt, die Möglichkeiten für Fehler sind endlos. Wenn es um Sicherheit geht, ist es selten eine schnelle Lösung. Der Wiederaufbau von Komponenten kostet viel wertvolle Zeit und damit Geld. Und der problematischste Aspekt von allen? Die Leute geben dem Sicherheits- und Compliance-Team die Schuld für diese Verzögerungen.

Wenn Sicherheit und Einhaltung von Vorschriften als nachträglicher Gedanke behandelt werden, fangen Unternehmen oft an, dieses Team als lästig zu betrachten, weil ihre Beteiligung häufig Nacharbeit erforderlich macht. Die Denkweise geht dahin, dass Sicherheit und Compliance den Produktionsprozess verlangsamen. Aber nicht das Team ist das Problem, sondern der Arbeitsablauf.

[embed]https://youtu.be/JNcK_HgpM3A[/embed]

Probleme beginnen mit Silos

Traditionell sind Unternehmen so organisiert, dass sie Mitarbeiter mit demselben Fachwissen in Gruppen zusammenfassen: Entwicklung, Betrieb, Marketing, Sicherheit und Compliance, usw. Jede Abteilung strebt nach operativer Exzellenz und schafft daher all diese standardisierten Prozesse innerhalb ihres eigenen Teams. Diese Prozesse funktionieren innerhalb der eigenen Blase jeder Abteilung hervorragend, aber wenn sie zusammenarbeiten müssen, kommt es zu Konflikten. Eine Abteilung verlangt von der anderen, dass sie ihren Prozess befolgt: "Füllen Sie diese Checkliste aus." - "Was? Das sind 50 Punkte. Das wird viel zu lange dauern." Die Teams müssen verhandeln, wo sie überhaupt anfangen sollen, bevor sie irgendetwas erledigen können.

Lineares Denken aufgeben

Softwaredesign und -entwicklung ist kein sauberer, linearer Schritt-für-Schritt-Prozess. Wenn Teams in Silos arbeiten, gibt es am Ende viel Nacharbeit und Unmut unter den Kollegen. Der effizienteste und produktivste Arbeitsablauf besteht darin, von Anfang an zusammenzuarbeiten.

Wenn die Sicherheit und die Einhaltung von Vorschriften von Anfang an mit einbezogen werden, sind die Diskussionen explorativ und positiv. "Wir werden mit dieser Infrastruktur arbeiten. Was halten Sie davon?" - "Das würde ein gewisses Sicherheitsrisiko mit sich bringen, aber wenn Sie es so machen, werden Sie dieses Risiko abdecken." Dann kann das Team bauen, ohne später langwierige Nacharbeiten befürchten zu müssen. Diese Art der Zusammenarbeit hat auch den zusätzlichen Vorteil, dass das Sicherheitsbewusstsein im Entwicklungsteam gestärkt wird.

Das mag in der Theorie einfach klingen, aber in der Praxis ist der Wandel schwer! Die Bequemlichkeit Ihres Silos aufzugeben, in dem alles nach Ihren Präferenzen kontrolliert und optimiert wird, ist eine Herausforderung. Die Einführung eines flüssigeren Arbeitsablaufs erfordert also nicht nur eine Änderung der Arbeitsweise, sondern vor allem eine Änderung der Denkweise. Wie dieser Wandel umgesetzt wird, sieht in jedem Unternehmen anders aus.

Möchten Sie tiefer in die DevOps-Praxis eintauchen? Chatten Sie mit uns!

Wenn es um DevOps geht, gibt es keine Einheitslösungen, die für alle passen. Jedes Unternehmen braucht einen Ansatz, der für seine Bedürfnisse und Teams maßgeschneidert ist. Wir können Ihnen dabei helfen! Kontaktieren Sie uns für weitere Informationen und Ideen, wie Sie eine Lösung finden können, die zu Ihrem Team passt.

Schalten Sie außerdem das nächste Mal ein, um zu erfahren, warum "wir konzentrieren uns auf eine 100%ige Betriebszeit für alles" die dritte Angewohnheit eines äußerst ineffektiven DevOps-Teams ist.

Laden Sie unser 7 Gewohnheiten eBook herunter