В попытках скоротать время в пути домой с DevOpsConf 2026 (а 4 часа в сидячем вагоне – это вам не шутки) я внезапно вспомнил, что у меня есть канал, в который надо бы что-то иногда писать, так что вот там поток сознания от докладчика конференции.
Роль "докладчика" на этой конференции была для меня весьма условной в этом году, доклада у меня не было (но скоро будет, ждите анонс), я поучаствовал в одном из воркшопов в качестве эксперта (я – эксперт, сам не верю) и члена жюри. Отдельное спасибо Кириллу и Денису за приглашение, это первый подобный опыт для меня и сразу такая удача: крупнейшая конференция, крутая команда, необычный формат. Еще и попал на доклады к ребятам из своей команды – а они невероятно классные, обязательно поделюсь с вами записью их выступлений.
Немного контекста о воркшопе: Пять команд, каждой достался свой кейс для работы в группе – описание некого высоконагруженного сервиса, его архитектуры, требований SLA и сценарий инцидента. За 30 минут командам предстояло спроектировать систему наблюдаемости своего продукта: описать метрики, логи, трейсы и SLO для сервисов, придумать алерты и дашборды. Каждому столу дали по 5 минут на презентацию и защиту своего решения, затем оценка от соперников и экспертного жюри. Нашей задачей, как экспертов, стала фасилитация обсуждения – мы помогали участникам, направляя их в нужную сторону, не давая растекаться мыслью по древу и углубляться в лишние детали.
Пять команд – пять
сервисов – пять непохожих друг на друга решений, но все очень сильные, мы с коллегами из жюри остались очень довольны результатом, стабильность продакшена в надежных руках.
Но я выделил для себя несколько моментов, в которых далеко не все команды оказались близки к моему представлению об эталонном решении (может быть и в силу ограничения во времени, а может и нет).
Решение каждого стола было очень подробным с технической стороны: стек технологий и решений, осуществляющих наблюдаемость и мониторинг, все участники описали супер подробно, тут вопросов никаких. Но на мой скромный экспертный взгляд, мало кто подумал о реальном процессе мониторинга и реагирования.
Наблюдаемость – это свойство системы, его характеристика. Мониторинг – это процесс обеспечения непрерывности этой системы, основанный в первую очередь на реагировании на сигналы и события от ваших систем наблюдаемости.
Помимо того, что ваши сервисы и продукты должны быть наблюдаемыми, необходимо чётко понимать, как именно и кто будет реагировать на сбои, которые только предполагаются или уже происходят.
Кто будет вашей аварийной командой? Кто должен реагировать на алерты разных приоритетов, в какой срок? И как вообще приоритизировать эти алерты? Какие инструменты помогут вашей аварийной команде оперативно определить причину сбоя и восстановить сервис за считанные минуты? Одно дело быстро понять, что вашему продукту уже дурно (или вот-вот ему станет хуже: надо бы учиться предотвращать пожары, а не тушить).
SRE – это, в первую очередь, про людей и процесс, про культуру, а не про технологию. Вы можете нарисовать десятки дашбордов и сотни алертов, но какой в них толк, если их никто не увидит вовремя и они не помогут вам быстро докопаться до сути проблемы.