Na podstawie dyskusji na czacie
Ostatnio toczą się prawdziwe bitwy na temat definicji pojęcia DevOps i SRE.
Mimo że dyskusje na ten temat już w wielu kwestiach zdążyły się znudzić, w tym także mnie, postanowiłem przedstawić społeczności Habr swoje spojrzenie na ten temat. Kto jest zainteresowany, zapraszam pod kat. I niech wszystko rozpocznie się od nowa!
Tło
Otóż, w dawnych czasach żyła osobno ekipa programistów i administratorów serwerów. Pierwsi z powodzeniem pisali kod, drudzy, używając różnych ciepłych, miłych słów w stronę pierwszych, konfigurowali serwery, czasami przychodząc do programistów i otrzymując w odpowiedzi wyczerpujące „na mojej maszynie wszystko działa”. Biznes czekał na oprogramowanie, wszystko stało w miejscu, czasami się psuło, wszyscy byli zdenerwowani. Szczególnie ten, kto za cały ten bałagan płacił. Chwała epoce lampowej. Ale pewnie wiecie, skąd biorą się korzenie DevOps.
Narodziny praktyk DevOps
Potem przyszli poważni panowie i powiedzieli — to nie przemysł, tak nie można pracować. I przyciągnęli modele cyklu życia. Oto, na przykład, model V.
Co widzimy? Biznes przychodzi z konceptem, architekci projektują rozwiązania, programiści piszą kod, dalej — klapa. Ktoś w jakiś sposób testuje produkt, ktoś w jakiś sposób dostarcza go do końcowego użytkownika, a gdzieś na końcu tego cudownego modelu siedzi samotny zamawiający z biznesu i czeka na obiecaną poprawę. Doszliśmy do wniosku, że potrzebne są metody, które pozwolą uporządkować ten proces. Postanowiono stworzyć praktyki, które by je realizowały.
Liryczne dygresje na temat tego, czym jest praktyka
Pod praktyką rozumiem połączenie technologii i dyscypliny. Przykład — praktyka opisywania infrastruktury kodem w terraformie. Dyscyplina — to, jak opisywać infrastrukturę kodem, jest w głowie programisty, a technologia — to własny terraform.
Postanowili nazwać je praktykami DevOps — myślę, że mieli na myśli przejście od rozwoju do operacji. Wymyślili różne skomplikowane rzeczy — praktyki CI/CD, praktyki oparte na zasadzie IaC, tysiące ich. I poszło, programiści piszą kod, inżynierowie DevOps przekształcają opis systemu w kod w działające systemy (tak, kod to niestety tylko opis, a nie wcielenie systemu), dostawa kręci się, no i tak dalej. Wczorajsi administratorzy, opanowując nowe praktyki, dumnie przekwalifikowali się na inżynierów DevOps, i wszystko się zaczęło. I był wieczór, i był poranek… przepraszam, nie stąd.
Znowu nic nie jest w porządku
Tylko wszystko się uspokoiło, a różni sprytni „metodycy” zaczęli pisać grube książki na temat praktyk DevOps, cicho wybuchły spory, kim w końcu jest nieszczęsny inżynier DevOps i że DevOps to kultura produkcji, znowu zaczęło narastać niezadowolenie. Nagle odkryto, że dostarczanie oprogramowania to absolutnie nietrywialne zadanie. Każda infrastruktura rozwoju ma swój stos, gdzieś trzeba zbierać, gdzie indziej wdrażać środowisko, tu potrzebny jest tomcat, tu jeszcze bardziej skomplikowany sposób uruchomienia — ogólnie głowa pęka. A jeszcze problem, jak dziwnie, okazał się przede wszystkim w organizacji procesów — ta funkcja dostarczania, jak wąskie gardło, zaczęła blokować procesy. Do tego operacja (Operations) nie została anulowana. W modelu V nie widać jej, a tam jeszcze cały cykl życia po prawej stronie. W końcu trzeba jakoś wspierać infrastrukturę, monitorować, zarządzać incydentami i jeszcze zajmować się dostawą. Tzn. trzeba siedzieć jedną nogą w rozwoju, a drugą w operacjach — i nagle wyszło z tego Development & Operations. A tu jeszcze pojawiła się ogólnokrajowa moda na mikroserwisy. A razem z nimi rozwój zaczął przechodzić z lokalnych maszyn do chmury — spróbuj coś debugować lokalnie, jeśli mikroserwisów jest dziesiątki i setki, tu ciągłe dostarczanie staje się sposobem na przetrwanie. Dla „małej, skromnej firmy” jeszcze nie jest źle, ale i tak? A Google?
SRE od Google
Przyszedł Google, zjadł największe kaktusy i postanowił — nie potrzebujemy tego, potrzebujemy niezawodności. A nad niezawodnością trzeba zarządzać. I postanowił — potrzebujemy specjalistów, którzy będą zarządzać niezawodnością. Nazwał ich inżynierami SRE i powiedział, oto wszystko, zróbcie to, jak zwykle, dobrze. Oto SLI, oto SLO, oto monitoring. I wskazał na operacje. I nazwał swój „niezawodny DevOps” SRE. Wszystko wydaje się dobrze, ale jest jeden brudny hack, na który Google mógł sobie pozwolić — w roli inżynierów SRE zatrudniał ludzi, którzy mieli kwalifikacje programistów i jeszcze trochę zajmowali się funkcjonowaniem działających systemów. A zatrudnienie takich ludzi również sprawia problem samemu Google — głównie dlatego, że tutaj sam ze sobą konkuruje — w końcu trzeba też opisać logikę biznesową. Dostawę rozdzielił na inżynierów wydania, inżynierowie SRE zarządzają niezawodnością (oczywiście nie bezpośrednio, ale wpływając na infrastrukturę, zmieniając architekturę, monitorując zmiany i wskaźniki, radząc sobie z incydentami). Pięknie, można . A co zrobić, jeśli nie jesteś Google, a niezawodność jednak jakoś niepokoi?
Rozwój idei DevOps
Właśnie tutaj pojawił się Docker, który wyrósł z lxc, a następnie różne systemy orkiestracji, takie jak Docker Swarm i Kubernetes, a inżynierowie DevOps odetchnęli — ujednolicenie praktyk uprościło dostawę. Uprościło to na tyle, że możliwe stało się oddanie dostawy programistom — co tam deployment.yaml. Konteneryzacja rozwiązuje problem. A dojrzałość systemów CI/CD już jest na poziomie — jeden plik napisałeś i wszystko się zaczęło — programiści sami sobie poradzą. I tutaj zaczynamy mówić, jak stworzyć własne SRE, z… no z kimkolwiek.
SRE nie w Google
No dobrze, dostawę mamy za sobą, wydaje się, że możemy odetchnąć, wrócić do dobrych, starych czasów, kiedy administratorzy monitorowali obciążenie procesorów, optymalizowali systemy i w ciszy i spokoju delektowali się czymś nieokreślonym z kubków... Moment. Nie dla tego wszystkiego się staraliśmy (chociaż szkoda!). Nagle okazuje się, że w podejściu Google możemy z powodzeniem przyjąć doskonałe praktyki — nie obciążenie procesorów jest ważne, ani to, jak często zmieniamy dyski, czy optymalizujemy koszty w chmurze, lecz metryki biznesowe — te same nieszczęsne SLx. I zarządzanie infrastrukturą również pozostaje w mocy, i incydenty trzeba rozwiązywać, i czasem pełnić dyżur, i w ogóle być w temacie procesów biznesowych. Chłopaki, zacznijcie już powoli programować na dobrym poziomie, Google na was czeka.
Podsumowując. Niespodziewanie, ale już się zmęczyliście czytaniem i nie możecie się doczekać, aby napisać autorowi komentarz do artykułu. DevOps jako praktyka dostaw była, jest i będzie. I nigdzie się nie wybiera. SRE jako zbiór praktyk eksploatacyjnych sprawia, że ta dostawa jest udana.
Źródło: habr.com
