12 ноября в «Слёрме» начнётся интенсив по SRE. На три полных дня участники погрузятся в теорию и практику поддержки высоконагруженных сервисов. Никаких задач по работе, никаких семейных дел — только учёба. Под катом рассказываем, что вас ждёт, если решите присоединиться.
«SRE — это не столько про алертинг и постмортемы. Это про то, чтобы до продакшена не доходил код, который ночью подрывает».
Кейс 1: downstream-зависимость. В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down. Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.
Кейс 2: upstream-зависимость. Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой. В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Кейс 3: проблемы с окружением и правильный Healthcheck. Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему, чтобы пользователи не столкнулись с проблемой. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении. Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
Кейс 4: проблемы с БД. База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно. Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.
Кейс 5: traffic shielding. Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана. Блокируя избыточный трафик, вы сохраните возможность системы выполнять задачи для части пользователей.
Кейс 6: проблемы с кодом. Как бы хорошо новые фичи не работали на стейджинге,
всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад. Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.