Ons span hou van eksperimente. Elke Slurm is nie 'n statiese herhaling van die voriges nie, maar 'n refleksie op die ervaring en 'n oorgang van goed na beter. Maar met ons het besluit om 'n heeltemal nuwe formaat toe te pas - om die deelnemers toestande so na as moontlik aan "geveg" te gee.
As ons kortliks uiteensit wat ons tydens die intensiewe kursus gedoen het: βOns bou, ons breek, ons herstel,
ons studeer." SRE is min werd in blote teorie - slegs praktyk, werklike oplossings, werklike probleme.
Die deelnemers is in spanne verdeel sodat 'n kragtige mededingende gees niemand sou toelaat om aan die slaap te raak of "Angry Birds" op die iPhone te begin nie, na die voorbeeld van Dmitri Anatolyevich.
Probleme, foute, foute en take is deur vier mentors aan die deelnemers verskaf. Ivan Kruglov, hoofontwikkelaar by Booking.com (Nederland). Ben Tyler, hoofontwikkelaar by Booking.com (VSA). Eduard Medvedev, CTO by Tungsten Labs (Duitsland). Evgeniy Varavva, algemene ontwikkelaar by Google (San Francisco).
Boonop word die deelnemers in spanne verdeel en kompeteer met mekaar. Interessant?
Ivan, Ben, Eduard en Evgeniy kyk na die arme Slurm SRE-deelnemers met vriendelike Leninistiese skeels voor die aanvang van die kompetisie.
Dus die taak:
Ons is ons s'n, ons sal 'n nuwe wΓͺreld bou...
Daar is 'n webwerf vir fliekkaartjie-aggregator. Insidente word deur mentors uitgedink in 'n vooraf uitgewerkte scenario (alhoewel niemand besonder gesofistikeerde en verraderlike improvisasie uitsluit nie), word die prestasie van die webwerf deur verskeie maatstawwe beskryf. Die probleme kan baie anders wees: kaartjies vir die Moulin Rouge-teater word nie in die databasis gelaai nie; plakkate van films en optredes word binne meer as 10 sekondes in die databasis gelaai; die beskrywing van 'n individuele film vries; 0,1% van bestellings is reeds gereserveer; Van tyd tot tyd stort die betalingverwerkingstelsel vir 'n minuut of twee ineen. En baie, baie, baie onaangename dinge wat 'n Slurm SRE-deelnemer by sy regte werk kan tref.
Ons is gereed om enigiets...en almal te hanteer.
Ons lankmoedige webwerf bestaan ββuit verskeie mikrodienste. Sy taak is om data oor vertonings, pryse en beskikbare sitplekke van alle rolprentteaters bymekaar te maak; dit wys fliekaankondigings, laat jou toe om 'n bioskoop, vertoning, saal en plek te kies, kaartjies te bespreek en te betaal. Oor die algemeen alles waarvan die kyker net kan droom. Maar die gebruiker vermoed nie eers watter titaniese stryd om die stabiliteit en toeganklikheid van die webwerf binne aan die gang is nie.
Vir die intensiewe webwerf het ons SLO, SLI, SLA-aanwysers gegenereer, argitektuur en infrastruktuur ontwikkel, die webwerf ontplooi, monitering en waarskuwing opgestel. En weg gaan ons.
SLO, SLI, SLA
SLI - diensvlakaanwysers. SLO's is diensvlakdoelwitte. SLA - diensvlakooreenkomste.
SLA is 'n ITIL-metodologieterm wat 'n formele ooreenkoms tussen die kliΓ«nt van 'n diens en sy verskaffer aandui, wat 'n beskrywing bevat van die diens, die regte en verpligtinge van die partye en, bowenal, die ooreengekome vlak van kwaliteit vir die verskaffing van hierdie diens.
'n SLO is 'n diensvlakdoelwit: 'n teikenwaarde of reeks waardes vir 'n diensvlak wat deur die SLI gemeet word. 'n Normale waarde vir SLO is βSLI β€ Targetβ of βLawer Limit β€ SLI β€ Upper Limitβ.
Die SLI is 'n diensvlak-aanwyser - 'n noukeurig gedefinieerde kwantitatiewe maatstaf van een aspek van die vlak van diens wat gelewer word. Vir die meeste dienste word die sleutel-SLI beskou as versoekvertraging - hoe lank dit neem om 'n antwoord op 'n versoek terug te gee. Ander algemene SLI's sluit in foutkoers, dikwels uitgedruk as 'n fraksie van alle versoeke wat ontvang word, en stelseldeurset, gewoonlik gemeet in versoeke per sekonde.
Eerstens sal ons die vliegtuie breek, en dan die meisies, en dan die meisies ...
Interne en eksterne faktore het SLO van die eerste minute af begin βbederfβ. Alles het op die administrateurs se koppe geval - ontwikkelaarfoute, infrastruktuurfoute, 'n toestroming van besoekers en DDoS-aanvalle. Alles wat SLO vererger.
β- Liewe deelnemers, ek haas om julle te behaag, die eerste ding wat julle misluk is... alles!β
Langs die pad het die sprekers stabiliteit, foutbegroting, toetspraktyke, bestuur van onderbrekings en operasionele las bespreek.
Ons is nie stokers nie, nie skrynwerkers nie...
Toe begin die deelnemers om dinge reg te maak - die belangrikste ding is om te verstaan ββwat om eerste te gryp.
"- Here, ek het dit nog nooit so sien breek nie, in hierdie vorm en in so 'n posisie!"
So, 'n ongeluk het plaasgevind. Die betalingsverwerkingsdiens is af. Hoe om op te tree om funksionaliteit in die kortste moontlike tyd te herstel?
Die kenners kyk liefdevol na die deelnemers en berei nog 'n truuk voor.
Elke span organiseer die werk van die groep om die ongeluk uit te skakel - betrek kollegas, stel belanghebbende partye (belanghebbendes) in kennis. Terselfdertyd word prioriteite gestel. Op hierdie manier het die deelnemers opgelei om onder uiters beperkte tydsomstandighede onder druk te werk.
βWatter soort gruwel het uitgekom?!β
Asem uit... en voltooi die oefening
Saam met die sprekers, nadat elke probleem opgelos is en die terrein tydelik gestabiliseer is, het die span die voorvalle vanuit 'n SRE-oogpunt bestudeer. Ons het die probleme in detail ontleed - die oorsake van voorkoms, die vordering van eliminasie. Daarna het ons, beide span-vir-span en gesamentlik, besluite geneem oor hoe om dit verder te voorkom: hoe om monitering te verbeter, hoe om die argitektuur wys te verander, hoe om die benadering tot ontwikkeling en bedryf aan te pas, hoe om regulasies reg te stel. Die sprekers het die praktyk van nadoodse ondersoek gedemonstreer.
βWie wil nog pyniging hΓͺ! - Ek!"
Die spanne se suksesse is streng en duidelik op die elektroniese telbord aangeteken.
Vir eerste plekke - 'n bonus van belanghebbendes.
Bron: will.com