{"id":8608,"date":"2017-09-12T11:51:00","date_gmt":"2017-09-12T09:51:00","guid":{"rendered":"https:\/\/fits-admng.f-i-ts.info\/blog\/?p=8608"},"modified":"2022-01-10T12:33:07","modified_gmt":"2022-01-10T11:33:07","slug":"devops-wer-wie-warum-teil-1","status":"publish","type":"post","link":"https:\/\/fitsde-admin-line2.f-i-ts.info\/blog\/finance-cloud\/devops-wer-wie-warum-teil-1\/","title":{"rendered":"DevOps – wer-wie-warum? -Teil 1"},"content":{"rendered":"

\"FI-TS<\/p>\n

Unsere Systemadministratoren\u00a0besch\u00e4ftigen sich\u00a0gerade mit den Erkenntnissen aus dem Bereich DevOps. Damit wir die Folgeschritte verstehen, liefere ich\u00a0Ihnen\u00a0heute einen \u00dcberblick \u00fcber den Begriff und das urspr\u00fcngliche Problem, aus dem der Ansatz entstanden ist.
\nIm 2. Teil dieses Blogbeitrags, den ich dann in der n\u00e4chsten Woche ver\u00f6ffentliche,\u00a0gehe ich dann auf unsere Arbeit mit DevOps ein und was der Ansatz uns als IT-Outsourcing-Dienstleister bringt.<\/p>\n

Der Begriff<\/h5>\n

DevOps ist ein Prozessverbesserungs-Ansatz. Der Begriff setzt sich aus den K\u00fcrzeln \u201eDev\u201c, das f\u00fcr die\u00a0Softwareentwickler (Developers) und \u201eOps\u201c, das f\u00fcr den IT-Betrieb (Operations) steht,\u00a0zusammen. DevOps soll eine effektivere und effizientere Zusammenarbeit der beiden Bereiche sowie der Qualit\u00e4tssicherung (QS) erm\u00f6glichen. Mit DevOps sollen die Qualit\u00e4t der Software, die Entwicklungsgeschwindigkeit, die Auslieferung sowie das Miteinander der beteiligten grundverschiedenen Teams verbessert werden.<\/p>\n

\"FI-TSSoftwareentwicklung (Developers)<\/h5>\n

Deutsche Bankkunden sind digital-affin und verlangen smarte Online-L\u00f6sungen. Darum erwarten wiederum Banken von ihren Softwareentwicklern, dass sie die am Markt gew\u00fcnschten Funktionen m\u00f6glichst schnell umsetzen. Die neue Funktion bringt dem User einen Mehrwert, der oft bereits nach der ersten Vorstellungsrunde \u00fcberzeugt und deshalb vom Auftraggeber abgesegnet wird.
\nDie Entwickler m\u00f6chten dem Kunden m\u00f6glichst schnell Updates oder neue Funktionalit\u00e4ten zur Verf\u00fcgung stellen. Je mehr Releases sie mit neuen Features anbieten,\u00a0umso positiver wird\u00a0ihre Arbeit wahrgenommen.<\/p>\n

\"FI-TSIT-Betrieb (Operations)<\/h5>\n

Die Aufgabe des IT-Betriebs ist es nun, die neu entwickelte Software auf der Produktivumgebung zur Verf\u00fcgung zu stellen.\u00a0 Beispiele hierf\u00fcr sind der Einsatz neuer Softwarereleases oder die Sicherstellung des laufenden Betriebs unter bestimmten Qualit\u00e4tsanforderungen.<\/p>\n

Nat\u00fcrlich m\u00f6chte der Nutzer die volle Verf\u00fcgbarkeit und Sicherheit der Anwendung garantiert bekommen. Der Betrieb \u00fcbernimmt die Verantwortung f\u00fcr diesen Anspruch. Er ist dann erfolgreich, wenn er alle Qualit\u00e4tsanforderungen einhalten kann. Ist beispielsweise die volle Verf\u00fcgbarkeit einmal beeintr\u00e4chtigt, so f\u00e4llt das direkt auf den Betrieb zur\u00fcck und f\u00fchrt in diesem Fall zu einer negativen Wahrnehmung des IT-Betriebs.
\nDoch warum kommt es zu Verf\u00fcgbarkeitsausf\u00e4llen? Das kann auch bei stabil laufenden Anwendungen passieren, wenn eine neue Software eingesetzt wird. Der Ausfall\u00a0kommt dann beim Auftraggeber nat\u00fcrlich nicht gut an. Deshalb setzt der Betrieb oft alles daran, diesen Zustand vor \u00c4nderungen zu sch\u00fctzen.<\/p>\n

Konflikte zwischen Entwicklern und IT-Betrieb<\/h5>\n

Wie wir sehen haben Softwareentwickler und IT-Betrieb unterschiedliche Ziele. Die Entwicklung ist an schnellen und h\u00e4ufigen Releases interessiert, der Betrieb hingegen w\u00fcrde Releases am liebsten vermeiden. Das f\u00fchrt zu Konflikten.
\nWie die im Alltag aussehen, m\u00f6chte ich anhand von zwei Beispielen kurz beschreiben:<\/p>\n

Die Entwicklung gibt ein neues Release an den IT-Betrieb weiter. Dem Betrieb gelingt es nicht die Software auf der Produktivumgebung lauff\u00e4hig zu machen. Er gibt die Fehlerbeschreibung an die Entwickler weiter. Diese blocken aber ab, schlie\u00dflich w\u00fcrde die Software auf der Entwicklungsumgebung fehlerfrei laufen. Damit habe der Betrieb etwas falsch gemacht. Beide Seiten beschuldigen sich\u00a0gegenseitig. Nach eingehender Recherche kommt beispielsweise heraus, dass sich Entwicklungs- und Produktivumgebung\u00a0 in einem wichtigen Detail unterscheiden. Das war aber keiner der beiden Seiten vorher bewusst.<\/p>\n

In der Produktivumgebung entsteht ein Performanceproblem. Die Entwickler arbeiten daraufhin mehrere N\u00e4chte durch und liefern einen Patch. Der IT-Betrieb hat allerdings Bedenken, dass der Patch die Stabilit\u00e4t des Systems gef\u00e4hrdet, weil er \u00c4nderungen an einer kritischen Komponente umfasst. Deshalb verlangt er eine genaue Qualit\u00e4tskontrolle auf einer Testumgebung. Nun l\u00e4sst sich die ben\u00f6tigte Last in der Testumgebung aber nicht ad\u00e4quat darstellen. Es vergeht viel Zeit, bis eine L\u00f6sung gefunden wird. Die Entwickler sind entt\u00e4uscht.<\/p>\n

Zum Schluss des ersten Teils noch ein kurzer Film von Ca, der den Konflikt erkl\u00e4rt\u00a0und schon etwas zur L\u00f6sung verr\u00e4t.
\nDie L\u00f6sung und die Ergebnisse aus der DevOps-Bewegung samt agiler Methoden und unseres unternehmeseigenen Ansatzes von FI-TS werde ich im 2. Teil des Beitrags veranschaulichen.<\/p>\n