Основы качества данных, глава шестая, часть 2.
Мысли об устранении проблем с качеством данных.
📎 Хорошее реагирование на инциденты начинается и заканчивается эффективной коммуникацией.
📎 Один из обязательных этапов подготовки – сценарии реагирования, пошаговый план процесса обработки инцидента, Runbook.
📎 Делегирование и разделение ролей в инцидент-менеджменте считается хорошей практикой.
📎 В случае проблем стоит сообщить о них и выше-, и нижестоящим потребителям – всем, кто использует эти данные.
📎 Поиск потребителей и зависимостей, схему тракта данных и оповещение можно автоматизировать.
📎 Провести анализ первопричин и найти место «поломки» может быть нетривиальной задачей, инциденты могут проявляться неочевидным образом.
📎 Большинство проблем с данными можно отнести к одному или нескольким из следующих событий: 1. Изменение в схеме данных, например, наименование или размерность атрибута 2. Изменение логики, преобразующей данные 3. Операционная проблема, сбои, инфраструктурные ошибки
📎 Для быстрого выявления проблем нужен целостный подход, учитывающий как и почему каждое из этих трех событий может произойти.
📎 Инциденты редко имеют одну причину, чаще это совокупность факторов.
📎 Полезная основа для анализа инцидентов от Амазон: 1. Определить проблему 2. Понять, почему она возникла 3. Определить, является ли эта причина основной 4. Узнать, можно ли было предотвратить основную причину 5. Могла ли быть эта причина обнаружена до того, как случился инцидент 6. Если причина в человеческом факторе, то почему так произошло
📎 Тесты и проверки должны показывать возможную проблему до того, как она реально проявится.
📎 Шаги анализа инцидента: 1. Изучить Data Lineage, найти самые первые узлы, где есть проблема 2. Изучить код на ошибки в логике создания таблиц, полей и расчетов 3. Посмотреть на ошибочные данные, сверить с другими атрибутами в поисках аномалий и закономерностей 4. Изучить работу и логи ETL/ELT в интересующий период 5. Спросить коллег 😊 Это работает!
