W artykule „DevOps – Trzy drogi” opisałem podstawowe zasady jakimi kieruje się DevOps w strumieniu wartości technologii. Teraz chciałbym bliżej przyjrzeć się na czym polega pierwsza droga i w jaki sposób może pomóc w zarządzaniu usługami IT. Pierwsza droga obejmuje zasady przepływu pracy w strumieniu wartości technologii, czyli np wytwarzaniu oprogramowania. Co jest w niej najważniejsze?

Spraw aby praca była widoczna

Pracę można zobaczyć w fabryce, gdzie mamy materiały do produkcji, maszyny i linie produkcyjne oraz pracowników obsługujących te maszyny lub przemieszczających się po zakładzie. Jak jednak to zrobić w przypadku wytwarzania oprogramowania komputerowego? Z pomocą przychodzi bardzo ciekawy wynalazek, tablica kanban. Jest to sposób aby na tablicy zwizualizować pracę, jaka jest wykonywana w zespole. W kolumnach mamy poszczególne etapy, kroki pracy do wykonania. W poziomie możemy mieć np. osoby, które dana pracę wykonują. Bardzo prosto możemy zrobić tablicę kanban rysując ją na dużym arkuszu papieru lub tablicy ścieralnej i naklejając karteczki post-it w odpowiednich kolumnach, jako reprezentację zadań, kart pracy. Na tablicy kanban praca wpływa z lewej strony i jest przekazywana w prawą stronę, pomiędzy kolejnymi etapami pracy. Praca kończy się z prawej strony, która reprezentuje produkcyjne działanie, wykonaną pracę. Takie podejście pozwala na zarządzanie pracą i mierzenie czasu jej wykonania na poszczególnych etapach. Takie obrazowanie pracy pozwala lepiej określać priorytety dla zadań oczekujących w kolejce i w ten sposób zwiększać przepustowość systemu.

Ograniczenie pracy w toku

Kolejna zasada przepływu, pokazuje nam, że powinniśmy ograniczać pracę w toku, czyli tą która jest aktualnie wykonywana. Czy to ma sens? Mamy robić wszystko aby pracy było mniej? Brzmi trochę podejrzanie ale wcale takie nie jest. DevOps wskazuje, że wielozadaniowość jest nieefektywna i proponuje jej ograniczanie, tak aby koncentrować jest na wykonaniu jednego zadania. Do tego wykorzystywana jest oczywiście tablica kanban. Określamy limity pracy w toku (Work In Progress – WIP), dla każdej kolumny lub etapu/ośrodka pracy poprzez ograniczenie liczby kart, które mogą występować w jednej kolumnie. Żadna praca nie może być wykonana, dopóki nie stworzy się jej reprezentacji w postaci karty pracy. Takie podejście nie zmniejsza ale zwiększa efektywność pracy i powoduje, że jest jej wykonywane więcej a nie mniej.

Zmniejszenie wielkości partii

Aby przepływ pracy był jak najbardziej optymalny, musimy zastosować kolejną zasadę, czyli wykonywać pracę w małych partiach. Takie postępowanie prowadzi do skrócenia czasu realizacji pracy oraz zwiększa jej jakość. Przy małych partiach pracy, wcześniej możemy wykryć błędy i je skorygować, tym samym poprawiając jakość pracy. W ten sposób zmniejszamy też współczynnik pracy w toku, który jest kluczowy dla DevOps. Oczywiście jeżeli mamy mniejsze partie pracy to jest ona wykonywana szybciej i czas realizacji jest krótszy. Dodatkowo jesteśmy w stanie szybciej wykrywać błędy i wprowadzać działania naprawcze. Oznacza to także, mniejszą liczbę koniecznych zmian.

Zmniejszenie liczby przełączeń

Aby przepływ pracy był jak najkrótszy, konieczne jest zautomatyzowanie jak największej ilości pracy, aby mogła być wykonywana bez oczekiwania w kolejkach. To kolejna zasada przepływu, którą musimy zastosować. Aby z niej skorzystać musimy zmienić organizację zespołów, tak aby mogły dostarczać wartość bezpośrednio do klienta. W ten sposób skracamy czas jaki praca musi czekać w kolejce i nie przynosi wartości dodanej.

Stałe identyfikowanie i eliminowanie ograniczeń

Jeżeli chcemy aby nasz praca była efektywna, musimy stale identyfikować i eliminować ograniczenia systemu naszej pracy. Najczęściej występujące ograniczenia w wytwarzaniu oprogramowania to:

• Tworzenie środowiska. Kto nie spotkał się z sytuacją, że nie można wdrożyć oprogramowania bo nie ma środowiska do testów funkcjonalnych lub wydajnościowych lub brakuje zasobów do środowiska produkcyjnego? Dążymy do środowisk na żądanie i pełnej automatyzacji ich tworzenia.
• Instalacja kodu. Jeżeli instalacja oprogramowania składa się z wielu kroków i wymaga kilku specjalistów to nie może trwać krótko. Dlatego pracujemy nad pełną automatyzacją instalacji oprogramowania.
• Konfiguracja i uruchamianie testów. Wykonywanie testów ręcznie, przygotowywanie danych testowych, planowanie zasobów ludzkich do testów, to wszystko powoduje, że testy trwają tygodniami. Lekarstwem jest jak w poprzednich punktach zautomatyzowanie testów.
• Zbyt ścisła architektura. Jeżeli architektura nie pozwala wprowadzać zmian bez angażowania procesu zarządzania zmianą i CAB, to jest to ograniczenie. Dążymy do wprowadzania zmian bezpiecznie i z większą autonomią.

Eliminowanie trudności i odpadów w strumieniu wartości

Ta zasada przepływu mówi, że powinniśmy dążyć do zmniejszenia trudności i uciążliwości codziennej pracy przez ciągłe uczenie się w celu osiągnięcia stawianych celów. Przykładowe kategorie trudności i odpadów to:

• Prace wykonane częściowo
• Dodatkowe procesy
• Dodatkowe funkcjonalności
• Oczekiwanie
• Defekty
• Prace niestandardowe i ręczne

Podsumowanie

Opisałem najważniejsze zasady przepływu, będące pierwszą drogą. Praca musi być widoczna, aby można było nią lepiej zarządzać. Należy zmniejszać pracę, która jest aktualnie wykonywana oraz dzielić pracę na małe partie i części. Zmniejszamy liczbę przekazywania pracy z etapu do etapu i z zespołu do zespołu. Ciągle identyfikujemy i eliminujemy ograniczenia systemu pracy. Stale eliminujemy trudności i problemy w strumieniu wartości technologii. Ich zastosowanie i przestrzeganie pozwoli na jak najkrótszy przepływ pracy.

Na podstawie książki „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”.

Artykuł DevOps – Pierwsza droga – Zasady przepływu pochodzi z serwisu Mariusz Siek.

Świat się zmienia. Zarządzanie usługami IT też. To co dziesięć lat temu wydawało się dobre i skuteczne dzisiaj stało się trochę skostniałe i mało elastyczne. Nie znaczy, że całkowicie jest niepotrzebne ale wymaga odświeżenia i dostosowania do istniejących warunków. Tak dzieje się np z ITIL, który w tym roku wprowadza czwartą wersję swojej biblioteki. Zanim jednak Axelos odkryje wszystkie karty postanowiłem bliżej przyjrzeć się DevOps. W tym celu nabyłem książkę „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”. Autorami są Gene Kim, Jez Humble, Patrick Debois i John Willis. Zacząłem ją zgłębiać i chciałbym się podzielić podstawową wiedzą o trzech drogach w DevOps.

Trzy drogi

Jako fundamentalne zasady DevOps wprowadza pojęcie trzech dróg:

• Pierwsza droga – Zasady przepływu pracy
• Druga droga – Zasady sprzężenia zwrotnego
• Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Pierwsza droga – Zasady przepływu pracy

Pierwsza droga mówi o zasadach związanych z przepływem pracy od jej rozpoczęcia do zakończenia. W przypadku strumienia wartości technologii, czyli działu wytwarzania oprogramowania, początkiem przepływu pracy jest zdefiniowanie wymagań biznesowych a końcem wdrożenie oprogramowania zawierającego funkcjonalności dotyczące tych wymagań na produkcję. Proces ten obejmuje przejście od developmentu do operacji (utrzymania). Jakoś nie lubię terminu operacje, bo źle mi się kojarzy i wolę używać „utrzymanie”. Według mnie lepiej odzwierciedla funkcje tej aktywności.

Zasady z pierwszej drogi koncentrują się na zwiększeniu przepływu pracy, tak aby czas od rozpoczęcia do zakończenia pracy był jak najkrótszy. Najważniejsze elementy to:

• Zwiększenie widoczności praca, które najlepiej wykonać poprzez tablicę kanban, umieszczoną w miejscu pracy zespołu
• Zmniejszenie rozmiaru partii, sprowadza się do dzielenia pracy, na jak najmniejsze, niezależne zadania
• Zmniejszenie interwału pracy, poprzez skracanie okresów wydań oprogramowania z miesięcy do tygodni, dni i godzin.
• Tworzenie jakości poprzez przeciwdziałanie przekazywania defektów, pomiędzy poszczególnymi etapami wytwarzania oprogramowania. Jednym słowem usuwanie błędów jak tylko się pojawią.
• Stałe optymalizowanie pracy, poprzez dążenie do ciągłego zwiększania efektywności i usuwania wąskich gardeł

Druga droga – Zasady sprzężenie zwrotnego

Druga droga skupia się na szybkim i stałym przepływie informacji zwrotnych. Najważniejsze jest aby wszystkie informacje, które mogą przyczynić się do skutecznego usuwania problemów były przekazywane na bieżąco z zespołu operacji (utrzymania) do zespołu developerskiego. Celem takiego działania jest:

• Zapobieganie występowaniu podobnych problemów w przyszłości
• Zwiększenie efektywności procesów wykrywania problemów i eliminowania ich skutków.

Budujemy w ten sposób mechanizmy pracy, które mogą rozwiązywać problemy na wczesnym etapie i zapobiegać ich katastrofalnym skutkom.

Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Trzecia droga koncentruje się na:

• Dynamicznym, zdyscyplinowanym i naukowym podejściu do eksperymentowania i podejmowania ryzyka
• Czerpaniu nauki z sukcesów jak i porażek
• Ciągłym skracaniu i wzmacnianiu pętli sprzężenia zwrotnego

Poszukujemy takich usprawnień w naszym codziennym działaniu, które będzie można zastosować globalnie i przyczynią się do poprawy działania innych osób w zespole.

Podsumowanie

Trzy drogi to dopiero początek mojej drogi w DevOps. Podane zasady wyglądają na proste i zrozumiałe. Pozostaje tylko zastosować je w praktyce i zweryfikować jak się sprawdzają. Do zobaczenia na dalszej drodze w odkrywaniu tajników DevOps.

Artykuł DevOps – Trzy drogi pochodzi z serwisu Mariusz Siek.

Od 12 lat zajmuję się zarządzaniem usługami IT. W mojej pracy wykorzystuję najlepsze praktyki ITIL i doświadczenie zdobyte na przestrzeni tego okresu. Świat jednak nie stoi w miejscu i zmienia się bardzo szybko, szczególnie w obszarze technologii. Czy ITIL, który został wymyślony w latach dziewięćdziesiątych poprzedniego wieku, spełnia oczekiwania dzisiejszego IT, które musi sprostać wysokim wymaganiom biznesowym? Czy wersja trzecia ITIL, która ukazała się w 2007 roku, nadal jest aktualna i stosowanie jej przynosi spodziewane korzyści? Jak zmieni się ITIL w wersji 4, która jest zapowiadana na ten rok? Czy ITIL ma szanse w konfrontacji z DevOps, które obecnie jest jednym z najbardziej popularnych i pożądanych podejść na funkcjonowanie IT? Za dużo pytań jak na początek artykułu :-). Spróbujmy znaleźć na nie odpowiedzi.

ITIL

ITIL w wersji 3 wprowadził usługowe podejście do IT i cykl życia usługi. Cykl życia składa się z pięciu faz:

• Strategii
• Projektowania
• Wdrożenia
• Utrzymania
• Ciągłej poprawy

Cykl ten się powtarza, ponieważ zawsze możemy coś zrobić aby usługa była świadczona lepiej, taniej i na wyższym poziomie.

To podejście objęło cały cykl wytwórczy dla usługi, czego nie było w poprzedniej, drugiej wersji biblioteki. Całkowitą nowością była faza strategii. Natomiast pozostałe fazy zostały rozszerzone o brakujące procesy.

Wiele organizacji IT nadal funkcjonuje w oparciu o procesy opisane w ITIL, z uwzględnieniem ich potrzeb i wymagań. Według mnie nie straciły one nic ze swojej aktualności, chociaż mogą się wydawać „ciężkie”, mało zwinne i bardzo sformalizowane. Czy ich biurokracja jest w stanie sprostać, wymaganiom na wykonywanie kilku wdrożeń dziennie?

Rys 1. Na podstawie książki ITIL Service Transition.

DevOps

Po drugiej stronie mamy DevOps, który mocno się rozpycha i pokazuje, że można do wytwarzania i wdrażania usług, rozumianych jako oprogramowanie i infrastruktura sprzętowa, zastosować takie rozwiązania, które pozwolą szybko, sprawnie i bezproblemowo, dostarczać na produkcję nowe funkcjonalności i aplikacje. W największym uproszczeniu, DevOps to połączenie wytwarzania usług (development) z ich utrzymaniem (operations). Usuwamy odwieczny mur pomiędzy rozwojem i utrzymaniem, i tak organizujemy pracę zespołu aby mógł szybko dostarczać wartość biznesową na produkcję. Nie chodzi tu oczywiście tylko o ludzi ale przede wszystkim procesy i narzędzie. Musimy zastosować pełną automatyzację testów, ciągłą integrację, infrastrukturę jako kod i kilka innych specyficznych dla DevOps rozwiązań.

Rys 2. Na podstawie wideo What is DevOps

Wspólne elementy

Czy to oznacza, że nie można pogodzić DevOps z ITIL? Na pierwszy rzut oka, wydaje się, że są to dwa różne światy, jednak po bliższym przyjrzeniu się znajdziemy kilka części wspólnych.

• Cykliczność. Oba podejścia uwzględniają cykliczne działanie, które ma na celu ciągłe doskonalenie wytwarzanych i implementowanych rozwiązań. Łatnie to widać na dwóch powyższych rysunkach. Oczywiście częstotliwość tych cykli jest inna ale można ją próbować synchronizować.
• Procesy. W obu metodykach wykorzystywane są procesy, które muszą być dobrze zaprojektowane, dostosowane i wdrożone do potrzeb organizacji. Co ciekawe niektóre tak samo lub bardzo podobnie się nazywają: zarządzanie zmianą, zarządzanie wydaniami, zarządzanie pojemnością i zarządzanie konfiguracją. Nie trzeba wyjaśniać, że np. proces zarządzania zmianą w ITIL aby działał na potrzeby DevOps musi zostać odpowiednio zmieniony, zaadaptowany i zautomatyzowany.
• Ciągłe doskonalenie. Nie ważne czy nasz cykl wytwórczy trwa jedną godzinę, jeden dzień czy jeden miesiąc, mamy świadomość, że nie dostarczymy idealnego rozwiązania i będziemy musieli je poprawiać, usprawniać i rozwijać. Tak samo do tego zagadnienia podchodzą obie metodologie i to daje szansę na ich wspólne funkcjonowanie.
• Narzędzia. Do wsparcia procesów zarówno w ITIL jak i DevOps potrzebne są specjalistyczne narzędzia. Oczywiście są to innego rodzaju narzędzia, bo specyfika jest różna ale bez narzędzi, obsługa procesów nie byłaby możliwa.

Chociaż ITIL i DevOps, wydają się dwoma, odmiennymi światami, to można znaleźć kilka cech wspólnych, które pozwalają na funkcjonowanie obu podejść jednocześnie w tej samem organizacji. ITIL nie wyklucza DevOps i DevOps nie wyklucza ITIL. Można wykorzystać obie metodologie i stworzyć własne rozwiązanie dopasowane do potrzeb organizacji. Wydaje się, że to ITIL, zgodnie z dewizą „adopt and adapt” musi dopasować się do DevOps a nie odwrotnie. Wymaga to jednak poważnego zastanowienia się jak to zrobić.

Pytanie: Czy uważasz, że można pogodzić ITIL i DevOps i dlaczego?

Artykuł Czy ITIL i DevOps można pogodzić? pochodzi z serwisu Mariusz Siek.

Tak jak obiecałem w jednym z poprzednich wpisów, dzisiaj recenzja książki. Kupiłem tą książkę aby dowiedzieć się coś o DevOps. W podtytule było napisane „Powieść o IT, modelu DevOps i o tym jak pomóc firmie w odniesieniu sukcesu”. Trzej autorzy Gene Kim, Kevin Behr i George Spafford, są liderami ruchu DevOps, tak przynajmniej jest napisane na odwrocie książki. „Projekt Feniks”, bo o tej książce piszę wciągnęła mnie od początku. Wyobraziłem sobie, że to moja historia i mogłaby zdarzyć się w moim życiu :-). Czy dowiedziałem się coś o DevOps? Przeczytajcie sami :-).

Fabuła

Książka „Projekt Feniks” opisuje losy firmy Parts Unlimited (PU), produkującej części do samochodów, gdzieś w USA. Poznajemy jej historię z perspektywy działu IT, gdy nie wiedzie się jej zbytnio. Główny bohater Bill Palmer zostaje poproszony o zajęcie stanowiska wiceprezesa ds. eksploatacji systemów informatycznych w PU, po zwolnieniu CIO i jego poprzednika. Tak naprawdę to nie jest prośba tylko ultimatum i nasz bohater nie ma innego wyjścia, jak podjąć się tego, wyglądającego na samobójcze, zadania. Bill ma wieloletnie doświadczenie w firmie, jest rozsądnie myślącym i zrównoważonym człowiekiem. Od początku spadają na niego wszystkie możliwe kataklizmy i musi radzić sobie z trupami w szafie, zostawionymi przez poprzedników. Trzeźwo jednak podchodzi do napotykanych trudności i odważnie stawia im czoła.

Ponieważ akcja dzieje się głównie w dziale IT, jest mi bliska, bo to moja działka. Dodatkowo opisywane sytuacje, pasują do tych doświadczanych przeze mnie, w trakcie mojej pracy zawodowej. Niektóre są tak podobne do tych, które miałem okazję obserwować lub w nich uczestniczyć, że aż nieprawdopodobne :-).

Nie zdradzam szczegółów abyście mieli większą przyjemność z czytania książki.

Dla kogo?

Chociaż książka koncentruje się głównie na historii Billa i patrzymy na Parts Unlimited oczami IT, to według mnie książkę powinni przeczytać wszyscy z działów biznesowych, którzy współpracują lub zależą w jakimś stopniu od IT. Czyli obecnie wszyscy, bo nie wyobrażam sobie biznesu, który funkcjonuje bez wsparcia i pomocy rozwiązań IT. Dlaczego? Bo pokazuje, jak ważna jest współpraca pomiędzy biznesem i IT i nie stosowanie kultury obwiniania. Widzimy że IT daje realną wartość dla biznesu a nie jest tylko dostawcą i wsparciem dla świadczonych usług.

Nie muszę mówić, że dla osób z IT jest to lektura obowiązkowa. Pozwala lepiej zrozumieć jak ważne jest wspólne działanie, nie tylko podczas „gaszenia pożarów” ale w codziennej pracy.

Lekcja

„Projekt Feniks” to również lekcja jak kierować i zarządzać organizacją IT i nie tylko. Uczymy się razem z Billem, który odkrywa nowe zagadnienia i obszary. Nie jest w tym poszukiwaniu osamotniony. Ma mentora w osobie Erika, kandydata na członka rady nadzorczej. Na podstawie fabryki produkującej części samochodowe, Erik uczy Billa, jak zarządzać organizacją IT. Wbrew temu co mogłoby się wydać analogii i podobieństwa jest bardzo dużo. Poznajemy cztery rodzaje pracy w IT, trzy drogi i wiele pożytecznych informacji w planowaniu i wykonywaniu pracy. Jak likwidować wąskie gardła i uniezależnić się od jednego super specjalisty, który całą wiedzę ma w swojej głowie, a bez niego nie można rozwiązać trudnych problemów lub wykonać skomplikowanych zadań. Bardzo dużo interesującej wiedzy, którą można zastosować w swojej organizacji.

DevOps

Jak dla mnie trochę za mało jest o DevOps, chyba że nadal nie wiem, co się kryje pod tym skrótem. W trzeciej części książki pokazana jest bardzo bliska współpraca programistów, testerów i zespołu utrzymania (eksploatacji) w wytworzeniu rozwiązania dla marketingu o nazwie „Jednorożec”. Erik stawia wyzwanie aby robić wdrożenia dziesięć razy dziennie. Dla wszystkich wydaje się to niemożliwe ale postanawiają, że zobaczą co można zrobić. Automatyzują testy, przygotowują środowiska testowe, tak jakby było to oprogramowanie. Na początku udaje im się zmniejszyć czas pomiędzy wdrożeniami z 3 miesięcy do 1 tygodnia a następnie do jednego dnia. Co ciekawe, tak wytworzone i zweryfikowane rozwiązanie odnosi spektakularny sukces, po tylko jednym miesiącu pracy. To chyba jest DevOps, przynajmniej w jakimś stopniu. Po dalszą wiedzę, muszę sięgnąć do innej książki.

Chociaż nie jest to kryminał ani thriller, akcja toczy się wartko i wciąga. Jesteś ciekawy co zrobi Bill, jak się potoczą kolejne wątki. Co nowego powie tajemniczy Erik. Czy wszystko zakończy się sukcesem czy spektakularną porażką. Jeżeli chcesz się dowiedzieć zachęcam do przeczytania tej pozycji, nie tylko nerdów z IT ale również lisów z biznesu.

Pytanie: Co rozumiesz pod określeniem DevOps?

Artykuł Projekt Feniks pochodzi z serwisu Mariusz Siek.