A webinárium hangja gyenge, ezért átírtuk.
A nevem Medvegyev Eduard. Ma arról fogok beszélni, hogy mi az SRE, hogyan jelent meg az SRE, mik a munkafeltételei az SRE mérnökeinek, egy kicsit a megbízhatósági kritériumokról, egy kicsit a monitorozásáról. Sétálunk majd a csúcsokon, mert egy óra alatt nem lehet sokat mondani, de adok anyagokat további áttekintéshez, és várunk mindenkit . január végén Moszkvában.
Először is beszéljünk arról, hogy mi az SRE – Site Reliability Engineering. És hogyan jelent meg külön pozícióként, külön irányként. Az egész azzal kezdődött, hogy a hagyományos fejlesztői körökben a Dev és az Ops két teljesen különböző csapat, általában két teljesen különböző céllal. A fejlesztőcsapat célja új funkciók bevezetése és a vállalkozás igényeinek kielégítése. Az Ops csapatának az a célja, hogy minden működjön, és semmi se törjön el. Nyilvánvaló, hogy ezek a célok egyenesen ellentmondanak egymásnak: hogy minden működjön, és semmi ne törjön meg, a lehető legkevesebbet terjesszen ki új funkciókat. Emiatt számos belső konfliktus van, amelyeket a mostani DevOps-nak nevezett módszertan próbál megoldani.
A probléma az, hogy nincs világos DevOps definíciónk és a DevOps egyértelmű megvalósítása. 2 évvel ezelőtt beszéltem egy konferencián Jekatyerinburgban, és mostanáig a DevOps szekció a „Mi a DevOps” jelentéssel kezdődött. 2017-ben a Devops majdnem 10 éves, de még mindig vitatkozunk, hogy mi az. És ez egy nagyon furcsa helyzet, amelyet a Google próbált megoldani néhány éve.
2016-ban a Google kiadott egy könyvet Site Reliability Engineering címmel. És valójában ezzel a könyvvel kezdődött az SRE mozgalom. Az SRE a DevOps paradigma konkrét megvalósítása egy adott vállalatnál. Az SRE mérnökei elkötelezettek a rendszerek megbízható működése mellett. Leginkább fejlesztőktől érkeznek, néha erős fejlesztői háttérrel rendelkező rendszergazdáktól. És azt csinálják, amit korábban a rendszergazdák, de az erős fejlesztési háttér és a rendszer kódbeli ismerete oda vezet, hogy ezek az emberek nem a rutin adminisztrációs munkára, hanem az automatizálásra hajlanak.
Kiderült, hogy a DevOps paradigmát az SRE csapatokban az a tény valósítja meg, hogy vannak SRE mérnökök, akik strukturális problémákat oldanak meg. Itt van, ugyanaz a kapcsolat a Dev és az Ops között, amiről az emberek 8 éve beszélnek. Az SRE szerepe hasonló az építészéhez abban, hogy az újoncok nem válnak SRE-vé. A pályakezdő embereknek még nincs tapasztalatuk, nem rendelkeznek a kellő szélességű tudással. Mert az SRE nagyon finom tudást igényel arról, hogy pontosan mi és mikor tud rosszul lenni. Ezért itt általában szükség van némi tapasztalatra, mind a vállalaton belül, mind azon kívül.
Megkérdezik, hogy leírják-e az SRE és a devops közötti különbséget. Most írták le. Beszélhetünk az SRE helyéről a szervezetben. Ezzel a klasszikus DevOps-megközelítéssel ellentétben, ahol az Ops még mindig külön részleg, az SRE a fejlesztőcsapat része. Részt vesznek a termékfejlesztésben. Létezik olyan megközelítés is, ahol az SRE egy olyan szerep, amely egyik fejlesztőről a másikra száll át. Ugyanúgy részt vesznek a kódellenőrzésekben, mint például az UX tervezők, maguk a fejlesztők, esetenként termékmenedzserek. Az SRE-k ugyanazon a szinten működnek. Jóvá kell hagynunk, felül kell vizsgálnunk őket, hogy az SRE minden egyes telepítésnél azt mondja: „Rendben, ez a telepítés, ez a termék nem befolyásolja negatívan a megbízhatóságot. És ha igen, akkor bizonyos elfogadható határokon belül. Erről is fogunk beszélni.
Ennek megfelelően az SRE-nek vétójoga van a kód megváltoztatására. És általában ez is vezet valamilyen kis konfliktushoz, ha az SRE-t nem megfelelően hajtják végre. Ugyanabban a könyvben, amely a Site Reliability Engineeringről szól, sok rész, még csak nem is egy, elmondja, hogyan lehet elkerülni ezeket az ütközéseket.
Azt kérdezik, hogyan kapcsolódik az SRE az információbiztonsághoz. Az SRE közvetlenül nem vesz részt az információbiztonságban. Alapvetően a nagy cégeknél ezt magánszemélyek, tesztelők, elemzők végzik. De az SRE abban az értelemben is kölcsönhatásba lép velük, hogy bizonyos műveletek, bizonyos véglegesítések, egyes, a biztonságot befolyásoló telepítések a termék elérhetőségét is befolyásolhatják. Ezért az SRE egésze kapcsolatban áll bármely csapattal, beleértve a biztonsági csapatokat, beleértve az elemzőket is. Ezért az SRE-kre főleg akkor van szükség, amikor a DevOps-t próbálják megvalósítani, ugyanakkor a fejlesztők terhei túlságosan nagyokká válnak. Vagyis maga a fejlesztőcsapat már nem tud megbirkózni azzal, hogy most az Ops-ért is nekik kell felelniük. És van egy külön szerep. Ezt a szerepet a költségvetésben tervezik. Néha ez a szerep a csapat méretében van lefektetve, megjelenik egy külön ember, néha az egyik fejlesztő válik azzá. Így jelenik meg a csapatban az első SRE.
Az SRE által érintett rendszer összetettsége, a működés megbízhatóságát befolyásoló komplexitás szükséges és véletlen. Szükséges komplexitásról akkor beszélünk, ha egy termék összetettsége olyan mértékben növekszik, amelyet az új termékjellemzők megkívánnak. Véletlenszerű bonyolultságról beszélünk, amikor a rendszer összetettsége növekszik, de a termék jellemzői és az üzleti követelmények ezt közvetlenül nem befolyásolják. Kiderül, hogy vagy a fejlesztő hibázott valahol, vagy az algoritmus nem optimális, vagy olyan további érdekeket vezetnek be, amelyek különösebb igény nélkül növelik a termék összetettségét. Egy jó SRE-nek mindig meg kell szüntetnie ezt a helyzetet. Vagyis minden véglegesítést, telepítést, lehívási kérelmet, ahol a véletlenszerű hozzáadás miatt nő a nehézség, le kell tiltani.
A kérdés az, hogy miért nem csak egy mérnököt, egy nagy tudású rendszergazdát veszünk fel a csapatba. A mérnöki szerepkörben fejlesztő fejlesztő, azt mondják, nem a legjobb személyzeti megoldás. A mérnök szerepében fejlesztő fejlesztő nem mindig a legjobb személyzeti megoldás, de itt az a lényeg, hogy az Ops-szal foglalkozó fejlesztőnek kicsit nagyobb a vágya az automatizálásra, kicsit több tudása és készségkészlete van a megvalósításhoz. ezt az automatizálást. És ennek megfelelően nem csak bizonyos műveletek idejét csökkentjük, nem csak a rutint, hanem olyan fontos üzleti paramétereket is, mint az MTTR (Mean Time To Recovery, recovery time). Így, és erről is lesz szó egy kicsit később, pénzt takarítunk meg a szervezetnek.
Most beszéljünk az SRE működésének kritériumairól. És mindenekelőtt a megbízhatóságról. Kis cégeknél, startupoknál gyakran előfordul, hogy az emberek azt feltételezik, hogy ha jól van megírva a szolgáltatás, ha jól és helyesen van megírva a termék, akkor működni fog, nem fog tönkremenni. Ennyi, jó kódot írunk, szóval nincs mit feltörni. A kód nagyon egyszerű, nincs mit feltörni. Körülbelül ugyanazokról az emberekről van szó, akik azt mondják, hogy nincs szükségünk tesztekre, mert nézd, ez a három VPI-módszer, minek itt törni.
Mindez persze helytelen. És ezeket az embereket nagyon gyakran megharapja az ilyen kód a gyakorlatban, mert eltörnek a dolgok. A dolgok néha a legkiszámíthatatlanabb módon törnek meg. Néha az emberek azt mondják, hogy nem, ez soha nem fog megtörténni. És ez mindig megtörténik. Elég gyakran előfordul. És ezért soha senki nem törekszik a 100%-os rendelkezésre állásra, mert a 100%-os rendelkezésre állás sosem történik meg. Ez a norma. Ezért amikor egy szolgáltatás elérhetőségéről beszélünk, mindig kilencről beszélünk. 2 kilences, 3 kilences, 4 kilences, 5 kilences. Ha ezt lefordítjuk leállásra, akkor például 5 kilenc, akkor ez valamivel több, mint 5 perc leállás évente, 2 kilenc az 3,5 nap leállás.
De nyilvánvaló, hogy egy ponton csökken a POI, a befektetés megtérülése. A kettő kilencről három kilencre való váltás több mint 3 nappal kevesebb leállást jelent. A négy kilencről ötre való átállás évi 47 perccel csökkenti az állásidőt. És kiderül, hogy az üzleti életben ez nem feltétlenül kritikus. Általánosságban elmondható, hogy a megkívánt megbízhatóság nem technikai kérdés, először is üzleti, hanem termékkérdés. Milyen szintű leállás elfogadható a termék felhasználóinak, mire számítanak, mennyit fizetnek, például mennyi pénzt veszítenek, mennyi pénzt veszít a rendszer.
Itt fontos kérdés, hogy a megmaradt alkatrészek milyen megbízhatóak. Mert a 4 és 5 kilences közötti különbség nem lesz látható egy 2 kilences megbízhatóságú okostelefonon. Nagyjából elmondható, hogy ha évente 10-szer elromlik valami az Ön szolgáltatásában lévő okostelefonon, akkor valószínűleg 8-szor az operációs rendszer oldalán történt a hiba. A felhasználó megszokta ezt, és nem fog odafigyelni évente egyszer. Össze kell hangolni a megbízhatóság növelésének és a profit növekedésének árát.
Éppen az SRE-ről szóló könyvben van egy jó példa arra, hogy 4 kilencről 3-re kell növelni. Kiderült, hogy a rendelkezésre állás növekedése valamivel kevesebb, mint 0,1%. Ha pedig a szolgáltatás bevétele évi 1 millió dollár, akkor a bevétel növekedése 900 dollár. Ha évi 900 dollárnál kevesebbbe kerül, hogy a megfizethetőséget kilencszeresre növeljük, az emelésnek van pénzügyi értelme. Ha évi 900 dollárnál többe kerül, annak már nincs értelme, mert a bevételnövekedés egyszerűen nem kompenzálja a munkaerő-, erőforrás-költségeket. És nekünk 3 kilenc is elég lesz.
Ez természetesen egy leegyszerűsített példa, ahol minden kérés egyenlő. És 3 kilencről 4 kilencre menni elég egyszerű, ugyanakkor például 2 kilencről 3-ra ez már 9 ezer dollár megtakarítás, anyagilag lehet értelme. Természetesen a valóságban a regisztrációs kérelem sikertelensége rosszabb, mint az oldal megjelenítésének elmulasztása, a kérések eltérő súlyúak. Lehet, hogy üzleti szempontból teljesen más kritériummal rendelkeznek, de általában, ha nem bizonyos szolgáltatásokról beszélünk, ez egy meglehetősen megbízható közelítés.
Kaptunk egy kérdést, hogy az SRE az egyik koordinátor a szolgáltatás építészeti megoldásának kiválasztásakor. Mondjuk a meglévő infrastruktúrába való beépülés szempontjából, hogy ne legyen veszteség a stabilitásában. Igen, az SRE-k, ugyanúgy, ahogy a pull kérések, commitok, kiadások hatnak az architektúrára, új szolgáltatások bevezetésére, mikroszolgáltatásokra, új megoldások megvalósítására. Miért mondtam korábban, hogy tapasztalat kell, képesítés kell. Valójában az SRE az egyik blokkoló hang minden építészeti és szoftveres megoldásban. Ennek megfelelően egy SRE-nek, mint mérnöknek mindenekelőtt nem csak meg kell értenie, hanem meg kell értenie azt is, hogy egyes konkrét döntések hogyan befolyásolják a megbízhatóságot, a stabilitást, és meg kell értenie, hogy ez hogyan kapcsolódik az üzleti igényekhez, és milyen szempontból lehet elfogadható és ami nem.
Ezért most már csak a megbízhatósági kritériumokról beszélhetünk, amelyeket az SRE hagyományosan SLA-ként (Service Level Agreement) definiál. Valószínűleg ismerős kifejezés. SLI (Service Level Indicator). SLO (Service Level Objective). A szolgáltatási szint megállapodás talán szimbolikus kifejezés, különösen, ha hálózatokkal, szolgáltatókkal, tárhelyszolgáltatással dolgozott. Ez egy általános megállapodás, amely leírja a teljes szolgáltatás teljesítményét, a büntetéseket, néhány hibabüntetést, mérőszámokat, kritériumokat. Az SLI pedig maga a rendelkezésre állási mérőszám. Vagyis mi lehet az SLI: válaszidő a szolgáltatástól, a hibák száma százalékban. Sávszélesség is lehet, ha valamilyen fájltárhelyről van szó. Ha a felismerési algoritmusokról van szó, mutató lehet például akár a válasz helyessége is. Az SLO (Service Level Objective) az SLI mutató, értékének és periódusának kombinációja.
Tegyük fel, hogy az SLA lehet ilyen. A szolgáltatás az idő 99,95%-ában egész évben elérhető. Vagy 99 kritikus támogatási jegyet negyedévente 3 órán belül lezárják. Vagy a kérések 85%-ára minden hónapban 1,5 másodpercen belül válaszolnak. Vagyis fokozatosan megértjük, hogy a hibák és kudarcok teljesen normálisak. Ez egy elfogadható helyzet, tervezzük, sőt bizonyos mértékig számolunk is vele. Vagyis az SRE olyan rendszereket épít, amelyek hibázhatnak, amelyeknek normálisan kell reagálniuk a hibákra, és figyelembe kell venniük azokat. A hibákat pedig lehetőség szerint úgy kell kezelni, hogy a felhasználó vagy észre se vegye, vagy észrevegye, de van valami megoldás, aminek köszönhetően nem esik le teljesen minden.
Például, ha feltölt egy videót a YouTube-ra, és a YouTube nem tudja azonnal konvertálni, ha a videó túl nagy, ha a formátum nem optimális, akkor a kérés természetesen nem fog sikertelenül időtúllépéssel, a YouTube nem ad 502-es hibát , a YouTube ezt fogja mondani: „Mindent létrehoztunk, a videód feldolgozás alatt áll. Körülbelül 10 percen belül kész lesz." Ez a kecses degradáció elve, ami ismerős például a front-end fejlesztésből, ha már csinált ilyet.
A következő kifejezések, amelyekről beszélni fogunk, amelyek nagyon fontosak a megbízhatósággal, a hibákkal, az elvárásokkal való munkához, az MTBF és az MTTR. Az MTBF a hibák közötti átlagos idő. MTTR Átlagos helyreállítási idő, átlagos helyreállítási idő. Azaz mennyi idő telt el a hiba felfedezésétől, a hiba megjelenésétől a szolgáltatás teljes normál működésének visszaállításáig. Az MTBF-et főleg a kódminőséggel kapcsolatos munka javítja. Vagyis az a tény, hogy az SRE-k "nem"-et tudnak mondani. És meg kell értenie az egész csapattal, hogy amikor SRE nemet mond, akkor nem azért mondja, mert káros, nem azért, mert rossz, hanem mert különben mindenki szenved.
Ismét sok cikk, sok módszer, nagyon sok mód van még abban a könyvben is, amelyre oly gyakran hivatkozom, hogyan lehet megbizonyosodni arról, hogy más fejlesztők ne kezdjék el utálni az SRE-t. Az MTTR ezzel szemben az SLO-kon (Service Level Objective) való munka. És ez többnyire automatizálás. Mert például az SLO-nk negyedévente 4 kilences üzemidő. Ez azt jelenti, hogy 3 hónap alatt 13 perc állásidőt engedhetünk meg. És kiderül, hogy az MTTR nem lehet több 13 percnél. Ha 13 percen belül legalább 1 állásidőre reagálunk, az azt jelenti, hogy már kimerítettük a negyedév teljes költségvetését. Megtörjük az SLO-t. 13 perc reagálni és kijavítani egy balesetet sok egy gépnek, de nagyon rövid egy embernek. Mert amíg az ember nem kap riasztást, amíg nem reagál, amíg meg nem érti a hibát, az már több perc. Amíg az ember nem érti, hogyan kell megjavítani, mit kell pontosan megjavítani, mit kell tennie, addig ez még néhány perc. És valójában még akkor is, ha csak újra kell indítania a szervert, mint kiderült, vagy új csomópontot kell emelnie, akkor manuálisan az MTTR már körülbelül 7-8 perc. A folyamat automatizálása során az MTTR gyakran eléri a másodpercet, néha ezredmásodpercet. A Google általában ezredmásodpercekről beszél, de a valóságban persze nem minden olyan jó.
Ideális esetben az SRE szinte teljesen automatizálja a munkáját, mert ez közvetlenül befolyásolja az MTTR-t, annak mérőszámait, a teljes szolgáltatás SLO-ját, és ennek megfelelően az üzleti profitot. Ha túllépi az időt, a rendszer megkérdezi, hogy az SRE a hibás-e. Szerencsére senki nem hibás. Ez pedig egy külön kultúra, az úgynevezett balmeless postmortem, amiről ma nem beszélünk, de a Slurm-on elemezzük. Ez egy nagyon érdekes téma, amiről sokat lehet beszélni. Durván fogalmazva, ha a negyedévenkénti időt túllépjük, akkor egy kicsit mindenki hibás, ami azt jelenti, hogy mindenkit hibáztatni nem produktív, inkább, talán ne hibáztassunk senkit, hanem korrigáljuk a helyzetet, és dolgozzunk azzal, amink van. Tapasztalataim szerint ez a megközelítés kissé idegen a legtöbb csapattól, különösen Oroszországban, de logikus és nagyon jól működik. Ezért a cikk és a szakirodalom végén ajánlom, hogy olvassa el a témát. Vagy gyere a Slurm SRE-hez.
Hadd magyarázzam. Ha a negyedévenkénti SLO időt túllépik, ha az állásidő nem 13 perc volt, hanem 15, akkor ki lehet ezért a hibás? Persze lehet, hogy SRE a hibás, mert nyilvánvalóan valami rossz kötelezettséget vagy bevetést hajtott végre. Ebben az adatközpont adminisztrátora lehet a hibás, mert esetleg valamiféle nem tervezett karbantartást hajtott végre. Ha ebben az adatközpont adminisztrátora a hibás, akkor az Ops-os ember a hibás, aki az SLO koordinálásakor nem számolta a karbantartást. Ebben a vezető, a műszaki igazgató, vagy valaki, aki aláírta az adatközponti szerződést, és nem figyelt arra, hogy az adatközpont SLA-ja nem az előírt leállásra készült. Ennek megfelelően ebben a helyzetben apránként mindenki a hibás. És ez azt jelenti, hogy ebben a helyzetben nincs értelme bárkit is hibáztatni. De persze korrigálni kell. Ezért vannak postmortemek. És ha elolvassa például a GitHub postmortemeket, és ez mindig egy nagyon érdekes, kicsi és váratlan történet minden konkrét esetben, akkor helyettesítheti azt, hogy soha senki nem mondja, hogy ez a személy volt a hibás. Mindig bizonyos tökéletlen folyamatokat kell hibáztatni.
Térjünk át a következő kérdésre. Automatizálás. Amikor az automatizálásról beszélek más összefüggésekben, gyakran hivatkozom egy táblázatra, amely megmutatja, mennyi ideig dolgozhat egy feladat automatizálásán anélkül, hogy több időt vesz igénybe az automatizálás, mint amennyit ténylegesen megtakarít. Van egy gubanc. A bökkenő az, hogy amikor az SRE-k automatizálnak egy feladatot, nem csak időt takarítanak meg, hanem pénzt takarítanak meg, mivel az automatizálás közvetlenül befolyásolja az MTTR-t. Úgymond megspórolják az alkalmazottak és a fejlesztők morálját, ami szintén kimerülő erőforrás. Csökkentik a rutint. Mindez pedig pozitív hatással van a munkára, és ennek következtében az üzletre, még akkor is, ha úgy tűnik, hogy az automatizálásnak nincs értelme az időköltség szempontjából.
Valójában szinte mindig megvan, és nagyon kevés olyan eset van, amikor valamit nem kellene automatizálni az SRE szerepében. A következőkben az úgynevezett hibaköltségvetésről, a hibák költségvetéséről lesz szó. Valójában kiderül, hogy ha minden sokkal jobb az Ön számára, mint a saját maga által beállított SLO, akkor ez sem túl jó. Ez elég rossz, mert az SLO nem csak alsó, hanem hozzávetőleges felső korlátként is működik. Ha beállítod magadnak egy 99%-os rendelkezésre állású SLO-t, és valójában 99,99%-kal rendelkezel, akkor kiderül, hogy van némi tere olyan kísérletekre, amelyek egyáltalán nem ártanak az üzletnek, mert ezt te magad határoztad meg együtt, és ezt a helyet ne használja. Van egy költségvetése a hibákra, ami az Ön esetében nincs felhasználva.
Mit csináljunk vele. Szó szerint mindenre használjuk. Gyártási körülmények között végzett teszteléshez, teljesítményt befolyásoló új funkciók bevezetéséhez, kiadásokhoz, karbantartáshoz, tervezett leállásokhoz. A fordított szabály is érvényes: ha kimerült a költségvetés, nem tudunk újat kiadni, mert különben túllépjük az SLO-t. A költségvetés már kimerült, kiadtunk valamit, ha az negatívan befolyásolja a teljesítményt, vagyis ha ez nem valamiféle javítás, ami önmagában közvetlenül növeli az SLO-t, akkor túllépünk a költségvetésen, és ez egy rossz helyzet , elemezni kell , postmortem, és esetleg néhány folyamatjavításra van szükség.
Vagyis kiderül, hogy ha maga a szolgáltatás nem működik jól, és az SLO-t elköltik, és a költségvetést nem kísérletekre, nem egyes kiadásokra, hanem önmagára költik, akkor néhány érdekes javítás helyett érdekes funkciók helyett érdekes kiadások helyett. Bármilyen kreatív munka helyett hülye javításokkal kell megküzdenie, hogy helyreállítsa a költségvetést, vagy szerkesztenie kell az SLO-t, és ez is egy olyan folyamat, aminek nem szabad túl gyakran megtörténnie.
Ezért kiderül, hogy egy olyan helyzetben, amikor több költségvetésünk van a hibákra, mindenkit érdekel: mind az SRE-t, mind a fejlesztőket. A fejlesztők számára a hibákra szánt nagy költségvetés azt jelenti, hogy foglalkozhat kiadásokkal, tesztekkel és kísérletekkel. Az SRE-k esetében a hibákra vonatkozó költségvetés és annak megadása azt jelenti, hogy közvetlenül jól végzik a munkájukat. Ez pedig kihat valamilyen közös munka motivációjára. Ha fejlesztőként hallgatja az SRE-ket, több helye lesz a jó munkának, és sokkal kevesebb rutinja lesz.
Kiderült, hogy a termelési kísérletek nagyon fontos és szinte szerves részét képezik az SRE-nek nagy csapatokban. És általában káoszmérnökinek hívják, ami a Netflix csapatától származik, amely kiadta a Chaos Monkey nevű segédprogramot.
A Chaos Monkey csatlakozik a CI/CD-folyamathoz, és véletlenszerűen összeomlik az éles kiszolgáló. Az SRE struktúrában megint arról beszélünk, hogy a levert szerver önmagában nem rossz, az elvárható. És ha a költségvetésen belül van, akkor az elfogadható, és nem károsítja a vállalkozást. A Netflixnek persze van elég redundáns szervere, elegendő replikációja ahhoz, hogy mindez javítható legyen, és a felhasználó összességében észre se vegye, és még inkább senki se hagyjon el egy szervert semmilyen költségvetésért.
A Netflixnek egy ideig egész sora volt ilyen segédprogramokból, amelyek közül az egyik, a Chaos Gorilla, teljesen leállítja az Amazon egyik elérhetőségi zónáját. És az ilyen dolgok segítenek felfedni először is a rejtett függőségeket, amikor nem teljesen világos, hogy mi mit érint, mi mitől függ. És ez, ha mikroszolgáltatással dolgozik, és a dokumentáció nem teljesen tökéletes, ez ismerős lehet Önnek. És ez megint nagyon sokat segít abban, hogy a kódban olyan hibákat kapjanak el, amelyeket nem lehet elkapni a stagingnél, mert minden szakaszolás nem éppen egzakt szimuláció, mivel más a terhelési skála, más a terhelési minta, a berendezés nagy valószínűséggel más is. A csúcsterhelések váratlanok és kiszámíthatatlanok is lehetnek. És egy ilyen tesztelés, amely szintén nem lépi túl a költségvetést, nagyon jól segít az infrastruktúra olyan hibáinak felderítésében, amelyeket a staging, az automatikus tesztek, a CI / CD-csővezeték soha nem fog elkapni. És amíg mindez benne van a költségvetésben, addig nem számít, hogy ott lemaradt a szolgáltatása, bár nagyon ijesztőnek tűnik, a szerver leállt, micsoda rémálom. Nem, ez normális, ez jó, segít elkapni a hibákat. Ha van költségvetése, akkor elköltheti.
K: Milyen irodalmat ajánlhatok? Lista a végén. Rengeteg szakirodalom van, tanácsot adok néhány jelentéshez. Hogyan működik, és működik-e az SRE saját szoftvertermék nélküli vagy minimális fejlesztéssel rendelkező cégeknél. Például egy olyan vállalkozásban, ahol a fő tevékenység nem a szoftver. Vállalkozásban, ahol nem a szoftver a fő tevékenység, az SRE pontosan ugyanúgy működik, mint mindenhol, mert egy vállalkozásban is kell használni, még ha nem is kifejlesztett szoftvertermékeket, frissítéseket kell kivezetni, változtatni kell. az infrastruktúra, növekednie kell, méretezni kell. Az SRE-k pedig segítenek azonosítani és előre jelezni ezekben a folyamatokban a lehetséges problémákat, és kontrollálni azokat, miután bizonyos növekedés megkezdődik és az üzleti igények megváltoznak. Mert egyáltalán nem szükséges szoftverfejlesztésben részt venni egy SRE-hez, ha legalább néhány szervered van, és legalább némi növekedés várható.
Ugyanez vonatkozik a kis projektekre, kis szervezetekre, mert a nagy cégeknek van költségvetésük és tere a kísérletezéshez. De ugyanakkor a kísérletek mindezen gyümölcsei bárhol felhasználhatók, vagyis az SRE természetesen megjelent a Google-ban, a Netflixben, a Dropboxban. De ugyanakkor a kis cégek, startupok már sűrített anyagokat olvashatnak, könyveket olvashatnak, riportokat nézhetnek. Gyakrabban kezdenek hallani róla, konkrét példákat nézegetnek, szerintem nem baj, tényleg hasznos lehet, nekünk is kell ez, remek.
Vagyis a folyamatok szabványosításával kapcsolatos összes fő munkát már elvégezték Ön helyett. Az Ön feladata, hogy meghatározza az SRE szerepét konkrétan az Ön vállalatában, és elkezdje ténylegesen végrehajtani ezeket a gyakorlatokat, amelyeket ismételten már leírtunk. Vagyis a kisvállalatok számára hasznos elvek alapján mindig ez az SLA, SLI, SLO definíciója. Ha nem foglalkozik szoftverekkel, akkor ezek belső SLA-k és belső SLO-k, a hibák belső költségvetése. Ez szinte mindig érdekes megbeszélésekhez vezet a csapaton és az üzleten belül, mert kiderülhet, hogy infrastruktúrára, ideális folyamatok valamiféle megszervezésére költ, az ideális csővezeték sokkal több a szükségesnél. És erre a 4 kilencre, ami az informatikai osztályon van, most nincs rájuk igazán szüksége. De ugyanakkor időt is fordíthat, és a hibákra szánt költségvetést valami másra költheti.
Ennek megfelelően a monitorozás és a monitoring megszervezése bármilyen méretű cég számára hasznos. És általában ez a gondolkodásmód, ahol a hibák elfogadhatóak, ahol van költségvetés, ahol vannak Célok, ez ismét hasznos egy bármilyen méretű cégnek, kezdve a 3 fős startupoktól.
Az utolsó technikai árnyalatok, amelyekről beszélni kell, a megfigyelés. Mert ha SLA-ról, SLI-ről, SLO-ról beszélünk, nem érthetjük meg anélkül, hogy ellenőriznénk, hogy beleférünk-e a költségvetésbe, betartjuk-e a Célkitűzéseinket, és hogyan befolyásoljuk a végső SLA-t. Sokszor láttam, hogy a monitorozás így történik: van valami érték, például a szerverhez érkezett kérés ideje, az átlagos idő, vagy az adatbázishoz érkezett kérések száma. Egy mérnök által meghatározott szabványa van. Ha a mérőszám eltér a normától, akkor e-mail érkezik. Ez általában teljesen haszontalan, mert a riasztások zsúfoltságához, a megfigyelésből származó üzenetek tömkelegéhez vezet, amikor az embernek először is minden alkalommal értelmeznie kell azokat, vagyis meg kell határoznia, hogy a metrika értéke azt jelenti-e. valamilyen cselekvés szükségessége. Másodszor pedig egyszerűen nem veszi észre ezeket a figyelmeztetéseket, amikor alapvetően nincs szükség semmilyen intézkedésre. Ez egy jó megfigyelési szabály, és az SRE végrehajtásának legelső szabálya az, hogy az értesítés csak akkor érkezzen, ha intézkedésre van szükség.
Normál esetben 3 szintű esemény van. Vannak riasztások, vannak jegyek, vannak naplók. A riasztások olyan dolgok, amelyek azonnali cselekvést igényelnek. Vagyis minden elromlott, azonnal meg kell javítani. A jegyek azok, amelyek késleltetett intézkedést igényelnek. Igen, valamit meg kell tennie, valamit kézzel kell csinálnia, az automatizálás meghiúsult, de a következő percekben nem kell megtennie. A naplók olyan dolgok, amelyek nem igényelnek cselekvést, és általában, ha a dolgok jól mennek, soha senki nem fogja elolvasni őket. Csak akkor kell majd elolvasni a naplókat, amikor utólag kiderült, hogy valami elromlott egy ideje, nem tudtunk róla. Vagy valami kutatást kell végeznie. De általában minden, ami nem igényel semmilyen műveletet, a naplókba kerül.
Mindezek mellékhatásaként, ha definiáltuk, hogy milyen események igényelnek cselekvéseket, és jól leírtuk, hogy ezeknek milyennek kell lenniük, ez azt jelenti, hogy a cselekvés automatizálható. Vagyis mi történik. A riadóból indulunk. Térjünk a cselekvésre. Továbblépünk ennek a műveletnek a leírásához. És akkor áttérünk az automatizálásra. Vagyis minden automatizálás egy eseményre adott reakcióval kezdődik.
A megfigyeléstől áttérünk a Megfigyelhetőség kifejezésre. Az elmúlt néhány évben egy kis hírverés is volt e szó körül. És kevesen értik, mit jelent a szövegkörnyezetből kiragadva. De a lényeg az, hogy a megfigyelhetőség a rendszer átláthatóságának mérőszáma. Ha valami elromlott, milyen gyorsan lehet megállapítani, hogy pontosan mi hibázott, és milyen állapotban volt a rendszer abban a pillanatban. Kód szempontjából: melyik funkció, melyik szolgáltatás hibásodott meg. Milyen állapotban voltak például a belső változók, konfiguráció. Az infrastruktúra szempontjából ez az, hogy melyik rendelkezésre állási zónában történt a hiba, és ha van telepítve Kubernetes, akkor melyik podban történt a hiba, milyen állapotban volt a pod. Ennek megfelelően a megfigyelhetőség közvetlen kapcsolatban áll az MTTR-rel. Minél magasabb a szolgáltatás Megfigyelhetősége, annál könnyebben azonosítható a hiba, könnyebben javítható a hiba, annál könnyebben automatizálható a hiba, annál alacsonyabb az MTTR.
Ha ismét a kisvállalatokra térünk át, már most is gyakran felmerül a kérdés, hogyan kezeljük a csapatlétszámot, és hogy egy kis csapatnak kell-e külön SRE-t felvennie. Erről már volt szó korábban. Egy startup vagy például egy csapat fejlesztésének első szakaszában erre egyáltalán nincs szükség, mert az SRE átmeneti szerepkörré tehető. Ez pedig egy kicsit felélénkíti a csapatot, mert legalább van némi sokszínűség. Ráadásul felkészíti az embereket arra, hogy a növekedéssel az SRE felelősségi köre általában jelentősen megváltozik. Ha felvesz valakit, akkor természetesen vannak elvárásai. És ezek az elvárások nem változnak az idő múlásával, de a követelmények nagyon megváltoznak. Ezért az SRE bérbeadása meglehetősen nehéz a korai szakaszban. A saját termesztés sokkal könnyebb. De érdemes elgondolkodni.
Az egyetlen kivétel talán az, amikor nagyon szigorú és jól meghatározott növekedési követelmények vannak. Azaz egy startup esetében ez lehet valamiféle befektetői nyomás, valamiféle növekedési előrejelzés egyszerre többször is. Akkor az SRE felvétele alapvetően indokolt, mert indokolható. Vannak követelményeink a növekedéshez, szükségünk van egy emberre, aki felelős azért, hogy egy ilyen növekedéssel semmi sem fog eltörni.
Még egy kérdés. Mi a teendő, ha a fejlesztők többször megvágnak egy olyan funkciót, amely átmegy a teszteken, de megszakítja a termelést, betölti az alapokat, megtöri az egyéb funkciókat, milyen folyamatot kell megvalósítani. Ennek megfelelően ebben az esetben a hibákra vonatkozó költségvetés kerül bevezetésre. Néhány szolgáltatást, néhány funkciót pedig már a gyártás során tesztelnek. Lehet kanári, amikor csak kis számú felhasználó, de már a termelésben van egy funkció, de már azzal az elvárással, hogy ha valami elromlik például az összes felhasználó fél százalékánál, akkor is megfelel a költségvetés a hibákra. Ennek megfelelően igen, lesz hiba, egyes felhasználóknál minden elromlik, de már mondtuk, hogy ez normális.
Volt egy kérdés az SRE eszközökkel kapcsolatban. Vagyis van-e olyan konkrét dolog, amit az SRE-k használnának, amit mindenki más nem. Valójában vannak nagyon speciális segédprogramok, vannak olyan szoftverek, amelyek például terheléseket szimulálnak vagy kanári A / B tesztelést végeznek. De alapvetően az SRE eszközkészletet használják a fejlesztők. Mivel az SRE közvetlenül érintkezik a fejlesztőcsapattal. És ha különböző eszközökkel rendelkezik, akkor kiderül, hogy időbe telik a szinkronizálás. Főleg, ha az SRE-k nagy csapatokban dolgoznak, nagy cégeknél, ahol több csapat is lehet, itt sokat segít a vállalati szintű szabványosítás, mert ha 50 csapatban 50 különböző segédprogramot használnak, az azt jelenti, hogy az SRE-nek ismernie kell őket. minden. És persze ez soha nem fog megtörténni. És a munka minősége, az ellenőrzés minősége legalább néhány csapatnál jelentősen csökkenni fog.
Webináriumunk a végéhez közeledik. Sikerült néhány alapvető dolgot elmondanom. Természetesen az SRE-ről semmit sem lehet egy óra alatt elmondani és megérteni. De remélem, sikerült átadnom ezt a gondolkodásmódot, a főbb kulcspontokat. És akkor lehetőség lesz, ha érdekel, elmélyülni a témában, önállóan tanulni, megnézni, hogyan valósítják meg mások, más cégeknél. Ennek megfelelően február elején gyere el hozzánk a Slurm SRE-be.
A Slurm SRE egy háromnapos intenzív tanfolyam, ami arról fog beszélni, amiről most beszélek, de sokkal mélyebben, valós esetekkel, gyakorlással az egész intenzív a gyakorlati munkára irányul. Az embereket csapatokra osztják. Mindannyian valódi ügyeken fogtok dolgozni. Ennek megfelelően a Booking.com oktatói, Ivan Kruglov és Ben Tyler. Van egy csodálatos Eugene Barabbas a Google-tól, San Franciscóból. És én is mondok valamit. Szóval mindenképpen látogass el hozzánk.
Tehát a bibliográfia. Vannak referenciák az SRE-ről. ugyanazon a könyvön, vagy inkább 2 SRE-ről szóló könyvön, amit a Google írt. Másik , ahol a feltételek és alkalmazásuk kissé részletesebb. A következő 3 az SRE-ről szóló jelentések különböző vállalatoknál. Első - , ez a főbeszéd a Google Ben Trainerétől. Második - . A harmadik megint . Negyedik riport innen , amelynek mindössze 5 fő SRE alkalmazottja van 190 országban. Nagyon érdekes mindezt végignézni, hiszen ahogy a DevOps nagyon mást jelent a különböző cégeknek, sőt csapatoknak, úgy az SRE-nek is nagyon eltérő feladatai vannak, még hasonló méretű cégeknél is.
2 további link a káoszmérnöki elvekről: , . A végén pedig van 3 lista az Awesome Lists című sorozatból , ról ről és róla . Az SRE-n hihetetlenül hatalmas a lista, nem kell mindent végigmenni, kb 200 cikk van. Nagyon ajánlom a kapacitástervezésről és a feddhetetlen postmortemről szóló cikkeket.
Érdekes cikk:
Köszönöm, hogy végig hallgattál. Remélem tanultál valamit. Remélem, van elég anyagod, hogy még többet tanulj. És találkozunk. Remélhetőleg februárban.
A webinárium házigazdája Eduard Medvegyev volt.
PS: Aki szeretnek olvasni, annak Eduard adott egy hivatkozási listát. Aki inkább a gyakorlatban szeretne megérteni, azt szívesen látjuk .
Forrás: will.com