Gustung-gusto ng aming koponan ang mga eksperimento. Ang bawat Slurm ay hindi isang static na pag-uulit ng mga nauna, ngunit isang pagmuni-muni sa karanasan at isang paglipat mula sa mabuti tungo sa mas mahusay. Pero may nagpasya kaming mag-aplay ng isang ganap na bagong format - upang bigyan ang mga kalahok ng mga kondisyon na mas malapit hangga't maaari upang "lumaban".
Kung binalangkas natin nang maikli ang ginawa natin sa masinsinang kurso: “Bumubuo tayo, sinira natin, kinukumpuni natin,
nag-aaral tayo." Maliit ang halaga ng SRE sa teorya lamang - pagsasanay lamang, tunay na solusyon, tunay na problema.
Ang mga kalahok ay nahahati sa mga koponan upang ang isang malakas na mapagkumpitensyang espiritu ay hindi magpapahintulot sa sinuman na makatulog o maglunsad ng "Angry Birds" sa iPhone, kasunod ng halimbawa ni Dmitry Anatolyevich.
Ang mga problema, aberya, bug at gawain ay ibinigay sa mga kalahok ng apat na mentor. Ivan Kruglov, Principal Developer sa Booking.com (Netherlands). Ben Tyler, Principal Developer sa Booking.com (USA). Eduard Medvedev, CTO sa Tungsten Labs (Germany). Evgeniy Varavva, pangkalahatang developer sa Google (San Francisco).
Bukod dito, ang mga kalahok ay nahahati sa mga koponan at nakikipagkumpitensya sa bawat isa. Interesting?
Sina Ivan, Ben, Eduard at Evgeniy ay tumitingin sa mga mahihirap na kalahok sa Slurm SRE na may mabait na mga Leninistang duling bago magsimula ang kumpetisyon.
Kaya ang gawain:
Atin tayo, gagawa tayo ng bagong mundo...
Mayroong website ng movie ticket aggregator. Ang mga insidente ay naimbento ng mga tagapayo sa isang paunang ginawang senaryo (bagaman walang sinuman ang nagbubukod ng partikular na sopistikado at mapanlinlang na improvisasyon), ang pagganap ng site ay inilalarawan ng iba't ibang sukatan. Ang mga problema ay maaaring ibang-iba: ang mga tiket para sa teatro ng Moulin Rouge ay hindi na-load sa database; ang mga poster ng mga pelikula at pagtatanghal ay na-load sa database sa loob ng higit sa 10 segundo; ang paglalarawan ng isang indibidwal na pelikula ay nag-freeze; 0,1% ng mga order ay nakareserba na; Paminsan-minsan ay nag-crash ang sistema ng pagpoproseso ng pagbabayad sa loob ng isang minuto o dalawa. At marami, marami, maraming hindi kasiya-siyang bagay na maaaring mangyari sa isang kalahok ng Slurm SRE sa kanyang tunay na trabaho.
Handa kaming hawakan ang anumang bagay...at lahat.
Ang aming mahabang pagtitiis na website ay binubuo ng ilang mga microservice. Ang gawain nito ay pagsama-samahin ang data sa mga palabas, presyo at available na upuan mula sa lahat ng sinehan; nagpapakita ito ng mga anunsyo ng pelikula, nagbibigay-daan sa iyong pumili ng sinehan, palabas, bulwagan at lugar, mag-book at magbayad ng mga tiket. Sa pangkalahatan, lahat ng bagay na mapapangarap lamang ng manonood. Ngunit ang gumagamit ay hindi kahit na pinaghihinalaan kung ano ang isang malaking pakikibaka para sa katatagan at accessibility ng site ay nangyayari sa loob.
Para sa masinsinang site, nakabuo kami ng mga tagapagpahiwatig ng SLO, SLI, SLA, binuong arkitektura at imprastraktura, na-deploy ang site, nag-set up ng pagsubaybay at pag-alerto. At umalis na kami.
SLO, SLI, SLA
SLI - mga tagapagpahiwatig ng antas ng serbisyo. Ang mga SLO ay mga layunin sa antas ng serbisyo. SLA - mga kasunduan sa antas ng serbisyo.
Ang SLA ay isang ITIL methodology term na nagsasaad ng pormal na kasunduan sa pagitan ng customer ng isang serbisyo at supplier nito, na naglalaman ng paglalarawan ng serbisyo, mga karapatan at obligasyon ng mga partido at, higit sa lahat, ang napagkasunduang antas ng kalidad para sa probisyon nito. serbisyo.
Ang SLO ay isang layunin sa antas ng serbisyo: isang target na halaga o hanay ng mga halaga para sa isang antas ng serbisyo na sinusukat ng SLI. Ang isang normal na halaga para sa SLO ay “SLI ≤ Target” o “Lower Limit ≤ SLI ≤ Upper Limit”.
Ang SLI ay isang tagapagpahiwatig ng antas ng serbisyo—isang maingat na tinukoy na sukat ng dami ng isang aspeto ng antas ng serbisyong ibinigay. Para sa karamihan ng mga serbisyo, ang pangunahing SLI ay itinuturing na latency ng kahilingan - kung gaano katagal bago magbalik ng tugon sa isang kahilingan. Kasama sa iba pang mga karaniwang SLI ang rate ng error, kadalasang ipinapahayag bilang bahagi ng lahat ng natanggap na kahilingan, at throughput ng system, kadalasang sinusukat sa mga kahilingan sa bawat segundo.
Una sa lahat, sisirain natin ang mga eroplano, at pagkatapos ay ang mga babae, at pagkatapos ay ang mga babae...
Ang panloob at panlabas na mga kadahilanan ay nagsimulang "palayawin" ang SLO mula sa mga unang minuto. Ang lahat ay nasa isip ng mga administrator—mga pagkakamali ng developer, pagkabigo sa imprastraktura, pagdagsa ng mga bisita, at pag-atake ng DDoS. Lahat ng nagpapalala sa SLO.
"- Minamahal na mga kalahok, nagmamadali akong pasayahin ka, ang unang bagay na nabigo ka ay... lahat!"
Sa daan, tinalakay ng mga tagapagsalita ang katatagan, badyet ng error, pagsasanay sa pagsubok, pamamahala ng mga pagkaantala at pagkarga ng pagpapatakbo.
Hindi kami mga karpintero, hindi mga karpintero...
Pagkatapos ay nagsimulang ayusin ng mga kalahok ang mga bagay - ang pangunahing bagay ay upang maunawaan kung ano ang unang kukunin.
"- Panginoon, hindi ko pa nakitang nasira ito ng ganito, sa ganitong anyo at sa ganoong posisyon!"
Kaya, isang aksidente ang nangyari. Naka-down ang serbisyo sa pagpoproseso ng pagbabayad. Paano kumilos upang maibalik ang pag-andar sa pinakamaikling posibleng oras?
Ang mga eksperto, na magiliw na tumitingin sa mga kalahok, ay naghahanda ng isa pang lansihin.
Ang bawat koponan ay nag-aayos ng gawain ng grupo upang maalis ang aksidente - nagsasangkot ng mga kasamahan, nagpapaalam sa mga interesadong partido (mga stakeholder). Kasabay nito, itinakda ang mga priyoridad. Sa ganitong paraan, ang mga kalahok ay nagsanay na magtrabaho sa ilalim ng presyon sa ilalim ng limitadong mga kondisyon ng oras.
"Anong klaseng katatakutan ang lumabas?!"
Exhale... at tapusin ang ehersisyo
Kasama ang mga tagapagsalita, pagkatapos malutas ang bawat problema at pansamantalang na-stabilize ang site, pinag-aralan ng team ang mga insidente mula sa isang SRE point of view. Sinuri namin ang mga problema nang detalyado - ang mga sanhi ng paglitaw, ang pag-unlad ng pag-aalis. Pagkatapos noon, parehong team-by-team at sama-sama, gumawa kami ng mga desisyon kung paano higit na mapipigilan ang mga ito: kung paano pagbutihin ang pagsubaybay, kung paano matalinong baguhin ang arkitektura, kung paano ayusin ang diskarte sa pag-unlad at operasyon, kung paano itama ang mga regulasyon. Ipinakita ng mga tagapagsalita ang kasanayan sa pagsasagawa ng post-mortem.
“Sino pa ba ang gustong magpahirap! - ako!"
Ang mga tagumpay ng mga koponan ay mahigpit at malinaw na naitala sa electronic scoreboard.
Para sa mga unang lugar - isang bonus mula sa mga stakeholder.
Pinagmulan: www.habr.com