TGViewer
DDDevotion DDDevotion @dddevotion · 4.44K subscribers
Post #461 3.02K
Давно не касался темы инцидентов и постмортемов.

SRE Book вышла уже 10 лет назад, и может показаться, что тема давно полностью раскрыта. Но я всё равно позволю себе небольшой рекап.

Хороший постмортем, на мой взгляд, держится на двух вопросах:

1. Как снизить вероятность повторения инцидента?
2. Как раньше заметить, что в системе происходит что-то нездоровое?

И я часто вижу в обсуждениях сильный перекос в сторону первого вопроса.

После инцидента команда часто приходит к выводам вроде:

* надо лучше тестировать;
* надо больше автотестов;
* надо строже линтеры;
* надо внимательнее ревьюить;
* надо писать только хороший код и т. д.

Все это правильно. Более того, чаще всего это действительно нужно.

Но важно помнить две вещи.

Во-первых, вероятность инцидента невозможно увести в ноль.

Во-вторых, каждая следующая “девятка” надежности может стоить непропорционально дорого. Переход от 0.9 к 0.99, от 0.999 к 0.9999 и так далее в какой-то момент может оказаться экономически не оправдан.

И если мы не можем или не хотим полностью предотвратить инцидент, остается другой путь: снижать ущерб.

А ущерб во многом определяется длительностью инцидента.

Чем раньше мы увидели проблему, чем быстрее поняли масштаб, источник и влияние на пользователей, тем быстрее можем среагировать.

Именно здесь появляется observability.

Поэтому в хорошем постмортеме, кроме обсуждения “как не допустить повторения”, обязательно должен быть отдельный разговор:

* как сработали наши сигналы;
* увидели ли мы проблему достаточно рано;
* были ли понятны симптомы;
* хватило ли метрик, логов, трейсов и алертов;
* помогли ли дашборды принять решение;
* где была слепая зона;
* какой процесс обнаружения или эскалации не сработал.

Пожалуй, главное изменение за эти 10 лет в том, что часть этой работы теперь можно делегировать агентам.

А значит, observability нужно проектировать не только для человека, но и для агента, который будет собирать контекст, искать аномалии и помогать с диагностикой.

То есть добавляем ещё один вопрос в наш постмортем: что агенты увидели в наших сигналах, что пропустили и какого контекста им не хватило, чтобы раньше поднять тревогу и помочь с расследованием?
  • 👏 14
  • 👍 11
  • 🔥 5
  • ❤ 2
More from @dddevotion
  1. Aug 19, 2026Вижу в индустрии два подхода к внедрению ai разработки. Понятно, что это спектр, но в цело…
  2. Jul 13, 2026Записываем в календарики Когда: завтра, во вторник 16:00 мск Что: стрим Александра Поломод…
  3. Jul 10, 2026Иногда наше бизнес-правило может выглядеть так: if (this.Total > 100) Мы точно знаем, как…
  4. Jun 12, 2026Вышел LeadDev Engineering Leadership Report 2026 Как же быстро ИИ в разработке прошел путь…
  5. Jun 9, 2026Интересный взгляд на агентскую разработку через DDD-призму. А как вы работаете с агентами?…
  6. May 28, 2026Такое мы смотрим https://www.youtube.com/watch?v=K-Xv8D8NjTk Я как дотнетчик со стажем нач…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →