Jak realizować projekty IT w modelu DevOps
Jak realizować projekty IT w modelu DevOps? Aby odpowiedzieć sobie na to pytanie, potrzebujemy zrozumieć filozofię metodyki DevOps, jej cienie i blaski oraz zweryfikować, czy będzie to najlepsze rozwiązanie w naszej organizacji.
Jak realizować projekty IT w modelu DevOps. Podstawowe założenia
Cykl życia oprogramowania coraz bardziej się skraca, jeśli chodzi o kolejne dodatki „ficzery”, kolejne cechy oprogramowania, infrastruktury, konfiguracji. Bardzo często mówi się, że to ciągła zmiana jest jedyną stałą w projekcie. Znaczy, że będą zmiany, będą problemy, będą nowe żądania klienta. Co bardzo pasuje do podejścia zwinnego, ponieważ zaczyna się od określonej wersji oprogramowania, minimalnie spełniającego swoją funkcję, dokłada się kolejne usprawnienia i cały czas trzeba być w kontakcie z klientem, który wskazuje, jakie są następne kroki, jakie poszczególne funkcjonalności należy wdrożyć.
DevOps zakłada, że znamy proces w całości, że każdy członek zespołu, każdy element i każdy zespół pracujący nad całym cyklem życia oprogramowania widzi co się dzieje, potrafi zaproponować zmiany, potrafi je wdrożyć, również w innych elementach, nie tylko tych, za które jest szczegółowo odpowiedzialny. To jest oczywiście możliwe dopiero w pewnym etapie ewolucji. Stosując pełen wachlarz technik zarządzania zmianą, czyli mając konfigurację, oprogramowanie, dokumentację poddaną pełnej kontroli wersji.
Techniki zarządzania zmianą to możliwość sprawdzenia w poprzednich wersjach projektu, co wtedy było naszym problemem, jakie zaproponowaliśmy zmiany, co te zmiany dały, czy wszystkie te zmiany rzeczywiście były na lepsze, jak zmianę ewentualnie wycofać czy też jak je ocenić z perspektywy jakiegoś czasu w całej organizacji. Wdrażamy nie tylko nowe funkcjonalności, ale wdrażamy nowe techniki. Zespoły wdrażają nowe technologie. Dostajemy nowe rozwiązania.
Efekt? Nowoczesne aplikacje trapione są złożonością, która cały czas rośnie z powodu używania różnych technologii, wielu rozwiązań i platform, a DevOps może okazać się jedynym sposobem, by radzić sobie z tak złożonym środowiskiem, że trapione są ogromną złożonością.
DevOps zakłada trzy podstawowe filary:
- Integracja
Ciągła integracja (continous integration) – częste (kilka razy dziennie) składowanie kodu do wspólnego repozytorium. Każda izolowana zmiana jest niezwłocznie testowana.
Ciągłe wdrażanie (continous deployment) – uruchomienie przetestowanych zmian w systemie produkcyjny w sposób możliwie natychmiastowy
- Współpraca
Kontrola wersji (version control) – praktyki i narzędzia wspomagające utrzymywanie i kontrolę zmian w repozytoriach kodu, konfiguracji, dokumentacji i wytycznych.
Automatyzacja testów (test automation) – zestaw narzędzi i technik wpierających poprawność wprowadzanych zmian
- Komunikacja
Monitoring i alarmowanie (monitoring and alerting) – podstawowy składnik dostarczający faktów i informacji pozwalających na stwierdzenie stanu oraz spełniania wymagań we wszystkich obszarach objętych projektem.
Śledzenie błędów (bug tracking) – system do raportowania i agregacji informacji o błędach, awariach, defektach i problemach. Bardzo istotna część stałej pętli informacji zwrotnej krążącej w całym projekcie.
DevOps zakłada uczenie się na błędach i to, że porażka, awaria, problem, to codzienne zmagania, element właśnie tej pracy. Zdawanie sobie z tego sprawy, że w każdej chwili może pojawić się jakiś problem i ważne jest nie tylko unikanie ich, ale też właśnie przyzwyczajenie się do tego, że problemy są, do których należy wypracować procedury działania oraz sposoby współdziałania takie, żeby ten problem jak najszybciej można było zlikwidować.
Wszystko próbujemy automatyzować, automatyzować, ile się da. Inżynierom devopsowym, którzy dbają o tą automatyzację, od razu przychodzą do głowy narzędzia typu GitLab CI, Jenkins, TeamCity, nam raczej chodzi o koncepcje. Koncepcja składowania kodu, ciągłą integrację równie dobrze można rozumieć pod kątem wymagań, czy też dokumentacji. Bo jeżeli mamy wymagania dotyczące jakichś komponentów naszego produktu, to również zmiany tych wymagań, też mogą być częste. Zmiany wymagań również są testowane, ale przede wszystkim muszą być przedyskutowane z architektami w celu zastanowienia się jaki jest ewentualny efekt. Same wymagania również dodawane są do repozytorium. To samo dzieje się dokumentacją, gdy się zmienia, zmienia się narzędzie – wdrażamy wtedy odpowiednie procedury, które zabezpieczają projekt.
Drugi z filarów to współpraca, gdzie wszystkie te działania: integracja, wdrożenia, wymagają pewnej współpracy. No i tu znowu, można popatrzeć na to bardzo technicznie: narzędzia kontroli wersji: Jira, Confluence, które wspomagają utrzymywanie, kontrolę zmian, pomagają również we współpracy/kolaboracji. Narzędzia automatyzacji testów też wspomagają współpracę, ponieważ one potwierdzają poprawność wprowadzanych zmian, przekazują informację, suche fakty lub nawet wręcz jakąś analizę, z której każdy może skorzystać. Możemy dzięki narzędziom wyeliminować pewien ciąg zależności naszej współpracy, kto ma co zatwierdzić, tutaj dzieje się to automatycznie. Jak najbardziej możemy się do tego odnieść już w systemie, gdzie możemy przedyskutować już ewentualne wyniki testów, a nie to, czy ten kod ma tam jakieś ewentualne błędy czy nie.
DevOps zakłada, że monitorujemy. My mamy informację o całym systemie i już wdrażając od początku system, od razu wdrażamy metody monitorowania i alarmowania. To musi być podstawowy składnik w każdym projekcie. Jeżeli realizujemy jakikolwiek komponent, natychmiast realizujemy dostarczanie przez niego faktów i informacji: metryk, logów, alarmów, jakiś wniosków. Możemy stwierdzić spełnienie wymagań w jakimkolwiek obszarze, obojętnie czy ktoś jest opiekunem, czy też zespołem opiekującym się danym komponentem, czy też nie. Oczywiście systemy śledzenia błędów do raportowania, agregacji informacji są bardzo istotną częścią również tego monitoringu, bo my chcemy z tego gąszczu metryk rzeczywiście coś zobaczyć. Nie bez powodu wizualizujemy dane, nie bez powodu agregujemy dane w bazie do wyszukiwania pełno tekstowego „elastic searchu”, nie bez powodu dokonujemy analiz, nawet przy użyciu sztucznej inteligencji, pochodzących z różnego rodzaju metryk próbujemy ze sobą skorelować, bo różnica między danymi, a informacjami jest niestety taka, że my potrzebujemy pewnego kontekstu, my potrzebujemy pewnych porównań, żeby z danych posiadać informacje. I potrzebujemy pewnych mechanizmów, żeby te informacje zamienić w wiedzę. To śledzenie błędów, ten monitoring, to jest bardzo istotna część takiej stałej pętli informacji zwrotnej, bo ta pętla informacji zwrotnej niekoniecznie musi wynikać z działań osób uczestniczących w projekcie DevOps. Te raporty mają być dostępne w każdej chwili. Jeżeli wymagają pewnych analiz to na żądanie możemy je uruchamiać, ale jako członek zespołu powinienem móc w każdej chwili wiedzieć co się dzieje. To nie tylko dotyczy dostępności metryk, to też dotyczy możliwości zrozumienia logów.
Horyzont narzędzi DevOps
W IT powszechnie stosuje się narzędzia związane z monitoringiem, konteneryzacją, wdrażaniem, testowaniem. Ten wachlarz dostępnych narzędzi staje się też problemem przy wdrażaniu metodologii DevOps, bo ona zakłada, że wszystkie zespoły współuczestniczą, integrują, współpracują i się ze sobą komunikują. Jeśli mają się ze sobą komunikować, powinny za pomocą tego samego kodu, korzystać z tego samego zestawu narzędzi oraz technik. Wybór pewnych technologii podyktowany jest bardzo wieloma czynnikami uzależnionymi od infrastruktury, ale również od technologii, które używa klient. Konsultując projekt z jednym klientem, przechodząc do drugiego klienta, okazuje się, że mamy do czynienia z zupełnie innym zestawem technik, używa innego zestawu narzędzi, funkcjonuje w oparciu o inny kod. Jeden klient używa mikroserwisów, wdraża je w Kubernetesie, inny klient używa ECSa, używa zestawu kontenerów.
Wyzwania DevOps
To przede wszystkim zmiana w filozofii pracy/współpracy, połączenie kompetencji deweloperów i operatorów. Szeroki zakres umiejętności w zespole zamiast wąskiej specjalizacji. Sukces zależy od współpracy pomiędzy zespołami/działami i otwartej komunikacji pomiędzy kluczowymi dla danego ciągu produkcyjnego osobami.
DevOps zakłada, że realizując pewien komponent, jednocześnie jesteśmy jego operatorem. Wyjaśniamy innym, jak się z niego korzysta, jak wyglądają i jak czytać informacje z nim związane, gdzie można się ewentualnie podpiąć. Nie ma nic w tym dziwnego, że tworząc nawet wewnętrzne narzędzie, czy też wewnętrzny element, zespół, przekazuje się go innym zespołom.
Droga do DevOps. Krok 1: Platforma
Pierwszy krok jest bardzo techniczny, tzn. potrzebujemy platformy czyli dostarczenie skalowalnego i stabilnego środowiska pozwalającego na dostarczanie produktów w metodologii DevOps. Środowiska zarówno do kolaboracji, współpracy, jak i właśnie działania elastycznego. Skalowalne, stabilne środowisko, bardzo często rekonfigurowane, zarządzane przez systemy kontroli wersji, czyli środowiska, choćby w plikach zarządzania infrastrukturą – „teraformach” – gdzie łatwo realizujemy zmianę środowiska, łatwo odtwarzamy na żądanie. Potęga Terraforma polega na tym, że może on być rozszerzany przez dodatkowe wtyczki nazywane providerami (np. AWS, Azure, Google Cloud, GitHub, Heroku, Docker, Kubernetes) lub napisać własny.
Droga do DevOps. Krok 2: Ciąg produkcyjny (Pipeline)
Drugi krok, to spojrzenie już nie tylko na platformę, ale na cały ciąg produkcyjny. Gdzie z punktu widzenia zarządzania znowu pracami DevOps na ciąg produkcyjny patrzymy jako produkt. W takim ciągu produkcyjnym zwiększamy przepływności, lokalizujemy ewentualne problemy, analizujemy, które z tych problemów są efektem działań manualnych, tzn. gdzie nie było automatyzacji. Staramy się doprowadzić do sytuacji, w której przewidywalność jest duża, w przypadku kolejnych iteracji, kiedy my wiemy co się będzie działo i będą kolejne iteracje. W takim ciągu produkcyjnym jesteśmy wstanie ustalić, kiedy będzie jakaś kolejna zmiana. Pozwala nam to osiągnąć stan, w którym zmniejszamy koszt dostarczania kolejnych ciągów produkcyjnych.
Droga do DevOps. Krok 3: Produkty (Applications)
Trzeci krok, to oczywiście produkty, które składają się z tych naszych pipeline’ów, definiowanych jako jednostki pracy, które są od siebie odróżnialne. Te jednostki muszę mieć odpowiedni czas życia, posiadają identyfikowalny, jednoznaczny cel biznesowy i możemy przydzielić DevOps management w tym momencie do konkretnego produktu, który będzie się starał optymalizować konkretny produkt.
Droga do DevOps. Krok 4: Kultura (Culture/Philosophy)
To jest ewolucja do pewnej filozofii, do kultury pracy, zmieniana zachowania, postaw i struktur zespołów, które pracują nad dostarczaniem tych konkretnych produktów. Używamy wspólnego zestawu technik, narzędzi, metod kolaboracji, również półatomatyzowanych, takich, które od razu wyrzucają tickety, wyniki testów, potrafią sięgnąć do metryk. I te zmiany doprowadzą do ułatwienia pracy.
Czy filozofię DevOps da się sformalizować?
Są pewne próby, można natknąć się na modele, takie jak CAMS (autor modelu John Willis), który mówi właśnie o tych czterech częściach: C – culture (kultura), A – automation (automatyzacja), M – measurement (metryki), S – sharing (współdzielenie). W kulturze jest mowa o tym, że kontekst czy informacja nie powinna mieć właścicieli, nie powinna być skrywana przed innymi działaniami, dokumentacja prac nad jakimś komponentem, to jest oczywiście związane ze współdzieleniem, metryki są publiczne, wszyscy wiedzą jakie były efekty zmian, wszyscy mogą również sprawdzić jakie były efekty zmian, nawet innych komponentów, to współdzielenie doświadczenia jest bardzo istotne. Ta pętla zwrotna informacji jest ciągła. W każdej chwili możemy spojrzeć jakie były dyskusje na temat danego komponentu, jakie były efekty, każdy może sobie sprawdzić. To oczywiście możliwe jest dzięki automatyzacji oraz metrykom, czyli tej technicznej podstawie filozofii DevOps.
Kilka przydatnych koncepcji
Test Driven Development/Behavior Driven Development – ma na celu zbudowanie właściwego oprogramowania w pierwszej wersji
Shift Left – jak najszybciej przyjmuj na siebie problemy,
Test Often, Test Early, Test in Production – testuj często, testuj wcześnie, testuj na produkcji, testuj
Google SRE (implementacja koncepcji DevOps) – ma na celu stworzenie ultra skalowalnych i wysoce niezawodnych systemów oprogramowania
Komunikacja jest kluczowa w DevOps
Monitoring i i alerting są konfigurowane przez zespół, obsługujący daną usługę (jako kluczowy komponent dostarczający informacji o działaniu). Pełne zrozumienie działania jakiejkolwiek usługi jest podstawą wprowadzania usprawnień, niezależnie czy wewnętrznie, czy horyzontalnie w całej organizacji. Dokumentacja, nawet jeśli to nie jest dokumentacja formalna, tylko dokumentacja za pomocą kodu, dokumentacja za pomocą wymagań. Ona jest niezbędna, żeby rozumieć horyzontalnie cały proces. Uzgodnione wzorce budowania, wdrażania i testowania aplikacji i usług mogą być używane ponownie w innych zespołach organizacji Zespoły mogą wprowadzić usprawnienia do praktyk, narzędzi czy technik używanych przez inne zespoły. Wyzwala to dyskusje nad priorytetami i planami dalszego rozwoju
Narzędzia zarządzania konfiguracją pozwalają do uczestniczenia we wprowadzaniu zmian zespołom developerów, bezpieczeństwa innymi poza operatorami. Pozwala to na wdrożenie współdzielonej odpowiedzialności i operatywności
Wzorce budowania, wzorce wdrażania aplikacji jak najbardziej powinny być uzgadniane, dyskutowane, poprawiane, zgodnie z metodologią DevOps, tak samo, jak i samo programowanie.
Jak sobie poradzić z komunikacją w praktyce?
To przejście na jeden konkretny system, gdzie dyskusja i dokumentacja będą w jednym miejscu, a system powiadomień na bieżąco aktualizował przepływ informacji, np.:
• Slack
• Rocket.chat
Można też rozważyć techniki zmniejszające kontekst, czyli np. trzymanie się stałego terminu spotkań, zmniejszanie ilości tych spotkań, na rzecz konkretnych terminowych. Wspólne „all-hands” zawsze w poniedziałki, „daily” zawsze o tej samej porze. Godziny w których nie wolno przeszkadzać „Do Not Disturb hours”. Jedno konkretne zadanie, podzielone na części. Wdrożenie technik, takich jak „Pomodoro”, gdzie mówimy sobie: 45 minut na zadanie, potem dopiero następne. Ustawiamy sobie budzik, czy też stoper i te 45 minut robimy konkretnie tylko jedną rzecz. To są techniki, których też się uczymy. To są techniki, które też można przedyskutować. Należą one do tworzenia i promowania kultury ciągłego uczenia się.
Ciągłość komunikacji jest jak najbardziej istotna, żeby była oparta na kluczowych metrykach, ale też na celach biznesowych, żeby realizujący projekt znali cele biznesowe i wynikające z nich rzeczywiste metryki. Tuż za tym powinna iść organizacja zadań w taki sposób, aby zmniejszyć konieczność przekazywania pracy. Oczywiście, w zależności od organizacji, wyzwania mogą być inne. Dlatego najważniejsze jest zdefiniowanie, czy w ogóle jesteśmy gotowi na wdrożenie metodyki DevOps w naszej firmie. Reszta przyjdzie sama.
Pytania? Skontaktuj się z nami
Zobacz również:
14 usług AWS, które musisz znać w 2019 roku
Czy projekt IT może skończyć się sukcesem?
44-200 Rybnik
Poland
REGON: 240692928
KRS: 275333
