Веб-версияОткрыть в Telegram

ПостДавно не касался темы инцидентов и постмортемов.

8 июля 2026
D
DDDevotion
Давно не касался темы инцидентов и постмортемов. SRE Book вышла уже 10 лет назад, и может показаться, что тема давно полностью раскрыта. Но я всё равно позволю себе небольшой рекап. Хороший постмортем, на мой взгляд, держится на двух вопросах: 1. Как снизить вероятность повторения инцидента? 2. Как раньше заметить, что в системе происходит что-то нездоровое? И я часто вижу в обсуждениях сильный перекос в сторону первого вопроса. После инцидента команда часто приходит к выводам вроде: * надо лучше тестировать; * надо больше автотестов; * надо строже линтеры; * надо внимательнее ревьюить; * надо писать только хороший код и т. д. Все это правильно. Более того, чаще всего это действительно нужно. Но важно помнить две вещи. Во-первых, вероятность инцидента невозможно увести в ноль. Во-вторых, каждая следующая “девятка” надежности может стоить непропорционально дорого. Переход от 0.9 к 0.99, от 0.999 к 0.9999 и так далее в какой-то момент может оказаться экономически не оправдан. И если мы не можем или не хотим полностью предотвратить инцидент, остается другой путь: снижать ущерб. А ущерб во многом определяется длительностью инцидента. Чем раньше мы увидели проблему, чем быстрее поняли масштаб, источник и влияние на пользователей, тем быстрее можем среагировать. Именно здесь появляется observability. Поэтому в хорошем постмортеме, кроме обсуждения “как не допустить повторения”, обязательно должен быть отдельный разговор: * как сработали наши сигналы; * увидели ли мы проблему достаточно рано; * были ли понятны симптомы; * хватило ли метрик, логов, трейсов и алертов; * помогли ли дашборды принять решение; * где была слепая зона; * какой процесс обнаружения или эскалации не сработал. Пожалуй, главное изменение за эти 10 лет в том, что часть этой работы теперь можно делегировать агентам. А значит, observability нужно проектировать не только для человека, но и для агента, который будет собирать контекст, искать аномалии и помогать с диагностикой. То есть добавляем ещё один вопрос в наш постмортем: что агенты увидели в наших сигналах, что пропустили и какого контекста им не хватило, чтобы раньше поднять тревогу и помочь с расследованием?
25 · 3K ·

Рядом в ленте

DDDDevotionИнтересный взгляд на агентскую разработку через DDD-призму. А как вы работаете с агентами? Знает ли ваш агент, с каким доменом он сейчас работает? Понимает ли, DDDDevotionВышел LeadDev Engineering Leadership Report 2026 Как же быстро ИИ в разработке прошел путь от “давайте попробуем” до обычной управленческой повестки. В отчете х
это сообщение
DDDDevotionИногда наше бизнес-правило может выглядеть так: if (this.Total > 100) Мы точно знаем, как получить результат. Но понимаем ли мы, что означают эти 100 и какое реDDDDevotionЗаписываем в календарики Когда: завтра, во вторник 16:00 мск Что: стрим Александра Поломодова и Максима Смирнова с обсуждением Engineering loop https://www.yout
DDDDevotionDDDevotion@dddevotion · канал · Технологии
4 436подписчиков445постов в индексе
Лента площадки Открыть в Telegram

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем