🥇Слёрм SRE. Сплошной эксперимент c экспертами из 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.

«- Дорогие участники, спешу вас порадовать, первым делом у вас падает… всё!»

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

Не кочегары мы, не плотники…

Тут участники начали чинить — главное понять, за что хвататься первым.

«- Господи, я никогда не видел, чтобы это ломалось так, в таком виде и в такой позе!»

Итак, произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?

Эксперты ласково поглядывая на участников готовят очередную каверзу.

Каждая команда организует работу группы по ликвидации аварии — подключает коллег, оповещает интересантов (stakeholders). Заодно выстраиваются приоритеты. Так участники тренировались работать под давлением в условиях предельно ограниченного времени.

«- Это что за ужас вылез?!»

Выдохнули… и закончили упражнение

Вместе со спикерами после каждой решённой проблемы и временно стабилизированного сайта команды изучала инциденты с точки зрение SRE. Детально анализировали проблемы — причины возникновения, ход устранения. После этого как покомандно, так и коллективно принимали решение по их дальнейшему предотвращению: как улучшить мониторинг, как грамотно изменить архитектуру, как откорректировать подход к разработке и эксплуатации, как исправить регламенты. Спикеры продемонстрировали практику проведения post-mortem.

«- Кто ещё хочет мучений! — Я!»