Ta książka zrodziła się z gotowości do pracy, jaką zaczęłam odczuwać kilka miesięcy po dołączeniu do firmy Uber Technologies jako inżynier niezawodności witryny (ang. site reliability engineer — SRE). Gigantyczny, monolityczny API, jakim posługiwano się w firmie Uber, był powoli dzielony na mikrousługi. W momencie, kiedy dołączyłam do zespołu, wykorzystywano ponad tysiąc mikrousług, które zostały wydzielone z API i działały razem z nim. Każda z nich była zaprojektowana, zbudowana i utrzymywana przez wyznaczony zespół programistów. Ponad 85% tych mikrousług było budowanych bez udziału inżynierów SRE lub z niewielkim ich udziałem. Usługi te nie korzystały także z zasobów SRE.
Zatrudnianie inżynierów SRE i budowanie zespołów tej specjalizacji jest niezwykle trudnym zadaniem. Niełatwo znaleźć odpowiednich specjalistów, ponieważ inżynieria niezawodności witryn jest nadal stosunkowo nową dziedziną, a inżynierowie SRE muszą być ekspertami (przynajmniej do pewnego stopnia) w inżynierii oprogramowania, inżynierii systemów oraz architekturze systemów rozproszonych. Mój zespół powstał dlatego, że nie było sposobu na szybkie wprowadzenie do wszystkich zespołów dedykowanych inżynierów SRE. W ten sposób narodził się mój zespół (Consulting SRE Team). Otrzymaliśmy od kierownictwa bardzo proste zadanie: znaleźć sposób na wdrożenie ścisłych standardów w 85% mikrousług, w których budowaniu nie uczestniczyli specjaliści SRE.
Nasza misja była na tyle prosta, a postawione zadanie na tyle ogólnikowe, że mój zespół uzyskał znaczną swobodę w określeniu zbioru norm, według których mogła działać każda z mikrousług wykorzystywanych w Uberze. Stworzenie ścisłych standardów, które można zastosować dla każdej mikrousługi działającej w ramach tej dużej organizacji inżynieryjnej, nie było łatwe. Dlatego z pomocą mojego niesamowitego kolegi, Ricka Boone'a (to jego standardy stosowane w mikrousługach, które wspierał, stały się inspiracją do napisania tej książki), stworzyłem szczegółowy wykaz norm, które moim zdaniem powinna spełniać każda usługa w Uberze przed dopuszczeniem do produkcji.
Wykonanie tego zadania wymagało określenia zestawu ogólnych zasad, w których zakres wchodziłyby wszystkie wymagania. Opracowaliśmy osiem takich zasad: ustaliliśmy, że każda mikrousługa w Uberze powinna być stabilna, niezawodna, skalowalna, odporna na awarie, wydajna, monitorowana, udokumentowana i przygotowana na wszelkie katastrofy. Pod każdą z tych zasad wyszczególniliśmy odrębne kryteria, które zdefiniowały, co to znaczy, że usługa jest stabilna, niezawodna, skalowalna, odporna na awarie, wydajna, monitorowana, udokumentowana i przygotowana na wszelkie katastrofy. Co ważniejsze, wymagaliśmy, aby każda zasada była wymierna oraz żeby każde kryterium dawało nam mierzalne efekty w postaci znacznej poprawy dostępności naszych mikrousług. Usługę, która spełniała te kryteria i ustalone wymagania, uznawaliśmy za gotową do produkcji.
Następnym krokiem było skuteczne i wydajne wdrożenie tych norm w zespołach. Stworzyłam szczegółowy proces, w którym zespoły SRE spotkały się z zespołami kluczowych usług (takich, których przestoje spowodowałyby awarię aplikacji), przeprowadzały wraz z zespołami przeglądy architektury, prowadziły audyty usług (proste listy kontrolne z odpowiedziami „tak” lub „nie” w zależności od tego, czy usługa spełniała każde z wymagań gotowości do produkcji), tworzyły szczegółowe plany działania (przewodniki krok po kroku, które uszczegółowiały sposób doprowadzania usługi do stanu gotowości) oraz oceniały każdą usługę pod kątem gotowości do produkcji.
Najważniejszą częścią procesu było prowadzenie przeglądów z zespołami: mój zespół miał na celu zebrać w sali konferencyjnej wszystkich programistów pracujących nad usługą i poprosić ich, aby w ciągu maksymalnie 30 minut przedstawili na tablicy strukturę swojej usługi. W ten sposób zarówno mój zespół, jak i zespół gospodarzy mógł szybko i łatwo zidentyfikować miejsca, w których usługi zawodziły — po zaprezentowaniu mikrousługi w całej jej okazałości (punkty końcowe, przepływy żądań, zależności itp.) wszystkie punkty awarii stawały się widoczne jak na dłoni.
Każdy przegląd architektury wymagał sporo pracy. Po każdym przeglądzie przeglądaliśmy listę kontrolną i obserwowaliśmy, czy usługa spełniła którekolwiek wymagania gotowości do pracy. Następnie prezentowaliśmy wyniki tego audytu menedżerom i programistom zespołu. W audytach stosowaliśmy punktację. Gdy dochodziliśmy do wniosku, że określenie „gotowy” lub „niegotowy” do produkcji nie było dostatecznie precyzyjne, aby mogło być przydatne do oceny gotowości usług, to każdemu z wymagań przypisywaliśmy określoną liczbę punktów. Suma tych punktów tworzyła ogólny wynik dla usługi.
Efektem audytów były plany działania. Zawierały one listę wymagań gotowości do pracy, których usługa nie spełniała, wraz z odnośnikami do informacji na temat ostatnich spowodowanych przez to usterek, opisami prac koniecznych do zrealizowania w celu spełnienia wymagania, łączami do otwartego zadania i nazwiskiem programisty przypisanego do danego zadania.
Po przeprowadzeniu własnej oceny gotowości do pracy za pomocą tego procesu (znanego również jako proces gotowości usługi do pracy Susan Fowler) wiedziałem, że następnym krokiem musi być jego automatyzacja, aby można go było przeprowadzać przez cały czas dla wszystkich mikrousług w Uberze. Gdy piszę tę książkę, cały system gotowości do produkcji jest zautomatyzowany przez niezwykły zespół SRE w Uberze pod kierownictwem nieustraszonej Roxany del Toro.
Wymagania gotowości do produkcji w ramach standardów gotowości oraz szczegóły ich realizacji powstały na podstawie niezliczonych godzin precyzyjnej i przemyślanej pracy — zarówno mojej, jak i moich kolegów w Uber SRE. Podczas tworzenia listy wymagań i prób implementowania ich we wszystkich mikrousługach tworzyliśmy niezliczone notatki, długo dyskutowaliśmy oraz analizowaliśmy wiedzę, jaką mogliśmy znaleźć w bieżącej literaturze na temat mikrousług (jest ona bardzo rzadka — można powiedzieć, że prawie nie istnieje). Próbując ustalić możliwości standaryzacji mikrousług i starając się odpowiedzieć na pytanie, czy istnieje uniwersalny zestaw zasad normalizacji, które można zastosować do każdej mikrousługi w każdej firmie, aby uzyskać wymierne, znaczące dla firmy wyniki, spotykałam się z wieloma zespołami programistów mikrousług, zarówno w Uberze, jak i w innych firmach. Efekty notatek, dyskusji, spotkań oraz analiz stworzyły podwaliny tej książki.
Dopiero gdy zaczęłam dzielić się moją pracą z inżynierami SRE i programistami w innych firmach w Bay Area, zdałam sobie sprawę z jej oryginalności, nie tylko w świecie SRE, ale również w branży technologicznej w ogóle. Gdy inżynierowie zaczęli pytać mnie o każdy szczegół informacji i wskazówki, których mogłabym im udzielić w celu ujednolicenia ich mikrousług i przygotowania do wykorzystania w produkcji, zaczęłam pisać.
W czasie, gdy pisałam tę książkę, istniało bardzo mało literatury fachowej o standaryzacji mikrousług i niewiele poradników na temat utrzymywania i budowania ekosystemu mikrousług. Nie było też książek, które odpowiadają na pytanie, jakie stawia sobie wielu inżynierów po podzieleniu swoich monolitycznych aplikacji na mikrousługi: co dalej? Ambitnym celem mojej książki jest wypełnienie tej luki oraz udzielenie precyzyjnej odpowiedzi na to pytanie. Krótko mówiąc: jest to książka, którą chciałabym mieć, kiedy zaczynałam standaryzację mikrousług w firmie Uber.
Dla kogo jest ta książka?
Tę książka napisałam przede wszystkim dla inżynierów oprogramowania i inżynierów SRE, którzy albo podzielili monolit i zastanawiają się „co teraz?”, albo od podstaw budują mikrousługę i chcą zaprojektować ją tak, aby była stabilna, niezawodna, skalowalna, odporna na awarie i wydajna.
Jednak znaczenie zasad zawartych w tej książce nie ogranicza się do podstawowej grupy odbiorców. Wiele zasad — począwszy od dobrego monitorowania do pomyślnego skalowania aplikacji — można zastosować do usprawniania usług i aplikacji o dowolnym rozmiarze i dowolnej strukturze w każdej organizacji. Inżynierowie, menedżerowie ds. technicznych, menedżerowie produktu i kierownictwo wysokiego szczebla mogą uznać tę książkę za przydatną z różnych powodów — do określania norm dla swoich aplikacji, zrozumienia zmian w strukturze organizacyjnej wynikających z decyzji architektonicznych lub w celu określenia wizji architektonicznych i operacyjnych w swoich organizacjach.
Wychodzę z założenia, że Czytelnik zna podstawowe pojęcia dotyczące mikrousług i ich architektury oraz podstawy nowoczesnych systemów rozproszonych. Czytelnicy, którzy rozumieją te pojęcia, zyskają najwięcej z lektury tej książki. Czytelnikom nieznającym tych zagadnień zalecam przeczytanie rozdziału 1., w którym zaprezentowałam krótki przegląd architektury mikrousług, ekosystemu mikrousług, wyzwań organizacyjnych towarzyszących mikrousługom oraz najważniejsze informacje dotyczące rozbijania monolitycznych aplikacji na mikrousługi.
*Artykuł stanowi fragment książki pt. „Mikrousługi. Wdrażanie i standaryzacja systemów w organizacji inżynierskiej” Susan J. Fowler (OnePress, 2017)
