Chat megbeszélés alapján
A közelmúltban igazi harcok robbantak ki a DevOps és az SRE meghatározása körül.
Annak ellenére, hogy az erről a témáról folytatott viták sok tekintetben már kiélezték a fogam, beleértve engem is, úgy döntöttem, hogy a témával kapcsolatos nézetemet a Habra közösség bírósága elé tárom. Akit érdekel, szeretettel várja a macskát. És kezdődjön minden elölről!
őstörténet
Tehát az ókorban egy csapat szoftverfejlesztő és szerveradminisztrátor külön élt. Az első sikeresen megírta a kódot, a második az elsőhöz intézett különféle meleg, szeretetteljes szavakkal beállította a szervereket, időről időre eljött a fejlesztőkhöz, és válaszul átfogó "minden működik a gépemen" üzenetet kapott. Az üzlet várt a szoftverre, minden tétlen volt, időszakonként tönkrement, mindenki ideges volt. Főleg az, aki fizetett ezért az egész rendetlenségért. Dicső lámpakorszak. Nos, már tudod, honnan származik a DevOps.
A DevOps gyakorlatok születése
Aztán komoly srácok jöttek, és azt mondták - ez nem egy iparág, nem lehet így dolgozni. És életciklus modelleket hoztak. Itt van például a V-modell.
Szóval mit látunk? Egy vállalkozáshoz jön egy koncepció, építészek terveznek megoldásokat, a fejlesztők kódot írnak, aztán megbukik. Valaki valahogy teszteli a terméket, valaki valahogy eljuttatja a végfelhasználóhoz, valahol pedig ennek a csodamodellnek a kimenetén ül egy magányos üzleti ügyfél, aki a tenger mellett várja az ígért időjárást. Arra a következtetésre jutottunk, hogy olyan módszerekre van szükségünk, amelyek lehetővé teszik ezt a folyamatot. És úgy döntöttünk, hogy olyan gyakorlatokat hozunk létre, amelyek megvalósítják ezeket.
Lírai kitérő arra a témára, hogy mi a gyakorlat
Gyakorlat alatt a technológia és a fegyelem kombinációját értem. Példa erre az infrastruktúra terraform kóddal történő leírásának gyakorlata. A fegyelem az, hogy hogyan írjuk le az infrastruktúrát kóddal, ez a fejlesztő fejében van, a technológia pedig maga a terraform.
És úgy döntöttek, hogy DevOps gyakorlatoknak hívják őket – azt hiszem, a fejlesztéstől az üzemeltetésig értettek. Különféle okos dolgokat találtunk ki - CI/CD gyakorlatokat, IaC elven működő gyakorlatokat, több ezer darabot. És indulunk is, a fejlesztők kódot írnak, a DevOps mérnökei a rendszer leírását kód formájában működő rendszerré alakítják át (igen, a kód sajnos csak leírás, de nem a rendszer megtestesítője), a szállítás folytatódik, stb. A tegnapi rendszergazdák, miután elsajátították az új gyakorlatokat, büszkén képezték át magukat DevOps mérnököknek, és innentől minden ment. És volt este, és volt reggel... bocs, nem onnan.
Megint nincs minden rendben, hála Istennek
Amint minden megnyugodott, és a különféle ravasz „metódusok” vastag könyveket kezdtek írni a DevOps gyakorlatairól, csendben fellángoltak a viták arról, hogy ki a hírhedt DevOps mérnök, és hogy a DevOps egy gyártási kultúra, ismét feltámadt az elégedetlenség. Hirtelen kiderült, hogy a szoftverszállítás abszolút nem triviális feladat. Minden fejlesztési infrastruktúrának megvan a maga verem, hol össze kell szerelni, hol a környezetet kell telepíteni, ide a Tomcat, itt egy ravasz és bonyolult út kell elindítani - úgy általánosságban üti a fejét. És a probléma furcsa módon elsősorban a folyamatok megszervezésében volt - ez a szállítási funkció, mint egy szűk keresztmetszet, blokkolni kezdte a folyamatokat. Ráadásul senki sem mondta le a műveleteket. A V-modellben nem látszik, de a jobb oldalon még mindig ott van a teljes életciklus. Ebből kifolyólag valahogyan karban kell tartani az infrastruktúrát, figyelemmel kell kísérni a monitoringot, megoldani az incidenseket, és foglalkozni kell a szállítással is. Azok. ülj fél lábbal a fejlesztésben és az üzemeltetésben is – és hirtelen kiderült, hogy ez a fejlesztés és üzemeltetés. Aztán ott volt a mikroszolgáltatások általános felhajtása. És velük együtt a helyi gépekről történő fejlesztés kezdett a felhőbe költözni - próbálj meg valamit helyben hibakeresni, ha több tucat és száz mikroszolgáltatás van, akkor az állandó szállítás a túlélés eszközévé válik. Egy „kis szerény társaságnak” minden rendben volt, de mégis? Mi a helyzet a Google-lel?
SRE a Google-tól
Jött a Google, megette a legnagyobb kaktuszt, és úgy döntött – nem erre van szükségünk, hanem megbízhatóságra. A megbízhatóságot pedig kezelni kell. És úgy döntöttem, hogy olyan szakemberekre van szükségünk, akik a megbízhatóságot irányítják. Felhívtam őket SR mérnököknek, és azt mondtam, neked ez az, csináld jól a szokásos módon. Itt az SLI, itt az SLO, itt a monitorozás. És beledugta az orrát a műtétekbe. És elhívta a „megbízható DevOps” SRE-t. Úgy tűnik, minden rendben van, de van egy piszkos hack, amit a Google megengedhet magának – az SR-mérnökök pozíciójára olyan embereket alkalmazzon, akik képzett fejlesztők voltak, és egy kis házi feladatot is végeztek, és megértették a működő rendszerek működését. Ráadásul a Google-nak magának is gondja van az ilyen emberek felvételével - főleg azért, mert itt önmagával versenyez -, le kell írni valakinek az üzleti logikát. A szállítás a kiadási mérnökökhöz volt rendelve, az SR - a mérnökök kezelik a megbízhatóságot (természetesen nem közvetlenül, hanem az infrastruktúra befolyásolásával, az architektúra megváltoztatásával, a változások és indikátorok követésével, az incidensek kezelésével). Szép, lehet . De mi van akkor, ha Ön nem a Google, de a megbízhatóság valahogy mégis aggodalomra ad okot?
DevOps ötletek fejlesztése
Éppen ekkor érkezett meg a Docker, ami az lxc-ből nőtt ki, majd különféle hangszerelési rendszerek, mint például a Docker Swarm és a Kubernetes, valamint a DevOps mérnökei kilélegeztek – a gyakorlatok egyesítése leegyszerűsítette a szállítást. Annyira leegyszerűsítette, hogy még a fejlesztőknek is kiszervezhetővé vált a kézbesítés – mi az a deployment.yaml. A konténerezés megoldja a problémát. A CI/CD rendszerek érettsége pedig már azon a szinten van, hogy írjunk egy fájlt, és már megy is – a fejlesztők maguk is kezelhetik. És akkor elkezdünk beszélni arról, hogyan készíthetjük el saját SRE-nket... vagy legalább valakivel.
Az SRE nem szerepel a Google-on
Nos, rendben, kézbesítettük a szállítást, úgy tűnik, kilélegezhetünk, visszatérhetünk a régi szép időkbe, amikor az adminok figyelték a processzorterhelést, tuningolták a rendszereket és csendben csendben valami érthetetlent kortyolgattak a bögrékből... Állj. Nem ezért kezdtünk el mindent (kár!). Hirtelen kiderül, hogy a Google megközelítésében könnyen átvehetünk kiváló gyakorlatokat – nem a processzorterhelés a fontos, és nem az, hogy milyen gyakran cseréljük ott a lemezeket, vagy optimalizáljuk a költségeket a felhőben, hanem az üzleti mutatók ugyanazok a hírhedt. SLx. És senki sem távolította el tőlük az infrastruktúra-kezelést, és meg kell oldaniuk az incidenseket, rendszeresen szolgálatot kell teljesíteniük, és általában az üzleti folyamatokkal kapcsolatban kell maradniuk. És srácok, kezdjetek el apránként jó szinten programozni, a Google már vár rátok.
Összefoglalni. Hirtelen, de már belefáradtál az olvasásba, és alig várod, hogy kiköpd és írj a cikkhez kommentben a szerzőnek. A DevOps mint kézbesítési gyakorlat mindig is volt és lesz. És nem megy sehova. Az SRE, mint működési gyakorlatok összessége teszi ezt a megvalósítást nagyon sikeressé.
Forrás: will.com