Расследование, которое можно повторить
Превращаем спор «это сеть или код?» в короткое правило, которое одинаково прочитают инженер, CI и AI-агент.
# свидетельство: то, что произошло when tcp.retransmit_rate > 0.05 for 30s # свидетельство: то, чего НЕ произошло and icmp.frag_needed absent within 30s then verdict = "path MTU blackhole" # правило обязано молчать здесь not_when wifi.channel_utilization > 0.7 # чего это НЕ доказывает limits: "не указывает на конкретный узел"
Пять инженеров смотрят одни данные
и выдают пять версий
Спор решается авторитетом, а не данными: диагноз живёт как текст и мнение, а не как проверяемый артефакт.
Источники: Google, «The State of Continuous Integration Testing» (84% и 16%); SANS Detection & Response Survey 2025 (73%).
И почти всегда упускают главное: сложные сбои проявляются как молчание — неответ, недошедший пакет, отсутствующее подтверждение.
Семь блоков по 40–45 минут
Каждый блок: короткое объяснение → практика в команде → разбор результата. Разбор идёт на базе сервиса для анализа сетевых проблем — он используется как пример архитектурных решений, а не как предмет изучения.
блок 01 · 40–45 минКак проводить инженерное расследование
Разбираем: чем наблюдение отличается от вывода; как формулировать проверяемую гипотезу; почему совпадение во времени не доказывает причину; как работать с неполными данными и искать альтернативные объяснения.
Практика: группа получает описание инцидента и делит утверждения на наблюдаемые факты, вычисленные признаки, гипотезы и решения, требующие проверки.
Результат: карта свидетельств и гипотез.
блок 02 · 40–45 минКак превратить экспертное знание в правило
Разбираем: разделение сбора событий, вычисления признаков и принятия решения; модель «наблюдение → причина → проблема»; явные пороги и интервалы; единицы измерения и округление; обработка неизвестных значений.
Практика: на примере сетевого сбоя разбираем логику, а затем каждая группа описывает аналогичное правило для своей области — журнала приложения, контроля платежа или отказа службы.
Результат: паспорт диагностического правила.
блок 03 · 40–45 минКак спроектировать границы между компонентами
Разбираем: почему обработчик входных данных не должен принимать итоговое решение; роль адаптера между измерениями и правилами; каталог событий и типизированные поля; единый формат результата; отделение диагностической логики от представления и доставки.
Практика: группа рисует границы пяти компонентов — источник данных, обработчик, нормализованные события, механизм правил, отчёт и интеграции.
Результат: схема взаимодействия компонентов и перечень контрактов.
блок 04 · 40–45 минКак переносить правила без потери поведения
Разбираем: сравнительные тесты старого и нового обработчиков; эталонные наборы; искусственные и реальные данные; категории расхождений; почему исчезнувший результат опасно считать улучшением.
Практика: группа получает результаты двух версий системы и классифицирует расхождения как совпадение, намеренное изменение, регрессию или недостаточность данных. Каждое «намеренное изменение» нужно обосновать.
Результат: таблица решений по расхождениям и перечень допустимых изменений.
блок 05 · 40–45 минКак строить убедительную проверку качества
Разбираем: что именно доказывает каждый вид теста; почему сто процентов пройденных тестов не означают ста процентов точности; отрицательные и граничные случаи; устойчивость к повреждённому входу; разница между отсутствием ошибки и доказательством корректности.
Практика: группа собирает набор проверок для своего правила — обычный случай, нижняя и верхняя границы, отсутствие обязательного события, противоречивые события, неполный вход, заведомо ложный сценарий.
Результат: минимальная стратегия проверки правила.
блок 06 · 40–45 минПеренос метода в собственный проект
Практика: группа выбирает свою задачу — отказ службы, подозрительная последовательность действий пользователя, нарушение договорённости между системами, ошибка обработки данных или сетевой инцидент.
Результат: карта свидетельств, возможные объяснения, одно формализованное правило, набор тестов, критерии выпуска и список ограничений.
блок 07 · 40–45 минПредставление решений и разбор
Практика: каждая группа за пять минут рассказывает, какую проблему расследует, какие свидетельства считает достаточными, какое правило предлагает, как проверяет ложные срабатывания и чего правило не доказывает.
Разбор: остальные участники выступают независимыми проверяющими и задают вопросы по чек-листу.
Чего нет в массовой практике
«Правила как код» — уже стандарт: в Prometheus есть юнит-тесты алертов. Отличие в трёх вещах.
Работаем с тем, чего не произошло, так же строго. В сложных сбоях это и есть ключ.
Половина практики — не «сработало на аварии», а «не сработало на похожей». Негативные тесты с первой минуты.
Раздел «чего правило НЕ доказывает» — обязательная часть артефакта. Защита от главной ошибки: принять корреляцию за доказательство.
Для кого воркшоп
Подойдёт
- Backend-разработчикам
- Техлидам и архитекторам
- QA-инженерам
- Специалистам по эксплуатации
- Инженерам распределённых систем
Не подойдёт
- BI- и продуктовым аналитикам
- Тем, у кого нет инженерной практики
- Тем, кто ждёт готовый инструмент вместо методики
Полезно, если помните инцидент, который так и не объяснили, или тикет «не воспроизводится».
Команды с фиксированными ролями
Не соревнование: ошибочная гипотеза ценна, если команда объясняет логику выводов.
Что команда соберёт
Всё это делается на своей задаче в шестом блоке и защищается в седьмом.
Три шага в первый рабочий день
Занимает около часа. План участник фиксирует на финале.
Кто ведёт
ИМЯ ВЕДУЩЕГО
ДОЛЖНОСТЬ И КОМПАНИЯ
Краткая биография: сколько лет в практике, какие системы разбирал.
Коротко о важном
Придётся писать код?
Не прикладной. Правила на 10–20 строк, по форме ближе к YAML. Знание языка не требуется.
Что взять с собой?
Ноутбук, можно один на команду. Интернет и софт не нужны. Полезно описание своей нерешённой проблемы.
Можно принести свой инцидент?
Да. Без реальных логов и имён клиентов — только описание симптомов. Если своего нет, ведущий выдаст кейс.
Это только про сети?
Нет. В кейсах отказ микросервиса, потеря записей в ETL, подбор паролей, нарушение SLA. Методика работает везде, где виновника ищут спором.
Вы утверждаете, что причина одна?
Нет. Отказ обычно требует нескольких совпавших условий. Правило формулируется не как «виноват X», а как проверяемое утверждение — и что оно не доказывает.
Чем это отличается от AI-инструментов?
Формализация предшествует автоматизации. На реальных отказах модели решают около трети случаев, в остальных уверенно достраивают версию. AI бесполезен там, где знание не записано однозначно.
Расследование, которое переживёт
увольнение автора
11 сентября 2026, Томск. Группа 18–20 человек, максимум 24.