Helyszíni megbízhatóság tervezése - tanfolyam 65 000 dörzsölje. Slurmból, képzés, 2024. január 1. dátum.
Vegyes Cikkek / / November 29, 2023
EMBEREKNEK
Az SRE mérnök lehet üzemeltetési mérnök vagy fejlesztő. Az intenzív tanfolyamon sokat gyakorolsz majd, a megszerzett készségek, ismeretek bármilyen területen adaptálhatók, megvalósíthatók.
ÜZLETI
Az SRE ugyanazokat a problémákat oldja meg, mint a DevOps: felgyorsítja az új funkciók kiadását, és javítja a csapaton belüli folyamatokat. Az SRE fő feladata azonban a szolgáltatások stabilitásának és megbízhatóságának biztosítása, kizárva azokat a helyzeteket, amikor a felhasználók meghibásodásokról panaszkodnak, és a mérnökök zöld ütemezéssel rendelkeznek.
Építünk:
Oktatóhelyünk több mikroszolgáltatásból áll. Összesíti az összes mozi műsorának, árának és elérhető ülőhelyeinek adatait, bemutatja a filmbejelentéseket, lehetővé teszi mozi, előadás, terem és hely kiválasztását, jegyfoglalást és fizetést.
Megfogalmazzuk az SLO, SLI, SLA indikátorokat erre az oldalra, kidolgozzuk az ezeket támogató architektúrát és infrastruktúrát, beállítjuk a felügyeletet és a riasztást.
A fejlesztői hibák, az infrastruktúra hibái, a látogatók beáramlása és a DoS támadások az SLO-k rosszabbodásához vezetnek.
Elemezzük a stabilitást, a hibakeretet, a tesztelési gyakorlatot, a megszakítások kezelését és az üzemi terhelést.
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?
Szervezzük a katasztrófaelhárítási csoport munkáját: kollégák bevonása, az érintettek értesítése, prioritások meghatározása. Nyomás alatti munkavégzésre edzünk, rendkívül korlátozott ideig.
Nézzük meg az oldal megközelítését SRE szempontból. Elemezzük az incidenseket (az előfordulás okait, a megszüntetés előrehaladását). Döntéseket hozunk ezek további megelőzése érdekében: javítjuk a monitoringot, megváltoztatjuk az architektúrát, a fejlesztési és üzemeltetési szemléletet, a szabályozást. A folyamatokat automatizáljuk.
— Több tucat kiépített infrastruktúrával és több száz írott CI/CD-csővezetékkel rendelkezünk,
– Okleveles Kubernetes-adminisztrátor,
— Számos Kubernetes és DevOps tanfolyam szerzője,
— Rendszeres előadó orosz és nemzetközi informatikai konferenciákon.
1. NAP: AMA kezdőülés
Megbeszéljük a kurzus céljait és célkitűzéseit, és azt is elmondjuk, mi az SRE, és csapatokra osztjuk.
2 elméleti téma nyitása:
1. téma: Monitoring
- Miért van szükség monitorozásra?
- Percentilisek
- Figyelmeztetés
- Megfigyelhetőség
2. téma: SRE elmélet
- SLO, SLI, SLA
- Tartósság
- Hiba költségkeret
2. NAP: gyakorlatok és esetek elemzése
Gyakorlat: Alapvető műszerfal készítése és a szükséges riasztások beállítása
Gyakorlat: SLO/SLI + figyelmeztetések hozzáadása az irányítópulthoz
Gyakorlat: Első rendszerbetöltés
1. eset megoldása: downstream függőség.
Egy nagy rendszerben sok egymásra épülő szolgáltatás létezik, amelyek nem mindig működnek egyformán jól. Különösen bosszantó, ha a szolgáltatás rendben van, de a szomszédos, amelytől függ, időnként leáll.
Az oktatási projekt pontosan ilyen körülmények között találja magát, és Ön biztosítja, hogy továbbra is a lehető legmagasabb minőséget produkálja.
3. NAP: AMA foglalkozás, kérdések megválaszolása
Megnyílik a 2. elméleti modul elérése:
A környezettel és építészettel kapcsolatos problémák megoldása
A második modul két eset megoldására épül: az upstream függőség és az építészeti problémák megoldására. Az előadók beszélnek az incidenskezelésről, a tűzoltóságra vonatkozó szabályokról és a post mortemekkel való munkavégzésről, és sablonokat biztosítanak, amelyeket a csapatában használhat.
3. téma: Incidenskezelés
- Resilience Engineering
- Hogyan alakul a tűzoltóság
- Mennyire hatékony a csapata az incidensben?
- 7 szabály egy incidensvezető számára
- 5 szabály egy tűzoltó számára
- HiPPO – a legjobban fizetett személy véleménye. Kommunikációs vezető
T4. téma: Varrum eszközök és riasztáskezelés.
Más cégek legjobb gyakorlata az incidenskezelés megszervezésében.
4. NAP: gyakorlatok és esetek elemzése
Megoldás a 2. esetre: upstream függőség.
Az egy dolog, ha egy alacsony SLO-val rendelkező szolgáltatástól függ. Más kérdés, hogy a szolgáltatásod a rendszer más részein is ugyanaz. Ez akkor történik, ha az értékelési kritériumok nem konzisztensek: például egy kérésre egy másodpercen belül válaszol, és sikeresnek tekinti, de a függő szolgáltatás csak 500 moszkvai időt vár, és hibával távozik.
Az ügyben megvitatjuk a mérőszámok összehangolásának fontosságát, és megtanuljuk a minőséget az ügyfél szemével nézni.
Megoldás a 3. esetre: problémák az adatbázissal.
Az adatbázis is problémák forrása lehet. Ha például nem figyeli a replikációs relét, a replika elavulttá válik, és az alkalmazás régi adatokat fog visszaadni. Ráadásul az ilyen esetek hibakeresése különösen nehéz: most már inkonzisztensek az adatok, de néhány másodperc múlva már nem konzisztensek, és nem világos, hogy mi a probléma oka.
Az eset során át fogja érezni a hibakeresés fájdalmát, és megtanulja, hogyan előzheti meg az ilyen problémákat.
Gyakorlat: Az előző esetről posztmortem írunk, és megbeszéljük az előadókkal.
5. NAP: AMA foglalkozás, kérdések megválaszolása
AMA foglalkozás és válaszok a korábbi témákkal kapcsolatos kérdésekre.
Megnyílik a 3. elméleti modul elérése:
Forgalomvédő és kanári kioldók
A harmadik modulban egy, a környezettel kapcsolatos problémának szentelt esetet elemezünk (az egészségügy részletes elemzése lesz Ellenőrzés), valamint lépésről lépésre elemezzük az SRE bevezetését a vállalatoknál, és megismerjük azoknak a cégeknek a tapasztalatait, ahol az előadók dolgoznak. intenzív
5. témakör: Egészségügyi ellenőrzés
- Állapotfelmérés Kubernetesben
- Él még a szolgálatunk?
- Exec szondák
- InitialDelaySeconds
- Másodlagos egészségügyi port
- Sidecar Health Server
- Fej nélküli szonda
- Hardveres szonda
6. témakör: Telepítési módszerek
7. témakör: SRE projekt bevezetése
A nagyvállalatok gyakran külön SRE csapatot alkotnak, amely más részlegek szolgáltatásait veszi át támogatásért. De nem minden szolgáltatás kész támogatásra. Megmondjuk, milyen követelményeknek kell megfelelnie. Az előadók megosztják tapasztalataikat, hogyan valósították meg az SRE-t és milyen hibákat követtek el.
6. NAP: gyakorlatok és esetek elemzése
Megoldás a 4. esetre: probléma van a környezettel, nem lehet jegyet venni.
A Healthcheck feladata, hogy észlelje a meghibásodott szolgáltatást, és blokkolja a forgalmat. És ha úgy gondolja, hogy ehhez elegendő kérést intéznie a szolgáltatáshoz a root-on, és megkapja a választ, akkor Ön tévedsz: még ha a szolgáltatás válaszol is, ez nem garantálja a működését - problémák merülhetnek fel környéke.
Ebben az esetben megtanulhatja, hogyan konfigurálhatja a megfelelő állapotellenőrzést, és nem engedi, hogy a forgalom oda kerüljön, ahol azt nem lehet feldolgozni.
Összegzés