Jak OpenShift zmienia strukturę organizacyjną IT. Ewolucja modeli organizacyjnych przy przejściu na PaaS

Chociaż same rozwiązania PaaS („Platforma jako usługa”) nie są w stanie zmienić sposobów interakcji indywidualnych i zespołowych, często stają się one katalizatorem zmian organizacyjnych w odpowiedzi na większą elastyczność technologii IT.

W rzeczywistości maksymalne zwroty z inwestycji w PaaS są często możliwe tylko po zmianach w rolach organizacyjnych, zakresach odpowiedzialności i schematach relacji. Na szczęście rozwiązania PaaS, takie jak OpenShift Container Platform, oferują wystarczającą elastyczność, aby każda organizacja IT mogła samodzielnie określić tempo i zakres zmian dotyczących zaangażowanych ludzi i procesów.

Na pierwszym etapie konteneryzacji przedsiębiorstwa głównym priorytetem jest wdrożenie platformy kontenerowej jako nowego systemu wdrażania aplikacji. W tym momencie organizacje przypisują znane zadania do znanych ról, aby reagować na standardowe zapytania zespołów deweloperskich w takich kwestiach, jak systemy przechowywania, środowiska wdrażania itp. W kolejnych etapach konteneryzacji mowa już o automatyzacji lub zapewnieniu deweloperom możliwości samodzielnego działania, aby zmniejszyć obciążenie administratorów systemów i podnieść autonomiczność oraz szybkość deweloperów na wyższy poziom. W ten sposób organizacja zaczyna kierować się w stronę DevOps. Na końcowym etapie konteneryzacji przedsiębiorstwo przechodzi do czystszej, kanonicznej modelu DevOps, w ramach którego wiele wcześniejszych zadań i prac przechodzi pod kontrolę zespołów międzyfunkcyjnych, które grupują się nie zgodnie z platformami lub technologiami, ale z punktu widzenia zapewnienia działania aplikacji lub usług aplikacyjnych.

W tym poście przedstawimy przewodnik po niezbędnych zmianach organizacyjnych i opowiemy, jak tradycyjne role IT zmieniają się wraz z wdrażaniem technologii kontenerowych w przedsiębiorstwie.

Przypisanie nowych zadań do starych ról

W swojej podstawowej formie organizacyjny model PaaS jest tworzony w celu elastyczniejszego i szybszego przydzielania zasobów IT aplikacjom jako środowiska wykonawczego. Mimo że daje to pewne korzyści administratorom systemów, deweloperzy zazwyczaj nie uzyskują żadnych istotnych zysków ani nowych możliwości, ponieważ na tym etapie firma spokojnie może obejść się bez automatyzacji, wprowadzania samoobsługi czy radykalnego ulepszania procesu wdrażania. Minimalnie wpływając na procesy rozwoju, PaaS jednak zwiększa dynamikę systemu IT, co pozwala administratorom lepiej obsługiwać potrzeby deweloperów. Na przykład, jeśli wcześniej tworzenie środowiska deweloperskiego wymagało dni, a nawet tygodni, i angażowało wielu różnych administratorów, to w PaaS wszystko odbywa się znacznie szybciej i za pomocą tylko jednego administratora. maszyn wirtualnych Innymi słowy, zespoły deweloperskie składają wnioski jak wcześniej, ale prace nad ich realizacją są teraz wykonywane według nowego schematu.

Na drodze do organizacji DevOps

Uruchamiając PaaS i przenosząc na nią specjalistów ds. eksploatacji systemów IT i deweloperów aplikacji, organizacja może kontynuować wdrażanie metodologii DevOps, która między innymi obejmuje następujące podstawowe zasady:

• Dzielić pracę na mniejsze etapy, aby uzyskiwać informacje zwrotne na wczesnym etapie, zmniejszać ryzyko i unikać „paraliżu analitycznego”;
• Automatyzować operacje w wystarczającym stopniu, aby nie tworzyć przeszkód ani wąskich gardeł w procesie wdrażania aplikacji;
• Wymiana wiedzy – klucz do budowania zaufania;
• Regularnie spłacać długi technologiczne, przeznaczając w każdym cyklu pracy określony czas na systematyczne ulepszanie.

W drugim etapie wdrażania technologii kontenerowych zespoły deweloperskie zaczynają dostrzegać możliwości poprawy, a firma skłania się ku bardziej kanonicznemu modelowi DevOps. Tradycyjny mechanizm składania i realizowania wniosków o usługi jest teraz postrzegany jako wąskie gardło, dlatego organizacja dąży do automatyzacji powtarzalnych działań i udostępnienia deweloperom możliwości samodzielnego zarządzania. Przy czym te możliwości deweloperów w ramach danej prośby są określane wspólnymi wysiłkami specjalistów IT zajmujących się eksploatacją platform oraz tych, którzy są odpowiedzialni za dostarczanie aplikacji. Innymi słowy, zamiast administratorów systemów wykonujących działania na wnioski deweloperów, przychodzą dwie wcześniej wspomniane kategorie pracowników, które odpowiadają za opis i wdrażanie polityk regulujących, co dokładnie deweloperom wolno wykonywać samodzielnie. Automatyzowane procedury pomagają zapewnić zgodność z tymi wymaganiami oraz koordynować działania w przypadkach, gdy sytuacja wychodzi poza obowiązujące polityki.

Przejście na iteracyjny harmonogram, w którym środowisko IT i model operacyjny podlegają iteracyjnym zmianom w czasie, jest krytycznym etapem w kształtowaniu dojrzałego systemu DevOps w firmie. Stopień przyjęcia metodologii DevOps zależy od tolerancji każdej konkretnej organizacji na zmiany oraz od tego, jakie zmiany przynoszą największe korzyści. Na przykład, jeśli potrzeba stworzenia nowych środowisk lub aplikacji występuje rzadko, to optymalizacja odpowiednich działań będzie mniej ważna niż wzmocnienie kontroli deweloperów nad cyklem życia aplikacji.

Nowe zadania, które pojawiają się w organizacjach IT przy przejściu na OpenShift

W tej sekcji omówimy role i zadania, które organizacje przechodzące na OpenShift zazwyczaj stosują, aby przyspieszyć automatyzację i samodzielne zarządzanie z wykorzystaniem technologii PaaS.

W poniższej tabeli przedstawiono podstawowe zadania na wysokim poziomie, które występują w każdej organizacji wdrażającej OpenShift, z przykładami odpowiednich prac i umiejętności. Ta lista zadań nie powinna być mylona z podziałem prac czy strukturą organizacyjną zespołów, to tylko zbiór zadań, które powinny zostać zrealizowane przez osoby odpowiedzialne za wsparcie środowiska IT, aby zapewnić pomyślne wdrożenie platformy kontenerowej. W rzeczywistości pokażemy dalej, że wdrożenie technologii kontenerowych stwarza przesłanki do rozwoju bardziej dojrzałej strategii DevOps w przedsiębiorstwie, co z kolei zwiększa stopień współpracy międzyfunkcyjnej zespołów i zmniejsza ryzyko wąskiej specjalizacji zarówno na poziomie poszczególnych pracowników, jak i zespołów.

Tabela 1. Definicje zadań OpenShift

Zadania
Wymagane umiejętności

Automatyzacja i przygotowanie (provisioning) infrastruktury IT

Prace:

• Projektowanie i budowa rozwiązań sprzętowych
• Organizacja i obsługa automatyzacji początkowej konfiguracji
• Projektowanie i automatyzacja przygotowania VM oraz hostów

• Projektowanie i realizacja centrów danych
• Administracja systemami Linux
• Scenariusze automatyzacji
• Znajomość systemów przechowywania
• Znajomość w zakresie projektowania i realizacji sieci
• Bezpieczeństwo

Instalacja i zarządzanie platformą OpenShift

Prace:

• Wykonanie instalacji klastra
• Zarządzanie usługami infrastrukturalnymi
• Zarządzanie skalowalnością platformy
• Weryfikacja tożsamości i autoryzacja na poziomie platformy

• Administracja systemami Linux
• Znajomość technologii sieciowych
• Scenariusze automatyzacji (Ansible)
• Znajomość systemów przechowywania
• Znajomość technologii i architektur kontenerowych
• Znajomość architektur Kubernetes i OpenShift
• Bezpieczeństwo platform
• Integracja monitorowania

Zarządzanie przygotowaniem środowisk klientów (tenant provisioning), izolacją zasobów IT

Prace:

• Tworzenie użytkowników i zespołów w ramach platformy
• Projektowanie i zarządzanie kwotami
• Projektowanie i realizacja RBAC

• Znajomość architektur Kubernetes i OpenShift
• Znajomość technologii i architektur kontenerowych
• Scenariusze automatyzacji
• Dobre znajomości w zakresie projektów, kwot, przypisywania ról i pracy z planerami

Budowa i zarządzanie podstawowymi obrazami

Prace:

• Rozwój workflow zmiany obrazów
• Rozwój obrazów zgodnych z normami

• Administracja systemami Linux
• Scenariusze automatyzacji
• Konfigurowanie komponentów runtime aplikacji i middleware
• Znajomość architektur kontenerowych
• Frameworki budowy aplikacji (application build frameworks)
• Dobre znajomości w zakresie obrazów, imagestream i szablonów

Projektowanie i zarządzanie potokami wdrożeniowymi

Prace:

• Projektowanie i dokumentowanie standardów potoków
• Opracowanie zwięzłych przewodników i szablonów
• Szkolenie programistów

• Zarządzanie kodem źródłowym
• Projektowanie i wdrażanie aplikacji
• Scenariusze automatyzacji
• Zautomatyzowane testowanie
• Testowanie jakości kodu
• Znajomość architektur kontenerowych
• Znajomość niezmiennych infrastruktur
• Bezpieczeństwo – zarządzanie dostępem do etapów potoku, zatwierdzanie procesów roboczych itp.
• Dobra znajomość szablonów OpenShift, komponentów buildconfigs, deploymentconfigs, services, routes, configmaps

Opracowanie aplikacji i testów

Prace:

• Kodowanie aplikacji
• Opracowanie zautomatyzowanych testów
• Reagowanie na niepowodzenia testów w trakcie potoku wdrożeniowego
• Reagowanie na awarie aplikacji
• Testowanie akceptacyjne użytkowników

• Projektowanie i wdrażanie aplikacji
• Zautomatyzowane testowanie
• Zarządzanie kodem źródłowym
• Monitoring aplikacji
• Znajomość architektur aplikacji chmurowych (cloud native)

Operacyjne monitorowanie i zarządzanie aplikacjami

Prace:

• Projektowanie aplikacji w kontekście wydajności
• Monitoring aplikacji w czasie rzeczywistym
• Skalowanie aplikacji (lub automatyczne skalowanie)
• Zarządzanie dostępnością aplikacji
• Limity zapytań i zarządzanie zasobami
• Testowanie wydajności i możliwości IT

• Projektowanie i realizacja wydajności aplikacji
• Monitorowanie wydajności aplikacji
• Testowanie wydajności i testowanie obciążeniowe

Testowanie akceptacyjne użytkowników

Prace:

• Testowanie UI (projekt i interakcje z użytkownikiem)
• Opracowanie zautomatyzowanych testów

• Projektowanie i weryfikacja interfejsów użytkownika
• Szablony zautomatyzowanego testowania
• Ramy testowe
• Szablony projektowania aplikacji

Nowe role, które powstają w organizacji IT podczas przejścia na OpenShift

W miarę przechodzenia na model organizacyjny zorientowany na DevOps, liczba specjalizacji ról zazwyczaj maleje, podczas gdy liczba zespołów i ról wielofunkcyjnych wzrasta, aby maksymalizować efektywność współpracy. Oto jak według nas wygląda lista podstawowych stanowisk w organizacji IT korzystającej z OpenShift:

• Inżynier operacji aplikacji (Application Operations Engineer) LUB Inżynier niezawodności systemu (Site Reliability Engineer). Wcześniej ta pozycja mogła być znana jako 'Administrator serwera aplikacji'.
• Programista aplikacji/programista oprogramowania/inżynier-programista.
• Administrator klastra/platformy aplikacji. Ta rola mogła być wcześniej nazywana „Administratorem systemu” lub „Administratorem platform Linux”.
• Menadżer ds. wydania oprogramowania (Release Manager)/Inżynier ds. budowy (Build Engineer).

Macierz ról i zadań RACI

W końcu przechodzimy do przyporządkowania wcześniej omówionych pozycji i zadań, aby dać ogólny obraz tego, jak powinna wyglądać struktura organizacji implementującej DevOps na platformie OpenShift. Początkowo poniżej wymienione role mogą być realizowane przez różne gałęzie starej, tradycyjnej struktury organizacyjnej. Jednak z biegiem czasu następuje konsolidacja i pojawiają się nowe zespoły, budowane wokół aplikacji, które przejmują większość lub nawet wszystkie wymienione poniżej zadania.

Zadania
Role

Inżynier ds. eksploatacji aplikacji/Inżynier ds. niezawodności strony
Programista aplikacji/Programista oprogramowania/Inżynier programista
Administrator klastra/platformy aplikacji
Menadżer ds. wydania oprogramowania/Inżynier ds. budowy

Automatyzacja i przygotowanie (provisioning) infrastruktury IT
I
I
R/A
C

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

Projektowanie i zarządzanie potokami wdrożeniowymi
C
C
I
R/A

Zarządzanie przygotowaniem środowisk klientów (tenant provisioning), izolację i możliwości IT
C
I
R/A
I

Budowa i zarządzanie podstawowymi obrazami
R
C
R/A
C

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

Operacyjne monitorowanie i zarządzanie aplikacjami
R/A
C
C
I

Testowanie akceptacyjne użytkowników
C
R
I
I

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

• Odpowiedzialny – Wykonawca – ten, kto wykonuje niezbędne zadania.
• Odpowiedzialny – Osoba odpowiedzialna – pracownik, który w końcu odpowiada za prawidłowe i dokładne wykonanie zadania lub osiągnięcie rezultatu; a także jedyny, kto może delegować prace wykonawcom.
• Konsultowany – Konsultanci – zazwyczaj są to eksperci w danej dziedzinie, których rada jest zasięgana; utrzymuje się z nimi dwustronną komunikację.
• Informowany – Osoby informowane – ludzi, którzy są na bieżąco informowani (czasami tylko po zakończeniu zadania lub osiągnięciu rezultatu); otrzymują informacje jednostronnie.

Jak wygląda współpraca zespołów w organizacji DevOps

Tradycyjny schemat pozyskiwania zasobów zazwyczaj przedstawia cykl zapytań o przydział zasobów, które następnie są realizowane przez kilka zespołów. Ostatecznie wszystkie niezbędne zasoby są przydzielane i potwierdzane przez stronę wnioskującą. Często procesy te są częściowo, a nawet całkowicie realizowane ręcznie i wymagają częstych i licznych interakcji między zespołami, aby skutecznie przetworzyć każde zapytanie.

Rysunek 1. Tradycyjna organizacja IT

Diagram powyżej ilustruje typowe relacje między zespołami w tradycyjnej organizacji IT. W ramach tego schematu jedne zespoły zwracają się do innych zespołów z prośbą o wykonanie niezbędnych prac, korzystając z bardziej lub mniej sformalizowanych środków komunikacji, takich jak systemy zgłoszeń czy e-mail. Następnie te prośby trafiają do kolejki i czekają na swoją kolej, a długie oczekiwanie często prowadzi do pogorszenia, a nawet zaostrzenia relacji między zespołami. Napięcie pogłębia się także przez to, że członkowie różnych zespołów rzadko spotykają się osobiście i zazwyczaj dzielą się jedynie minimalnie potrzebnymi informacjami.

Rysunek 2. Organizacja IT DevOps

Na tym diagramie przedstawiono, jak wygląda współpraca w organizacji DevOps. Te same zespoły z poprzedniego diagramu zrezygnowały z nieefektywnych form komunikacji, które potęgowały izolację, i zastąpiły je osobistymi kontaktami, tworząc tym samym stałe kanały interakcji między zespołami. Te kanały sprzyjają formowaniu hybrydowego zestawu umiejętności, który pomaga pracownikom lepiej rozumieć i reprezentować potrzeby, problemy i możliwości zespołów, które reprezentują. Zespoły dają sobie nawzajem możliwość realizacji niezbędnych prac poprzez zautomatyzowane portale samoobsługowe zamiast ręcznego realizowania wniosków o zmiany, jak to miało miejsce wcześniej. Dzięki obecności kanałów interakcji te systemy samoobsługowe mogą szybko dostosowywać się do potrzeb zespołów, dla których zostały stworzone. Aby osiągnąć jeszcze większe zrozumienie i wymianę wiedzy w organizacji, członkowie zespołów okresowo rotują role, aby zdobyć doświadczenie w interakcji z różnymi zespołami i lepiej rozumieć ogólny obraz systemów IT, którymi się zajmują, co zwiększa ich poziom wielofunkcyjności i użyteczności.

Podsumowując

W tym wpisie omówiliśmy, jak wdrożenie rozwiązań PaaS może skłonić organizację do przyjęcia metodologii DevOps, przy czym w ramach tego procesu tradycyjne role i zadania ulegają zmianom. Dlatego wymieniliśmy podstawowe zadania IT, które pojawiają się w organizacji przy przejściu na OpenShift, a także umiejętności niezbędne do ich realizacji. Przedstawiliśmy również podstawowy zestaw ról organizacyjnych, które pojawiają się przy budowie zespołów DevOps o charakterze cross-funkcjonalnym, oraz matrycę RACI, która łączy nowe role z nowymi zadaniami. Na koniec omówiliśmy, jak platforma OpenShift i związana z nią metodologia DevOps mogą zmienić strukturę organizacyjną firmy, przechodząc od tradycyjnej hierarchii i systemów obsługi zgłoszeń do zespołów cross-funkcjonalnych z wyższym poziomem komunikacji osobistej.

Źródło: habr.com