Podczas czerwcowego spotkania CXO HUB dyskutowaliśmy o wykorzystaniu podejścia observability oraz inżynierii niezawodności. Oba – obudowane odpowiednimi narzędziami i platformami – podejścia to sposób radzenia sobie firm z nową złożonością otoczenia cyfrowego, z przeprowadzeniem organizacji przez procesy transformacji cyfrowej czy migracji do chmury.
Zwinna, cyfrowa firma powinna być wyposażona w środki umożliwiające obserwowanie jej życiowych parametrów i dynamiczne podejmowanie decyzji o zmianach. Trendy, takie jak Site Reliability i Observability, wyznaczają zmianę podejścia do zarządzania środowiskiem w toku wielkich wyzwań, jakimi są migracja do chmury czy przeskalowanie w trakcie dostosowania biznesu do pandemii. Podczas spotkania CXO HUB „Co powinien wiedzieć CXO cyfrowej firmy?” dyskutowaliśmy o tym w gronie kilkudziesięciu CXO. Partnerem spotkania była firma Dynatrace, która dostarcza platformę Software Intelligence, w sposób nowoczesny realizującą zadania monitorowania i optymalizowania efektywności całego stosu technologicznego w powiązaniu z doświadczeniem użytkownika – klienta.
W pierwszej części spotkania wystąpili Robert Kucharczyk, CIO InterCars; Piotr Mynarski, CTO eSky; Jaromir Pelczarski, Technology Consulting Technology Principal w Accenture i członek Rady Programowej CXO HUB oraz Marek Walczak, szef sprzedaży w Omnilogy, firmie będącej przedstawicielem Dynatrace. Dyskusja toczyła się wokół wyzwań zarządzania infrastrukturą i aplikacjami w kontekście cyfryzacji, porównania zadań i cech Observability i monitoringu oraz założeń SRE wobec klasycznych kontraktów SLA. W dalszej części spotkania Andy Grabner z Dynatrace mówił o skutecznym skalowaniu podejścia DevOps przy wsparciu paradygmatu SRE. Mieliśmy także okazję wysłuchać wystąpienia Piotra Mynarskiego, CTO eSky, który opowiadał o doświadczeniach wdrożenia i stosowania SRE.
Obserwować, rozumieć, działać
Nowe wyzwania dotyczące monitorowania efektywności, niezawodności rozwiązań przyniosła cyfryzacja. Jaromir Pelczarski zwrócił uwagę na bardzo szeroką definicję i rozumienie transformacji cyfrowej. Kilka lat intensywnego marketingu z przekazem „Software makes the world go around” sprawiło, że wszyscy są – lub mają poczucie, że są – w toku transformacji. Każdy jest zanurzony w cyfrowym świecie, cyfryzacja stała się wręcz tematem dla magazynów lifestyle’owych. W efekcie często umyka fakt, że cyfryzacja jest procesem, który nie kończy się dopóty, dopóki firma żyje. Dwa wymiary pozwalają utrzymać trajektorię procesu, podporządkowanego strategii i wizji: skupienia uwagi na kliencie oraz to, co znamy z agilowych metodyk – podejście elastyczne, iteracyjne. Nakłada to zarazem określone oczekiwania dotyczące podejść do obserwacji, monitoringu oraz sposobu działania na tej podstawie.
Obecna fala cyfryzacji nie zapoczątkowała bowiem wcale dążenia do pomiaru efektywności. Robert Kucharczyk przez wiele lat w Inter Cars wykorzystywał bogate portfolio różnych narzędzi, które tylko na przestrzeni dekady stale się zmieniało. Za każdym razem dobór wynikał z aktualnych potrzeb i nowego doświadczenia. Teraz obserwuje dwa trendy: odejście od monitoringu czysto technicznego oraz przełom polegający na tym, że 90% używanych narzędzi to narzędzia oparte na open source.
Nowe podejście musi nadążyć w każdym razie za transformacją cyfrową. Marek Walczak zwrócił uwagę, że proste na poziomie marketingowej narracji schematy modelu SaaS czy chmury obliczeniowej, dla IT oznaczają wyzwania. Przede wszystkim konieczność zapewnienia spójnego ekosystemu obejmującego różne architektury, integrującego obszary o różnej dynamice zmienności. Klasyczne narzędzia monitoringowe były instalowane wyspowo i bezbudżetowo (czego zasługą jest nadmiar rozwiązań open source). Pojawienie się podejścia Observability i SRE, wraz z atrybutami jak budżety błędów, SLO, SLE, odpowiada na wyzwanie komplikacji środowiska, trudności migracji chmurowych, integracji środowisk itd.
Od kokpitu do platformy
W innym wymiarze trwa automatyzacja narzędzi i procesów oraz ewolucja od, już dzisiaj przyjętego, modelu DevOps przez DevSecOps, BizSecDevOps, do modelu no-Ops. One właśnie oczekują dążenia do stałego monitorowania, analizy i odnoszenia wniosków do kontekstu biznesowego. Ma to umożliwić szybkie i trafne diagnozy systemu, ze wskazywaniem co zrobić, gdy określony parametr spada poniżej założeń. Wtedy właśnie dochodzimy do tytułowego kokpitu. Podstawowy dylemat, to dla kogo jest on projektowany: dla IT, biznesu czy dla wszystkich?
Dziś potrzeba kokpitu na poziomie zarządu firmy, gdzie najczęściej zasiada – albo gdzie jest wzywany bardzo często – CIO. Dlatego na scenie pojawiają się rozwiązania takie jak Dynatrace, które potrafią informacje z monitoringu, poprzez wbudowane mechanizmy Observability, poddane stałej analizie przez automatycznego diagnostę, sztuczną inteligencję, na bieżąco pokazywać informacje niezbędne do prowadzenia biznesu. To platforma Software Intelligence, która automatyzuje funkcjonowanie IT i pokazuje bieżący stan ekosystemu biznes-IT. Odpowiada to zarazem paradygmatowi, jaki reprezentuje SRE.
Wzrostowi biznesu towarzyszą zwykle nieregularne, za to skokowe przyrosty technologiczne, oznaczające także dokładanie złożoności. Tak było też w eSky. Piotr Mynarski zwrócił uwagę, że jedynym sposobem, aby zapanować nad tym, jest zastosowanie spójnych i jednakowych rozwiązań we wszystkich elementach systemów. To zarazem dążenie do uproszczenia rozwiązań monitorowania, w wyraźnej kontrze do przyrostu złożoności, jaki niesie wejście do chmury czy konteneryzacja.
Observability i monitoring są komplementarne, ale czy kompletne?
Monitoring mówi o prostym wskaźniku, a Observability układa te wskaźniki w kontekst. Marek Walczak wskazuje, że są to uzupełniające się elementy, które jednak nadal nie odzwierciedlają kontekstu biznesowego. Proces przez nie realizowany jest przy tym czasochłonny, obarczony błędem i tak naprawdę nietwórczy. Niezbędne jest więc sięgnięcie po automatyzację i wsparcie się sztuczną inteligencją.
Ten ujawniony deficyt jest przejawem istotnego dylematu. Jaromir Pelczarski uważa, że potrzebne jest nowe zrozumienie tematów wokół nas. Wracamy do pytań podstawowych, co jest naszym celem, jak opisują je KPI, czego biznes potrzebuje? Przez długie lata Facebook miał jeden KPI dla całej organizacji: liczba zalogowanych, aktywnych użytkowników na stronie danego dnia. Z punktu widzenia angażowania biznesu, to istota naszego działania. Wobec zmiany, jaką wprowadza cyfryzacja, niezbędne jest upewnienie się, zrozumienie, co jest istotą naszego działania. Do tego należy przyjąć odpowiednie miary i dobierać realizujące je rozwiązania. To mogą być rozwiązania platformowe, które dają wielką ilość informacji, zagregowaną tak, że można je porównać do przykładu z Facebooka. To ważne, bo za dużo informacji w złym momencie jest tak samo złe, jak ich brak.
Łączony model monitorowania
Czy zatem da się sprowadzić do rozmiaru kokpitu firmę pokroju Inter Cars, zredukować ją do 4-5, wspólnych KPI? Robert Kucharczyk uważa, że model monitorowania efektywności jeszcze długo będzie modelem mieszanym. Inter Cars ma za sobą różne podejścia, także model, gdzie faktycznie przyjęto KPI czysto biznesowe dla całej organizacji, aby IT i biznes był motywowany w ten sam sposób. Ale kiedy nasze środowisko rozłożymy na części pierwsze, to schodzimy do poziomu programisty, który pisze połączenia między systemami i nie do końca rozumie, jak działa ERP. I nie do końca rozumie też, jak działa cały łańcuch dostaw. Im bardziej mu tłumaczymy, tym mniej w nim zrozumienia i zapału.
W Inter Cars rok 2021 jest przełomowy, ponieważ firma odeszła od uniwersalnego podejścia. Dziś angażowanie w efektywność wnioskowaną z monitoringu odbywa się już na poziomie zespołów produktowych. Tak, aby ich uczestnicy wiedzieli, co na przestrzeni jednego czy kilku sprintów dowieźć. Są i wspólne, dla ludzi z informatyki i biznesu, związane z dostępnością aplikacji, ale przedstawiane przez pryzmat transakcji czy dostępności systemów dla klientów. Zrozumiałe dla wszystkich i niepodważalne, ale nie uzależnione wprost od wskaźników przychodowych czy obrotowych.
W jakich warunkach można stworzyć kokpit?
Observability może być tylko możliwością interpretacji wskaźników, czy sprawdzeniem, w jaki sposób wskaźniki biznesowe funkcjonują. Piotr Mynarski sądzi jednak, że tę definicję można rozszerzyć, jeśli chcemy obserwować niezawodność naszego systemu i prezentować tę niezawodność klientowi. Wyzwaniem jest wspólny z biznesem właściwy dobór wskaźników, określenie, co jest dla nas niezawodnością i co steruje naszym biznesem. Aby to zbudować, potrzebny jest długi proces porozumiewania się z biznesem, który doprowadzi do tego, że stopniowo organizacja będzie myśleć wspólnymi kategoriami.
Oprogramowanie wytwarzane w kanonie niezawodności
Andreas Grabner, ekspert Dynatrace i kontrybutor społeczności DevOps, zwrócił uwagę, że wiele organizacji buduje jednocześnie role DevOps oraz SRE. Są one pokrewne, co wynika ze wspólnoty celu – niezawodnego dostarczania. A jak współgrają? Service Level Indicator (SLI), czyli miernik np. dostarczania usługi w czasie krótszym niż 4 ms w 90% przypadków, na przestrzeni 30 dni. Budżet błędu w tym okresie wynosi 10% i jest obciążany za każdym razem, gdy przekroczony jest poziom SLO (Service Level Objective). Kiedy budżet jest przekroczony, oznacza to złamanie SLA (Service Level Agreement). Jest to koncepcja Google, ale platforma Dynatrace także pozwala definiować SLO, np. infrastrukturalne czy biznesowe. W ostatecznym rozrachunku ich definicja brzmi: „czy jesteśmy dobrzy, czy nie?”. Można jednak konstruować z nich alerty, „cieniować” komunikaty, w zależności od tego, czy zbliżamy się do granicy SLO. Słowem, budować wyrafinowaną komunikację, umożliwiającą podejmowanie właściwych decyzji.
Można zresztą osiągnąć więcej, jeśli w inżynierię wytwarzania wpisać koncepcję SLO. Każda kolejna wersja, która przechodzi przez Jenkins Pipeline, GitLab czy Azure DevOps, może być przetestowana automatycznie pod kątem ustalonych SLO. Pamiętajmy, że DevOps i SRE mają wspólny cel – nie tyle „przepychać” szybciej rzeczy, ile dostarczać zdrowe produkty, o jakości potwierdzonej przez SLO. Schemat taki zastosowano np. w Raiffeisen Software, gdzie platforma Dynatrace waliduje wersję przed decyzją o jej wydaniu. Rzeczywisty shift-left, jak powiedzieliby marketingowcy.
Progressive Delivery to następny krok, czapka, pod którą kryje się wiele zagadnień: Canary Deployments, Blue-Green Deployments, testy AB, Feature Flaking itd. To kolejny etap rozwoju wytwarzania, po waterfall, agile, Continuous Delivery. Wraz z nim będzie stale przybywać nowych narzędzi do wydań. A zatem także źródeł prawdy. Dynatrace w tym przypadku monitoruje wszystkie środowiska deweloperskie, dając wiedzę na bieżąco, która wersja, którego oprogramowania jest wdrażana, do którego środowiska należy. To być może pieśń przyszłości, ale czy na pewno?
Problem: nadmiar kokpitów i wskaźników
Początkowo eSky korzystało z wielu mierników. Każdy zespół deweloperski produkował szereg wskaźników, bardzo technicznych, dotyczących zużycia procesora, czasów odpowiedzi naszych usług, serwisów itd. Na początku było to wystarczające, aby odpowiadać sobie na pytanie, czy systemy działają prawidłowo, gdzie doszukiwać się awarii. Z czasem doprowadziło to jednak do sytuacji, że powstał nadmiar kokpitów ze wskaźnikami. Efektem był poznawczy nieład prowadzący do znieczulicy wśród deweloperów.
Mierniki często pokazywały niespójne i sprzeczne informacje. Deweloperzy i cały zespół IT przestał – wobec tego – traktować je z ufnością i zaczął ignorować. To prowadziło do awarii, które obsługiwane były w sposób reaktywny. Na przełomie lat 2018-2019 zdecydowano się więc na zmianę podejścia – uspójnienie, konsolidację i uproszczenie miar. Wówczas też pojawiło się w firmie pojęcie inżynieria niezawodności. Zbiegło się to z planowaniem zmiany pod kątem skalowalności – migracji do chmury obliczeniowej. Kontakt z inżynierami w Google sprawił, że pojawił się impuls, aby spróbować podejścia, metodyki i praktyk SRE. Powstał Proof of Concept dla pomiaru niezawodności.
Pierwszy dashboard powstał już we współpracy z biznesem, w oparciu o to, co w jego opinii stanowi o niezawodności i w jaki sposób można ją argumentować użytkownikom. Pokazywał zaledwie kilka wskaźników. Był początkiem odrodzenia szacunku do wybranych wspólnie miar, ale i początkiem budowania kultury niezawodności. Zapadła decyzja, że powstanie zespół, który będzie odpowiedzialny za to, aby te praktyki SRE dobrze poznać, by się wyszkolić w tym temacie, zacząć budować bazę wiedzy i wdrażać te praktyki wśród deweloperów, biznesu. Za to, żeby rozpowszechniać myślenie o niezawodności z punktu widzenia biznesu, użytkowników, którzy do naszego serwisu przychodzą.
SRE, czyli kosztowo pragmatyczne podejście do pomiaru niezawodności
Czym tak naprawdę jest niezawodność? Odpowiedni poziom zadowolenia osób biznesowych, to nie tylko odczucie subiektywne, wzrost niezawodności systemów wiąże się wprost z kosztami. To że mamy Service Level Indicator (SLI), które gwarantujemy, to kompromis pomiędzy zadowoleniem z niezawodności a kosztami, które jesteśmy w stanie na to wyłożyć. Ta świadomość miała znaczenie, kiedy pojawiła się dyskusja o migracji do chmury z powodu dynamiki wzrostu firmy. Biznes chętnie o tych tematach rozmawiał. W chmurze każda awaria pomnożona o skalę przynosi dużo większe straty niż kiedy ta skala jest mniejsza. I dlatego migracja do usług cloud computing dała asumpt do tego, by rozmawiać skutecznie z biznesem na temat wdrożenia praktyk SRE.
Intencją tej dyskusji było zapewnienie bezpiecznej migracji do chmury. Dlatego migrowane usługi będą opisane wskaźnikami SLI i SLO (Service Level Objective). Każda usługa uruchamiana w chmurze będzie wystandaryzowana do podejścia SRE. Decyzja o przyjęciu wskaźników SLO i SLI oznaczała, że niedopuszczalne było ignorowanie błędów. Zbudowany został kokpit, na którym widać wszystkie SLO. Wiadomo, jaka jest niezawodność systemu. Obrazuje on aktualne SLI, przyłożone do nich miary SLO, wiadomo, kiedy system alarmuje, wiadomo, jaka jest mechanika, tj. tempo wypalania się poszczególnych wskaźników. Jak utrzymać niekłamane dziś zainteresowanie biznesu tą wizualizacją niezawodności?
Jednym z rozwiązań, które się sprawdziło, jest prezentacja po każdym sprincie wskaźników i komunikowanie, z jaką niezawodnością działały systemy w ostatnich dwóch tygodniach.
Przypadek przekroczenia jakiegoś wskaźnika powoduje dyskusję o przyczynach, ale i samym SLO, o otoczeniu, np. można podejmować działania biznesowe, aby dostawcy odpowiadali bardziej stabilnie, albo wykluczyć mechanizmy, które owocowały „incydentem” nieefektywności.
Działa także z powodzeniem budżet błędów, zespół SRE, stara się wykorzystywać budżet błędów, aby testować systemy, np. poprzez testy szokowe, wyłączanie pewnych usług itp. Takie kontrolowane, wpisane w scenariusz działania, które w konsekwencji prowadzą do usprawnień, podnoszą jakość i niezawodność. Są elementem kultury SRE, tak, jak wdrażanie biznesu do rozmowy nad wskaźnikami, to jest też wykorzystanie budżetu błędu do testowania systemów i usprawniania rozwiązań.
Kultura SRE
Kiedy dochodzi do awarii, kultura SRE zakłada wyciąganie wniosków. Wszelkie te przypadki są post mortem analizowane. Na tej podstawie wykonywane są poprawki do systemu. Systemy stają się bardziej niezawodne. Wszystkie te działania w ramach SRE doprowadziły do tego, że z poziomu licznych awarii w ciągu tygodnia, firma doszła do kilku w ciągu miesiąca. Zwykle też wynikają ze zmiany w biznesie, który szybko się teraz skaluje, a nie jest powtórzeniem dawnego schematu błędu.
SRE w eSky to nie tylko wskaźniki i Observability, lecz także nieustanne zbliżanie percepcji IT i biznesu. Wspólnego mówienia o niezawodności organizacji. Zależy ona od technologii, choć nie jest już wyłącznie tematem dla zespołów technologicznych. Istnieją metodyki wdrożenia SRE, m.in. bardzo dobrze opisany jest sposób, w jaki dokonało się to w Google. Wdrożenie SRE jest wymagające, ale jak najbardziej dostępne. Istnieje np. prosta metoda – zapytać u źródła, jak uczynił to eSky. Okazuje się, że Google chętnie o tym opowiada i pomoże wdrożyć się w tę ścieżkę. Zespół SRE w Google liczy raptem 10 osób, ale o kulturze tej wie cała kadra inżynierska firmy.
Taki cel widać też w eSky. Pierwszy zespół SRE w eSky składał się z 4 osób. Na początku miał dwie odpowiedzialności. W trakcie wdrażania chmury zespół SRE łączył kompetencje DevOps i zdobywał umiejętności najlepszych praktyk wdrażania i korzystania z rozwiązań chmurowych. Druga odpowiedzialność to opanowanie praktyk SRE, specjalizacja, a następnie przekazanie wiedzy deweloperom i biznesowi, budowa frameworku do obserwacji efektywności.
Z czasem, podsumowywał Piotr Mynarski, kiedy zainstalowano narzędzia, pojawiły się fundamenty i SRE mogło działać, zadaniem zespołu staje się angażowanie w kulturę SRE biznesu.
***
Apetyt uczestników spotkania CXO HUB na szczegóły wdrożenia środowiska SRE nie został wyczerpany dyskusją. Dlatego z inicjatywy Jacka Kujawy i Marka Walczaka do uczestników spotkania trafiła jedna z „biblii” SRE.
