Tiimimme rakastaa kokeiluja. Jokainen Slurm ei ole aiempien staattinen toisto, vaan pohdiskelu kokemuksesta ja siirtyminen hyvästä parempaan. Mutta kanssa päätimme soveltaa täysin uutta muotoa - antaa osallistujille olosuhteet mahdollisimman lähellä "taistelua".
Jos hahmotellaan lyhyesti, mitä teimme intensiivikurssilla: "Rakennamme, rikomme, korjaamme,
me opiskelemme." SRE on vähän arvokas pelkässä teoriassa - vain käytäntö, todelliset ratkaisut, todelliset ongelmat.
Osallistujat jaettiin tiimeihin, jotta voimakas kilpailuhenki ei antanut kenenkään nukahtaa tai käynnistää "Angry Birds" -ohjelmaa iPhonella Dmitri Anatoljevitšin esimerkin mukaisesti.
Ongelmia, vikoja, bugeja ja tehtäviä tarjosi osallistujille neljä mentoria. Ivan Kruglov, Booking.comin (Alankomaat) pääkehittäjä. Ben Tyler, Booking.comin (USA) pääkehittäjä. Eduard Medvedev, Tungsten Labsin teknologiajohtaja (Saksa). Evgeniy Varavva, Googlen yleinen kehittäjä (San Francisco).
Lisäksi osallistujat jaetaan joukkueisiin ja kilpailevat keskenään. Mielenkiintoista?
Ivan, Ben, Eduard ja Evgeniy katsovat Slurm SRE:n köyhiä osallistujia ystävällisin leninistisin silmin ennen kilpailun alkua.
Tehtävä siis:
Olemme meidän, rakennamme uuden maailman...
Siellä on elokuvalippujen kerääjäsivusto. Mentorit keksivät tapahtumat ennalta laaditussa skenaariossa (vaikka kukaan ei sulje pois erityisen hienostunutta ja salakavalaa improvisaatiota), sivuston suorituskykyä kuvataan erilaisilla mittareilla. Ongelmat voivat olla hyvin erilaisia: Moulin Rouge -teatterin lippuja ei ladata tietokantaan; elokuvien ja esitysten julisteet ladataan tietokantaan yli 10 sekunnissa; yksittäisen elokuvan kuvaus jäätyy; 0,1 % tilauksista on jo varattu; Ajoittain maksujenkäsittelyjärjestelmä kaatuu minuutiksi tai kahdeksi. Ja monia, monia, monia epämiellyttäviä asioita, jotka voivat kohdata Slurm SRE:n osallistujaa hänen todellisessa työssään.
Olemme valmiita käsittelemään mitä tahansa... ja kaikkia.
Pitkään kärsinyt nettisivumme koostuu useista mikropalveluista. Sen tehtävänä on koota tietoja esityksistä, hinnoista ja saatavilla olevista paikoista kaikista elokuvateattereista; se näyttää elokuvatiedotteet, antaa sinun valita elokuvateatterin, esityksen, salin ja paikan, varata ja maksaa liput. Yleensä kaikki, mistä katsoja voi vain haaveilla. Mutta käyttäjä ei edes epäile, mitä titaanista taistelua sivuston vakaudesta ja saavutettavuudesta käydään sisällä.
Intensiivistä sivustoa varten loimme SLO-, SLI- ja SLA-indikaattorit, kehitimme arkkitehtuuria ja infrastruktuuria, otimme sivuston käyttöön, määritimme valvonnan ja hälytyksen. Ja pois mennään.
SLO, SLI, SLA
SLI - palvelutason ilmaisimet. SLO:t ovat palvelutason tavoitteita. SLA - palvelutasosopimukset.
SLA on ITIL-metodologian termi, joka tarkoittaa muodollista sopimusta palvelun asiakkaan ja sen toimittajan välillä, joka sisältää kuvauksen palvelusta, osapuolten oikeuksista ja velvollisuuksista sekä ennen kaikkea sovitun laatutason tämän tarjoamisen osalta. palvelua.
SLO on palvelutason tavoite: SLI:n mittaama tavoitearvo tai arvoalue palvelutasolle. Normaali arvo SLO:lle on “SLI ≤ Tavoite” tai “Alaraja ≤ SLI ≤ Yläraja”.
SLI on palvelutason indikaattori – tarkasti määritelty määrällinen mitta yhdestä tarjotun palvelun tason näkökulmasta. Useimmissa palveluissa SLI-avain katsotaan pyyntöviiveeksi – kuinka kauan kestää vastauksen palauttamiseen pyyntöön. Muita yleisiä SLI:itä ovat virheprosentti, joka ilmaistaan usein murto-osana kaikista vastaanotetuista pyynnöistä, ja järjestelmän suorituskyky, joka mitataan yleensä pyyntöinä sekunnissa.
Ensin rikomme lentokoneet ja sitten tytöt ja sitten tytöt...
Sisäiset ja ulkoiset tekijät alkoivat "pilata" SLO:ta ensimmäisistä minuuteista lähtien. Kaikki putosi järjestelmänvalvojien päähän – kehittäjien virheet, infrastruktuurihäiriöt, vierailijavirrat ja DDoS-hyökkäykset. Kaikki mikä pahentaa SLO:ta.
"- Hyvät osallistujat, kiirehdin miellyttämään teitä, ensimmäinen asia, jonka epäonnistutte, on... kaikki!"
Matkan varrella puhujat keskustelivat vakaudesta, virhebudjetista, testauskäytännöistä, keskeytysten hallinnasta ja käyttökuormituksesta.
Emme ole kivimiehiä, emme puuseppiä...
Sitten osallistujat alkoivat korjata asioita - tärkeintä on ymmärtää, mihin tarttuu ensin.
"- Herra, en ole koskaan nähnyt sen murtuvan näin, tässä muodossa ja sellaisessa asennossa!"
Tapahtui siis onnettomuus. Maksunkäsittelypalvelu on poissa käytöstä. Kuinka toimia toiminnan palauttamiseksi mahdollisimman lyhyessä ajassa?
Asiantuntijat, jotka katsovat hellästi osallistujia, valmistelevat uutta temppua.
Jokainen tiimi organisoi ryhmän työskentelyä onnettomuuden poistamiseksi - ottaa kollegoita mukaan, ilmoittaa asiasta kiinnostuneille (sidosryhmille). Samalla asetetaan prioriteetit. Tällä tavalla osallistujat harjoittelivat työskentelemään paineen alla erittäin rajoitetuissa olosuhteissa.
"Millainen kauhu on ilmestynyt?!"
Hengitä ulos... ja lopeta harjoitus
Kun jokainen ongelma oli ratkaistu ja sivusto tilapäisesti vakiintunut, tiimi tutki tapauksia SRE:n näkökulmasta yhdessä puhujien kanssa. Analysoimme ongelmat yksityiskohtaisesti - esiintymisen syitä, poistamisen edistymistä. Sen jälkeen teimme sekä joukkueittain että kollektiivisesti päätöksiä, miten niitä voidaan edelleen ehkäistä: miten seurantaa parannetaan, miten arkkitehtuuria muutetaan viisaasti, miten kehitys- ja toimintatapaa muokataan, miten säännöksiä korjataan. Puhujat esittelivät post mortem -johtamisen käytäntöä.
"Kuka muu haluaa piinaa! - Minä!"
Joukkueiden onnistumiset kirjattiin tarkasti ja selkeästi sähköiseen tulostauluun.
Ykköspaikoista - bonus sidosryhmiltä.
Lähde: will.com