Wie OpenShift die Organisationsstruktur der IT-Organisation verändert. Evolution der Organisationsmodelle bei der Umstellung auf PaaS

Obwohl die Lösungen von PaaS („Platform as a Service“) für sich genommen nicht in der Lage sind, die Art und Weise des individuellen und teamübergreifenden Austauschs zu ändern, dienen sie häufig als Katalysator für organisatorische Veränderungen, um auf die zunehmende Flexibilität der IT-Technologien zu reagieren.

In der Praxis ist eine maximale Kapitalrendite aus PaaS oftmals nur möglich, wenn organisatorische Rollen, Verantwortungsbereiche (Aufgaben) und Beziehungsstrukturen geändert werden. Glücklicherweise verfügen PaaS-Lösungen wie OpenShift Container Platform über ausreichend Flexibilität, damit jede IT-Organisation selbst die Geschwindigkeit und das Ausmaß der Veränderungen in Bezug auf die beteiligten Personen und die ablaufenden Prozesse festlegen kann.

In der ersten Phase der Containerisierung ist die Einführung einer Containerplattform als neues System zur Bereitstellung von Anwendungen oberste Priorität. Zu diesem Zeitpunkt verknüpfen Unternehmen gängige Arbeitsabläufe mit vertrauten Rollen, um auf Standardanfragen der Entwicklungsteams in Fragen wie Speicherlösungen, Bereitstellungsumgebungen usw. zu reagieren. In den folgenden Phasen der Containerisierung geht es bereits um Automatisierung oder um die Bereitstellung von Self-Service-Möglichkeiten für Entwickler, um die Belastung der Systemadministratoren zu verringern und die Autonomie und Effizienz der Entwickler auf ein höheres Niveau zu heben. So beginnt die Organisation, sich in Richtung DevOps zu bewegen. In der abschließenden Phase der Containerisierung gelangt das Unternehmen zu einem saubereren, kanonischen DevOps-Modell, in dessen Rahmen viele der bisherigen Aufgaben und Arbeiten in die Verantwortung funktionsübergreifender Teams übergehen, die sich nicht nach Plattformen oder Technologien, sondern nach der Bereitstellung von Anwendungen oder Anwendungsdiensten gruppieren.

In diesem Beitrag werden wir einen Leitfaden für die erforderlichen organisatorischen Veränderungen vorstellen und erläutern, wie sich traditionelle IT-Rollen mit der Einführung von Contain technologies im Unternehmen verändern.

Verknüpfung neuer Arbeiten mit alten Rollen

In ihrer grundlegenden, anfänglichen Form wird das organisatorische Modell von PaaS geschaffen, um IT-Ressourcen für Anwendungen flexibler und schneller bereitzustellen. Und obwohl dies bestimmten Vorteilen für Systemadministratoren bietet, erhalten Entwickler in der Regel keine wesentlichen Vorteile und neuen Möglichkeiten, da das Unternehmen zu diesem Zeitpunkt durchaus ohne die Einführung von Automatisierung, Selbstbedienung oder wesentlichen Verbesserungen im Bereitstellungsprozess auskommen kann. Während PaaS die Entwicklungsprozesse in dieser Phase minimal berührt, erhöht es dennoch die Dynamik des IT-Systems, was es den Administratoren ermöglicht, die Anfragen der Entwickler besser zu bedienen. Zum Beispiel, wenn es früher Tage oder sogar Wochen in Anspruch nahm, eine Entwicklungsumgebung aus mehreren virtuelle Maschinen und Speichervolumes aufzubauen, wobei die Mitwirkung mehrerer verschiedener Administratoren erforderlich war, geschieht in PaaS alles viel schneller und nur durch einen Administrator. Mit anderen Worten, die Entwicklungsteams reichen weiterhin Anträge ein wie zuvor, aber die Umsetzung dieser Anträge erfolgt jetzt nach einem neuen Schema.

Auf dem Weg zur DevOps-Organisation

Durch den Start von PaaS und die Übertragung der IT-Systemoperatoren und Anwendungsentwickler auf diese Plattform kann die Organisation die Einführung der DevOps-Methodologie fortsetzen, die unter anderem folgende grundlegende Prinzipien umfasst:

• Die Arbeit in kleine Schritte aufteilen, um frühzeitiges Feedback zu erhalten, Risiken zu minimieren und „analytische Lähmung“ zu vermeiden;
• Betriebsabläufe in ausreichendem Maße automatisieren, um keine Hindernisse oder Engpässe im Anwendungsbereitstellungsprozess zu schaffen;
• Wissenstransfer – der Schlüssel zum Aufbau von Vertrauen;
• Technische Schulden regelmäßig abzubauen, indem in jedem Arbeitszyklus Zeit für systematische Verbesserungen eingeplant wird.

In der zweiten Phase der Implementierung von Containervirtualisierungstechnologien beginnen die Entwicklungsteams selbstverständlich, Verbesserungspotenziale zu erkennen, und das Unternehmen neigt zu einem kanonischeren DevOps-Modell. Der traditionelle Mechanismus zur Einreichung und Ausführung von Serviceanfragen wird nun als Engpass wahrgenommen, daher strebt die Organisation an, sich wiederholende Tätigkeiten zu automatisieren und den Entwicklern Self-Service-Möglichkeiten zu bieten. Dabei werden diese Möglichkeiten der Entwickler im Rahmen der jeweiligen Anfrage durch die gemeinsame Anstrengung der IT-Spezialisten für die Plattformentwicklung und derjenigen, die für die Bereitstellung von Anwendungen verantwortlich sind, definiert. Anders ausgedrückt, an die Stelle von Systemadministratoren, die auf die Anfragen der Entwickler reagieren, treten die beiden genannten Mitarbeiterkategorien, die für die Beschreibung und Anwendung von Richtlinien zuständig sind, die regulieren, was den Entwicklern gestattet ist, eigenständig zu tun. Automatisierte Verfahren helfen dabei, die Einhaltung der festgelegten Anforderungen zu gewährleisten und Maßnahmen in Fällen abzustimmen, in denen die Situation über die geltenden Richtlinien hinausgeht.

Der Übergang zu einem iterativen Zeitplan, in dem die IT-Umgebung und das Betriebsmodell über die Zeit hinweg iterative Veränderungen durchlaufen, ist ein kritischer Meilenstein zur Schaffung eines reifen DevOps-Systems im Unternehmen. Der Grad der Übernahme der DevOps-Methodologie hängt von der Veränderungstoleranz jeder einzelnen Organisation ab und davon, welche Veränderungen den größten Nutzen bringen. Wenn beispielsweise der Bedarf an der Schaffung neuer Umgebungen oder Anwendungen nicht häufig auftritt, wird die Optimierung der entsprechenden Prozesse weniger wichtig sein als die Stärkung der Kontrolle der Entwickler über den Lebenszyklus von Anwendungen.

Neue Aufgaben, die in IT-Organisationen beim Übergang zu OpenShift entstehen

In diesem Abschnitt werden wir die Rollen und Aufgaben untersuchen, die Organisationen, die auf OpenShift umgestiegen sind, üblicherweise anwenden, um die Automatisierung und den Self-Service mit Technologien und PaaS zu beschleunigen.

In der folgenden Tabelle sind die wichtigsten Aufgaben auf oberster Ebene aufgeführt, die in jeder Organisation, die OpenShift implementiert hat, existieren, einschließlich entsprechender Arbeiten und Fähigkeiten. Diese Liste der Aufgaben sollte nicht mit dem Arbeitsverteilungsschema oder der Organisationsstruktur der Teams verwechselt werden; sie ist nur eine Sammlung von Aufgaben, die von den Verantwortlichen für die IT-Infrastruktur erledigt werden müssen, um die erfolgreiche Implementierung der Containerplattform zu gewährleisten. Tatsächlich werden wir weiter unten zeigen, dass die Implementierung von Contain-Technologien die Voraussetzungen für die Entwicklung einer reiferen DevOps-Strategie im Unternehmen schafft, was wiederum den Grad der interdisziplinären Zusammenarbeit der Teams erhöht und die Risiken einer engen Spezialisierung sowohl auf individueller als auch auf Teamebene verringert.

Tabelle 1. Definitionen der Aufgaben von OpenShift

Aufgaben
Erforderliche Fähigkeiten

Automatisierung und Bereitstellung (Provisioning) von IT-Infrastrukturen

Arbeiten:

• Entwurf und Aufbau von Hardwarelösungen
• Organisation und Unterstützung der Automatisierung des Onboardings
• Entwurf und Automatisierung der Bereitstellung von VMs und Hosts

• Entwurf und Implementierung von Rechenzentren
• Systemadministration von Linux
• Automatisierungsskripte
• Kenntnisse über Speichersysteme
• Kenntnisse im Entwurf und in der Implementierung von Netzwerken
• Sicherheit

Installation und Verwaltung der OpenShift-Plattform

Arbeiten:

• Durchführung der Clusterinstallation
• Verwaltung von Infrastrukturservices
• Verwaltung der Skalierung der Plattform
• Authentifizierung und Autorisierung auf Plattformebene

• Systemadministration von Linux
• Kenntnisse über Netzwerktechnologien
• Automatisierungsskripte (Ansible)
• Kenntnisse über Speichersysteme
• Kenntnisse über Containertechnologien und -architekturen
• Kenntnisse über Kubernetes- und OpenShift-Architekturen
• Sicherheit von Plattformen
• Integration von Monitoring

Verwaltung der Bereitstellung von Kundensystemen (Tenant Provisioning), Isolierung durch IT-Ressourcen

Arbeiten:

• Erstellung von Benutzern und Teams innerhalb der Plattform
• Entwurf und Verwaltung von Quoten
• Entwurf und Implementierung von RBAC

• Kenntnisse über Kubernetes- und OpenShift-Architekturen
• Kenntnisse über Containertechnologien und -architekturen
• Automatisierungsskripte
• Gute Kenntnisse über Projekte, Quoten, Rollenzuweisungen und Arbeit mit Planern

Zusammenstellung und Verwaltung von Basis-Images

Arbeiten:

• Entwicklung von Arbeitsabläufen zur Änderung von Images
• Entwicklung von Images basierend auf Standards

• Systemadministration von Linux
• Automatisierungsskripte
• Konfiguration von Laufzeit-Komponenten von Anwendungen und Middleware
• Kenntnisse über Containerarchitekturen
• Anwendungs-Bau-Frameworks
• Gute Kenntnisse über Images, Imagestreams und Vorlagen

Planung und Verwaltung von Bereitstellungskonvektoren

Arbeiten:

• Planung und Dokumentation von Konvektorstandards
• Entwicklung kurzer Leitfäden und Vorlagen
• Schulung der Entwickler

• Quellcodeverwaltung
• Entwurf und Implementierung von Anwendungen
• Automatisierungsskripte
• Automatisiertes Testen
• Code-Qualitätstest
• Kenntnisse über Containerarchitekturen
• Kenntnis von immutable Infrastrukturen
• Sicherheit – Verwaltung des Zugangs zu den Phasen des Konvektors, Genehmigung von Arbeitsabläufen usw.
• Gute Kenntnisse der OpenShift-Vorlagen, Komponenten von buildconfigs, deploymentconfigs, services, routes, configmaps

Entwicklung von Anwendungen und Tests

Arbeiten:

• Codierung von Anwendungen
• Entwicklung von automatisierten Tests
• Reaktion auf Testausfälle während des Bereitstellungskonvektors
• Reaktion auf Anwendungsfehler
• Benutzerakzeptanztests

• Entwurf und Implementierung von Anwendungen
• Automatisiertes Testen
• Quellcodeverwaltung
• Überwachung von Anwendungen
• Kenntnis der Architektur von cloud-nativen Anwendungen

Betriebsüberwachung und -verwaltung von Anwendungen

Arbeiten:

• Anwendungsdesign im Hinblick auf die Leistung
• Überwachung von Anwendungen während der Ausführung
• Skalierung von Anwendungen (oder automatisches Skalieren)
• Verwaltung der Verfügbarkeit von Anwendungen
• Anfragequoten und Ressourcenmanagementbeschränkungen
• Leistungs- und IT-Kapazitätstests

• Planung und Umsetzung der Anwendungsleistung
• Überwachung der Anwendungsleistung
• Leistungs- und Lasttests

Benutzerakzeptanztests

Arbeiten:

• UI-Tests (Design und Interaktion mit Benutzern)
• Entwicklung von automatisierten Tests

• Gestaltung und Überprüfung von Benutzeroberflächen
• Vorlagen für automatisierte Tests
• Testframeworks
• Anwendungsdesignvorlagen

Neue Rollen, die in der IT-Organisation bei der Umstellung auf OpenShift entstehen

Mit der Umstellung auf ein DevOps-orientiertes Organisationsmodell wird die Anzahl der spezialisierten Rollen in der Regel geringer, während die Anzahl der funktionsübergreifenden Teams und Rollen zunimmt, um die Effektivität der Zusammenarbeit zu maximieren. Hier ist, wie wir die Liste der wichtigsten Positionen in einer IT-Organisation, die OpenShift nutzt, sehen:

• Application Operations Engineer oder Site Reliability Engineer. Diese Position wurde früher als "Anwendungsserveradministrator" bezeichnet.
• Anwendungsentwickler/Softwareentwickler/Programmierer.
• Administrator des Clusters/der Anwendungsplattform. Früher konnte diese Rolle als „Systemadministrator“ oder „Administrator von Linux-Plattformen“ bezeichnet werden.
• Release-Manager/Build-Ingenieur.

RACI-Rollen- und Aufgabenmatrix

Schließlich kommen wir zur Zuordnung der zuvor besprochenen Positionen und Aufgaben, um eine allgemeine Vorstellung davon zu geben, wie die Struktur einer Organisation aussehen sollte, die DevOps auf der OpenShift-Plattform implementiert. Die zunächst aufgeführten Rollen können von unterschiedlichen Zweigen der alten, traditionellen Organisationsstruktur ausgeführt werden. Im Laufe der Zeit erfolgt jedoch eine Konsolidierung, und es entstehen neue, um Anwendungen gebaute Teams, die sich um die meisten oder sogar alle der unten genannten Aufgaben kümmern.

Aufgaben
Rollen

Anwendungsingenieur/Site Reliability Engineer
Anwendungsentwickler/Softwareentwickler/Programmierer
Administrator des Clusters/der Anwendungsplattform
Release-Manager/Build-Ingenieur

Automatisierung und Bereitstellung (Provisioning) von IT-Infrastrukturen
I
I
R/A
C

Installation und Verwaltung der OpenShift-Plattform
C
I
R/A
C

Planung und Verwaltung von Bereitstellungskonvektoren
C
C
I
R/A

Verwaltung der Bereitstellung der Kundenumgebungen (tenant provisioning), Isolation und IT-Kapazitäten
C
I
R/A
I

Zusammenstellung und Verwaltung von Basis-Images
R
C
R/A
C

Entwicklung von Anwendungen und Tests
C
R/A
I
I

Betriebsüberwachung und -verwaltung von Anwendungen
R/A
C
C
I

Benutzerakzeptanztests
C
R
I
I

Legenden in der RACI-Matrix
Quelle: Wikipedia

• Verantwortlich – Der Ausführende – derjenige, der das Notwendige zur Erfüllung der Aufgabe tut.
• Rechenschaftspflichtig – Der Verantwortliche – die Person, die letztendlich für die ordnungsgemäße und sorgfältige Durchführung der Aufgabe oder das Erreichen des Ergebnisses verantwortlich ist; außerdem ist er der einzige, der die Arbeit an die Ausführenden delegieren kann.
• Konsultiert – Berater – in der Regel Experten im Fachgebiet, deren Rat eingeholt wird; die Kommunikation mit ihnen erfolgt bidirektional.
• Informiert – Die Informierten – Personen, die über den Stand der Dinge auf dem Laufenden gehalten werden (oft nur nach Abschluss der Aufgabe oder dem Erreichen des Ergebnisses); sie erhalten Informationen einseitig.

Wie die Zusammenarbeit von Teams in einer DevOps-Organisation organisiert ist

Das traditionelle System zur Ressourcengewinnung stellt in der Regel einen Zyklus von Anfragen zur Zuweisung von Ressourcen dar, die dann von mehreren Teams durchgeführt werden. Am Ende werden alle erforderlichen Ressourcen zugewiesen und von der anfragenden Seite bestätigt. Oft werden diese Prozesse teilweise oder sogar vollständig manuell durchgeführt und erfordern häufige und zahlreiche Interaktionen zwischen den Teams, um jede Anfrage erfolgreich zu bearbeiten.

Abbildung 1. Traditionelle IT-Organisation

Das obige Diagramm veranschaulicht die typischen Beziehungen zwischen den Teams in einer traditionellen IT-Organisation. Im Rahmen dieses Modells wenden sich einige Teams an andere Teams mit der Bitte um Durchführung notwendiger Arbeiten, und zwar unter Verwendung mehr oder weniger formalisiertem Kommunikationsmittel, wie z.B. Ticketsysteme oder E-Mail. Diese Anfragen gelangen dann in eine Warteschlange und warten auf ihre Bearbeitung, wobei lange Wartezeiten oft zu einer Verschlechterung oder sogar zu einer Verschärfung der Beziehungen zwischen den Teams führen. Die Anspannung wird zusätzlich dadurch verstärkt, dass die Mitglieder verschiedener Teams selten persönlich miteinander in Kontakt treten und in der Regel nur die minimal notwendigen Informationen austauschen.

Abbildung 2. IT-Organisation DevOps

In diesem Diagramm wird gezeigt, wie die Zusammenarbeit in einer DevOps-Organisation gestaltet ist. Hier haben dieselben Teams aus dem vorherigen Diagramm auf ineffektive Kommunikationswege verzichtet, die die Trennung verstärkt haben, und stattdessen persönliche Kontakte geschaffen, um somit anhaltende Kommunikationskanäle zwischen den Teams zu etablieren. Diese Kanäle fördern die Entwicklung eines hybriden Fähigkeitssatzes, der den Mitarbeitern hilft, die Bedürfnisse, Probleme und Möglichkeiten der Teams besser zu verstehen und zu repräsentieren, die sie vertreten. Teams ermöglichen sich gegenseitig, notwendige Arbeiten über automatisierte Self-Service-Portale auszuführen, anstatt manuell auf die Änderungsanfragen anderer zu reagieren, wie es früher der Fall war. Und dank der vorhandenen Kommunikationskanäle können diese Self-Service-Systeme schnell auf die Bedürfnisse der Teams reagieren, für die sie geschaffen wurden. Um ein noch besseres gegenseitiges Verständnis und Wissensaustausch innerhalb der Organisation zu erreichen, rotieren die Teammitglieder regelmäßig in ihren Rollen, um Erfahrung in der Zusammenarbeit mit verschiedenen Teams zu sammeln und ein besseres Verständnis für das Gesamtbild der IT-Systeme zu entwickeln, die sie betreuen, wodurch ihre cross-funktionale Effizienz und Nützlichkeit erhöht wird.

Zusammenfassend

In diesem Beitrag haben wir erläutert, wie die Einführung von PaaS-Lösungen eine Organisation dazu anregen kann, die DevOps-Methodologie zu implementieren. Im Zuge dieses Prozesses unterliegen traditionelle Rollen und Aufgaben Veränderungen. Daher haben wir die wichtigsten IT-Aufgaben aufgelistet, die in einer Organisation mit der Umstellung auf OpenShift auftreten, sowie die erforderlichen Fähigkeiten für deren Ausführung. Außerdem haben wir das grundlegende Set an organisatorischen Rollen aufgeführt, das beim Aufbau von cross-funktionalen DevOps-Teams entsteht, und eine RACI-Matrix bereitgestellt, die neue Rollen mit neuen Aufgaben verknüpft. Schließlich haben wir dargelegt, wie die OpenShift-Plattform und die damit verbundene DevOps-Methodologie die Organisationsstruktur verändern können, indem sie von einer traditionellen Hierarchie und Antragsbearbeitungssystemen zu cross-funktionalen Teams mit einem höheren Maß an persönlichen Kommunikationen übergeht.

Quelle: habr.com