Техношоу «Дропнуто»: выпуск 1
Прямой эфир с честным postmortem-разбором двухнедельного инцидента в data-платформе: от первопричины до архитектурного разворота и организационных выводов.
Источник
Telegram: book_cube
Оригинальный обзор выпуска с акцентом на SRE-практики и управленческие выводы.
Контекст выпуска
Выпуск выдержан в духе blameless postmortems: фокус на причинах, механике отказа и изменениях в архитектуре/процессах, а не на персональных обвинениях. Это делает выпуск полезным как для инженеров, так и для руководителей, которым нужен общий язык надежности.
Гость и фокус экспертизы
Александр Крашенинников
- Практик в области платформ данных, ETL и DWH.
- Гость первого выпуска, рассказывающий о реальном двухнедельном инциденте.
- Акцент на инженерных и организационных выводах после восстановления сервиса.
Цепочка инцидента
Потеря метаданных и деградация чтения
Удаление/потеря метаданных привела к сбоям в Trino и каскадной деградации потребителей данных.
Ограничения восстановления
Бэкапа в нужной точке не оказалось, а восстановление через CDC происходило медленно и не перекрывало потребность бизнеса.
Критический инцидент и смена подхода
Команда перешла к новой Kafka-архитектуре с контрактами, унификацией схем и параллельными загрузками.
Валидация, ремонт расхождений и recovery
Далее - сверка данных, исправление несоответствий, частичное восстановление сервиса и дозагрузка исторических данных из резервов.
Связанная глава
Data Pipeline / ETL / ELT Architecture
Проектирование пайплайнов: orchestration, recovery и качество данных.
Что важно инженерам
- CDC-конвейеры удобны в эксплуатации, но требуют заранее продуманных сценариев восстановления и проверки целостности.
- Outbox-подход снижает риск потери событий между сервисами, но не заменяет дисциплину по схемам и версиям контрактов.
- Контракты данных и унификация схем критичны для устойчивости ETL/DWH-контуров при аварийном переключении.
- Для pipeline-надежности важна отдельная observability для коннекторов, лагов и сбоев репликации.
Primary source
Google SRE: Postmortem Culture
Базовые принципы blameless-культуры и обучения на сбоях.
Управленческая оптика
- Blameless postmortem снижает внутреннюю турбулентность и ускоряет переход к системным улучшениям вместо поиска виноватых.
- Единый язык риска (severity, error budget, release freeze) помогает синхронизировать ожидания бизнеса и инженерии.
- SLO для данных нужно формулировать в пользовательских терминах, а затем приземлять в технические метрики и алерты.
- Инцидент в data-платформе - это не только технологический сбой, но и управленческий сигнал о зрелости процессов.
Primary source
Google SRE Workbook: Implementing SLOs
Как приземлять пользовательские ожидания в измеримые цели и алертинг.
SLI/SLO для data-платформы
Скорость данных
freshness, end-to-end latency, consumer lag
Целостность
дубликаты, пропуски, расхождения по контрольным выборкам
Устойчивость коннекторов
error rate, restart rate, время восстановления
Пример пользовательского SLO: «данные в витрине свежи не старше X минут в 99.9% времени», после чего цель раскладывается в алерты и план/факт по риску.
Ссылки и связанные главы
YouTube: «Дропнуто», выпуск 1
Оригинальная запись эфира с разбором инцидента.
Telegram обзор
Сводка по инциденту и ключевые выводы.
Blameless postmortems (Google SRE)
Принципы постмортем-культуры без поиска виноватых.
SLO implementation (Google SRE Workbook)
Практика перехода от метрик к действующим SLO.
Надёжность в Т-Банке
Контекстный материал по reliability-практикам и культуре эксплуатации.