Csapatunk szereti a kísérleteket. Minden Slurm nem statikus ismétlés, hanem a tapasztalatok értelmezése és az átmenet a jótól a jobbig. De ezzel új formátumot alkalmaztunk — olyan körülményeket biztosítunk a résztvevőknek, amelyek maximálisan közel állnak a "harci" körülményekhez.
Ha röviden összefoglalnánk, min dolgoztunk az intenzív tréning során: "Építünk, lerombolunk, javítunk,
tanulmányozunk." Az SRE-nek alig van értelme pusztán elméletben — csak a gyakorlat, valós megoldások és valós problémák számítanak.
A résztvevőket csapatokra osztottuk, hogy a versenyszellem ne engedje senkinek, hogy elszundítson vagy éppen "Angry Birds"-ozzon az iPhone-on Dmitrij Anatoljevics példáját követve.
A problémákat, hibákat és feladatokat négy mentor biztosította. Ivan Kruglov, Principal Developer a Booking.com-nál (Hollandia). Ben Tyler, Principal Developer a Booking.com-nál (USA). Eduard Medvedev, CTO a Tungsten Labs-nál (Németország). Jevgenyij Varavva, széleskörű szakértő a Google-nál (San Francisco).
Ráadásul a résztvevők csapatokra vannak osztva — és versenyeznek egymással. Érdekes?
Ivan, Ben, Eduard és Jevgenyij jóságos lenini pillantással nézik a szegény Slurm SRE résztvevőket a verseny kezdete előtt.
Íme a feladat:
Mi összességében, egy új világot építünk...
Van egy jegyaggregátor weboldal. Az incidenseket a mentorok egy előre kidolgozott forgatókönyv alapján találják ki (bár senki sem zárja ki a különösen rafinált és ravasz improvizáció lehetőségét), a weboldal működését különböző metrikák írják le. A problémák sokfélék lehetnek: a "Moulin Rouge" színház jegyei nem töltenek be az adatbázisba; a filmek és előadások poszterei több mint 10 másodperc alatt töltődnek be az adatbázisba; egy adott film leírása megakad; a rendelés 0,1%-a már lefoglalt helyekre kerül; időnként a rendszer, amely a kifizetéseket kezeli, egy-két percre leáll. És még sok-sok kellemetlen dolog, ami a Slurm SRE résztvevőjére vár a való életben.
Készen állunk, hogy mindennel... és mindenkivel megbirkózzunk.
A szenvedő weboldalunk több mikroszolgáltatásból áll. Feladata az adatgyűjtés a mozi előadásaival, áraival és szabad helyeivel kapcsolatban, filmelőzeteseket mutat be, lehetővé teszi a mozi, előadás, terem és hely kiválasztását, valamint a jegyek lefoglalását és kifizetését. Röviden: mindaz, amiről a néző csak álmodhat. Csak éppen a felhasználó nem is sejti, milyen hatalmas harc folyik a weboldal stabilitásáért és elérhetőségéért a háttérben.
Az intenzív weboldalunk számára SLO, SLI, SLA mutatókat alakítottunk ki, megterveztük az architektúrát és az infrastruktúrát, telepítettük a weboldalt, beállítottuk a monitorozást és az értesítéseket. És kezdődött is.
SLO, SLI, SLA
Az SLI — a szolgáltatás szintjének indikátorai. Az SLO — a szolgáltatás szintjének célkitűzései. Az SLA — a szolgáltatási szint megállapodásai.
Az SLA — az ITIL módszertanának egy kifejezése, amely egy hivatalos szerződést jelöl a szolgáltatás megrendelője és annak szolgáltatója között, amely tartalmazza a szolgáltatás leírását, a felek jogait és kötelezettségeit, és ami a legfontosabb, a megállapodott szintet a szolgáltatás minőségénél.
Az SLO — a szolgáltatás szintjének célja: a célérték vagy a szolgáltatás szintjének mérésére szolgáló értékek tartománya, amelyet az SLI mér. Az SLO normál értéke "SLI ≤ célérték" vagy "alsó határ ≤ SLI ≤ felső határ".
Az SLI a szolgáltatási szint indikátora – egy pontosan meghatározott mennyiségi mértéke a szolgáltatás szintjének egyik aspektusának. A legtöbb szolgáltatás esetén a kulcs SLI-t a kérés késleltetése képezi – mennyi idő szükséges a válasz visszaküldéséhez a kérésre. Egyéb gyakori SLI-k közé tartozik a hibák aránya, amely gyakran a kapott kérések arányában van kifejezve, és a rendszer áteresztőképessége, amelyet általában másodpercenkénti kérésekben mérnek.
Első lépésként összetörjük a repülőgépeket, na és a lányokat, a lányokkal majd később…
A belső és külső tényezők már az első percekben elkezdték "rontani" az SLO-t. Az adminisztrátorokra minden rázuhant — a fejlesztők hibái, az infrastruktúra leállása, a látogatók hirtelen megnövekedett száma és a DDoS-támadások. Mindez rontja az SLO-t.
"- Kedves résztvevők, örömmel jelentem, hogy első lépésként minden le fog zuhanni…!"
A beszélgetések során a szónokok az ellenállóságot, a hibaköltséget, a tesztelési gyakorlatot, a megszakítások és az operatív terhelés kezelését tárgyalták.
Nem vagyunk kazánfűtők, nem ácsok…
Itt a résztvevők elkezdték a javítást — a legfontosabb megérteni, hogy mivel érdemes kezdeni.
„- Uram, még soha nem láttam, hogy ez így romoljon el, ilyen állapotban és ilyen pózban!”
Tehát baleset történt. Az online fizetési szolgáltatás leállt. Hogyan járjunk el, hogy a lehető leghamarabb helyreállítsuk a működést?
A szakértők kedvesen figyelik a résztvevőket, miközben készítik a következő kihívást.
Minden csapat megszervezi a baleset felszámolására irányuló munkát — bevonják a kollégákat, tájékoztatják az érdekelteket. Eközben prioritásokat állítanak fel. A résztvevők így gyakorolták a nyomás alatti munkavégzést rendkívül korlátozott időkeretek között.
„- Mi a fene történt?!“
Kibocsátották a levegőt... és befejezték a gyakorlatot.
A spíkerekkel együtt, minden problémamegoldás után és ideiglenes stabilizált webhellyel a csapatok az SRE szempontjából tanulmányozták az eseményeket. Részletesen elemezték a problémákat - azok okait, a megszüntetés menetét. Ezt követően csapatonként és kollektíven döntést hoztak a további megelőzésükről: hogyan javítsák a monitorozást, hogyan változtassanak racionálisan az architektúrán, hogyan módosítsák a fejlesztési és üzemeltetési megközelítést, hogyan korrigálják a szabályzatokat. A spíkerek bemutatták a post-mortem gyakorlatot.
„- Ki akar még szenvedni! - Én!”
Az elektronikus táblán szigorúan és világosan rögzítették a csapatok eredményeit.
Az első helyezettek jutalma a részvényesektől.
Forrás: habr.com
