SRE w kontekście
- 10 min
Zanim zbadamy niektóre praktyki związane z inżynierią SRE, dobrze będzie umieścić niektóre pomysły poznane w poprzedniej lekcji w kontekście. W tej krótkiej lekcji poznamy niektóre z historii związane z usługą SRE i sposób, w jaki odnosi się on do innych praktyk operacyjnych, z którymi możesz się zapoznać. Ta wiedza umożliwia nam późniejsze osiągnięcie większego sukcesu, ponieważ te praktyki mają większe znaczenie w kontekście. Ponadto, gdy twoi przyjaciele pytają "Jak różni się SRE od ..." masz gotową odpowiedź.
Historia
Bardzo skrócona historia inżynierii SRE rozpoczyna się od źródeł tej idei w firmie Google w roku 2003. Ben Treynor, teraz Treynor Sloss, przejął kierownictwo "Production Team" Google (wtedy tylko siedmiu inżynierów oprogramowania). Treynor stworzył pomysł i opisał go jako "co się stanie, gdy poprosisz inżyniera oprogramowania o zaprojektowanie funkcji operacji". Warto zrozumieć tę historię, ponieważ pomaga wyjaśnić, dlaczego inżynieria SRE może czuć się bardzo "inżynierią oprogramowania" dla osób korzystających z tej historii po raz pierwszy. Przyjęła ona wartości i narzędzia z tego pola, np. znaczenie kodowania oraz systemy kontroli źródła, jako narzędzia fundamentalne. Wstępne i bieżące wdrożenie SRE w firmie Google jest dobrze udokumentowane w dwóch książkach opublikowanych przez wydawnictwo O'Reilly (zobacz lekcję Wprowadzenie).
Kiedy część osób zaczęła odchodzić z Google (i ludzie z firmy zaczęli częściej publicznie mówić o ich praktykach), pojęcie SRE zaczęło rozprzestrzeniać się do innych organizacji w branży. Kiedy inżynieria SRE dotarła do nowych organizacji, zaczęły one przyjmować i dostosowywać zasady i praktyki SRE, aby dopasować je do lokalnej kultury. Ten proces rozszerzania przyniósł wiele różnych implementacji SRE w terenie.
DevOps i SRE
Szersza branża doświadczała tych samych wyzwań związanych ze skalowaniem, prędkością rozwoju oraz stabilnością operacyjną oraz innych problemów z dostarczaniem oprogramowania, które przyczyniły się do powstania ruchu inżynierii niezawodności lokacji. Równolegle wysiłki związane z tymi wyzwaniami były podejmowane poza firmą Google (w kilku większych firmach w tym czasie), które przyczyniły się do powstania metodyki DevOps.
Aby uzyskać wiele dobrych informacji na temat metodyki DevOps, zobacz Centrum zasobów DevOps.
Uwaga
Należy zauważyć, że DevOps i SRE to dwa różne, równoległe podejścia, które powstały w odpowiedzi na te same wyzwania. Inżynieria SRE nie jest następnym krokiem w ewolucji DevOps. SRE nie został utworzony jako "przyszłość metodyki DevOps".
Różnice między usługami SRE i DevOps są nadal przedmiotem znacznej dyskusji w tej dziedzinie. Istnieje kilka ogólnie uzgodnionych różnic, w tym:
- Inżynieria SRE to dyscyplina inżynieryjna, która koncentruje się na niezawodności. DevOps to ruch kulturowy, który pojawił się z chęci podzielenia silosów zwykle związanych z oddzielnymi organizacjami deweloperskimi i operacyjnymi.
- SRE może być nazwą roli, np. „Jestem inżynierem niezawodności lokacji (SRE)”. DevOps nie może. Nikt, mówiąc ściślej, nie zarabia na życie będąc „DevOps”.
- SRE wydaje się być bardziej normatywne, ale Metodyka DevOps celowo tak nie jest. Niemal uniwersalne przyjęcie ciągłej integracji/ciągłego dostarczania oraz zasad Agile są najbliższym elementem w tej kwestii.
Dwa rozwiązania związane z operacjami, DevOps i SRE, dzielą wspólne zamiłowanie do monitorowania/możliwości obserwacji oraz automatyzacji (możliwe, że z różnych powodów). Jest to jeden z powodów, dla których często łatwiej jest zaimportować praktyki i zasady inżynierii SRE do organizacji z istniejącą praktyką DevOps. Ten proces musi być przeprowadzany z rozwagą i rozmysłem. Można go również wdrażać przyrostowo. Nie trzeba robić nagłego przełączania.
Ostrzeżenie
Zamiana tytułów dla osób w organizacji jest strategią implementacji, która prawie nigdy nie powiedzie się. Nie przyniesie korzyści, jakie usługa SRE ma do zaoferowania. Zobacz sekcję Wprowadzenie w tej lekcji, aby uzyskać lepsze sugestie.
Podsumowanie
Celem tej krótkiej lekcji było zaprezentowanie odrobiny kontekstu dla inżynierii SRE oraz metodyki DevOps. Usługi SRE i DevOps najlepiej traktować jako sąsiadujące szkoły myśli w praktykach operacyjnych.
Teraz, gdy krótko przyjrzeliśmy się niektórym z podstaw inżynierii SRE, przejdźmy do niektórych podstawowych zasad.