Расследование, которое можно повторить
День практики для инженеров. В командах разбираем инциденты и превращаем диагноз в правило, которое можно запустить и проверить.
Пять инженеров смотрят одни данные
и выдают пять версий
Диагноз существует только словами. «Задержка большая», «часто ретраится» — у каждого своё «большая», и проверить некому: утверждение нельзя запустить. Поэтому спор закрывает авторитет, знание уходит вместе с инженером, а один и тот же сбой расследуют заново.
Если узнали хотя бы два пункта — это ваш воркшоп.
Источники: 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 минПредставление решений и разбор
Практика: каждая группа за пять минут рассказывает, какую проблему расследует, какие свидетельства считает достаточными, какое правило предлагает, как проверяет ложные срабатывания и чего правило не доказывает.
Разбор: остальные участники выступают независимыми проверяющими и задают вопросы по чек-листу.
Чем это отличается от того,
что вы уже делаете
Хранить правила в репозитории и тестировать алерты — уже норма. Мы этого не изобретали. Отличие в трёх вещах.
Работаем с тем, чего не произошло, так же строго. В сложных сбоях это и есть ключ.
Половина практики — не «сработало на аварии», а «не сработало на похожей». Негативные тесты с первой минуты.
Раздел «чего правило НЕ доказывает» — обязательная часть артефакта. Защита от главной ошибки: принять корреляцию за доказательство.
Как устроен день
Семь блоков по 40–45 минут. В каждом ведущий коротко объясняет метод, команда работает руками, потом общий разбор результата.
Работаете не в одиночку: группа делится на команды по 3–5 человек. Внутри команды распределяются роли — кто держит границы доказательств, кто пишет правило, кто ищет ложные срабатывания, кто представляет результат. Финал дня — короткие питчи и вопросы от соседних команд.
Что команда соберёт
Всё это делается на своей задаче в шестом блоке и защищается в седьмом.
Кто ведёт
Александр Лошкарев
Техлид Eltex · 15+ лет в телекоме
Разрабатывал ПО для спутниковой связи — там цена непроверенной гипотезы высока, а сбой часто выглядит как молчание: нет ответа, не дошёл пакет, нет подтверждения.
Сейчас проектирует сервисы управления радиоресурсами, траблшутинга и радиопланирования. В таких системах «кажется, задержка большая» и «часто ретраится» не работают как аргументы — нужны правила с порогами, единицами и явным списком того, чего они не доказывают.
Был тренером по телеком-технологиям в Nokia и Huawei: учил инженеров искать причину, а не назначать виноватого. Преподаёт в СибГУТИ, выступает на конференциях.
Коротко о важном
Придётся писать код?
Не прикладной. Правила на 10–20 строк, по форме ближе к YAML. Знание языка не требуется.
Что взять с собой?
Ноутбук, можно один на команду. Интернет и софт не нужны. Полезно описание своей нерешённой проблемы.
Можно принести свой инцидент?
Да. Без реальных логов и имён клиентов — только описание симптомов. Если своего нет, ведущий выдаст кейс.
Это только про сети?
Нет. В кейсах отказ микросервиса, потеря записей в ETL, подбор паролей, нарушение SLA. Методика работает везде, где виновника ищут спором.
Вы утверждаете, что причина одна?
Нет. Отказ обычно требует нескольких совпавших условий. Правило формулируется не как «виноват X», а как проверяемое утверждение — и что оно не доказывает.
Чем это отличается от AI-инструментов?
Формализация предшествует автоматизации. На реальных отказах модели решают около трети случаев, в остальных уверенно достраивают версию. AI бесполезен там, где знание не записано однозначно.
Расследование, которое переживёт
увольнение автора
11 сентября 2026, Томск. Группа 18–20 человек, максимум 24.