A csevegés alapján
Az utóbbi időben valódi harcok robbannak ki a DevOps és SRE fogalmának meghatározásáról.
Bár ennek a témának a vitái már részben meguntak, úgy döntöttem, hogy a Habr közösség elé terjesztem a nézőpontomat. Aki kíváncsi, az jöjjön alá. És kezdődjön minden elölről!
Háttér
Réges-régen a szoftverfejlesztők és a szerveradminisztrátorok külön csapatokban éltek. Az első csoport sikeresen írta a kódot, míg a második különböző kedves szavakkal körbeölelték a fejlesztőket, és beállították a szervereket, időnként benéztek a fejlesztőkhöz, akik kimerítő választ adtak: "az én gépemen minden működik". A vállalkozás szoftvert várt, minden leállt, időnként elromlott, mindenki ideges volt. Különösen az, aki az egész káoszért fizetett. Szép, nosztalgikus időszak. De ti ezt már tudjátok, honnan ered a DevOps.
A DevOps gyakorlatok születése
Aztán megjelentek a komoly urak, és azt mondták — ez nem ipar, így nem lehet dolgozni. És behozták az életciklus modelleket. Például itt van a V-modell.
Szóval, mit is látunk? A vállalkozás jön egy koncepcióval, az építészek megtervezik a megoldásokat, a fejlesztők írják a kódot, aztán — kudarc. Valaki valahogyan teszteli a terméket, valaki valahogyan eljuttatja a végfelhasználóhoz, és valahol ennek a csodás modellnek a végén ül egy magányos üzleti megrendelő, várva a megígért jó időre. Arra jutottunk, hogy szükség van olyan módszerekre, amelyek lehetővé teszik a folyamat zavartalan működését. Ezért döntöttek a gyakorlatok létrehozásáról, amelyek ezt megvalósítják.
Lírai kitérő arról, hogy mi is az a gyakorlat
Gyakorlat alatt a technológia és a diszciplína összekapcsolódását értem. Példa — az infrastruktúra kód általi leírásának gyakorlata Terraformon. A diszciplína az, ahogyan a fejlesztő a kódot írja le az infrastruktúrához, ez a fejlesztő fejében van, míg a technológia maga a Terraform.
És úgy döntöttek, hogy DevOps gyakorlatoknak nevezik őket – úgy gondolom, a Fejlesztéstől a Műveletekig terjedő folyamatra utaltak. Különféle bonyolult dolgokat találtak ki – CI/CD gyakorlatok, az IaC elven alapuló gyakorlatok, és még ezer más. És itt kezdődött, a fejlesztők kódot írnak, a DevOps mérnökök a rendszer leírását kódként működő rendszerekké alakítják (igen, a kód sajnos csupán a leírás, nem pedig a rendszer megvalósítása), a szállítás pörög, és így tovább. A tegnapi rendszergazdák, akik elsajátították az új gyakorlatokat, büszkén átminősültek DevOps mérnökökké, és elindult a folyamat. És este lett, és reggel lett... elnézést, nem onnan.
Minden ismét nem a legjobban alakult.
Csak minden kezdeti zűrzavar után különféle ügyes „módszertanok” elkezdtek vastag könyveket írni a DevOps gyakorlatokról, csendesen lángra kaptak a viták, hogy ki is valójában az a hírhedt DevOps mérnök, és hogy a DevOps – a gyártás kultúrája, ismét elégedetlenség merült fel. Hirtelen kiderült, hogy a szoftver szállítása – egyáltalán nem triviális feladat. Minden fejlesztési infrastruktúrának megvan a saját stackje, valahol építeni kell, máshol környezetet kell telepíteni, itt tomcat szükséges, ott pedig egy bonyolultabb indítási módszer – összességében a fejünk hasogat. Ráadásul a probléma, meglepő módon, elsősorban a folyamatok megszervezésében merült fel – ez a szállítási funkció, mint egy palacknyak, megakadályozza a folyamatokat. Ráadásul a működés (Operations) senki előtt nem tűnt el. Az V-modellben nem látszik, de ott van még a teljes életciklus jobbra. Végeredményben valahogy támogatni kell az infrastruktúrát, figyelni a monitorozásra, kezelni az incidenseket, és még a szállítással is foglalkozni. Vagyis egy lábbal a fejlesztésben, és egy lábbal a működésben ülni – és hirtelen ilyen Development & Operations keletkezett. Ehhez még egy nagy hype is jött a mikroszolgáltatásokra. A mikroszolgáltatásokkal pedig a fejlesztés a helyi gépekről a felhőbe költözött – próbálj meg valamit helyben hibakeresni, amikor mikroszolgáltatások tucatjai és százai vannak, itt a folyamatos szállítás már a túlélés eszközévé válik. Egy „kicsi szerény cégnél” még elmegy, de mégis? És a Google?
SRE a Google-tól
A Google megérkezett, megevett néhány nagy kaktuszt, és úgy döntött, hogy erre nincs szükségünk, nekünk megbízhatóságra van szükségünk. De a megbízhatóságot kezelni kell. És úgy döntött, hogy szükségük van szakemberekre, akik a megbízhatóságot menedzselik. SR mérnököknek nevezte őket, és azt mondta nekik, itt van minden, csináljátok, ahogy szokásos, jól. Itt van az SLI, itt van az SLO, itt van a monitorozás. És megmutatta nekik az üzemeltetést. És a „megbízható DevOps” néven nevezte el az SRE-t. Úgy tűnik, minden rendben, de van egy piszkos trükk, amit a Google megengedhetett magának — az SR mérnöki pozíciókra olyan embereket alkalmazni, akik fejlesztői képesítéssel rendelkeztek, és egy kicsit még otthon is konyítottak a működő rendszerek működéséhez. Ráadásul a Google-nek is problémái vannak az ilyen emberek felvételével — főként azért, mert itt saját magával versenyez — végül is valakinek le kell írnia az üzleti logikát. A szállítást a kiadómérnökökre bízta, az SR mérnökök a megbízhatóságot irányítják (értelemszerűen nem közvetlenül, hanem az infrastruktúrára gyakorolt hatásuk révén, az architektúra megváltoztatásával, a változások és mutatók nyomon követésével, valamint incidensek kezelésével). Szép, lehet. . De mi a teendő, ha nem a Google vagy, de azért a megbízhatóság mégis aggaszt?
A DevOps ötleteinek fejlődése
Ide épp megérkezett a Docker, amely az lxc-ből fejlődött ki, majd különböző orchestration rendszerek, mint a Docker Swarm és a Kubernetes, és a DevOps mérnökök felsóhajtottak — a gyakorlatok egységesítése megkönnyítette a szállítást. Annyira megkönnyítette, hogy most már akár a fejlesztőknek is átadható a szállítás — mi van ott a deployment.yaml-mal. A konténerizáció megoldja a problémát. És a CI/CD rendszerek érettsége már azon a szinten van, hogy egy fájlt írtam, és máris minden elindult — a fejlesztők maguk is boldogulnak. És itt kezdjük el beszélni, hogyan készítsük el a saját SRE-nket, akár kikkel is.
SRE nem a Google-nél
Nos, akkor rendben van, a szállítást elintéztük, úgy tűnik, fellélegezhetünk, visszatérhetünk a régi, jó időkhöz, amikor az adminisztrátorok figyelték a processzorok terheltségét, optimalizálták a rendszereket és csendben kortyolgattak valami érthetetlent a nyugalomban... Állj. Nem ezért kezdtük el az egészet (bár kár!). Hirtelen kiderül, hogy a Google megközelítésével kiváló gyakorlati tapasztalatokat szerezhetünk – nem a processzorok terheltsége a fontos, és nem az, hogy milyen gyakran cseréljük a lemezeket, vagy hogy az felhőben az árakat optimalizáljuk, hanem az üzleti metrikák – ugyanazok a hírhedt SLx. És az infrastruktúra irányítása senkit sem mentesít ettől, és az incidenseket meg kell oldani, és időnként posztot kell őrizni, és egyáltalán, benne kell lenni az üzleti folyamatokban. Fiúk, kezdjetek el már egy kicsit jól programozni, a Google már türelmetlenül vár rátok.
Összefoglalva. Hirtelen, de már fáradtak vagytok az olvasástól, és alig várjátok, hogy a cikk szerzőjének kommentben elmondjátok a véleményetek. A DevOps mint szállítási gyakorlat megvolt, van és lesz. És sehová sem tűnik el. Az SRE mint működtetési gyakorlatok készlete ezeket a szállításokat sikeressé teszi.
Forrás: habr.com
