Istnieje zestaw typowych pytań, które pojawiają się wokół relacji między inżynierią niezawodności lokacji i metodyką DevOps, w tym "Jak są one takie same? Czym się od siebie różnią? Czy możemy mieć obie te elementy w naszej organizacji?". W tym artykule podjęto próbę udostępnienia niektórych odpowiedzi oferowanych przez społeczności SRE i DevOps, które przybliżą nas do zrozumienia tej relacji.
Jak są one takie same?
SRE i DevOps to nowoczesne rozwiązania operacyjne, które zostały utworzone i opracowane w odpowiedzi na wyzwania, które obejmowały:
- rosnąca złożoność naszych środowisk produkcyjnych i procesów programistycznych
- zwiększenie zależności biznesowej od ciągłego działania tych środowisk,
- niezdolność do liniowego skalowania liczby pracowników proporcjonalnie do rozmiaru tych środowisk.
- konieczność szybszego działania przy zachowaniu stabilności operacyjnej
Obie praktyki operacyjne cenią uwagę na tematy, które mają kluczowe znaczenie dla radzenia sobie z tymi wyzwaniami, takimi jak monitorowanie/ obserwowanie, automatyzacja, dokumentacja i narzędzia do tworzenia oprogramowania do współpracy.
Istnieje znaczne nakładanie się na narzędzia i obszary pracy między usługami SRE i DevOps. Jak ujął to skoroszyt niezawodności lokacji, "usługa SRE wierzy w te same elementy co metodyka DevOps, ale z nieco różnych powodów".
Trzy różne sposoby porównywania dwóch praktyk operacyjnych
Podobieństwa między usługami SRE i DevOps są jasne. Gdzie jest naprawdę interesujące jest to, jak te dwie różnice lub rozbieżność. Tutaj oferujemy trzy sposoby, aby myśleć o ich relacji jako sposób na wprowadzenie pewnych niuansów do tego pytania. Możesz nie zgadzać się z tymi odpowiedziami, ale każda z nich stanowi dobre miejsce wyjścia do dyskusji.
"Klasa SRE implementuje interfejs DevOps"
Skoroszyt niezawodności lokacji (wymieniony na naszej liście książek zasobów) omawia SRE i DevOps w pierwszym rozdziale. W tym rozdziale użyto frazy "class SRE implementuje interfejs DevOps" jako jej podtytuł. Ma to na celu sugerowanie (przy użyciu frazy skierowanej do deweloperów), którą można uznać za określoną implementację filozofii metodyki DevOps. Jak podkreśla rozdział, "DevOps jest stosunkowo cichy, jak uruchamiać operacje na szczegółowym poziomie", podczas gdy SRE jest znacznie bardziej proskrypcyjny w swoich praktykach. Więc jedną z możliwych odpowiedzi na pytanie, w jaki sposób te dwa powiązania są SRE, można uznać za jedną z wielu możliwych implementacji metodyki DevOps.
SRE to niezawodność, ponieważ metodyka DevOps ma dostarczać
To porównanie jest nieco błotniste, ponieważ istnieje wiele definicji zarówno SRE, jak i DevOps, ale nadal jest potencjalnie przydatne. Zaczyna się od pytania "Gdyby trzeba było destylować poszczególne operacje praktykować w jednym lub dwóch słowach, które odzwierciedlają jego podstawowe obawy, co by się stało?"
Jeśli używamy tej definicji inżynierii niezawodności lokacji z centrum inżynierii niezawodności lokacji:
Inżynieria niezawodności lokacji to dyscyplina poświęcona pomaganiu organizacji w trwałym osiągnięciu odpowiedniego poziomu niezawodności w zakresie systemów, usług i produktów.
wtedy łatwo byłoby powiedzieć, że słowo dla SRE jest "niezawodność". Posiadanie go w środku nazwy oferuje również kilka doskonałych dowodów na to twierdzenie.
Jeśli używamy tej definicji metodyki DevOps z centrum zasobów usługi Azure DevOps:
DevOps to związek ludzi, procesów i produktów umożliwiający ciągłe dostarczanie wartości użytkownikom końcowym.
wówczas podobna destylacja metodyki DevOps może być "dostarczanie".
W związku z tym "SRE jest niezawodność, ponieważ metodyka DevOps ma dostarczać".
Kierunek uwagi
Ta odpowiedź jest cytowana lub nieco parafrazowana z udziału Thomasa Limoncelli'ego w książce Seeking SRE wymienionej na naszej liście książek zasobów. Zauważa, że inżynierowie DevOps w dużej mierze koncentrują się na potoku cyklu życia tworzenia oprogramowania z okazjonalnymi obowiązkami operacji produkcyjnych, podczas gdy srEs koncentrują się na operacjach produkcyjnych z okazjonalnymi obowiązkami potoku SDLC.
Ale co ważniejsze, rysuje również diagram, który rozpoczyna się od procesu tworzenia oprogramowania po jednej stronie, a operacje produkcyjne działają na drugim. Te dwa są połączone przez zwykły potok, który został utworzony, aby pobrać kod od dewelopera, przeprowadzić go przez żądaną liczbę testów i etapu, a następnie przenieść ten kod do środowiska produkcyjnego.
Limoncelli zauważa, że inżynierowie DevOps rozpoczynają pracę w środowisku deweloperskim i automatyzują kroki w kierunku produkcji. Po zakończeniu wracają do optymalizowania wąskich gardeł.
Z drugiej strony SPRO koncentrują się na operacjach produkcyjnych i zagłębiają się w potok jako środek poprawy wyniku końcowego (zasadniczo działają w przeciwnym kierunku).
Jest to różnica w kierunku skupienia się na usługach SRE i DevOps, które mogą pomóc je odróżnić.
Współistnienie w tej samej organizacji
Ostatnim pytaniem, które chcemy rozwiązać, jest "Czy możesz mieć zarówno SRE, jak i DevOps w tej samej organizacji?"
Odpowiedź na to pytanie to emphatic "yes!".
Mamy nadzieję, że poprzednie odpowiedzi oferują pewne pomysły, w jaki sposób obie praktyki operacyjne nakładają się na siebie i, gdy nie nakładają się, jak mogą one być uzupełniające w centrum uwagi. Organizacje z ustanowioną praktyką DevOps mogą eksperymentować z praktykami SRE na małą skalę (na przykład próbą użycia wskaźników SLI i celów SLO) bez konieczności zatwierdzania tworzenia stanowisk lub zespołów SRE. Jest to dość typowy wzorzec wdrażania SRE.