Skip to main content
wysota_1

Automatyzacja zmian

Są takie aspekty zarządzania IT, które wydają się nierozwiązywalne od kilku-kilkunastu lat. Jednym z nich jest obsługa zmian standardowych i releasów aplikacji, a także – od kilku lat – warstwy wirtualizacji.

Z jednej strony – w organizacjach IT (a przynajmniej większości z nich) funkcjonuje imperatyw kontroli zmian, powodujący zwiększenie kosztów obsługi zmiany (zgłoszenie, obsługa w procesie), zwłaszcza w porównaniu do często krtókich aktywności związanych z faktycznycm wdrożeniem, z drugiej – trudności w przeprocesowaniu zmiany (brak integracji narzędziowych, automatyzacji, standaryzacji) od początku do końca.

Bazując na kilku case studies postanowilismy z ekipą Mr. SPOC przyjrzeć się tematowi i zaproponować rozwiązanie. Przy czym poniższy mini-case abstrahuje od tego, czy Wasza organizacja jest „itilowa”, „agile-owa”, „dev-opsowa” czy może stosuje mix podejść.

Założenia brzegowe

Dla celów tego mini-case’a należy przyjąć kilka założeń. Po pierwsze – dostępne narzędzia:

– system klasy ITSM (w naszym wypadku Service Now), umożliwiający integrację z innymi narzędziami na poziomie pojedynczych powiadomień i triggerów, wyzwalających działania w systemach zewnętrznych i na podstawie powiadomień z systemów zewnętrznych – w samym ITSM;

– zmiany kodu, paczki releasowe są obsługiwane w repozytorium wersji (w naszym przypadku GIT) umożliwiającym przegląd (code review) oraz przygotowanie kodu do wdrożenia w integracji z narzędziami autodeploymentu

– system autodeploymentu – tu oczywiście dużo zależy od platformy w ramach której się poruszamy – my na potrzeby mini – case’a przyjęliśmy że takim narzędziem jest …. (Puppet/Chef)

VM Change v.1.0

Kolejne założenia – procesowo-organizacyjne:

– wszystkie zmiany kodu są rejestrowane w repozytorium

– deployment dla przypadków, o których mówimy jest objęty automatyką – poprzez releasowanie kodu na poszczególne środowiska

– wdrażane zmiany są pre-aprobowane do wdrożeń standardowych (bez przeglądu CAB, na podstawie decyzji właściciela Usługi i właściciela procesu Zarządzania Zmianą);

– ustalone są standardowe okna serwisowe – umożliwiające wdrażanie na środowiskach produkcyjnych, bez negatywnego wpływu na działanie usług;

– w organizacji funkcjonuje separacja ról w procesach (SoD – Separation of Duties), umożliwiająca rozdzielenie działań osób uczestniczących w zmianie.

Ile to kosztuje? Jaki jest ROI?

Przygotowanie mechanizmu, który przedstawiamy poniżej to koszt 16-48 roboczogodzin konfiguracji systemów/narzędzi.

W takim modelu obsługa każdej zmiany od momentu złożenia SR/RFC do momentu zakończenia wdrożenia (bez samej produkcji kodu, testów, kosztów przeglądu powdrożeniowego – PIR w wypadku nieudanej zmiany) to 30  minut.

Rozdzielenie ról wymaga 4 ról: Developer, Code Reviewer, Change/Release Coordinator,  Originator/Business Reviewer (jeśli interesuje cię kwestia, które role nie mogą lub… mogą się ze sobą łączyć – skontaktuj się z nami).

Dla porównania – koszt obsługi podobnych zmian w procesie niezautomatyzowanym to ok. 8-24 godzin dla każdej zmiany (osobno obsługa „ticketa” w ITSM, osobno obsługa w repo wersji, paczkowanie i przygotowanie wdrożenia, manualny deployment).

Jak to zrobić?

Podstawą do automatyzacji zmian jest standaryzacja. Dla zmian niestandardowych oczywiście równeiż da się zastosowac podobny mechanizm, jednak w ich przygotowaniu (niestandardowa konfiguracja, niestandardowy kod, zwiększone ryzyko implementacji) nie odczujemy takich korzyści jeśli chodzi o czas procesowania/koszt.

W naszych systemach należy przygotować kilka rzeczy:

  1. Service Now – niestandardowy workflow dla Zmian – obejmujący triggery dla wykonywanych operacji:
  2. Service Now lub zewnętrzna baza Asset Mgmt/CMDB – CI odpowiadające środowisku, dla którego będziemy zarządzać Zmianami – CI poza serwerami (VM/maszyny fizyczne) powinny odwzorowywać strukturę logiczną np. grupę maszyn w określonej roli, logiczną strukturę aplikacji (Instancja aplikacji – Aplikacja – moduł – funkcja)
  3. Repozytorium wersji (GIT) – strukturę repozytorium odpowiadającą logicznie strukturze CI (podział na role maszyn, odwzorowanie środowisk lub struktura aplikacji) oraz zasilenie danymi o kodzie/konfiguracji z właściwych źródeł
  4. Narzędzia autodeploymentu – setup narzędzia, objęcie serwerów agentami i przygotowanie plików konfiguracyjnych i ścieżek dla serwerów, na których będzie realizowany deployment
  5. Globalnie we wszystkich narzędziach – podział ról i uprawnień umożliwiający realizację Zmiany Standardowej

Poniższe diagramy pokazują dwa przypadki – deployment prekonfigurowanej VM na podstawie SR oraz deployment zmian w kodzie aplikacji poprzez CR.

SW Change v.1.0

W zasadzie schemat działania w takim modelu – po konfiguracji narzędzi jest dośc prosty. Na podstawie ticketa (SR/CR), po akceptacji biznesowej (koszty/licencje/decyzja) dokonywana jest zmiana kodu (wariant aplikacyjny) lub deployment znanej konfiguracji na wybrane środowisko. W przypadku zmiany kodu – akceptacja techniczna jest realizowana na poziomie repozytorium wersji (code review). W przypadku deploymentu znanej konfiguracji VM – taka akceptacja nie jest konieczna, ew. w sytuacji, gdy zasoby sprzętowe są ograniczone – powinna nastąpić weryfikacja pod kątem pojemności/wydajności środowiska. Po etapie akceptacji należy wyłącznie wskazać termin (data/czas) realizacji (domyślnie – w oknie serwisowym, nawet na podstawie automatycznych skryptów z CRON, w zalezności od potrzeb i możliwości można modyfikować ten parametr – aż do podejścia continuous deployment – przypominamy, że zmiany realizowane w tym trybie są zmianami standardowymi – mają pomijalny lub niewielki wpływ na działanie usługi). Można na tym etapie także zarejestrować (podejście – maszyna VM w predefiniowanej konfiguracji) nieaktywny CI w CMDB. Po implementacji zmiany z narzędzia autodeloymentu powiadomienie pus ewentualny raport wykonania/błedów trafia do narzędzia ITSM, a bazie CMDB aktualizowane są CI.

Zwróćcie proszę uwagę, że usystematyzowanie ścieżek dla repozytorium wersji i narzędzi autodeploymentu „z automatu” porządkuje zagadnienie kontroli wersji (deployment faktycznie odpowiada temu, co znajduje się w repozytorium).

Podział logiczny CI/ścieżek wg schematu Usługa-Środowisko-Rola również porządkuje architekturę IT. Dodatkowo można uporządkować kwestię adresacji IP, przypisując odpowiednie zakresy tylko i wyłącznie do określonych środowisk/ról.

Ewentualne „wariable” w zakresie definicji ścieżek dla repozytorium/narzędzia autodeploymentu (a przez to i logicznych CI) mogą obejmować podział na środowiska (prod/test/dev/qa itd.), podział na poszczególne DC, jeśli w ramach jednej roli mamy kilka róznych konfiguracji – również odwzorowanie tych różnic (np www1, www2). Znacznie ułatwia to składanie SR dla użytkowników końcowych (nie muszą znać adresacji IP, punktu mocowania, polityk sieciowych itd.) Najistotniejsze jest, aby wskazanie na właściwy szablon konfiguracji było jednoznaczne i logicznie spójne z wersją, zarządzaną w repozytorium.

Comments