Наш прод пожрал долгоносик, Милорд

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

😏 Соскучились по офлайну? Встречаемся на DevOpsConf! 2 и 3 апреля приходите послушать доклады наших экспертов и пообщаться после выступлений: 🟢Автоматизируй это немедленно! Инциденты, когда на кону большие деньги. Дарья Попова, руководитель группы мониторинга и Алексей Глотов, руководитель группы разработки. 🟢SLO as a code — нельзя верить людям. Вячеслав Литкович, руководитель группы инженеров ИТ-инфраструктуры. 🟢Воркшоп «Observability: system design». Максим Бурцев, руководитель отдела мониторинга, и Кирилл Гриднев, инженер разработки автоматизаций внутренних процессов, будут консультировать команды и разбирать их решения в составе жюри. Ставьте 🔥, если идёте на конференцию или будете смотреть её онлайн!

Новых постов не будет, будет анонс очередной конфы 🤷‍♂️ Едем на DevOpsConf большой толпой, приходите на доклад и на воркшоп 🙂

Думали, я вам под ёлочку пост положу? Снова нет 🙂 Сделали из моего доклада на Highload статью на Хабр – https://habr.com/ru/companies/kuper/articles/979408/ Лайк, Шер, Алишер ❤️

Как превратить разбор инцидентов в источник инсайтов и улучшений? Почти каждый инцидент — это возможность сделать систему лучше. Пропустив разбор, вы рискуете столкнуться с той же проблемой снова. Postmortem помогает понять, что пошло не так, чего не хватило и как предотвратить сбой в будущем. 💭В новой статье Максим Бурцев, руководитель отдела мониторинга, рассказывает о нашем подходе к Postmortem, который помогает извлекать из инцидентов максимум пользы и менять инженерную культуру. 👉 Читайте на Хабре!

Оригинального контента для канала пока нет, но вот вам ссылка на Хабр 😃

🔥Как спать по ночам, не пропускать инциденты и писать постмортемы, которые работают. Максим Бурцев, руководитель отдела мониторинга в Купер.тех, делится практиками, которые упростили нам жизнь. Все фишки — в карточках ниже 💫

Нашелся повод оживить этот забытый канал — сделал небольшой пост для Купер.тех, приходите в комменты, ставьте лайки ❤️

Кажется, нет ни одного человека, который не слышал о вчерашнем массовом сбое Windows-устройств. А если вы вдруг не в курсе – погуглите, новостные издания пестрят заголовками. «Виновник торжества» обнаружился в соцсетях. Это был его первый рабочий день в CrowdStrike, он же стал и последним. Нашего любимого “blameless” не случилось – системного администратора уволили из-за ошибки в коде, которая привела к проблемам в авиасообщении, банковской сфере и целом списке других отраслей по всему миру. Эта история в очередной раз навела на мысль – а нужен ли тот самый “blameless”? Понятно, что есть ситуации, когда человек действительно не виновен, невозможно предусмотреть все, у всех должно быть право на ошибку. Но возможны сценарии, когда причина инцидента кроется в элементарной халатности: нарушении требований регламентов (которые, как и техника безопасности, зачастую тоже написаны кровью), игнорировании базовых принципов тестирования и, порой, даже здравого смысла. Так вот. Нужен ли абсолютный, безусловный “blameless”? Не приводит ли это к размыванию, или, даже, к полному отказу от личной ответственности за действия или бездействия? Можно дропнуть базу случайным кликом в веб-консоли (а подтверждения конечно же не предусмотрено), а можно выкатить непротестированные изменения. Точно ли в обеих ситуациях не виновен конкретный человек? Кстати, уволенный сотрудник CS – фейк, не переживайте. Хотя, кто знает, может действительного виновника и в самом деле уволили.

мама, я в телевизоре митап прошел, смотрите запись, задавайте вопросики первый опыт публичного выступления в качестве спикера на митапе/конференции, больно не бейте, пожалуйста https://www.youtube.com/watch?v=sJy6hT-WlBI

и немного спойлеров к моему докладу Каким критериям должен соответствовать качественный Action Item к проблеме: Action Item должен быть: 1. Actionable, то есть такой, который отражает действие, а не процесс. Задача должна отвечать на вопрос "что сделать", а не "что делать". "Не делай плохо, а хорошо – делай" – тоже антипример. Не стоит делать вывод "мы перестанем баги писать, чтобы инциденты не случались", лучше подумать о том, что именно нужно сделать, чтобы такие баги отловить на этапе тестирования. 2. Specific – то есть конкретный, определенный: Результат выполнения максимально точный – не "сделать хорошо", а "как именно сделать". Хороший пример такой задачи: "установить рейт-лимитер на Х рпс", а не "сделать рейтлимитер на эту ручку" 3. Bounded – то есть ограниченный, тот который имеет явный и понятный критерий выполнения. Не "добавить тестов в пайплайн", а "дополнить пайплайн автоматической проверкой на изменение схемы". Корректный вординг позволит избежать разночтений и гарантированно достичь ожидаемого результата. Есть живые примеры того, как неточность формулировок приводила к печальным последствиям: некорректно настроенный рейт-лимитер (на RPS вместо RPM) пропустил лавинную нагрузку на одну из ручек нашего апи, хотя инцидент был разобран и проблема закрыта за пару месяцев до повторения инцидента.