Czym różnią się: DevOps, SRE oraz utrzymanie?

DevOps to ogólna filozofia wytwarzania oprogramowania, w której osoby „od operations” pracują wspólnie z osobami zajmującymi się „development’em” w ramach tego samego zespołu oraz tych samych zadań. SRE jest jedną z implementacji praktyki DevOps zaproponowaną i rozpowszechnioną przez Google.

W świecie IT nieco błędnie używamy nazwy DevOps do nazywania stanowisk oraz całych działów. Choć oczywiście nie ma nic w tym złego, o ile jest to dla wszystkich zrozumiałe i każdy wie, co powinien robić.

SRE a DevOps Engineer

Jakie są różnice?

1. DevOps zwyczajowo jest bliżej development’u i zajmuje się również systemami CI/CD oraz środowiskami developerskimi (nie oznacza to, że nie będzie go można spotkać pracującego przy produkcji); SRE koncentruje się na środowiskach produkcyjnych (często z powodów praktycznych zarządza również wcześniejszymi środowiskami).
2. DevOps pracuje z zespołem, przygotowując produkt funkcjonalnie, natomiast SRE ma zadania związane z bezpośrednim zapewnieniem ciągłości działania produkcji.
3. DevOps pracuje w rytmie zespołu produktowego natomiast SRE w swoim własnym (będzie również pracować w tzw. sprintach czy z wykorzystaniem innych praktyk Agile).

Które elementy pracy są podobne?

1. Z technologicznego punktu widzenia zestaw umiejętności jest zasadniczo podobny (mogą pojawić się lokalne różnice w zależności od konkretnych firm).
2. Automatyzacja to podstawa pracy zarówno inżynierów DevOps, jak i SRE. Ci pierwsi większą uwagę będą poświęcać rozwiązaniom bliższym developmentowi tj. CI/CD, a Ci drudzy (SRE) zagadnieniom monitoringu, automatyzacji deploymentów, itp.
3. W ramach umiejętności obu grup możemy wymienić, takie jak: praca z systemem operacyjnym, znajomość sieci, czy rozwiązań cloudowych.

Zespół SRE a Utrzymanie

Systemy IT poza tym, że muszą być najpierw wytworzone, następnie trzeba je uruchomić na tzw. produkcji. Zespół, który zajmuje się dbaniem o takie aplikacje nazywamy czasami zespołem utrzymania. Zwykle zespół taki odpowiada za całość prac zaczynając od obsługi kontaktu z klientem a kończąc na poprawie bugów.

Co ciekawe, o ile różnice pomiędzy DevOps a SRE to głównie kwestia obszaru zainteresowań to tzw. „utrzymanie” od SRE różni się już dość znacząco. Nie jest to intuicyjne, ponieważ jeden i drugi zespół skupia się głównie na dopilnowaniu poprawnego działania systemu na produkcji:

1. SRE nie stanowi bezpośredniego wsparcia zgłoszeń klientów, nawet jeśli takie zgłoszenie wymaga ingerencji z jego strony, to zwykle odbywa się to poprzez wewnętrzną komunikację z opiekunami danego klienta czy też L1. Utrzymanie często bezpośrednio pracuje z klientem.
2. SRE nie poprawia błędów funkcjonalnych produktów, którymi się opiekuje (niefunkcjonalne błędy np.: OutOfMemory również będą trafiały do zespołów produktowych). Utrzymanie może wykonywać bugfix zwalniając z tej nieprzyjemnej czynności developerów (w mojej ocenie powoduje to największe straty tym drugim, gdyż nie mają możliwości uczyć się na własnych błędach).
3. Produkt nie jest przekazywany do SRE tak, jak by to miało miejsce w przypadku utrzymania. Zespół developerski odpowiada w całości za swoje dzieło włącznie z produkcją. Rola SRE to wsparcie utrzymania na produkcji, a nie przejmowanie odpowiedzialności za wszystko, co dzieje się na produkcji. Stanowi ono swojego rodzaju „SRE Gate” dla produktów, których jakość odbiega od standardów dopuszczonych w danej firmie.
4. SRE nie jest obowiązkowe. Pewne produkty albo raczej specyfika ich aktualnego etapu w cyklu życia, nie powinny być przekazywane do SRE. Możliwe jest również oddanie z powrotem zbyt wadliwych produktów do utrzymania po stronie zespołu który dany produkt zbudował.
5. SRE ściśle współpracuje z zespołami developerskimi dbając również o komunikację między zespołową np. pomiędzy developmentem a security, czy zespołem architektów. Co więcej, SRE jest aktywne na etapie budowy produktu tak, aby produkt był możliwie łatwy w późniejszej pracy na środowiskach produkcyjnych.

Różnica lub raczej brak podobieństw w sposobie pracy wynika właśnie z ideologii devops i świadomości wewnątrz organizacji, że to zespół, który wytworzył oprogramowanie najlepiej się nim zaopiekuje. SRE stanowi wysoce wyspecjalizowany zespół wsparcie w sytuacjach trudnych a także w prawidłowym lub raczej bezprzestojowym zorganizowaniu aplikacji i architektury.

Zobacz też

DevOps Kim jest DevOps Engineer i jak nim zostać?

Czym w takim razie jest SRE?

SRE to zespół inżynierów, którego głównym zadaniem jest zrobienie wszystkiego, aby systemy produkcyjne były dostępne cały czas. W sieci często powtarzają się te same wymagania bądź aspekty z pracy SRE: monitoring, automatyzacja, ale także wsparcie w tworzeniu architektury czy walidacja poprawności budowy aplikacji przed jej uruchomieniem. Nie mniej ważne są również aspekty dbania i nadzorowania bezpieczeństwa aplikacji.

To, co zasługuje na powtórzenie to fakt, że SRE jest zaangażowane od samego początku tworzenia aplikacji i aktywnie uczestniczy w jej dostarczeniu.

Pojawia się w takim razie pytanie ,czy developerzy nie mogą tych zadań wykonać samodzielnie.

SRE a development

Z technicznego punktu widzenia SRE wywodzi się albo z developmentu albo z oddziałów devops. Pozwolę sobie w tym miejscu na personalną opinię. Najlepszym możliwym sposobem zadbania o aplikacje na “produkcji” jest powierzenie tego właśnie zespołowi developerskiemu. Nikt inny nie zrobi tego lepiej, z jednym wyjątkiem. Gdy ilość aplikacji, które uruchomiliśmy lub ich złożoność rośnie, wtedy konieczna jest wyższa specjalizacji i pojawia się potrzeba stworzenia dedykowanych zespołów, bądź też osób w ramach SRE.

Oferty pracy z

Jakie będą w takim razie różnice:

1. Developerzy muszą dzielić czas pomiędzy wytwarzanie nowych funkcjonalności zamawianych przez biznes a działania produkcyjne. Oczywiście założenie, że to problemy produkcyjne muszą być rozwiązane w pierwszej kolejności jest możliwe, to w praktyce rzadko udaje się to spełnić szczególnie pod koniec sprintów czy w przededniu release. SRE nie ma takiego dylematu w ogóle. Podziału zadań dokonujemy odpowiednio organizując zespół.
2. Praca SRE oparta jest o świadomość i doświadczenia wynikające z zarządzania systemem produkcyjnym, pokusa pójścia na skróty będzie pojawiała się zdecydowanie rzadziej.
3. Zespoły SRE będą mniej skłonne do innowacji w obrębie doboru technologii, szczególnie w ramach tzw, nowinek i pojawiających się tendencji nie podpartych udanymi wdrożeniami.

W tym miejscu warto podkreślić, że zarówno członkowie SRE, jak i developerzy bardzo szczegółowo i z dużą dbałością będą analizowali wszystkie możliwe scenariusze funkcjonalne tak, aby system zachowywał się możliwie bezbłędnie. Pychą byłoby uważać, że SRE z racji lepszej (bo doświadczonej) świadomości konsekwencji będzie popełniać znacząco mniej błędów. Wszyscy jesteśmy tylko ludźmi.

Zdjęcie główne artykułu pochodzi z unsplash.com.