Blog

21 lipca 2022 Piotr Mynarski

Wdrożenie SRE w organizacji

Wdrożenie SRE w organizacji

pierwszej części opisałem czym jest koncepcja SRE, co leży u jej podstaw oraz jakie korzyści z niej wynikają z kolei druga część dotyczyła fundamentów podejścia SRE. W części trzeciej chciałbym zastanowić się, kiedy organizacja potrzebuje podejścia SRE. Czy takie podejście jest zawsze opłacalne?

Kiedy organizacja dojrzewa do SRE 

Nie każda organizacja potrzebuje systemów o wysokiej niezawodności. O ile nie jest to kluczowe dla naszej organizacji lub nie jest to system, na którym zarabiamy, z powodzeniem można naprawić awarię w ciągu kilku godzin w dni robocze. Koszt utrzymania w takim modelu będzie stosunkowo niski. 

Kilka lat temu, kiedy w eSky nasze rozwiązania zaczęły obsługiwać znacznie większy ruch, spowodowany ekspansją na wiele rynków całego świata, stanęliśmy przed problemem wiarygodnej oceny niezawodności naszych systemów. Utrata możliwości obsługi wzrastającego ruchu bolała nas coraz bardziej. Każda minuta przestoju wiązała się z realnymi stratami związanymi z niezrealizowanymi transakcjami zakupu oraz przepalonymi pieniędzmi na kampanie marketingowe SEM. Zaczęliśmy poszukiwania rozwiązań, które pozwoliłyby zneutralizować ten problem. I tak na przełomie 2018 i 2019 roku zaczęliśmy interesować się podejściem SRE, co planuję opisać w kolejnym artykule. 

Jak dowiedzieć się czy podejście SRE w organizacji faktycznie się opłaca? Możemy posłużyć się kilkoma heurystykami, które pomogą nam zrozumieć potrzebę jego wdrożenia.

Pierwszym pytaniem, na jakie warto sobie odpowiedzieć, jest to czy nasz system jest niezawodny. Pod pozornie prostym pytaniem kryje się bardzo złożony problem. Jednakże pozwala nam ono zainicjować proces zastanawiania się nad zagadnieniem niezawodności. Czasem to pytanie obnaża, jak było to również w przypadku eSky, brak zrozumienia tej tematyki, powierzchowność lub brak zainteresowania. Żeby odpowiedzieć sobie na to pytanie, muszą być spełnione trzy warunki: po pierwsze należy wiedzieć, jakie miary w naszych rozwiązaniach są istotne z punktu widzenia użytkownika, po drugie musimy wiedzieć jakie poziomy tych miar są dla nas wyznacznikiem niezawodności, do jakiej chcemy dążyć, oraz po trzecie, musimy potrafić je zmierzyć. Dopiero spełnienie wszystkich trzech warunków pozwoli nam ocenić, czy nasz system jest niezawodny.

Każdy z nas spotkał się wielokrotnie w swojej karierze z powracającymi problemami na produkcji. Ich przyczyny mogą leżeć zarówno w infrastrukturze, jak i w kodzie oprogramowania uruchomionego produkcyjnie. Jeżeli często mamy do czynienia z problemami o podobnej genezie to znak, że prawdopodobnie brakuje w organizacji kultury wyciągania wniosków z zaistniałych awarii. Podejście SRE ma wbudowany mechanizm usprawniania, polegający na dokumentowaniu awarii, w postaci spotkań Postmortem oraz wdrażania działań usprawniających, które z nich wynikają. Cały ten proces ma na celu budowanie stałej dbałości o niezawodność, poprzez eliminowanie przyczyn zidentyfikowanych błędów, ciągłe usprawnianie rozwiązań jak również budowanie odpowiedzialności w atmosferze wzajemnego zaufania (blameless).

Kolejną heurystyką mogą być powtarzające się spory na linii biznes oraz IT. Jak zostało już wspomniane w pierwszej części artykułu, często dochodzi do przepychanek i wzajemnego obwiniania się w kontekście działania systemu. Najczęściej wynika z to z różnych wyobrażeń osób będących interesariuszami rozwiązań a naszą percepcją na ich działanie. To z kolei może wynikać z innych przyczyn, takich jak obserwowanie różnych wskaźników, różnych źródeł danych, patrzenia z różnych perspektyw na podobne problemy. Jednym słowem wynika to z braku porozumienia co do definicji niezawodności. 

Nad wdrożeniem SRE warto również zastanowić się w przypadku, gdy mamy biznesowe zobowiązania SLA z naszymi partnerami i użytkownikami, a ich naruszenie generuje koszty w postaci kar umownych. Podejście SRE w takiej sytuacji może nam pomóc lepiej zarządzać takim ryzykiem.

Wracając do postawionego wyżej pytania, czy wdrożenie SRE się opłaca? Z reguły im większa organizacja tym bardziej opłaca się inwestycja w niezawodność. Podejście SRE jest jedną z możliwych dróg na jej osiągnięcie. Z doświadczeń w eSky.pl wynika, że jest to droga szybka i skuteczna przy spełnieniu kilku warunków.

Wyzwania towarzyszące wdrażaniu SRE

Dobrą analogią do wdrażania SRE w organizacji jest wdrażanie SCRUMa. Podejście SRE jest łatwe do zrozumienia, ale trudne w implementacji, ponieważ nie ogranicza się do zastosowania kilku reguł lecz wymaga zmiany w działaniu organizacji i jej mentalności. Z naszego doświadczenia wynika, że warto na wczesnych etapach angażować jak najwięcej osób biznesowych w ustalanie reguł niezawodności, aby był to wynik wspólnego porozumienia pomiędzy biznesem oraz technologią. Trudno jest przekonać decydentów, że poziom niezawodności to pewien koszt, a zarazem inwestycja, często wymagająca wspólnego podejmowania trudnych decyzji. Jeżeli będziemy w stanie zaprezentować naszemu biznesowi choć jeden praktyczny przykład SLI/SLO i zaczniemy o tym rozmawiać to nasze szanse na wdrożenie SRE w całej organizacji zdecydowanie wzrosną!

Dosyć trudnym może również okazać się przekonanie biznesu, że 0 oraz 100% to jedyne złe wartości poziomów SLO. Wiadomo, że zaraz po słowach „ma działać” usłyszymy najczęściej: „zawsze” lub „na 100%”. Takie podejście jest naturalne i zrozumiałe. Biznes inwestuje w technologię ogromne pieniądze, licząc na zwrot z tej inwestycji, nie koncentrując się na złożoności tej materii. My z kolei oczekujemy, że biznes doceni nasze trudy i starania, przy tym doskonale wiedząc jak ciężko jest ogarnąć tak wiele serwerów, napisać czysty, piękny kod, w pełni przetestowany, który na dodatek dobrze się skaluje pod obciążeniem i oczywiście jest bezpieczny. Przecież to zadanie dla superbohaterów, jakimi jesteśmy. Możemy wzajemnie żyć w takim wyizolowanym świecie, ale lepiej jest znaleźć porozumienie, które obie strony zaakceptują i będą rozumiały. Takim kontraktem są liczby, a w tym przypadku oczywiście wartości SLI i SLO. Jeżeli pokażemy biznesowi nasze aktualne wyniki SLI i oszacujemy, że podniesienie tej wartości będzie niosło za sobą określony koszt finansowy (możemy wyestymować liczbę godzin pracy, dodać koszty infrastruktury itp.) to takie podejście będzie dla biznesu dokładnie tym, czego oczekują. Przekonanie ich do tego, że mogą zarządzać takim kosztem porównując go z potencjalnymi korzyściami uzyskanymi w wyniku podniesienia niezawodności usługi będzie raczej kwestią formalną.

Warto zwrócić uwagę również na problem braku regularnego obserwowania wskaźników i ignorowania przekroczeń ustalonych SLO. Wydaje się to być z pozoru błahym problemem. W rzeczywistości, kiedy pozwolimy sobie na małe ustępstwa to z czasem zaczynają one stawać się czymś normalnym, akceptowalnym i przeradzają się w zupełną ignorancję. Warto zatem regularnie przyglądać się tym wskaźnikom i ich SLO aby cały czas je ewaluować. Praktyką, jaką wdrożyliśmy w eSky.pl jest ewaluacja wskaźników SLO na review produktowych, które u nas odbywają się co 2 tygodnie. Jest to moment, w którym zespoły produktowe, wraz z prezentacją wyników sprinta, prezentują również poziomy SLO. Każdy może wówczas zapytać o przyczyny ewentualnych przekroczeń lub zaproponować zmianę wartości SLO, jak również dodanie nowych wskaźników. Rozmawiamy wtedy dokładnie o tym samym i tym samym językiem. 

Innym wyzwaniem może również okazać się kultura blameless, czyli skoncentrowanie się na problemie i sposobach jego poprawienia i unikania w przyszłości, a nie na szukaniu winnych. W niektórych organizacjach, być może takich, które wysoko cenią sobie indywidualne wyniki pracowników i gdzie zakorzeniła się kultura nagród i kar, wdrożenie kultury blameless może okazać się najtrudniejszą zmianą do przeprowadzenia. Wydaje się jednak, że takich organizacji, szczególnie w dzisiejszym świecie technologii, jest coraz mniej, a dla tych, które jeszcze funkcjonują w podobnych modelach, kultura blameless w SRE może być pretekstem do zmiany.

Korzyści z punktu widzenia przedsiębiorstwa

Wdrożenie podejścia SRE jest wyrazem dojrzałości organizacji w rozumieniu biznesu na styku z technologią. Jest przejściem z zawodnego, życzeniowego wyobrażenia, na świadome zarządzanie niezawodnością systemów i rozwiązań. Jednocześnie tworzy platformę porozumienia i współodpowiedzialności za te decyzje, mobilizując obie strony do aktywnego udziału w tym procesie.

Observability towarzyszące SRE zmienia percepcję z poziomu dostępności systemów na poziom niezawodności — różnica polega na patrzeniu od strony biznesu i użytkownika oraz obserwowaniu rozwiązań jako całości, a nie jako poszczególnych komponentów i technologii (parametry techniczne: zajętość procesora, przepustowość sieci, dostępność RAM, HDD).

Niezawodność staje się częścią stałych procesów w organizacji. Staje się powszechna, a nie przypadkowa, incydentalna. Niezawodność jest udoskonalana zarówno w sposób reaktywny jak i, co ważniejsze, proaktywny. Skuteczne rozwiązywanie problemów wspiera Postmortem, będące retrospektywą problemów i sprzężeniem zwrotnym, na którym buduje się mechanizm continuous improvement oraz kultura blameless, przełamująca bariery winy i naturalnie sprzyja zaangażowaniu i poczuciu odpowiedzialności. 

Co więcej, niezawodność otrzymuje wymierny kształt, który można zmierzyć, policzyć, wycenić i porównać z kosztem potencjalnych korzyści, które może dostarczyć dla biznesu.

Dzięki za wytrwanie do końca! 

Mam szczerą nadzieję, że zachęciłem Cię do głębszego poznania podejścia SRE, które wiele zmieniło w moim postrzeganiu niezawodności, jak również wiele zmieniło w całej naszej organizacji. Z mojej obserwacji wynika, że dzięki podejściu SRE, niewdzięczny temat niezawodności, który zawsze stanowił powód do sporów, kontrowersji i nikt go nie lubił, stał się czymś, z czego możemy być dumni, utożsamiać się z nim i dbać o niego z motywacją i zaangażowaniem. Naprawdę warto!

Jeżeli jesteście zainteresowani tematem SRE, jeśli macie własne doświadczenia w tym obszarze albo chcielibyście się dowiedzieć więcej na temat samego wdrożenia SRE w eSky, dajcie proszę znać w komentarzu. Chętnie podzielimy się naszymi doświadczeniami.

Zobacz na blogu

09.09.2022
Marcin Jahn
It’s Not Just HTTP It’s Not Just HTTP

In today’s world of cloud-based solutions, distributed systems, and microservices-based architectures, network communication is a...

23.08.2022
Adam Mrowiec
Konferencja IPC 2022 Berlin Konferencja IPC 2022 Berlin

Pandemia wreszcie się kończy, dlatego w tym roku postanowiliśmy wrócić do naszych wyjazdów na konferencje....