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

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

Ако накратко опишем с какво се занимавахме на интензивната сесия: "Строим, разчупваме, поправяме,
изучаваме". SRE има малка стойност в голата теория – само практиката, реалните решения, реалните проблеми.

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

Проблемите, бъговете и задачите бяха осигурени от четирима ментора. Иван Круглов, Principal Developer в Booking.com (Нидерландия). Бен Тайлер, Principal Developer в 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.

„- Скъпи участници, искам да ви зарадвам, първото, което пада, е… всичко!“

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

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

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

«- Господи, никога не бях виждал нещо да се чупи по този начин, в тази форма и поза!»

Е, случи се злополука. Платежната услуга отказа. Как да действаме, за да възстановим функционалността в най-кратки срокове?

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

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

«- Какво е това ужасно нещо?!»

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

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

«- Кой още иска мъки!? — Аз!»

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

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

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