DevOps

Wachs­tum meis­tern: DevOps – Teil III

Teil 1: Defini­tion und Mo­ti­va­tion
Teil 2: Veränderungen als unverzichtbare Basis
Teil 3: Herausforderungen und Risikofaktoren
Teil 4: DevOps in der Praxis

Heraus­­for­de­run­gen, die es zu neh­­men gilt

Unabhängig davon, ob ein Unternehmen Kanban oder Scrum als Management-Modell wählt, bedarf das DevOps Konzept einer Person, welche die zahlreichen Administrationstätigkeiten übernimmt und so als Ansprechpartner für kommende Herausforderungen und Risiken fungiert.

Hierfür wurde die Rolle des DevOps Engineers geschaffen. Er kommt im Grunde schon ins Spiel, wenn sich das Unternehmen für DevOps als Modell entscheidet.
In seiner schnittstellenübergreifenden Position legt er die Weichen und optimiert die Grundlagen. Er führt agile Methoden zur Softwareentwicklung ein, stellt die Infrastruktur in Form von Automatisierungssystemen und Entwicklungstools zur Verfügung und bringt teils abteilungsübergreifend Mitarbeiter in Teams zusammen. Wenn es dann an die Projekte geht, trägt er die Verantwortung für die Lösungsoptimierung bei den Software-Entwicklungs-Lebenszyklen, natürlich stets mit der strategischen Ausrichtung der Firma im Visier.
In kleineren Unternehmen oder bei einer überschaubaren Anzahl an Projekten kann er gleichzeitig die Aufgabe des Scrum Masters übernehmen. Erfahrungen zeigen aber, dass es häufig empfehlenswerter ist, die Rollen zu trennen.

Ist der DevOps Engineer gewählt, müssen sich die Beteiligten zahlreichen Herausforderungen stellen, wie beispielsweise gewachsene Prozesse umzubauen, neue Denkweisen zu fördern und ausreichend Ressourcen anzubieten.

Aufgaben des DevOps Engineer
Wer DevOps im Unternehmen etablieren möchte, muss zahlreiche Herausforderungen meistern und Risikofaktoren abwehren. Als Ansprechpartner hierfür fungiert in erster Reihe der DevOps Engineer.

Alte Strukturen auf­geben

Jede im Software-Lebenszyklus integrierte Abteilung hat jahrelang in gewachsenen Strukturen, Frameworks, Systemen und Prozessen agiert. Die langwierige Erfahrung sowie Spezialisierung führt dazu, dass die einzelnen Abteilungen, in dem was sie täglich tun, effizient und zielorientiert vorgehen. Was aber zu Problemen führt, sind fehlende Systemschnittstellen und die intensive Kommunikation zwischen diesen Kokons. Es sollte daher den einzelnen Mitarbeitern nähergebracht werden, dass sie vom Aufbrechen der eigenen, teils abgeschotteten, Abteilungsgebilde profitieren. Das fällt zunächst schwer und ist oft mit Verunsicherung sowie Ängsten verbunden.
Ist dies dennoch geschafft, müssen sich die einzelnen Abteilungen damit auseinandersetzen, wie die jeweils anderen arbeiten. Gibt es technische und organisatorische Parallelen, reichen Anpassungen. Sind keine vorhanden, müssen Schnittstellen oder neue standardisierte Lösungen für gemeinsame Systeme gesucht werden. Ohne diese Werkzeuge im Hintergrund, kann der für agiles DevOps notwendige Automatisierungsgrad nicht erreicht werden.

Kooperatives Denken fördern

Sind die gewachsenen Prozesse aufgebrochen und neu zusammengepuzzelt, müssen zudem Denkweisen und Verantwortlichkeiten umgestaltet werden. Arbeiten die Abteilungen getrennt, beharrt jeder auf seine Ziele: Die Entwicklung möchte schnell Neuerungen realisieren, die Mitarbeiter aus Test und Betrieb möchten besonders stabile Anwendungen liefern. Die Entwicklung möchte jedoch nicht durch die nachfolgenden Abteilungen langwierig ausgebremst werden. Weder der Kunde noch das Unternehmen profitieren von gegenseitigen Schuldzuweisungen bei Problemen.
Wenn jedoch relevante Aspekte zur Stabilität einer Anwendung bereits in der Entwicklungsphase thematisiert werden, da alle Bereiche eng zusammenarbeiten, ziehen alle am gleichen Strang und übergeben schließlich das Projekt mit gleichem Verantwortungsbewusstsein.

Für diese Revolution in der Kultur muss das DevOps-Konzept aber in allen Details nähergebracht werden. Eine neue Kultur wird nicht lediglich mittels einer E-Mail die Bisherige verdrängen. Und allein gut gemeinte Vorgaben von oben nach unten zu kommunizieren, bietet ebenfalls keine Lösung. Die Unternehmensleitung muss sich Zeit nehmen, das Thema immer wieder direkt zu kommunizieren. Authentische Vorbilder, die für das Thema und für eine gute sowie erfolgreiche Zusammenarbeit brennen, stecken an und verbreiten intrinsische Motivation.

Wenn sich schließlich neue Denkmuster durchgesetzt haben, entsteht aber auch eine neue Verantwortung von oben. Ideen, Experimentierfreude genauso wie ein interdisziplinäres Verständnis, werden auf fruchtbaren Boden treffen. Kaum ein Mitarbeiter wird hingegen geduldig eigene und fremdverursachte Fehler auf Dauer tolerieren, wenn er fortwährend überlastet ist. Somit stehen Kultur und entlastende Strukturen, beispielsweise durch Automatisierung, in einer engen Wechselwirkung zueinander.

Häufig kommt Kritik auf, dass der Begriff Kultur lediglich vorgeschoben wird, um nicht tatkräftig an den Strukturen schrauben zu müssen. Es wirkt in der Tat zunächst wie eine nicht greifbare Herausforderung, der man sich im ersten Schritt stellen muss. Außerdem sind mit Umstrukturierungen ebenfalls Ängste verbunden. Daher gilt es zunächst, aufzuklären, unentwegt zu erläutern und Geduld mitzubringen. Hat die neue Denkweise Fuß gefasst, fällt der nächste Schritt leichter.

Ressourcen schaf­fen

DevOps beinhaltet agile Lean-Methoden. Ein Ziel ist demnach, möglichst wenig Raum für Überflüssiges zu schaffen. Konzentriert und schlank sollen Abläufe im Software-Entwicklungs-Zyklus sein. Das entwickelt sich jedoch nicht von alleine. Voraussetzung sind angepasste Schnittstellen und meist neue Systeme. Doch um dies zu realisieren, darf zunächst nicht an Ressourcen gespart werden. Das wirkt widersprüchlich, aber Know-how und funktionierende Teams werden nur entstehen, wenn Raum und Zeit dafür besteht, sich über Situationen, Herausforderungen und Anforderungen auszutauschen.

Regeln und Strukturen, die beispielsweise Scrum einfordert, können nur bestehen bleiben, wenn die nötigen Positionen mit ausgebildeten Ansprechpartnern belegt werden. Reibungslose Kanban-Abläufe können nur funktionieren, wenn die Spezialisten den Freiraum haben, Termine selbst realistisch einzuschätzen. Ausreichende Ressourcen wie Zeit, Geld, Know-how und Personal sind also trotz Verschlankung der Prozesse nach wie vor eine Hürde, die es zu überwinden gilt.

Technische Her­aus­for­de­run­gen

Neben den zwischenmenschlichen und strukturellen Herausforderungen gibt es zudem technische, die bedacht werden müssen.

Zum einen besteht bei DevOps durch die Zusammenführung von Aufgaben ein erhöhtes Sicherheitsrisiko. Da die Entwickler weitreichende Schreibrechte auf Produktionssysteme erhalten, können diese einfacher manipuliert werden. Es können trotz der weitreichenden Automatisierung beispielsweise Programmcodes für Betrugsversuche mitprogrammiert werden. Um dies zu verhindern, könnten zusätzliche Sicherheitstest sowie Reviewer eingesetzt werden.

Zum anderen kann das erhöhte Tempo zum Problem werden. Im Rahmen von DevOps schnell kleine Anwendungspakete durchzuschleusen klingt sehr verlockend. Das angesagte Tempo kann jedoch dazu führen, dass Sicherheitskonzepte wie sichere Verschlüsselung, Authentifizierung und Zertifikate als zu langwierig gesehen und nicht ausreichend eingesetzt werden. Eigensignierte Schlüssel oder mehrfachverwendete Schlüssel werden zum Sicherheitsrisiko, da die Transparenz über vertrauenswürdige Software fehlt. Die Automatisierung der Schlüsselvergabe sowie der Zertifikatvergabe über den Build-Prozess kann wertvolle Zeit einsparen und so Sicherheit und Transparenz schaffen.

Risiko­för­dern­de Fak­to­ren

Die Risiken ergeben sich größtenteils durch Nachlässigkeiten in folgenden Bereichen:

IT-Governance: Die einzelnen Rollen und Verantwortlichkeiten zu definieren und ausreichend voneinander abzugrenzen ist, neben der Hauptausrichtung der Unternehmens-IT, ein Teilbereich von IT-Governance. Ein wichtiger Bestandteil ist hier die Security Policy. In einer Security Policy wird unter anderem definiert, wer wann auf welche Systeme zugreifen darf. Bei DevOps ist in den agilen Teams die Rollenverteilung jedoch nicht mehr so strikt, wie bei klassischen Konzepten. So müssen häufig mehrere Entwickler sicherheitsrelevante Entscheidungen treffen. Hier dennoch überschaubare Abgrenzungen vorzunehmen, bedarf Aufmerksamkeit. Getrennt werden kann beispielsweise in die folgenden Rollen: Security Architekt, Security Tester, Security Officer und Security Champion.
Zudem können beispielsweise das Einfordern eines Sicherheitskonzeptes, eingebettete Sicherheitsfunktionen in Plattformen, die Sicherheitszertifizierung von Frameworks oder eine weitreichende Automatisierung zu sicherer Software verhelfen. Wenn diese im Zuge von DevOps nicht genügend definiert sind, kann das fatale Folgen haben.

Skills: Ein weiterer Aspekt bei der Entwicklung sicherer Software ist das Schulen von Mitarbeitern in Bezug auf Sicherheitsfragen. Um eine sichere Qualität zu gewährleisten, müssen Sicherheitsaspekte bereits in einem frühen Stadium der Anwendungsentwicklung mitberücksichtigt werden. Ohne ein breites Sicherheitsbewusstsein bei den Mitarbeitern der Entwicklung, ist die Sicherheit kaum zu gewährleisten. Es bestehen zudem eine höhere Chance, dass Schadsoftware eingeschleust wird.

Compliance: Das Zusammenwachsen von Entwicklung und Betrieb sollte nicht zu einer kompletten Verschmelzung der beiden Bereiche führen. Dies bedeutet einerseits einen Verstoß gegen die Compliance-Vorgaben, wie PCI-DSS und ISO 2700. Anderseits können so Sicherheitslücken entstehen, da wertvolles Know-how fehlt und unkontrolliert schadhafte Software mit eingebaut werden kann.

Zeitdruck: Ein zu hoher Zeitdruck kann dazu führen, dass für die Sicherheit entscheidende Tests, Zertifikate etc. nicht angewendet werden.

Teil IV: Dass DevOps als Methode nur mit ausreichend Einsatz und ohne Nachlässigkeit in kritischen Bereichen eingeführt werden kann, zeigen die zahlreichen Herausforderungen und risikofördernden Faktoren. Wie die Unternehmen damit jedoch in der Praxis umgehen und welche Aspekte sich bei DevOps bisher als erfolgsentscheidend erwiesen haben, wird im abschließenden Artikel der DevOps-Serie betrachtet.

 

 

Katy Spalek

Katy Spalek

Manager Corporate Publishing bei BROCKHAUS AG
Katy Spalek ist bei der BROCKHAUS AG als Redakteurin für die Bereiche Marketing und Vertrieb zuständig und verantwortet Recherche, Verfassen und Layout von Texten zur Kundenkommunikation. Für das blogHAUS verfasst sie Beiträge über aktuelle Trendthemen aus IT, Marketing und Wirtschaft.
Katy Spalek
<< Vorheriger Beitrag
Nächster Beitrag >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.