Co to jest platform engineering? Przewodnik dla zespołów

Co to jest platform engineering? To praktyka budowania i utrzymywania wewnętrznej platformy, która daje programistom samoobsługowy dostęp do tego, czego potrzebują, żeby dowozić oprogramowanie: środowisk, pipeline'ów, usług, dokumentacji i zabezpieczeń. W praktyce mały zespół traktuje drogę między „mam pomysł” a „działa na produkcji” jak produkt, a programiści są jego klientami. Celem jest mniej czekania, mniej zgłoszeń i mniej narzędzi do nauczenia się.

Ten problem prawdopodobnie zna każdy zespół. Nowa usługa wymaga repozytorium, pipeline'u, bazy danych, sekretów, dashboardów i dyżurów, a każdy z tych elementów siedzi za inną stroną w wiki albo u innej osoby na Slacku.

Skąd się wzięło platform engineering?

Hasło „you build it, you run it” działało dobrze, dopóki zespół odpowiadał za jedną usługę i kilka narzędzi. Przestało się skalować, gdy stos urósł do Kubernetesa, Terraform, trzech systemów CI, menedżera sekretów, service mesha i stosu obserwowalności. Każdy programista miał nagle być po trochu inżynierem infrastruktury.

Koszt widać nie w budżecie, tylko w obciążeniu poznawczym. Programista, który potrzebuje 90 minut, żeby ustalić, który chart Helm jest „właściwy”, nie jest wolniejszy z powodu braku umiejętności. Spowalnia go brak domyślnych rozwiązań.

Platform engineering jest odpowiedzią na ten problem. Zamiast prosić każdy zespół o złożenie tego samego stosu od zera, dedykowany zespół składa go raz, czyni z niego łatwą opcję i dba o jego kondycję. Analitycy widzą ten sam trend: Gartner przewiduje, że do 2026 roku 80% dużych organizacji inżynierii oprogramowania będzie miało zespoły platform engineering, wobec 45% w 2022 roku.

Co tak naprawdę buduje zespół platformy?

Na chwilę pomińmy diagramy dostawców. W większości firm zespół platformy dostarcza cztery rzeczy.

• Wewnętrzną platformę deweloperską (IDP). Zbiór samoobsługowych narzędzi i przepływów pracy nad chmurą i CI. Może to być portal Backstage, produkt dostawcy albo dobrze utrzymywane repozytorium szablonów i CLI.

• Złote ścieżki. Zalecane, wspierane trasy dla typowych zadań, na przykład „utwórz nową usługę API” albo „dodaj kolejkę”.

• Zabezpieczenia (guardrails). Polityki, skanowanie i limity kosztów stosowane domyślnie, tak aby bezpieczna opcja była jednocześnie najwygodniejszą.

• Dokumentację i odkrywanie. Katalog, który odpowiada na pytania: kto odpowiada za tę usługę, gdzie jest jej runbook i od czego zależy?

Dobry test złotej ścieżki jest prosty: policz, ile kroków dzieli nowego programistę od pierwszego uruchomienia usługi w środowisku testowym. Jeśli odpowiedź to jeden krok, czyli uruchomienie generatora, ścieżka działa. Jeśli to kilkanaście kroków, w tym trzy prośby do innych zespołów i dwa tygodnie czekania na dostęp do konta chmurowego, ścieżka wymaga pracy, zanim ktokolwiek ją polubi. Ten sam test działa na całej platformie: im więcej czasu programista spędza na szukaniu, tym bardziej platforma przypomina biuro obsługi, a nie produkt.

Żadna z tych rzeczy nie wymaga nowej kategorii produktów. Wiele dobrych platform zaczynało jako szablon cookiecutter i plik README, który ktoś na bieżąco aktualizował.

Czym jest złota ścieżka i dlaczego zespoły je ignorują?

CNCF opisuje złotą ścieżkę jako „szablonowe złożenie dobrze zintegrowanego kodu i możliwości do szybkiego tworzenia projektów”. Tę definicję Google Cloud rozpisuje na przykładzie Spring Boot. Mówiąc prościej, to szablon, który już pierwszego dnia daje nowej usłudze repozytorium, pipeline, logowanie i konfigurację wdrożenia.

Tryb awarii jest równie prosty. Ścieżka, o którą nikt nie prosił, zbudowana bez rozmowy z zespołami, które będą z niej korzystać, ma adopcję na poziomie jednocyfrowym, a zespół platformy zastanawia się, czemu programiści wciąż otwierają zgłoszenia. Ścieżka musi być krótsza niż obejście, inaczej ludzie wybiorą obejście.

Dwie zasady pomagają utrzymać złote ścieżki przy życiu:

1. Wybrukowana, nie ogrodzona. Można zejść ze ścieżki, ale wtedy wsparcie dla tego, co powstało poza nią, spada na programistę.

2. Prowadzona jak produkt. Ktoś czyta opinie, śledzi adopcję i usuwa ścieżki, z których nikt nie korzysta.

Czy platform engineering to po prostu DevOps pod nową nazwą?

Po części tak, a uczciwa odpowiedź jest bardziej przydatna niż ta marketingowa. DevOps to kultura: wspólna odpowiedzialność deweloperów i operacji oraz krótkie pętle sprzężenia zwrotnego. Platform engineering to jeden ze sposobów, by tę kulturę dało się utrzymać w skali, bo powtarzalną pracę operacyjną zamienia w produkt.

SRE to z kolei inna dyscyplina. Inżynierowie SRE definiują cele niezawodności, mierzą je i decydują, kiedy wstrzymać wdrożenia, żeby je chronić. Zespół platformy dostarcza utwardzoną drogę. Zespół SRE mówi, ile ryzyka można na niej sobie pozwolić.

• DevOps to kultura i zestaw praktyk. Jego efektem są wspólna odpowiedzialność i automatyzacja, a zwykle zawodzi, gdy zamienia się w stanowisko pracy i kolejkę zgłoszeń.

• SRE to dyscyplina niezawodności. Jego efektem są SLO, budżety błędów i proces incydentów, a zwykle zawodzi, gdy staje się dyżurem bez autorytetu.

• Platform engineering to wewnętrzny zespół produktowy. Jego efektem są samoobsługowa platforma i złote ścieżki, a zwykle zawodzi, gdy powstaje platforma, z której nikt nie korzysta.

Praktyczną różnicę da się sprawdzić jednym pytaniem. DevOps pyta, czy zespoły wspólnie odpowiadają za produkcję. SRE pyta, czy usługa spełnia cel niezawodności. Platform engineering pyta, czy programista może dowieźć zmianę bez pomocy kogoś z zewnątrz.

Tryb awarii warto przeczytać dwa razy. Zespół platformy, który przyjmuje zgłoszenia i buduje wszystko, o co go poproszą, jest przemianowanym zespołem operacyjnym i dziedziczy wszystkie stare problemy kolejek.

Kiedy zespół platformy się opłaca?

Pomiń go, jeśli masz mniej więcej 30 inżynierów i jedną albo dwie usługi. Przy tej skali dobre repozytorium z szablonem i wspólny moduł Terraform wystarczą, a stały zespół platformy byłby narzutem. Kilka osób w zespole dziesięciu cicho stanie się platformą i to jest w porządku.

Zwrot zaczyna się wtedy, gdy powtarzają się te sygnały:

• Nowe usługi trafiają na produkcję tygodniami, głównie czekając na innych ludzi.

• Trzy zespoły rozwiązały ten sam problem wdrożeniowy na trzy różne sposoby.

• Wdrożenie nowego inżyniera oznacza stos wiedzy plemiennej i sporo pytań w stylu „zapytaj Priyę, ona wie”.

• Przeglądy bezpieczeństwa i zgodności odbywają się na końcu, osobno w każdym zespole, ręcznie.

Najmniejsza przydatna wersja to to, co Team Topologies nazywa najcieńszą wykonalną platformą (thinnest viable platform): tyle, ile wystarcza, by usunąć największy powtarzalny ból, dobrze udokumentowane i nic więcej. Zacznij od jednego przepływu, który kosztuje najwięcej godzin w zespołach, zwykle „utwórz nową usługę” albo „uzyskaj środowisko podglądu”.

Zarządzanie funkcjonalnościami to dobry przykład możliwości, która jest tańsza jako wspólna usługa niż jako dziesięć prywatnych.

Usługa flag, z której może korzystać każdy zespół, z tym samym śladem audytu i tymi samymi zasadami sprzątania, oszczędza każdemu zespołowi pisania własnego, pół-działającego systemu przełączników. Kupić czy zbudować, powinna należeć do platformy, a nie do każdego repozytorium osobno.

Co platforma ma wspólnego z czytaniem kodu?

Więcej, niż pokazują diagramy. Platforma jest tak użyteczna, jak wiedza wokół niej. Gdy programista pyta „jak usługa A uwierzytelnia się w usłudze B?”, odpowiedź siedzi w kodzie, konfiguracji i runbooku, który może mieć sześć miesięcy.

Tu zespoły platformy po cichu tracą czas. To do nich trafia pytanie na Slacku zaczynające się od „gdzie jest skonfigurowane X?”, a odpowiadają z pamięci, po raz piąty w tym tygodniu. Efekt widać, gdy repozytorium przekracza 80 tys. linii i zespół platformy staje się ludzkim indeksem wyszukiwania.

Kilka narzędzi pomaga tutaj, i każde rozwiązuje inną połowę problemu. Narzędzia docs-as-code trzymają część pisemną blisko źródła.

Asystenci świadomi kodu odpowiadają na pytania o sam kod. Asystent Sourcegraph celuje w duże organizacje z wieloma repozytoriami i jest sprzedawany przedsiębiorstwom na podstawie wyceny, więc lepiej pasuje do zespołów platform w dużych środowiskach niż do zespołu piętnastu osób.

Do codziennej pracy w edytorze ogólny asystent pokrywa sporo, z zastrzeżeniem, że zna tylko kontekst, który mu podasz.

Wzorzec, który warto skopiować: umieścić szablony złotych ścieżek, katalog własności i przeszukiwalny indeks kodu w jednym miejscu i pozwolić nowym inżynierom zadawać pytania tam, zanim zapytają człowieka. Efekt też da się zmierzyć w godzinach. Jeśli zespół platformy po wdrożeniu odpowiada na mniej niż dziesięć pytań „gdzie to jest skonfigurowane” tygodniowo, to zadziałało.

Jak zacząć bez budowania katedry?

Większość nieudanych wysiłków zaczyna się od narzędzia. Lepsza kolejność to: ludzie, potem ścieżki, potem narzędzia.

1. Przeprowadź wywiady z dziesięcioma programistami. Zapytaj, gdzie tracą czas między zmergowanym PR a działającą funkcją. Usłyszysz te same trzy odpowiedzi.

2. Wybierz jedną ścieżkę i wdróż ją w miesiąc. Jeden szablon „nowa usługa”, działający od początku do końca, pokonuje portal z 40 pustymi kafelkami.

3. Mierz przed i po. Śledź czas do pierwszego wdrożenia nowej usługi i czas do pierwszego zmergowanego PR nowego pracownika. Te dwie liczby powiedzą więcej niż każda ankieta satysfakcji.

4. Opublikuj plan i changelog. Praca platformy jest niewidoczna, dopóki nie uczynisz jej widoczną.

5. Usuwaj rzeczy. Wycofuj ścieżki i narzędzia, z których nikt nie korzysta. Mniejsza platforma, której ludzie ufają, bije większą, którą omijają.

Powstrzymaj się przed kupnem portalu na początek. Portal nałożony na chaotyczne przepływy daje ładniejszy chaos, a katalog z 247 wpisami, z których połowa jest nieaktualna, jest gorszy niż brak katalogu.

Co zrobić w poniedziałek? Wybrać jedną rzecz, która marnuje najwięcej czasu w wielu zespołach, i uczynić ją nudną. W większości firm to tworzenie nowej usługi albo uzyskanie środowiska testowego. Opisz ścieżkę, umieść ją tam, gdzie ludzie jej szukają, policz godziny, które oszczędza, i dopiero potem zdecyduj, czy potrzebujesz większego zespołu.

Co idzie nie tak i jak to wcześnie wychwycić?

Trzy wzorce awarii wracają raz po raz.

Platforma helpdesk. Prośby przychodzą zgłoszeniami, zespół ręcznie je realizuje i nazywa to samoobsługą. Test: czy programista może wykonać typowe zadanie bez rozmowy z kimkolwiek?

Platforma nakazowa. Kierownictwo wymusza na każdym zespole przejście na platformę, zanim jest dobra. Liczby adopcji wyglądają świetnie, a nastroje się załamują. Korzystanie powinno być zdobywane przez pierwsze sześć miesięcy.

Platforma wszystkiego. Każda prośba staje się funkcją, powierzchnia rośnie, a jakość spada. Mów „nie”, na piśmie i z uzasadnieniem.

Przydatny wczesny sygnał to stosunek pytań na Slacku do udokumentowanych odpowiedzi. Jeśli to samo pytanie pojawia się trzy razy w miesiącu i nie ma na nie dokumentu, szablonu ani automatyzacji, to Twoja następna pozycja w backlogu.

Platform engineering to nie zestaw narzędzi, który się instaluje. To decyzja, by traktować wewnętrznych programistów jak klientów, a dowodem, że ją podjęto, jest krótsza droga między pierwszym dniem nowego pracownika a jego pierwszą zmianą scalona do głównej gałęzi.