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

Нашият екип обича експериментите. Всеки Слёрм не е статично повторение на предишните, а осмисляне на опита и преминаване от добро към по-добро. Но с Слёрма SRE решихме да приложим напълно нов формат — да предложим на участниците условия, максимално близки до „бойните“.

Ако накратко опишем какво правихме на интензивното: „Строим, чупим, поправяме,
изучаваме“. SRE не струва почти нищо в голата теория — само практика, реални решения, реални проблеми.

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

Проблеми, глюкове, бъгове и задачи осигуриха на участниците четирима ментори. Иван Круглов, главен разработчик в Booking.com (Нидерландия). Бен Тайлер, главен разработчик в Booking.com (САЩ). Едуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варава, разработчик с широк профил в Google (Сан Франциско).

И освен това участниците са разделени на отбори и се състезават помежду си. Интересно ли е?

Иван, Бен, Едуард и Евгений с добро ленинско присмехулство гледат на бедните участници на Слёрм SRE преди началото на състезанието.

И така, задачата:

Ние ще построим нашия, наш нов свят…

Има сайт агрегатор на билети за кино. Инцидентите се измислят от менторите по предварително разработен сценарий (въпреки че никой не изключва особено изкусна и коварна импровизация), работоспособността на сайта се описва с различни метрики. Проблемите могат да бъдат най-разнообразни: билетите за театър „Мулен Руж“ не се зареждат в базата; постерите на филмите и спектаклите зареждат в базата за повече от 10 секунди; описанието на отделен филм закъснява; 0,1% от поръчките попадат на вече резервирани места; периодично накрая системата за обработка на плащанията спира за една-две минути. И много, много, много неприятни неща, които могат да се стоварят на участника на Слёрма SRE на неговата реална работа.

Готови сме да се справим с всичко… и с всички.

Нашият многостранен сайт се състои от няколко микросервиза. Неговата задача е агрегацията на данни за сеанси, цени и свободни места от всички кина, показва анонси на филми, позволява избор на кино, сеанс, зала и място, а също така да резервирате и заплатите билетите. Всичко, за което зрителят може да мечтае. Но потребителят дори не подозира каква титанична борба за стабилност и достъпност на сайта се води вътре.

За сайта по време на интензивния курс формулирахме показатели SLO, SLI, SLA, разработихме архитектура и инфраструктура, внедрихме сайта, настроихме мониторинг и алертиране. И започна всичко.

SLO, SLI, SLA

SLI — индикатори за ниво на обслужване. SLO — цели за ниво на обслужване. SLA — споразумения за ниво на обслужване.

SLA е термин от методологията ITIL, обозначаващ формален договор между клиента на услугата и нейния доставчик, съдържащ описание на услугата, права и задължения на страните и, най-важното, предварително уговорено ниво на качество на предоставянето на услугата.

SLO е цел за ниво на обслужване: целево значение или диапазон от стойности за ниво на обслужване, измервано с SLI. Нормалната стойност за SLO е «SLI ≤ целева стойност» или «долна граница ≤ SLI ≤ горна граница».

SLI е индикатор за ниво на обслужване — точно определена количествена мярка за един от аспектите на предоставяното ниво на обслужване. За повечето услуги ключов SLI е забавянето на запитването — колко време е необходимо за връщане на отговора на запитването. Други разпространени SLI включват честотата на грешки, често изразявана като дял от всички получени запитвания, и пропускната способност на системата, обикновено измервана в запитвания в секунда.

Първо, ще разбием самолетите, а за момичетата, а за момичетата след това...

Вътрешни и външни фактори от самото начало започнаха да "развалят" SLO. На администраторите се стовариха всичко — и грешки на разработчиците, и откази на инфраструктурата, и наплив на посетители, и DDoS атаки. Всичко, което влошава SLO.

"- Скъпи участници, бързам да ви зарадвам, първо, всичко ви пада..."

По време на събитието лекторите разглеждаха устойчивост, budget за грешки, практика за тестване, управление на прекъсвания и операционна натовареност.

Не сме котли, не сме дърводелци...

Тук участниците започнаха да поправят — най-важното е да разберете откъде да започнете.

„- Господи, никога не съм виждал това да се счупва по такъв начин и в такава поза!”

И така, настъпи авария. Системата за обработка на плащания е паднала. Как да действате, за да възстановите работоспособността в най-кратки срокове?

Експертите, внимателно наблюдавайки участниците, подготвят поредната каприз.

Всяка екип организира работата на групата за ликвидиране на аварията — включва колеги, уведомява заинтересованите. Също така се определят приоритетите. Така участниците тренираха как да работят под напрежение при крайно ограничено време.

„- Какво е това ужасяващо нещо?!”

Поехте дъх… и завършихте упражнението.

Заедно със спикерите след всяка решена проблема и временно стабилизирания сайт, отборите изучаваха инцидентите от гледна точка на SRE. Детайлно анализираха проблемите — причините за възникването им, хода на отстраняването. След това, както поотделно, така и колективно, вземаха решение за тяхното по-нататъшно предотвратяване: как да подобрят мониторинга, как да променят архитектурата, как да коригират подхода към разработката и експлоатацията, как да поправят регламентите. Спикерите демонстрираха практиката на post-mortem.

„- Кой още иска мъки! — Аз!”

На електронната табла строго и ясно се фиксираха успехите на отборите.

За първите места — награда от заинтересованите лица.

Източник: habr.com