Slurm SRE. Комплетен експеримент со експерти од Booking.com и Google.com

Нашиот тим сака експерименти. Секој Slurm не е статично повторување на претходните, туку размислување за искуството и премин од добро кон подобро. Но со Slurm SRE решивме да примениме сосема нов формат - да им дадеме на учесниците услови што е можно поблиску до „борба“.

Ако накратко опишеме што направивме за време на интензивниот курс: „Градиме, кршиме, поправаме,
ние учиме“. SRE вреди малку само во теорија - само практика, вистински решенија, реални проблеми.

Учесниците беа поделени во тимови, така што енергичниот натпреварувачки дух не дозволува некој да заспие или да лансира „Angry Birds“ на iPhone, по примерот на Дмитриј Анатолиевич.

Проблеми, грешки, грешки и задачи на учесниците им даваа четворица ментори. Иван Круглов, главен програмер на Booking.com (Холандија). Бен Тајлер, главен програмер на Booking.com (САД). Едуард Медведев, CTO во Tungsten Labs (Германија). Евгениј Варавва, генерален програмер во Google (Сан Франциско).

Покрај тоа, учесниците се поделени во тимови и се натпреваруваат едни со други. Интересно?

Иван, Бен, Едуард и Евгениј ги гледаат сиромашните учесници во Slurm SRE со љубезни ленинистички кривогледи пред почетокот на натпреварот.

Значи задачата:

Наши сме, ќе изградиме нов свет...

Постои веб-страница за агрегатор на билети за филм. Инцидентите се измислени од ментори во однапред сработено сценарио (иако никој не исклучува особено софистицирана и подмолна импровизација), перформансите на страницата се опишуваат со различни метрики. Проблемите можат да бидат многу различни: билетите за театарот Мулен Руж не се вчитуваат во базата на податоци; постери од филмови и изведби се вчитуваат во базата на податоци за повеќе од 10 секунди; описот на поединечен филм замрзнува; 0,1% од нарачките се веќе резервирани; Од време на време, системот за обработка на плаќања паѓа на минута или две. И многу, многу, многу непријатни работи што може да го снајдат учесник во Slurm SRE на неговата вистинска работа.

Подготвени сме да се справиме со се...и со секого.

Нашата долготрпелива веб-страница се состои од неколку микроуслуги. Неговата задача е да собира податоци за емисиите, цените и достапните седишта од сите кина. Во принцип, сè за што гледачот може само да сонува. Но, корисникот не се ни сомнева каква титанска борба за стабилност и пристапност на страницата се води внатре.

За интензивната локација, генериравме индикатори SLO, SLI, SLA, развивме архитектура и инфраструктура, ја распоредивме страницата, поставивме мониторинг и предупредување. И одиме далеку.

SLO, SLI, SLA

SLI - индикатори за ниво на услуга. SLO се цели на ниво на услуга. SLA - договори за ниво на услуга.

SLA е ITIL методолошки термин кој означува формален договор помеѓу клиентот на услугата и неговиот добавувач, кој содржи опис на услугата, правата и обврските на страните и што е најважно, договореното ниво на квалитет за обезбедување на оваа Сервис.

SLO е цел на ниво на услуга: целна вредност или опсег на вредности за ниво на услуга што се мери со SLI. Нормална вредност за SLO е „SLI ≤ Target“ или „Lower Limit ≤ SLI ≤ Upper Limit“.

SLI е индикатор за ниво на услуга - внимателно дефинирана квантитативна мерка на еден аспект од нивото на обезбедената услуга. За повеќето услуги, клучниот SLI се смета за латентност на барањето - колку време е потребно за да се врати одговор на барање. Други вообичаени SLI вклучуваат стапка на грешка, често изразена како дел од сите примени барања и пропусната моќ на системот, обично мерена во барања во секунда.

Најпрво ќе ги скршиме авионите, а потоа девојките, а потоа девојките ...

Внатрешните и надворешните фактори почнаа да го „расипуваат“ СЛО уште од првите минути. Сè падна врз главата на администраторите - грешки на програмерите, дефекти во инфраструктурата, прилив на посетители и DDoS напади. Сè што го влошува СЛО.

„- Драги учесници, побрзам да ве задоволам, првото нешто што не успевате е... сè!

Попатно, говорниците разговараа за стабилноста, буџетот за грешки, практиката на тестирање, управувањето со прекини и оперативното оптоварување.

Ние не сме столари, не столари...

Тогаш учесниците почнаа да ги поправаат работите - главната работа е да разберат што прво да зграпчат.

„- Господи, никогаш не сум видел да се скрши вака, во оваа форма и во таква положба!

Значи, се случи несреќа. Услугата за обработка на плаќања е во прекин. Како да дејствувате за да ја вратите функционалноста во најкус можен рок?

Експертите, гледајќи со приврзаност кон учесниците, подготвуваат уште еден трик.

Секој тим ја организира работата на групата за елиминирање на несреќата - вклучува колеги, ги известува заинтересираните страни (засегнати страни). Во исто време се поставуваат приоритети. На овој начин учесниците тренираа да работат под притисок под исклучително ограничени временски услови.

„Каков хорор излезе?!“

Издишете... и завршете ја вежбата

Заедно со звучниците, откако секој проблем беше решен и локацијата беше привремено стабилизирана, тимот ги проучуваше инцидентите од гледна точка на SRE. Детално ги анализиравме проблемите - причините за нивното настанување, напредокот на елиминацијата. После тоа, тим по тим и колективно, донесовме одлуки како понатаму да ги спречиме: како да го подобриме мониторингот, како мудро да ја промениме архитектурата, како да го прилагодиме пристапот кон развојот и работењето, како да ги исправиме регулативите. Говорниците ја демонстрираа практиката на спроведување посмрт.

„Кој друг сака маки! - Јас!"

Успесите на тимовите беа строго и јасно запишани на електронската табла.

За први места - бонус од засегнатите страни.

Извор: www.habr.com