Obwohl PaaS-Lösungen („Platform as a Service“) an sich nicht in der Lage sind, die Art und Weise von individueller und teamübergreifender Zusammenarbeit zu verändern, fungieren sie oft als Katalysatoren für organisatorische Veränderungen, die als Reaktion auf die zunehmende Flexibilität der IT-Technologien entstehen.
In der Praxis ist eine maximale Rendite auf Investitionen in PaaS häufig nur möglich, wenn sich die organisatorischen Rollen, Verantwortungsbereiche und Beziehungsstrukturen ändern. Glücklicherweise bieten PaaS-Lösungen wie die OpenShift Container Platform ausreichend Flexibilität, damit jede IT-Organisation selbst festlegen kann, in welchem Tempo und Umfang Veränderungen hinsichtlich involvierter Personen und ablaufender Prozesse stattfinden.
In der ersten Phase der Containerisierung liegt der Hauptfokus auf der Implementierung einer Containerplattform als neues System zur Bereitstellung von Anwendungen. An diesem Punkt verbinden Organisationen gewohnte Arbeitsabläufe mit vertrauten Rollen, um auf standardisierte Anforderungen der Entwicklungsteams in Bezug auf Speicherlösungen, Bereitstellungsumgebungen und Ähnliches zu reagieren. In den späteren Phasen der Containerisierung geht es bereits um Automatisierung oder um die Bereitstellung von Self-Service-Funktionen durch die Entwickler, um die Belastung der Systemadministratoren zu verringern und die Autonomie sowie die Effizienz der Entwickler auf ein neues Niveau zu heben. Genau so beginnt die Organisation, in Richtung DevOps zu arbeiten. In der abschließenden Phase der Containerisierung gelangt das Unternehmen zu einem klareren, kanonischen DevOps-Modell, in dem viele der vorherigen Aufgaben und Arbeiten in die Verantwortung interdisziplinärer Teams übergehen, die nicht nach Plattformen oder Technologien, sondern nach der Gewährleistung des Betriebs von Anwendungen oder Anwendungsdiensten gruppiert werden.
In diesem Beitrag werden wir eine Anleitung zur Durchführung der notwendigen organisatorischen Veränderungen vorstellen und erläutern, wie sich traditionelle IT-Rollen mit der Einführung von Containermethoden im Unternehmen verändern.
Verknüpfung neuer Aufgaben mit alten Rollen
In ihrer Grundform wird das organisatorische Modell von PaaS entwickelt, um IT-Ressourcen für Anwendungen flexibler und schneller bereitzustellen. Zwar bringt dies bestimmte Vorteile für Systemadministratoren, jedoch profitieren Entwickler in der Regel nicht von signifikanten Vorteilen oder neuen Möglichkeiten, da das Unternehmen in dieser Phase möglicherweise noch nicht auf Automatisierung, Self-Service oder radikale Verbesserungen des Bereitstellungskonzepts angewiesen ist. Obwohl die Entwicklungsprozesse in dieser Phase nur minimal betroffen sind, erhöht PaaS dennoch die Dynamik des IT-Systems, was es Administratoren ermöglicht, besser auf die Anforderungen der Entwickler einzugehen. Beispielsweise benötigten sie früher eine Entwicklungsumgebung, die aus mehreren ... virtuellen Maschinen Die Speicherung von Daten konnte Tage oder sogar Wochen in Anspruch nehmen, und dabei waren mehrere verschiedene Administratoren erforderlich. Mit PaaS geschieht dies jedoch viel schneller und nur mit einem einzigen Administrator. Anders ausgedrückt, die Entwicklungsteams reichen ihre Anträge wie gewohnt ein, doch die Umsetzung dieser Anträge erfolgt nach einem neuen Schema.
Auf dem Weg zur DevOps-Organisation
Durch die Einführung von PaaS und die Übertragung der IT-Systemadministratoren und Anwendungsentwickler auf diese Plattform kann die Organisation das DevOps-Modell weiter implementieren, das unter anderem die folgenden Grundsätze umfasst:
- Arbeit in kleine Schritte unterteilen, um frühzeitig 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;
- Wissen teilen ist der Schlüssel zum Aufbau von Vertrauen;
- Technische Schulden regelmäßig begleichen, indem in jedem Arbeitszyklus Zeit für systematische Verbesserungen eingeplant wird.
In der zweiten Phase der Einführung von Containermanagement-Technologien erkennen die Entwicklungsteams natürlich Möglichkeiten zur Verbesserung, und das Unternehmen tendiert zu einem traditionelleren DevOps-Modell. Der traditionelle Prozess zur Einreichung und Ausführung von Wartungsanfragen wird jetzt als Engpass wahrgenommen, weshalb die Organisation bestrebt ist, sich wiederholende Aufgaben zu automatisieren und den Entwicklern Selbstbedienungsoptionen zu bieten. Diese Möglichkeiten der Entwickler im Rahmen spezifischer Anfragen werden dabei durch die Zusammenarbeit von IT-Betriebsspezialisten und denen, die für die Anwendungsbereitstellung verantwortlich sind, definiert. Anders ausgedrückt, die systemadministrativen Aufgaben, die zuvor von Administratoren im Auftrag der Entwickler ausgeführt wurden, werden jetzt von diesen beiden oben genannten Mitarbeiterkategorien übernommen, die für die Definition und Umsetzung der Richtlinien zuständig sind, die festlegen, was die Entwickler eigenverantwortlich tun dürfen. Automatisierte Verfahren unterstützen die Einhaltung dieser Anforderungen und koordinieren Handlungen in Fällen, in denen die Situation über die aktuellen Richtlinien hinausgeht.
Der Übergang zu einem iterativen Modell, in dem die IT-Umgebung und das Betriebsmodell über die Zeit hinweg schrittweise Veränderungen durchlaufen, ist ein entscheidender Meilenstein für die Entwicklung eines reifen DevOps-Systems im Unternehmen. Der Grad der Akzeptanz der DevOps-Methodologie hängt von der Toleranz einer jeden Organisation gegenüber Veränderungen ab und davon, welche spezifischen Veränderungen den größten Nutzen bringen. Wenn beispielsweise der Bedarf an der Schaffung neuer Umgebungen oder Anwendungen selten auftritt, wird die Optimierung der entsprechenden Maßnahmen weniger wichtig sein als die Stärkung der Kontrolle der Entwickler über den Lebenszyklus der Anwendungen.
Neue Aufgaben, die in IT-Organisationen beim Übergang zu OpenShift entstehen
In diesem Abschnitt werden wir die Rollen und Aufgaben betrachten, die Organisationen, die auf OpenShift umgestiegen sind, typischerweise zur Beschleunigung der Automatisierung und Selbstbedienung unter Verwendung von Technologien und PaaS einsetzen.
In der folgenden Tabelle sind die wichtigsten Aufgaben auf höherer Ebene aufgeführt, die in jeder Organisation bestehen, die OpenShift implementiert hat, mit Beispielen für entsprechende Arbeiten und Fähigkeiten. Diese Aufgabenliste darf nicht mit einem Arbeitsverteilungsschema oder der organisatorischen Struktur der Teams verwechselt werden; es handelt sich lediglich um einen Satz von Aufgaben, die von den Personen, die für die Unterstützung der IT-Umgebung verantwortlich sind, erledigt werden müssen, um die erfolgreiche Implementierung der Containerplattform zu gewährleisten. In der Tat werden wir später zeigen, dass die Einführung von Contain Technologien die Voraussetzungen für die Entwicklung einer reiferen DevOps-Strategie im Unternehmen schafft, was wiederum den Grad der funktionsübergreifenden Teamarbeit erhöht und das Risiko der Spezialisierung sowohl auf individueller als auch auf Team-Ebene verringert.
Tabelle 1. Definitionen der OpenShift-Aufgaben
Aufgaben
Erforderliche Fähigkeiten
Automatisierung und Bereitstellung (Provisioning) von IT-Infrastrukturen
Arbeiten:
- Entwurf und Aufbau von Hardwarelösungen
- Organisation und Unterstützung der Automatisierung der Erstkonfiguration
- Entwurf und Automatisierung der Vorbereitung von VMs und Hosts
- Entwurf und Implementierung von Rechenzentren
- Systemadministration für Linux
- Automatisierungsskripte
- Wissen über Speichersysteme
- Fachkenntnisse in der Planung und Umsetzung von Netzwerken
- Sicherheit
Einrichtung und Verwaltung der OpenShift-Plattform
Arbeiten:
- Durchführung der Clusterinstallation
- Management von Infrastruktur-Services
- Skalierungsmanagement der Plattform
- Authentifizierung und Autorisierung auf Plattformebene
- Systemadministration für Linux
- Kenntnisse in Netzwerktechnologien
- Automatisierungsskripte (Ansible)
- Wissen über Speichersysteme
- Kenntnisse über Containertechnologien und -architekturen
- Vertrautheit mit Kubernetes- und OpenShift-Architekturen
- Plattformsicherheit
- Integration von Monitoring-Lösungen
Management der Bereitstellung von Mandantenumgebungen (tenant provisioning) und Isolation von IT-Ressourcen
Arbeiten:
- Erstellung von Benutzern und Gruppen innerhalb der Plattform
- Gestaltung und Verwaltung von Quoten
- Planung und Implementierung von RBAC
- Vertrautheit mit Kubernetes- und OpenShift-Architekturen
- Kenntnisse über Containertechnologien und -architekturen
- Automatisierungsskripte
- Gute Kenntnisse in Projekten, Quoten, Rollenbindung und der Arbeit mit Planern
Erstellung und Verwaltung von Basis-Images
Arbeiten:
- Entwicklung von Workflow für die Image-Änderung
- Entwicklung von Images nach Standards
- Systemadministration für Linux
- Automatisierungsskripte
- Konfiguration von Runtime-Komponenten von Anwendungen und Middleware
- Kenntnisse über Containerarchitekturen
- Anwendungsbuild-Frameworks
- Gute Kenntnisse in Bezug auf Images, Imagestreams und Vorlagen
Entwurf und Verwaltung von Bereitstellungspipelines
Arbeiten:
- Entwurf und Dokumentation von Pipeline-Standards
- Erstellung von kurzen Leitfäden und Vorlagen
- Schulung von Entwicklern
- Quellcodeverwaltung
- Entwurf und Implementierung von Anwendungen
- Automatisierungsskripte
- Automatisierte Tests
- Codequalitätstest
- Kenntnisse über Containerarchitekturen
- Kenntnisse über unveränderliche Infrastrukturen
- Sicherheit – Verwaltung des Zugriffs auf Pipeline-Stufen, Genehmigung von Arbeitsabläufen usw.
- Gute Kenntnisse der OpenShift-Vorlagen, Buildconfigs, Deploymentconfigs, Services, Routen, Configmaps
Entwicklung von Anwendungen und Tests
Arbeiten:
- Anwendungsprogrammierung
- Entwicklung automatisierter Tests
- Reaktion auf Testausfälle in der Bereitstellungspipeline
- Reaktion auf Anwendungsfehler
- Benutzerakzeptanztests
- Entwurf und Implementierung von Anwendungen
- Automatisierte Tests
- Quellcodeverwaltung
- Anwendungsüberwachung
- Kenntnisse über Cloud-native Anwendungsarchitekturen
Betriebsüberwachung und Anwendungsmanagement
Arbeiten:
- Entwurf von Anwendungen im Hinblick auf Leistung
- Überwachung von Anwendungen während der Ausführung
- Anwendungsskalierung (oder automatisches Skalieren)
- Verwaltung der Verfügbarkeit von Anwendungen
- Anforderungen an Anfragen und Ressourcenkontingente
- Leistungs- und IT-Kapazitätstests
- Gestaltung und Umsetzung der Anwendungsleistung
- Überwachung der Anwendungsleistung
- Leistungs- und Lasttests
Benutzerakzeptanztests
Arbeiten:
- UI-Tests (Design und Benutzerinteraktion)
- Entwicklung automatisierter Tests
- Gestaltung und Überprüfung von Benutzeroberflächen
- Vorlagen für automatisierte Tests
- Test-Frameworks
- Vorlagen für Anwendungsdesign
Neue Rollen, die in einer IT-Organisation bei der Umstellung auf OpenShift entstehen
Mit der Einführung eines DevOps-orientierten Organisierungsmodells nimmt in der Regel die Spezialisierung der Rollen ab, während die Anzahl der funktionsübergreifenden Teams und Rollen zunimmt, um die Effektivität der Zusammenarbeit zu maximieren. So könnte, unserer Meinung nach, die Liste der Hauptpositionen in einer IT-Organisation, die OpenShift nutzt, aussehen:
- Application Operations Engineer oder Site Reliability Engineer. Diese Position wurde früher möglicherweise als „Application Server Administrator“ bezeichnet.
- Anwendungsentwickler / Softwareentwickler / Programmierer.
- Cluster- / Anwendungsplattform-Administrator. Früher wurde diese Rolle als „Systemadministrator“ oder „Linux-Plattformadministrator“ bezeichnet.
- Release Manager / Build Engineer.
RACI-Rollen- und Aufgabenmatrix
Schließlich kommen wir zur Zuordnung der zuvor genannten Positionen und Aufgaben, um einen Überblick darüber zu geben, wie die Struktur einer Organisation aussehen sollte, die DevOps auf der OpenShift-Plattform umsetzt. Zunächst können die unten aufgeführten Rollen von verschiedenen Vertretern der alten, traditionellen Organisationsstruktur wahrgenommen werden. Im Laufe der Zeit erfolgt jedoch eine Konsolidierung und es entstehen neue, um Anwendungen herum gebildete Teams, die die meisten oder sogar alle der unten angegebenen Aufgaben übernehmen.
Aufgaben
Rollen
Anwendungsbetriebsingenieur / Site Reliability Engineer
Anwendungsentwickler / Softwareentwickler / Programmierer
Cluster- / Anwendungsplattformadministrator
Release Manager / Build Engineer
Automatisierung und Bereitstellung (Provisioning) von IT-Infrastrukturen
I
I
R/A
C
Einrichtung und Verwaltung der OpenShift-Plattform
C
I
R/A
C
Entwurf und Verwaltung von Bereitstellungspipelines
C
C
I
R/A
Management der Bereitstellung von Kundenumgebungen (Tenant-Provisioning), Isolierung und IT-Ressourcen
C
I
R/A
I
Erstellung und Verwaltung von Basis-Images
R
C
R/A
C
Entwicklung von Anwendungen und Tests
C
R/A
I
I
Betriebsüberwachung und Anwendungsmanagement
R/A
C
C
I
Benutzerakzeptanztests
C
R
I
I
Legenden in der RACI-Matrix
Quelle:
- Verantwortlich – Ausführender – die Person, die die notwendigen Schritte zur Erledigung der Aufgabe unternimmt.
- Rechenschaftspflichtig – Verantwortlicher – der Mitarbeiter, der letztendlich für die korrekte und sorgfältige Erledigung der Aufgabe oder das Erreichen des Ergebnisses verantwortlich ist; auch die einzige Person, die die Arbeit delegieren kann.
- Konsultiert – Berater – in der Regel Experten auf ihrem Gebiet, deren Rat eingeholt wird; die Kommunikation erfolgt beidseitig.
- Informiert – Informierte – Personen, die über den Verlauf der Ereignisse auf dem Laufenden gehalten werden (manchmal erst nach Abschluss der Aufgabe oder Erreichung des Ergebnisses); sie erhalten Informationen einseitig.
Wie die Zusammenarbeit in einem DevOps-Organisation funktioniert
Das traditionelle Ressourcenbereitstellungsschema besteht typischerweise aus einem Zyklus von Anfragen zur Zuteilung von Ressourcen, die dann von mehreren Teams bearbeitet werden. Letztendlich werden alle benötigten Ressourcen zugewiesen und von der anfordernden Seite bestätigt. Häufig 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 Teams in einer traditionellen IT-Organisation. In diesem Schema wenden sich die einen Teams an andere und bitten um die Erledigung notwendiger Aufgaben, häufig unter Nutzung mehr oder weniger formalisierter Kommunikationsmittel wie Ticketsystemen oder E-Mails. Die Anfragen gelangen dann in eine Warteschlange und warten auf ihre Bearbeitung, wobei lange Wartezeiten oft zu einem Verschlechterung oder sogar zu einer Eskalation der Beziehungen zwischen den Teams führen können. Die Spannung wird zusätzlich dadurch verschärft, dass Mitglieder unterschiedlicher Teams selten persönlich miteinander in Kontakt treten und in der Regel nur die minimal notwendigen Informationen austauschen.
Abbildung 2. IT-Organisation DevOps
Dieses Diagramm zeigt, wie die Zusammenarbeit in einer DevOps-Organisation strukturiert ist. Hier haben die gleichen Teams aus dem vorherigen Diagramm ineffiziente Kommunikationswege, die die Fragmentierung verstärkten, aufgegeben und durch persönliche Kontakte ersetzt, wodurch sie kontinuierliche Kommunikationskanäle zwischen den Teams geschaffen haben. Diese Kanäle fördern die Entwicklung eines hybriden Fähigkeitssets, das den Mitarbeitern hilft, die Bedürfnisse, Herausforderungen und Möglichkeiten der Teams, die sie vertreten, besser zu verstehen und darzustellen. Die Teams ermöglichen es einander, benötigte Arbeiten über automatisierte Self-Service-Portale zu erledigen, anstatt manuell die Anfragen anderer zur Änderung zu bearbeiten, wie es früher der Fall war. Dank dieser Kommunikationskanäle können sich diese Self-Service-Systeme schnell an die Bedürfnisse der Teams anpassen, für die sie geschaffen wurden. Um zusätzliches Verständnis und Wissensaustausch innerhalb der Organisation zu fördern, rotieren die Teammitglieder regelmäßig in ihren Rollen, um Erfahrungen im Umgang mit verschiedenen Teams zu sammeln und ein besseres Gesamtverständnis der IT-Systeme, die sie betreuen, zu erlangen, wodurch ihr Niveau an Cross-Functionality und Nützlichkeit steigt.
Zusammenfassend
In diesem Beitrag haben wir erörtert, wie die Implementierung von PaaS-Lösungen Organisationen dazu anregen kann, die DevOps-Methodik einzuführen, wobei auch die traditionellen Rollen und Aufgaben während dieses Prozesses verändert werden. Daher haben wir die zentralen IT-Herausforderungen aufgelistet, die für Organisationen mit dem Übergang zu OpenShift entstehen, sowie die erforderlichen Fähigkeiten zu deren Bewältigung. Zudem haben wir einen grundlegenden Satz organisatorischer Rollen aufgeführt, die beim Aufbau von cross-funktionalen DevOps-Teams entstehen, sowie eine RACI-Matrix, die neue Rollen mit neuen Aufgaben verknüpft. Schließlich haben wir erläutert, wie die OpenShift-Plattform und die damit verbundene DevOps-Methodik die Organisationsstruktur bei der Ablösung von traditionellen Hierarchien und Antragsbearbeitungssystemen durch cross-funktionale Teams mit einem höheren Maß an persönlicher Kommunikation verändern können.
Quelle: habr.com
