5 podstawowych różnic między DevOps a SRE, o których powinieneś wiedzieć
Opublikowany: 2021-02-22Świat technologii informatycznych i tworzenia oprogramowania często łączy metody DevOps z SRE, aby oznaczać to samo. Jednak są między nimi ogromne różnice. Podczas gdy inżynieria niezawodności witryny (SRE) zyskała na popularności w ostatnich latach, DevOps istnieje znacznie dłużej (nawet przed pojawieniem się terminu DevOps).
Mówiąc prościej, DevOps i SRE to praktyki wprowadzone w celu szybszego dostarczania oprogramowania. Jedyna różnica między nimi polega na ich podejściu; DevOps koncentruje się na skróceniu cyklu życia oprogramowania, a SRE koncentruje się na wyeliminowaniu słabości systemu, aby osiągnąć ten sam cel.
W tym artykule przyjrzymy się podstawowym różnicom między DevOps i SRE. Zanim to zrobimy, zacznijmy od zrozumienia, czym są DevOps i SRE.
Spis treści
Co to jest DevOps?
Mówiąc słowami Gene Kima, autora Podręcznika DevOps i Projektu Phoenix,
„DevOps to zestaw norm kulturowych i praktyk technologicznych, które umożliwiają szybki przepływ zaplanowanej pracy, między innymi od rozwoju, przez testy do operacji, przy jednoczesnym zachowaniu światowej klasy niezawodności, działania i bezpieczeństwa. W DevOps nie chodzi o to, co robisz, ale o to, jakie są Twoje wyniki”.
Tak więc DevOps koncentruje się głównie na przekształcaniu praktyk kulturowych wewnątrz organizacji w celu przyspieszenia cyklu życia oprogramowania (SDLC). Nie jest skierowany do osoby, grupy ani stanowiska. DevOps ma na celu wzmocnienie współpracy zarówno między zespołami operacyjnymi IT, jak i zespołami programistycznymi.
Co robi i jak to robi, nie jest ważne; tylko wynik procesu jest potwierdzany.
DevOps wykorzystuje zestaw zasad, aby zintensyfikować ekspozycję zespołów inżynierów oprogramowania na systemy produkcyjne i umożliwić zespołowi operacyjnemu IT bardziej efektywne eskalowanie rozbieżności do zespołu programistów. W rzeczywistości SRE odgrywa kluczową rolę w organizacji DevOps, ułatwiając proaktywne testowanie, przyspieszając, umożliwiając obserwowanie i poprawiając niezawodność usług. DevOps zachęca każdą organizację zorientowaną na DevOps do działania zgodnie z zasadami kulturowymi przedstawionymi w jej modelu CALMS.
Co to jest SRE?
SRE, skrót od Site Reliability Engineering, to termin wymyślony przez starszego wiceprezesa Google, Bena Treynora, odpowiedzialnego za nadzorowanie operacji technicznych.
Drew Farnsworth (z Green Lane Design) wyjaśnia: „Ogólnie lubię myśleć o SRE jako o systemie, w którym rozwój kontroluje operacje. Jest to system, w którym środowisko jest podzielone na najbardziej podstawowe komponenty stosu IT i wdrażane z najlepszymi praktykami wbudowanymi w sprzęt”.
Zasadniczo, zespół SREs posiadający doświadczenie w tworzeniu oprogramowania ma za zadanie rozwiązywać problemy w produkcji systemu przy jednoczesnym zachowaniu równowagi między szybkością dostarczania a niezawodnością systemu. W ten sposób podejście SRE łączy personel zajmujący się tworzeniem oprogramowania w ramach ról operacyjnych w celu zastosowania ustrukturyzowanych praktyk inżynierskich w celu przestrzegania zasad organizacji.
Zapewniają, że systemy są dostępne i działają wydajnie przez cały czas, aby zespoły programistyczne mogły opracowywać usługi techniczne w celu zwiększenia niezawodności systemu. Obowiązkiem SRE jest zidentyfikowanie wszelkich potencjalnych słabości, zanim przerodzą się one w poważny problem.
DevOps vs SRE: największe różnice między DevOps a SRE
W praktyce DevOps i SRE należy postrzegać jako uzupełniające się dyscypliny, w których SRE jako część struktury skoncentrowanej na DevOps koncentrują się na poprawie niezawodności ich usług technicznych. Tak więc zasadniczo nie ma czegoś takiego jak DevOps kontra SRE.
Dlatego to, co robimy w tej sekcji, to ocena fundamentalnych różnic między DevOps a SRE.
Wdrażanie zmiany
Aby aktualizacje były częste, a użytkownicy mieli dostęp do nowszych i bardziej odpowiednich technologii, zarówno DevOps, jak i SRE zamierzają szybko działać. Jednak DevOps idzie do przodu stopniowo, z ostrożnością, podczas gdy SRE bierze pod uwagę koszt braku szybszego działania.
Zarówno wdrażają automatyzację, jak i wykorzystują do tego narzędzia.
Traktowanie awarii jako normalnych
DevOps jest ogromny w akceptowaniu porażek i traktowaniu ich jako uczącej się opresji. Z tego powodu zachęca do kultury bez winy, akceptując fakt, że awarie są częścią procesu i nie skupia się na tym, aby systemy były w 100% odporne na błędy. Przykładem tego jest Netflix ze swoją armią małp.
Z drugiej strony SRE popiera nienaganną sekcję zwłok. Celem tego jest zidentyfikowanie przyczyny niepowodzenia, przypisanie odpowiedzialności i praca, aby uniknąć podobnych awarii w przyszłości. Ile awarii może ulec systemowi, jest uwzględnione w budżecie błędów. Metryki SLI, SLO i SLA określają to, aby obniżyć koszty produkcji. Zasadniczo SRE stosuje proaktywne praktyki monitorowania i ostrzegania, aby zapobiec potencjalnej awarii.
Ucz się kursów rozwoju oprogramowania online z najlepszych światowych uniwersytetów. Zdobywaj programy Executive PG, Advanced Certificate Programs lub Masters Programs, aby przyspieszyć swoją karierę.
Automatyzacja kontra innowacja
DevOps przywiązuje najwyższą wagę do automatyzacji. W środowisku skoncentrowanym na DevOps przekłada się to na maksymalne zautomatyzowanie systemów, co skutkuje nudnymi wydaniami. Po zatwierdzeniu kodu przez programistę większość poniższych czynności, jeśli nie wszystkie, musi zostać zautomatyzowana.
Dlatego powodem, dla którego DevOps jest dążenie do CI/CD, jest rozwijanie wysokiej jakości systemów z większą prędkością.
Powody, dla których SRE dąży do CI/CD, są różne, mają na celu zmniejszenie kosztów awarii. Wszelkie typowe, ogólne lub powtarzające się zadania w operacjach, takie jak wdrażanie i tworzenie kopii zapasowych, są uważane za mniej warte uwagi. Dlatego SRE przeznaczają określoną ilość czasu, aby uniknąć trudu operacyjnego. Ma to na celu umożliwienie im wykonywania bardziej atrakcyjnych zadań, takich jak wdrażanie lub wprowadzanie innowacji do nowych technologii lub działań związanych z architekturą.
Zamówienie: Projekty DevOps dla początkujących
Rozbijanie silosów organizacyjnych
Deweloperzy i operatorzy wchodzą w konflikt, jeśli chodzi o proces wdrażania. Podczas gdy programiści skorzystaliby na wdrożeniu funkcji zaraz po ich zakodowaniu, ludzie zajmujący się obsługą koncentrują się na udostępnianiu systemów, co utrudnia proces wdrażania.
Zarówno DevOps, jak i SRE różnią się sposobem usuwania silosów w organizacji.
DevOps, jak wyjaśniono w Podręczniku DevOps, podchodzi do tego problemu, włączając praktyki, takie jak działanie w mniejszych partiach i lepsze zarządzanie konfiguracjami.
SRE mają na celu nie tylko optymalizację przepływu między zespołami, ale także wspomaganie systemów w produkcji. Robią to, integrując się z zespołami jako konsultanci i wspierając programistów, dzieląc się odpowiedzialnością za uruchamianie systemów. W ten sposób SRE rozbijają silosy w organizacji.
Mierzenie udanej implementacji
Metryki DevOps dotyczą szybkości operacji; obejmuje to, jak często mają miejsce wdrożenia, czas potrzebny na ich wykonanie i jak często napotykają problemy.
Zgodnie z raportem Puppet i DORA z 2017 r. pomiar udanego wdrożenia w DevOps zależy od następujących czynników:
- częstotliwość, z jaką mają miejsce wdrożenia
- czas między zatwierdzeniem kodu a jego wdrożeniem
- częstotliwość niepowodzenia wdrożeń
- czas potrzebny na odzyskanie sprawności po niepowodzeniu wdrożenia
Te pętle zwrotne są wprowadzane, aby pomóc DevOps poprawić jakość systemu, jednocześnie ułatwiając zmianę podczas eksperymentowania.
Z drugiej strony SRE pracuje nad ulepszaniem systemów, mając na uwadze ich niezawodność. Uwzględnia następujące kluczowe wskaźniki w celu określenia pomyślnej implementacji:
- cel poziomu usług (SLO)
- wskaźnik poziomu usług (SLI)
- umowa o poziomie usług (SLA)
Powyższe metryki są wskaźnikami niezawodności systemu. Te metryki określają z góry, czy wydanie zmiany trafi do produkcji.
W SRE te metryki szybkości i jakości przydają się przy tworzeniu budżetu błędów i poprawianiu niezawodności systemów, zamiast pracy nad nowymi funkcjami.
Przeczytaj: Wynagrodzenie inżyniera DevOps w Indiach
Wniosek
Google opublikował e-book o tym, jak wdrażają Site Reliability Engineering w swoich systemach produkcyjnych, w którym Treynor wyjaśnił SRE jako:
„SRE jest tym, co dzieje się, gdy poprosisz inżyniera oprogramowania o zaprojektowanie zespołu operacyjnego”.
Jeśli chodzi o różnice między DevOps i SRE, wystarczy pamiętać, że SRE jest napędzany przez programistów, a nie zespół operacyjny. Zarówno utrzymanie, jak i monitorowanie są w dużej mierze pod kontrolą programistów. To przede wszystkim wyróżnia te dwie dyscypliny.
Jeśli chcesz dowiedzieć się więcej o dużych DevOps, pełnym rozwoju stosu, sprawdź program Executive PG UpGrad i IIIT-B w tworzeniu oprogramowania - specjalizacja w rozwoju pełnego stosu , który jest przeznaczony dla pracujących profesjonalistów i oferuje ponad 500 godzin rygorystycznego szkolenia, Ponad 9 projektów i zadań, status absolwentów IIIT-B, praktyczne praktyczne projekty zwieńczenia i pomoc w pracy z najlepszymi firmami.
