🚐 🧑🏽‍🤝‍🧑🏽 ❤️ Wie OpenShift die Organisationsstruktur einer IT-Organisation verändert. Die Entwicklung von Organisationsmodellen beim Wechsel zu PaaS ↖️ 🧔🏿 👩‍🎨

Obwohl PaaS-Lösungen (Platform as a Service) allein nicht in der Lage sind, die Art der Einzel- und Teaminteraktion zu ändern, dienen sie häufig als Katalysator für organisatorische Änderungen als Reaktion auf die erhöhte Flexibilität von IT-Technologien.

Tatsächlich ist die maximale Kapitalrendite in PaaS oft nur möglich, wenn die organisatorischen Rollen, Verantwortungsbereiche (Aufgaben) und Beziehungen geändert werden. Glücklicherweise sind PaaS-Lösungen wie die OpenShift Container Platform flexibel genug, sodass jede IT-Organisation unabhängig die Geschwindigkeit und das Ausmaß von Änderungen in Bezug auf die beteiligten Personen und die stattfindenden Prozesse bestimmen kann.

In der ersten Phase der Containerisierung von Unternehmen ist die Implementierung der Containerplattform als neues Anwendungsbereitstellungssystem die Hauptpriorität. Zu diesem Zeitpunkt verknüpfen Unternehmen vertraute Jobs mit vertrauten Rollen, um auf Standardanforderungen von Entwicklungsteams in Fragen wie Speichersystemen, Bereitstellungsumgebungen und mehr zu reagieren. In den folgenden Phasen der Containerisierung geht es bereits um die Automatisierung oder die Bereitstellung von Self-Service-Funktionen für Entwickler, um die Belastung der Systemadministratoren zu verringern und die Autonomie und Effizienz der Entwickler auf ein höheres Niveau zu bringen. Auf diese Weise beginnt sich die Organisation in Richtung DevOps zu bewegen. In der letzten Phase der Containerisierung von Unternehmen kommt es zu einem saubereren, kanonischen DevOps-Modell.in deren Rahmen viele der bisherigen Aufgaben und Arbeiten von funktionsübergreifenden Teams kontrolliert werden, die nicht nach Plattformen oder Technologien gruppiert sind, sondern unter dem Gesichtspunkt der Sicherstellung des Betriebs von Anwendungen oder Anwendungsdiensten.

In diesem Beitrag geben wir Anleitungen zu den erforderlichen organisatorischen Änderungen und beschreiben, wie sich die traditionellen IT-Rollen mit der Einführung der Containertechnologie im Unternehmen ändern.

Neue Jobs mit alten Rollen verknüpfen

In seiner ursprünglichen Grundform wird das PaaS-Organisationsmodell gebildet, um IT-Ressourcen flexibler und effizienter als Laufzeitumgebung Anwendungen zuzuweisen. Und obwohl dies den Systemadministratoren gewisse Vorteile bringt, erhalten die Entwickler hier in der Regel keine wesentlichen Vorteile und neuen Möglichkeiten, da das Unternehmen in dieser Phase möglicherweise auf die Automatisierung, die Einführung von Self-Service oder die radikale Verbesserung der Bereitstellungspipeline verzichten kann. PaaS wirkt sich in dieser Phase nur minimal auf die Entwicklungsprozesse aus und erhöht dennoch die Dynamik des IT-Systems, sodass Administratoren die Anforderungen der Entwickler besser bedienen können. Wenn es beispielsweise früher Tage oder sogar Wochen dauern kann, bis eine Entwicklungsumgebung aus mehreren virtuellen Maschinen und Speichervolumes erstellt wird,und es erforderte die Teilnahme mehrerer verschiedener Administratoren, dann wird in PaaS alles viel schneller und mit Hilfe von nur einem Administrator erledigt. Mit anderen Worten, die Entwicklungsteams reichen Anträge wie zuvor ein, aber die Arbeiten zur Implementierung dieser Anträge werden bereits nach dem neuen Schema durchgeführt.

Auf dem Weg zu einer DevOps-Organisation

Durch den Start von PaaS und die Übertragung von IT-Systembetriebsspezialisten und Anwendungsentwicklern kann das Unternehmen die DevOps-Methodik weiter implementieren, die unter anderem die folgenden Grundprinzipien umfasst:

Teilen Sie die Arbeit in kleine Phasen auf, um frühzeitig Feedback zu erhalten, Risiken zu reduzieren und „analytische Lähmungen“ zu vermeiden.
Automatisieren Sie Vorgänge ausreichend , um keine Hindernisse oder Engpässe bei der Anwendungsbereitstellung zu verursachen.
Der Austausch von Wissen ist der Schlüssel zum Aufbau von Vertrauen.
Zahlen Sie regelmäßig technische Schulden , indem Sie in jedem Arbeitszyklus eine bestimmte Zeit für systematische Verbesserungen einplanen.

In der zweiten Phase der Implementierung von Containertechnologien sehen Entwicklungsteams natürlich Verbesserungsmöglichkeiten, und das Unternehmen lehnt sich für ein kanonischeres DevOps-Modell an. Der traditionelle Mechanismus zum Senden und Ausführen von Serviceanfragen wird jetzt als Engpass angesehen. Daher versucht das Unternehmen, sich wiederholende Aktionen zu automatisieren und Entwicklern Self-Service-Funktionen bereitzustellen. Darüber hinaus werden diese Fähigkeiten von Entwicklern im Rahmen einer bestimmten Anwendung durch die gemeinsamen Anstrengungen von IT-Spezialisten beim Betrieb von Plattformen und denjenigen bestimmt, die für die Bereitstellung von Anwendungen verantwortlich sind. Mit anderen Worten, die Systemadministratoren, die auf Anfrage der Entwickler Aktionen ausführen, werden durch die beiden oben genannten Kategorien von Mitarbeitern ersetzt, die für die Beschreibung und Anwendung der Richtlinien verantwortlich sind.Was genau dürfen Entwickler selbst tun? Automatisierte Verfahren tragen dazu bei, die Einhaltung dieser Anforderungen sicherzustellen und Maßnahmen zu koordinieren, wenn die Situation über den Rahmen bestehender Richtlinien hinausgeht.

Der Wechsel zu einer iterativen Zeitachse, in der sich die IT-Umgebung und das Betriebsmodell im Laufe der Zeit iterativ ändern, ist ein entscheidender Meilenstein für den Aufbau eines ausgereiften DevOps-Systems im Unternehmen. Der Grad der Übernahme der DevOps-Methodik hängt von der Toleranz der einzelnen Organisationen gegenüber Änderungen ab und davon, welche Änderungen am vorteilhaftesten sind. Wenn beispielsweise selten neue Umgebungen oder Anwendungen erstellt werden müssen, ist die Optimierung der entsprechenden Maßnahmen weniger wichtig als die Stärkung der Kontrolle der Entwickler über den Anwendungslebenszyklus.

Neue Herausforderungen für IT-Organisationen bei der Umstellung auf OpenShift

In diesem Abschnitt werden die Rollen und Aufgaben beschrieben, die Unternehmen, die zu OpenShift gewechselt sind, normalerweise verwenden, um die Automatisierung und den Self-Service mithilfe von Technologie und PaaS zu beschleunigen.

In der folgenden Tabelle sind die Hauptaufgaben der obersten Ebene aufgeführt, die in einer Organisation vorhanden sind, die OpenShift implementiert hat, sowie Beispiele für relevante Arbeiten und Fähigkeiten. Diese Liste von Aufgaben sollte nicht mit dem Arbeitsteilungsschema oder der Organisationsstruktur von Teams verwechselt werden. Dies ist nur eine Reihe von Aufgaben, die von den Verantwortlichen für die Unterstützung der IT-Umgebung (en) für die erfolgreiche Implementierung der Containerplattform geschlossen werden müssen. In der Tat werden wir weiter zeigen, dass die Implementierung von Containertechnologien die Voraussetzungen für die Entwicklung einer ausgereifteren DevOps-Strategie im Unternehmen schafft, die wiederum den Grad der Cross-Funktionalität von Teams erhöht und das Risiko einer engen Spezialisierung auf der Ebene einzelner Mitarbeiter und Teams verringert.

Tabelle 1. OpenShift-Aufgabendefinitionen

Aufgaben	Benötigte Fähigkeiten
(provisioning) - :	- Linux
OpenShift :	Linux (Ansible) Kubernetes OpenShift
(tenant provisioning), - : RBAC	Kubernetes OpenShift , ,
:	Linux runtime- middleware (application build frameworks) , imagestream
:	immutable – , . . OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps
:	(cloud native)
: ( ) -
: UI ( )	Frameworks testen Anwendungsdesign-Vorlagen

Neue Rollen, die in IT-Organisationen bei der Migration zu OpenShift entstehen

Wenn Sie zu einem DevOps-basierten Organisationsmodell wechseln, nimmt die Anzahl der Rollenspezialisierungen tendenziell ab, und die Anzahl der funktionsübergreifenden Teams und Rollen nimmt zu, um die Effizienz der Zusammenarbeit zu maximieren. Hier ist unserer Meinung nach die Liste der Schlüsselpositionen in einer IT-Organisation, die OpenShift verwendet:

Application Operations Engineer ODER Site Reliability Engineer. Bisher wurde diese Position als "Application Server Administrator" bezeichnet.
Anwendungsentwickler / Softwareentwickler / Softwareentwickler.
Administrator der Cluster- / Anwendungsplattform. Bisher wurde diese Rolle als "Systemadministrator" oder "Linux-Plattformadministrator" bezeichnet.
Software Release Manager (Build Engineer).

RACI-Rollen- und Aufgabenmatrix

Abschließend vergleichen wir die oben diskutierten Positionen und Aufgaben, um eine allgemeine Vorstellung davon zu erhalten, wie die Struktur einer Organisation aussehen sollte, die DevOps auf der OpenShift-Plattform implementiert. Die folgenden Rollen können zunächst von verschiedenen Zweigen der alten, traditionellen Organisationsstruktur übernommen werden. Im Laufe der Zeit finden jedoch Konsolidierungen statt, und es entstehen neue Teams, die auf Anwendungen basieren und die meisten oder sogar alle der folgenden Aufgaben abschließen.

Aufgaben	Rollen
Aufgaben	Application Operations Engineer / Site Reliability Engineer	Anwendungsentwickler / Softwareentwickler / Softwareentwickler	Administrator der Cluster- / Anwendungsplattform	Software Release Manager / Assembly Engineer
Automatisierung und Bereitstellung von IT-Infrastrukturen	ich	ich	R / a	C.
Installieren und Verwalten der OpenShift-Plattform	C.	ich	R / a	C.
Entwerfen und Verwalten von Bereitstellungspipelines	C.	C.	ich	R / a
Verwalten der Mandantenbereitstellung, Isolation und IT-Funktionen	C.	ich	R / a	ich
Erstellen und verwalten Sie grundlegende Images	R.	C.	R / a	C.
Anwendungs- und Testentwicklung	C.	R / a	ich	ich
Betriebsüberwachung und Anwendungsverwaltung	R / a	C.	C.	ich
Benutzerdefinierte Abnahmetests	C.	R.	ich	ich

Konventionen in der RACI-Matrix
Quelle: Wikipedia

Verantwortlich - Ein Testamentsvollstrecker ist einer, der das Notwendige tut, um eine Aufgabe zu erledigen.
Accountable – – , ; , .
Consulted – – , , ; .
Informed – – , (, ); .

DevOps-

Das traditionelle Schema zum Abrufen von Ressourcen besteht in der Regel aus einer Reihe von Anforderungen für die Zuweisung von Ressourcen, die dann von mehreren Befehlen ausgeführt werden. Letztendlich werden alle erforderlichen Ressourcen vom Antragsteller zugewiesen und bestätigt. Oft werden diese Prozesse teilweise oder sogar vollständig manuell ausgeführt und erfordern häufige und zahlreiche Interaktionen zwischen Teams, um jede Anforderung erfolgreich zu verarbeiten.

Abbildung 1. Traditionelle IT-Organisation

Das obige Diagramm zeigt die typischen Beziehungen zwischen Teams in einer traditionellen IT-Organisation. Im Rahmen dieses Schemas wenden sich einige Teams an andere Teams, um die erforderlichen Arbeiten mit mehr oder weniger formalisierten Kommunikationsmitteln wie einem Ticketsystem oder einer E-Mail auszuführen. Dann fallen diese Anfragen in die Warteschlange und warten in den Startlöchern, und ein langes Warten führt oft zu einer Verschlechterung und sogar zu einer Verschlechterung der Beziehungen zwischen den Teams. Die Spannung wird durch die Tatsache verschärft, dass sich Mitglieder verschiedener Teams selten persönlich treffen und in der Regel nur die minimal notwendigen Informationen teilen.

Abbildung 2. DevOps IT-Organisation

Dieses Diagramm zeigt, wie die Zusammenarbeit in einer DevOps-Organisation funktioniert. Hier gaben dieselben Teams aus dem vorherigen Diagramm ineffiziente Kommunikation auf, was die Uneinigkeit erhöhte, und ersetzten sie durch persönliche Kontakte, wodurch permanente Interaktionskanäle zwischen Teams geschaffen wurden. Diese Kanäle helfen beim Aufbau eines hybriden Skillsets, mit dem Mitarbeiter die Bedürfnisse, Herausforderungen und Fähigkeiten der von ihnen vertretenen Teams besser verstehen und darstellen können. Die Teams geben sich gegenseitig die Möglichkeit, die erforderlichen Arbeiten über automatisierte Self-Service-Portale auszuführen, anstatt die Änderungsanforderungen eines anderen wie zuvor manuell zu verarbeiten. Aufgrund des Vorhandenseins von Interaktionskanälen können sich diese Self-Service-Systeme schnell an die Bedürfnisse von Teams anpassen.für die sie geschaffen sind. Um ein noch besseres gegenseitiges Verständnis und einen besseren Wissensaustausch innerhalb des Unternehmens zu erreichen, wechseln die Teammitglieder regelmäßig die Rollen, um Erfahrungen in der Interaktion mit verschiedenen Teams zu sammeln und das Gesamtbild der IT-Systeme, denen sie dienen, besser zu verstehen. Dadurch wird das Maß an Funktionalität und Nützlichkeit erhöht.

Zusammenfassen

In diesem Beitrag haben wir darüber gesprochen, wie die Implementierung von PaaS-Lösungen die Organisation dazu ermutigen kann, die DevOps-Methodik zu implementieren, und dass sich traditionelle Rollen und Aufgaben innerhalb dieses Prozesses ändern können. Aus diesem Grund haben wir die wichtigsten IT-Aufgaben aufgelistet, die sich beim Übergang zu OpenShift in der Organisation ergeben, sowie die für deren Implementierung erforderlichen Fähigkeiten. Wir haben auch die wichtigsten organisatorischen Rollen vorgestellt, die beim Aufbau funktionsübergreifender DevOps-Teams auftreten, sowie die RACI-Matrix, die neue Rollen mit neuen Aufgaben verknüpft. Schließlich sprachen wir darüber, wie die OpenShift-Plattform und die damit verbundene DevOps-Methodik die Organisationsstruktur einer Organisation ändern können, wenn von einer traditionellen Hierarchie und Anwendungsverarbeitungssystemen zu funktionsübergreifenden Teams mit einem höheren Maß an persönlicher Kommunikation übergegangen wird.

Wie OpenShift die Organisationsstruktur einer IT-Organisation verändert. Die Entwicklung von Organisationsmodellen beim Wechsel zu PaaS