Csapatunk szereti a kísérleteket. Minden egyes Slurm nem az előzőek statikus megismétlése, hanem a tapasztalat reflexiója és átmenet a jóból a jobb felé. De azzal úgy döntöttünk, hogy egy teljesen új formátumot alkalmazunk – hogy a résztvevőknek a lehető legközelebbi feltételeket biztosítsuk a „harchoz”.
Ha röviden felvázoljuk, mit csináltunk az intenzív tanfolyamon: „Építünk, bontunk, javítunk,
tanulunk." Az SRE puszta elméletben keveset ér – csak gyakorlat, valódi megoldások, valós problémák.
A résztvevőket csapatokra osztották, hogy a lendületes versenyszellem ne engedje senkinek elaludni, vagy Dmitrij Anatoljevics mintájára elindítani az „Angry Birds”-t iPhone-on.
A problémákat, hibákat, hibákat és feladatokat négy mentor látta el a résztvevőknek. Ivan Kruglov, a Booking.com (Hollandia) fő fejlesztője. Ben Tyler, a Booking.com (USA) fő fejlesztője. Eduard Medvegyev, a Tungsten Labs (Németország) műszaki igazgatója. Evgeniy Varavva, a Google általános fejlesztője (San Francisco).
Sőt, a résztvevők csapatokra oszlanak és versenyeznek egymással. Érdekes?
Ivan, Ben, Eduard és Jevgenyij kedves lenini hunyorogással nézik a Slurm SRE szegény résztvevőit a verseny kezdete előtt.
Tehát a feladat:
Miénk vagyunk, új világot építünk...
Van egy mozijegy-összesítő weboldal. Az incidenseket mentorok találják ki egy előre kidolgozott forgatókönyvben (bár a különösen kifinomult és alattomos rögtönzést senki sem zárja ki), az oldal teljesítményét különféle mérőszámok írják le. A problémák nagyon különbözőek lehetnek: a Moulin Rouge színház jegyei nincsenek betöltve az adatbázisba; a filmek és előadások plakátjai több mint 10 másodperc alatt betöltődnek az adatbázisba; az egyes filmek leírása lefagy; A megrendelések 0,1%-a már le van foglalva; A fizetésfeldolgozó rendszer időnként egy-két percre összeomlik. És sok-sok-sok kellemetlen dolog, ami egy Slurm SRE résztvevőt az igazi munkahelyén érhet.
Készek vagyunk bármire...és mindenkire.
Sokáig szenvedő weboldalunk több mikroszolgáltatásból áll. Feladata az összes mozi műsoraira, árakra és szabad férőhelyekre vonatkozó adatok összesítése, filmbejelentések megjelenítése, mozi, előadás, terem és hely kiválasztása, jegyfoglalás és jegyvásárlás. Általában minden, amiről a néző csak álmodozhat. De a felhasználó nem is sejti, milyen titáni küzdelem folyik odabent az oldal stabilitásáért és elérhetőségéért.
Az intenzív oldalhoz SLO, SLI, SLA indikátorokat generáltunk, architektúrát és infrastruktúrát fejlesztettünk, telepítettük az oldalt, beállítottuk a felügyeletet és a riasztást. És elmegyünk.
SLO, SLI, SLA
SLI - szolgáltatási szintjelzők. Az SLO-k szolgáltatási szintű célok. SLA - szolgáltatási szint megállapodások.
Az SLA egy ITIL módszertani fogalom, amely a szolgáltatás megrendelője és szállítója között létrejött formális megállapodást jelöl, amely tartalmazza a szolgáltatás leírását, a felek jogait és kötelezettségeit, és ami a legfontosabb, a szolgáltatás nyújtására vonatkozó megállapodás szerinti minőségi szintet. szolgáltatás.
Az SLO egy szolgáltatási szint célkitűzés: egy szolgáltatási szint célértéke vagy értéktartománya, amelyet az SLI mér. Az SLO normál értéke „SLI ≤ cél” vagy „Alsó határ ≤ SLI ≤ felső határ”.
Az SLI a szolgáltatási szint mutatója – a nyújtott szolgáltatási szint egy aspektusának gondosan meghatározott mennyiségi mérőszáma. A legtöbb szolgáltatás esetében a kulcs SLI-t a kérés késleltetésének tekintik – mennyi ideig tart a kérésre adott válasz visszaadása. Egyéb gyakori SLI-k közé tartozik a hibaarány, amelyet gyakran az összes fogadott kérés töredékében fejeznek ki, és a rendszer átviteli sebességét, amelyet általában másodpercenkénti kérésekben mérnek.
Először is feltörjük a repülőket, aztán a lányokat, aztán a lányokat...
A belső és külső tényezők már az első percekben elkezdték „elrontani” az SLO-t. Minden a rendszergazdák fejére esett – fejlesztői hibák, infrastrukturális hibák, látogatók özöne és DDoS támadások. Minden, ami rontja az SLO-t.
"- Kedves résztvevők, sietek a kedvükben járni, az első dolog, amit elbuktok, az... minden!"
Útközben az előadók szóba kerültek a stabilitásról, a hibaköltségvetésről, a tesztelési gyakorlatról, a megszakítások kezeléséről és az üzemi terhelésről.
Nem vagyunk tűzrakók, nem ácsok...
Ezután a résztvevők elkezdték kijavítani a dolgokat - a lényeg az, hogy megértsék, mit kell először megragadni.
"- Uram, még soha nem láttam, hogy így megtörjön, ebben a formában és ilyen helyzetben!"
Szóval baleset történt. A fizetésfeldolgozó szolgáltatás nem működik. Hogyan lehet a lehető legrövidebb időn belül visszaállítani a funkcionalitást?
A szakértők szeretettel a résztvevőkre nézve újabb trükkel készülnek.
Minden csapat megszervezi a csoport munkáját a baleset elhárítására - bevonja a kollégákat, értesíti az érdeklődőket (érintetteket). Ezzel párhuzamosan a prioritásokat is felállítják. Ily módon a résztvevők nyomás alatti munkavégzésre edzettek rendkívül korlátozott ideig.
"Miféle horror jött ki?!"
Lélegezz ki... és fejezd be a gyakorlatot
Az egyes problémák megoldása és a helyszín átmeneti stabilizálása után a felszólalókkal együtt a csapat SRE szemszögből vizsgálta az incidenseket. Részletesen elemeztük a problémákat - az előfordulás okait, a megszüntetés előrehaladását. Ezt követően csapatonként és kollektíven is döntéseket hoztunk a további megelőzésükről: hogyan javítsuk a monitorozást, hogyan változtassuk meg okosan az architektúrát, hogyan igazítsuk a fejlesztési és üzemeltetési szemléletet, hogyan korrigáljuk a szabályozást. Az előadók bemutatták a post mortem levezetésének gyakorlatát.
„Ki akar még kínt! - Én!"
A csapatok sikereit szigorúan és egyértelműen rögzítették az elektronikus eredményjelzőn.
Az első helyekért - bónusz az érintettektől.
Forrás: will.com