Jak OpenShift zmienia strukturę organizacyjną organizacji IT. Ewolucja modeli organizacyjnych podczas przejścia na PaaS

Choć same rozwiązania PaaS (platforma jako usługa) nie są w stanie zmienić sposobu interakcji poszczególnych osób i zespołów, często służą one jako katalizator zmian organizacyjnych w odpowiedzi na zwiększoną elastyczność IT.

W rzeczywistości maksymalny zwrot z inwestycji w PaaS często można osiągnąć jedynie poprzez zmianę ról organizacyjnych, obowiązków (zadań) i relacji. Na szczęście rozwiązania PaaS takie jak OpenShift Container Platform są na tyle elastyczne, że pozwalają każdej organizacji IT określić szybkość i skalę zmian w stosunku do zaangażowanych osób i zachodzących procesów.

Na pierwszym etapie konteneryzacji przedsiębiorstwa głównym priorytetem jest wdrożenie platformy kontenerowej jako nowego systemu wdrażania aplikacji. Na tym etapie organizacje łączą znane stanowiska ze znanymi rolami, aby odpowiedzieć na standardowe żądania zespołów programistycznych dotyczące takich kwestii, jak systemy pamięci masowej, środowiska wdrożeniowe i tak dalej. Na kolejnych etapach konteneryzacji mówimy już o automatyzacji, czyli zapewnieniu deweloperom możliwości samoobsługi, aby odciążyć administratorów systemów i wynieść autonomię i efektywność programistów na wyższy poziom. W ten sposób organizacja zaczyna zmierzać w kierunku DevOps. Na końcowym etapie konteneryzacji przedsiębiorstwo dochodzi do czystszego, kanonicznego modelu DevOps, w ramach którego wiele dotychczasowych zadań i prac przechodzi pod kontrolę zespołów interdyscyplinarnych, pogrupowanych nie według platform czy technologii, ale z punktu widzenia w celu zapewnienia działania aplikacji lub usług aplikacyjnych.

W tym poście podamy wskazówki, jak dokonać niezbędnych zmian organizacyjnych i jak zmieniają się tradycyjne role IT wraz z przyjęciem technologii kontenerowych w przedsiębiorstwie.

Łączenie nowych stanowisk pracy ze starymi rolami

W swojej podstawowej, początkowej formie, model organizacyjny PaaS został zaprojektowany tak, aby elastyczniej i szybciej przydzielać zasoby IT aplikacjom w formie środowiska wykonawczego. Chociaż zapewnia to pewne korzyści administratorom systemów, programiści zazwyczaj nie zyskują żadnych znaczących korzyści ani nowych możliwości, ponieważ na tym etapie przedsiębiorstwo może z łatwością obejść się bez automatyzacji, samoobsługi czy radykalnej poprawy procesu wdrażania. Mimo minimalnego wpływu na procesy programistyczne na tym etapie, PaaS zwiększa jednak elastyczność systemu IT, umożliwiając administratorom lepszą obsługę zgłoszeń programistów. Na przykład, podczas tworzenia środowiska programistycznego z kilku… maszyna wirtualna Podczas gdy tworzenie i wdrażanie wolumenów pamięci masowej mogło trwać dni, a nawet tygodnie, wymagając zaangażowania kilku różnych administratorów, w PaaS wszystko odbywa się znacznie szybciej i przez jednego administratora. Innymi słowy, zespoły programistów zgłaszają wnioski jak dotychczas, ale prace nad ich wdrożeniem są teraz realizowane według nowego modelu.

W stronę organizacji DevOps

Uruchamiając PaaS i przenosząc do niego specjalistów ds. operacji IT oraz twórców aplikacji, organizacja może w dalszym ciągu wdrażać metodologię DevOps, która obejmuje m.in. następujące podstawowe zasady:

• Podziel pracę na małe krokiaby otrzymać wczesną informację zwrotną, zmniejszyć ryzyko i uniknąć paraliżu analitycznego;
• Wystarczająca automatyzacja operacjiaby uniknąć tworzenia przeszkód lub wąskich gardeł w procesie wdrażania aplikacji;
• Wymiana wiedzy – klucz do budowania zaufania;
• Regularnie spłacaj długi techniczne, przeznaczając określony czas w każdym cyklu pracy na systematyczne doskonalenie.

W drugiej fazie wdrażania technologii kontenerowej zespoły programistów w naturalny sposób zaczynają dostrzegać możliwości ulepszeń, a przedsiębiorstwo skłania się w stronę bardziej tradycyjnego modelu DevOps. Tradycyjny mechanizm składania i realizacji zgłoszeń serwisowych jest obecnie postrzegany jako wąskie gardło, dlatego organizacja stara się zautomatyzować powtarzalne działania i zapewnić programistom możliwości samoobsługi. Co więcej, o możliwościach deweloperskich w ramach danej aplikacji decyduje wspólny wysiłek specjalistów IT obsługujących platformy i osób odpowiedzialnych za dostarczanie aplikacji. Innymi słowy, administratorzy systemów, którzy wykonują czynności na zlecenie programistów, są zastępowani przez dwie wyżej wymienione kategorie pracowników, którzy są odpowiedzialni za opisywanie i stosowanie polityk określających, co dokładnie programiści mogą robić we własnym zakresie. Zautomatyzowane procedury pomagają zapewnić zgodność z określonymi wymaganiami i koordynować działania, gdy sytuacja wykracza poza zakres istniejących polityk.

Przejście na harmonogram iteracyjny, w którym środowisko IT i model operacyjny podlegają w czasie iteracyjnym zmianom, jest kluczowym kamieniem milowym w osiągnięciu dojrzałego przedsiębiorstwa DevOps. Stopień przyjęcia metodologii DevOps zależy od indywidualnej tolerancji każdej organizacji na zmiany i tego, które zmiany przynoszą największe korzyści. Przykładowo, jeśli potrzeba tworzenia nowych środowisk lub aplikacji występuje rzadko, wówczas optymalizacja odpowiednich działań będzie mniej istotna niż zwiększenie kontroli dewelopera nad cyklem życia aplikacji.

Nowe wyzwania, które pojawiają się w organizacjach IT podczas migracji do OpenShift

W tej sekcji przyjrzymy się rolom i zadaniom, które organizacje, które wdrożyły OpenShift, zazwyczaj wykorzystują w celu przyspieszenia automatyzacji i samoobsługi przy użyciu technologii i PaaS.

Poniższa tabela zawiera listę głównych zadań najwyższego poziomu istniejących w każdej organizacji, która wdrożyła OpenShift, wraz z przykładami powiązanych stanowisk i umiejętności. Tej listy zadań nie należy mylić ze strukturą podziału pracy lub strukturą zespołu, ale raczej z zestawem zadań, które muszą wykonać osoby odpowiedzialne za wsparcie środowisk IT, aby pomyślnie wdrożyć platformę kontenerową. Tak naprawdę pokażemy dalej, że wprowadzenie technologii kontenerowych stwarza przesłanki do ukształtowania się w przedsiębiorstwie bardziej dojrzałej strategii DevOps, co z kolei zwiększa stopień cross-funkcjonalności zespołów i zmniejsza ryzyko wąskiej specjalizacji na poziomie poziom zarówno indywidualny, jak i zespołowy.

Tabela 1. Definicje zadań OpenShift

zadania
Wymagane umiejętności

Automatyzacja i udostępnianie infrastruktury IT

Działa:

• Projektowanie i budowa rozwiązań sprzętowych
• Organizacja i wsparcie automatyzacji wstępnej konfiguracji
• Projektowanie i automatyzacja przygotowania maszyny wirtualnej i hosta

• Projektowanie i wdrażanie centrów danych
• Administracja systemem Linux
• Scenariusze automatyzacji
• Znajomość systemów magazynowania
• Znajomość projektowania i wdrażania sieci
• bezpieczeństwo

Instalacja i zarządzanie platformą OpenShift

Działa:

• Przeprowadzanie instalacji klastra
• Zarządzanie usługami infrastrukturalnymi
• Zarządzanie skalowaniem platformy
• Uwierzytelnianie i autoryzacja na poziomie platformy

• Administracja systemem Linux
• Znajomość technologii sieciowych
• Skrypty automatyzujące (Ansible)
• Znajomość systemów magazynowania
• Znajomość technologii i architektur kontenerowych
• Znajomość architektur Kubernetes i OpenShift
• Bezpieczeństwo platformy
• Integracja monitorowania

Zarządzanie przygotowaniem środowisk klienckich (dzierżawa zasobów), izolacja zasobów IT

Działa:

• Tworzenie użytkowników i zespołów w ramach platformy
• Projektowanie kwot i zarządzanie nimi
• Projekt i wdrożenie RBAC

• Znajomość architektur Kubernetes i OpenShift
• Znajomość technologii i architektur kontenerowych
• Scenariusze automatyzacji
• Dobra znajomość projektów, kwot, przydziału ról i współpracy z planistami

Tworzenie i zarządzanie obrazami bazowymi

Działa:

• Opracowanie procesu modyfikacji obrazu
• Tworzenie wizerunku w oparciu o standardy

• Administracja systemem Linux
• Scenariusze automatyzacji
• Konfigurowanie komponentów aplikacji i oprogramowania pośredniczącego w czasie wykonywania
• Znajomość architektur kontenerowych
• Frameworki do tworzenia aplikacji
• Dobra znajomość obrazów, strumienia obrazów i szablonów

Projektuj potoki wdrażania i zarządzaj nimi

Działa:

• Projektowanie i dokumentacja standardów przenośników
• Opracowywanie szybkich przewodników i szablonów
• Szkolenia programistów

• Zarządzanie kodem źródłowym
• Projektowanie i wdrażanie aplikacji
• Scenariusze automatyzacji
• Automatyczne testowanie
• Testowanie jakości kodu
• Znajomość architektur kontenerowych
• Znajomość niezmiennych infrastruktur
• Bezpieczeństwo – zarządzanie dostępem do etapów rurociągu, zatwierdzanie przepływów pracy itp.
• Dobra znajomość szablonów OpenShift, konfiguracji komponentów, konfiguracji wdrażania, usług, tras i map konfiguracyjnych

Tworzenie aplikacji i testów

Działa:

• Kodowanie aplikacji
• Rozwój testów automatycznych
• Reagowanie na niepowodzenia testów podczas potoku wdrożenia
• Reagowanie na błędy aplikacji
• Testowanie akceptacji użytkownika

• Projektowanie i wdrażanie aplikacji
• Automatyczne testowanie
• Zarządzanie kodem źródłowym
• Monitorowanie aplikacji
• Znajomość natywnych architektur aplikacji chmurowych

Monitorowanie operacyjne i zarządzanie aplikacjami

Działa:

• Projektowanie aplikacji w kontekście wydajności
• Monitorowanie aplikacji w czasie wykonywania
• Skalowanie aplikacji (lub autoskalowanie)
• Zarządzanie dostępnością aplikacji
• Żądaj przydziałów i limitów zarządzania zasobami
• Testowanie wydajności i wydajności IT

• Projektowanie i wdrażanie wydajności aplikacji
• Monitorowanie wydajności aplikacji
• Testowanie wydajności i obciążenia

Testowanie akceptacji użytkownika

Działa:

• Testowanie interfejsu użytkownika (projekt i doświadczenie użytkownika)
• Rozwój testów automatycznych

• Projektuj i testuj interfejsy użytkownika
• Zautomatyzowane wzorce testowe
• Frameworki testowe
• Wzorce projektowe aplikacji

Nowe role, które pojawiają się w organizacji IT podczas migracji do OpenShift

W miarę przechodzenia do modelu organizacyjnego skoncentrowanego na DevOps stopień specjalizacji ról ma tendencję do zmniejszania się, a liczba wielofunkcyjnych zespołów i ról z kolei wzrasta, aby zmaksymalizować efektywność współpracy. Oto jak naszym zdaniem wygląda lista kluczowych stanowisk w organizacji IT korzystającej z OpenShift:

• Inżynier ds. operacji aplikacji LUB inżynier ds. niezawodności obiektu. Wcześniej stanowisko to mogło nazywać się „Administrator serwera aplikacji”.
• Programista aplikacji/programista oprogramowania/inżynier oprogramowania.
• Administrator platformy klastra/aplikacji. Wcześniej ta rola mogła być nazywana „Administratorem systemu” lub „Administratorem”. Linux-platformy".
• Menedżer wersji/Inżynier kompilacji.

Macierz ról i zadań RACI

Na koniec przechodzimy do porównania omówionych powyżej stanowisk i zadań, aby dać ogólne wyobrażenie o tym, jak powinna wyglądać struktura organizacji wdrażającej DevOps na platformie OpenShift. Początkowo poniższe role mogą pełnić różne gałęzie starej, tradycyjnej struktury organizacyjnej. Jednak z biegiem czasu następuje konsolidacja i budowane są nowe zespoły wokół aplikacji, które wykonują większość lub nawet wszystkie zadania wymienione poniżej.

zadania
Role

Inżynier ds. operacji aplikacji / Inżynier ds. niezawodności witryny
Programista aplikacji / Programista oprogramowania / Inżynier oprogramowania
Administrator Klastra/Platformy Aplikacyjnej
Menedżer ds. wersji oprogramowania/inżynier montażu

Automatyzacja i udostępnianie infrastruktury IT
I
I
R / A
C

Instalacja i zarządzanie platformą OpenShift
C
I
R / A
C

Projektuj potoki wdrażania i zarządzaj nimi
C
C
I
R / A

Zarządzaj udostępnianiem najemców, izolacją i wydajnością IT
C
I
R / A
I

Tworzenie i zarządzanie obrazami bazowymi
R
C
R / A
C

Tworzenie aplikacji i testów
C
R / A
I
I

Monitorowanie operacyjne i zarządzanie aplikacjami
R / A
C
C
I

Testowanie akceptacji użytkownika
C
R
I
I

Konwencje w macierzy RACI
Źródło: Wikipedia

• Odpowiedzialny – Wykonawca to ten, który robi wszystko, co konieczne, aby wykonać zadanie.
• Odpowiedzialny – Odpowiedzialny – pracownik, który ostatecznie ponosi odpowiedzialność za prawidłowe i rzetelne wykonanie zadania lub osiągnięcie wyniku; a także jako jedyny może delegować pracę wykonawcom.
• konsultowany – Konsultanci – zazwyczaj są to eksperci w danej dziedzinie, do których zwraca się o poradę; Utrzymuje się z nimi dwustronną komunikację.
• Poinformowany – Poinformowani – ludzie, którzy są na bieżąco informowani o zdarzeniach (a czasami dopiero po wykonaniu zadania lub osiągnięciu wyniku); otrzymują informacje jednostronnie.

Jak zespoły współpracują w organizacji DevOps

Tradycyjne pozyskiwanie zasobów zazwyczaj obejmuje cykl żądań zasobów, które są następnie realizowane przez wiele zespołów. Ostatecznie wszystkie niezbędne zasoby są przydzielane i potwierdzane przez stronę wnioskującą. Często procesy te są częściowo lub całkowicie ręczne i wymagają częstych i wielokrotnych interakcji między zespołami, aby pomyślnie przetworzyć każde żądanie.

Rysunek 1. Tradycyjna organizacja IT

Powyższy diagram ilustruje typowe relacje pomiędzy zespołami w tradycyjnej organizacji IT. W tym schemacie niektóre zespoły kontaktują się z innymi zespołami z prośbą o wykonanie niezbędnych prac, korzystając z mniej lub bardziej formalnych środków komunikacji, takich jak system zgłoszeń czy poczta elektroniczna. Zgłoszenia te następnie trafiają do kolejki i czekają z boku, a długie oczekiwanie często prowadzi do pogorszenia, a nawet zaostrzenia relacji między zespołami. Napięcie zwiększa fakt, że członkowie różnych zespołów rzadko spotykają się osobiście i zazwyczaj przekazują sobie jedynie minimum niezbędnych informacji.

Rysunek 2: Organizacja IT DevOps

Ten diagram pokazuje, jak działa współpraca w organizacji DevOps. Tutaj te same zespoły z poprzedniego diagramu porzuciły nieefektywną komunikację, która wzmacniała silosy i zastąpiła je kontaktami osobistymi, tworząc w ten sposób stałe kanały interakcji pomiędzy zespołami. Kanały te wspierają hybrydowy zestaw umiejętności, który pomaga pracownikom lepiej zrozumieć i wyobrazić sobie potrzeby, wyzwania i możliwości zespołów, które reprezentują. Zespoły umożliwiają sobie nawzajem wykonywanie pracy za pośrednictwem zautomatyzowanych portali samoobsługowych, zamiast ręcznej obsługi żądań zmian innych osób, jak miało to miejsce w przeszłości. A dzięki obecności kanałów interakcji te samoobsługowe systemy potrafią szybko dostosować się do potrzeb zespołów, dla których są przeznaczone. Aby osiągnąć jeszcze większe zrozumienie i dzielenie się wiedzą w organizacji, członkowie zespołu okresowo zmieniają role, aby zdobyć doświadczenie w interakcji z różnymi zespołami i lepiej zrozumieć ogólny obraz obsługiwanych przez siebie systemów informatycznych, zwiększając w ten sposób ich poziom wielofunkcyjności i użyteczności.

Reasumując

W tym poście omówiliśmy, w jaki sposób przyjęcie rozwiązań PaaS może skierować organizację w stronę DevOps, zmieniając w ramach procesu tradycyjne role i zadania. Dlatego wymieniliśmy główne wyzwania IT, przed którymi stoi organizacja podczas migracji do OpenShift, a także umiejętności wymagane do ich ukończenia. Udostępniliśmy także podstawowy zestaw ról organizacyjnych, które powstają podczas budowania wielofunkcyjnych zespołów DevOps, oraz macierz RACI, która łączy nowe role z nowymi zadaniami. Na koniec omówiliśmy, w jaki sposób platforma OpenShift i związana z nią metodologia DevOps mogą zmienić strukturę organizacyjną organizacji w miarę przechodzenia od tradycyjnych hierarchii i systemów zgłoszeń do zespołów wielofunkcyjnych o wyższym poziomie komunikacji osobistej.

Źródło: www.habr.com