Наша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом 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, разработали архитектуру и инфраструктуру, задеплоили сайт, настроили мониторинг и алертинг. И понеслось.
SLI — индикаторы уровня обслуживания. SLO — цели уровня обслуживания. SLA — соглашения об уровне обслуживания.
SLA — термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.
SLO — это цель уровня обслуживания: целевое значение или диапазон значений для уровня обслуживания, который измеряется SLI. Нормальным значением для SLO является «SLI ≤ целевого значения» или «нижняя граница ≤ SLI ≤ верхняя граница».
SLI является индикатором уровня обслуживания — тщательно определенной количественной мерой одного из аспектов предоставляемого уровня обслуживания. Для большинства сервисов в качестве ключевого SLI считают задержку запроса — сколько времени требуется для возврата ответа на запрос. Другие распространенные SLI включают частоту ошибок, часто выражаемую как долю всех полученных запросов, и пропускную способность системы, обычно измеряемую в запросах в секунду.
Первым делом мы сломаем самолёты, ну а девушек, а девушек потом...
Внутренние и внешние факторы с первых же минут начали «портить» SLO. Свалилось на голову админам всё — и ошибки разработчиков, и отказы инфраструктуры, и наплыв посетителей, и DDoS-атаки. Всё то, что ухудшает SLO.
«- Дорогие участники, спешу вас порадовать, первым делом у вас падает… всё!»
По ходу дела спикеры разбирали устойчивость, error budget, практику тестирования, управление прерываниями и операционной нагрузкой.
Не кочегары мы, не плотники...
Тут участники начали чинить — главное понять, за что хвататься первым.
«- Господи, я никогда не видел, чтобы это ломалось так, в таком виде и в такой позе!»
Итак, произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?
Эксперты ласково поглядывая на участников готовят очередную каверзу.
Каждая команда организует работу группы по ликвидации аварии — подключает коллег, оповещает интересантов (stakeholders). Заодно выстраиваются приоритеты. Так участники тренировались работать под давлением в условиях предельно ограниченного времени.
«- Это что за ужас вылез?!»
Выдохнули… и закончили упражнение
Вместе со спикерами после каждой решённой проблемы и временно стабилизированного сайта команды изучала инциденты с точки зрение SRE. Детально анализировали проблемы — причины возникновения, ход устранения. После этого как покомандно, так и коллективно принимали решение по их дальнейшему предотвращению: как улучшить мониторинг, как грамотно изменить архитектуру, как откорректировать подход к разработке и эксплуатации, как исправить регламенты. Спикеры продемонстрировали практику проведения post-mortem.
«- Кто ещё хочет мучений! — Я!»
На электронном табло строго и чётко фиксировались успехи команд.
За первые места — премия от стейкхолдеров.
