Наша команда любить експерименти. Кожен Сльорм – це не статичне повторення попередніх, а осмислення досвіду та перехід від доброго на краще. Але зі ми вирішили застосувати абсолютно новий формат — дати учасникам умови, які максимально наближені до «бойових».
Якщо коротко описати, чим ми займалися на інтенсивності: «Будуємо, ламаємо, чинимо,
вивчаємо». 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.
- Дорогі учасники, поспішаю вас порадувати, насамперед у вас падає ... все!
У ході справи спікери розбирали стійкість, error budget, практику тестування, управління перериваннями та операційним навантаженням.
Не кочегари ми, не теслярі.
Тут учасники почали лагодити – головне зрозуміти, за що хапатися першим.
«- Господи, я ніколи не бачив, щоб це ламалося так, у такому вигляді та в такій позі!»
Отже, сталась аварія. Сервіс обробки платежів ліг. Як діяти, щоб поновити працездатність у мінімальні терміни?
Експерти ласкаво поглядаючи на учасників, готують чергову каверзу.
Кожна команда організовує роботу групи з ліквідації аварії – включає колег, сповіщає інтересантів (stakeholders). Заодно вишиковуються пріоритети. Так учасники тренувалися працювати під тиском за умов гранично обмеженого часу.
- Це що за жах виліз?!
Видихнули... і закінчили вправу
Разом зі спікерами після кожної вирішеної проблеми та тимчасово стабілізованого сайту команди вивчала інциденти з точки зору SRE. Детально аналізували проблеми - причини виникнення, перебіг усунення. Після цього як покомандно, так і колективно ухвалювали рішення щодо їх подальшого запобігання: як покращити моніторинг, як грамотно змінити архітектуру, як відкоригувати підхід до розробки та експлуатації, як виправити регламенти. Спікери продемонстрували практику проведення post-mortem.
- Хто ще хоче мук! - Я!»
На електронному табло суворо та чітко фіксувалися успіхи команд.
За перші місця – премія від стейкхолдерів.
Джерело: habr.com