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

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

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

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

Проблеми, бъгове, грешки и задачи бяха предоставени на участниците от четирима ментори. Иван Круглов, главен разработчик в Booking.com (Холандия). Бен Тайлър, главен разработчик в Booking.com (САЩ). Едуард Медведев, технически директор в 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“ или „Долна граница ≤ SLI ≤ Upper Limit“.

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

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

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

„- Уважаеми участници, бързам да ви зарадвам, първото нещо, което проваляте, е... всичко!“

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

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

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

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

И така, стана инцидент. Услугата за обработка на плащания не работи. Как да действате, за да възстановите функционалността в най-кратки срокове?

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

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

„Какъв ужас излезе?!“

Издишайте... и завършете упражнението

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

„Кой друг иска мъки! - Аз!"

Успехите на отборите се записваха стриктно и ясно на електронното табло.

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

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