Начиная

Обнаружение инцидентов и оповещение для ваших конвейеров данных

Как настроить сквозное обнаружение и оповещение для выявления и предотвращения скрытых ошибок в ваших данных.

Нарушены конвейеры данных? Ненадежные дашборды? Слишком много нулевых значений в этом критическом отчете?

Когда дело доходит до получения надежных и точных данных, испытания и автоматические выключатели не дадут вам большего. В нашей последней серии статей мы рассказываем, как группы обработки данных могут настроить сквозные рабочие процессы управления инцидентами для своих конвейеров производственных данных, включая обнаружение инцидентов, реагирование, анализ и устранение первопричин (RCA), а также безупречное вскрытие. .

В этом гостевом посте Скотт О'Лири из Монте-Карло расскажет, как начать работу с обнаружением инцидентов и предупреждением, вашей первой линией защиты от простоев данных.

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

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

Первый шаг? Обнаружение инцидентов и оповещение, ваша первая линия защиты от нарушенных конвейеров данных и неизбежных утренних звонков от ваших руководителей («почему данные неверны?») и заинтересованных сторон («что случилось? на эту панель? »), когда конвейеры действительно ломаются.

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

Шаг 1. Напишите модуль Runbook для инцидентов с данными

Прежде чем вы сможете обнаруживать инциденты, вам необходимо установить процессы и разработать хорошую (достаточную) документацию, чтобы сообщить об обязанностях, ролях и четком пути вперед, когда вы все же получите это ужасное сообщение Slack или уведомление PagerDuty. По словам Бенджамина Франклина, неудача в планировании ведет к провалу, и это определенно верно, когда речь идет об управлении неизвестными неизвестными в конвейере данных.

Независимо от того, сколько тестирования вы настроили для своих конвейеров данных, инциденты обязательно произойдут, и наличие плана поможет вам, когда проблема действительно возникнет. Подобно тому, как инженеры по надежности сайта (SRE) используют модули Runbook на случай сбоя приложений, современные инженеры по обработке данных должны разработать планы и на случай сбоя конвейеров.

Как минимум, я рекомендую следующий адрес модуля Runbook:

  1. Что ваша организация считает инцидентом с данными?. Это позволяет вашей команде определить, стоит ли вам беспокоиться об этом. Может быть, инцидент с данными можно решить, перезапустив Airflow DAG, или, может быть, вам нужно отправить заявку, чтобы глубже погрузиться в проблему с остальной частью группы данных. В любом случае, определение того, что на самом деле является инцидентом, а что можно исключить из приоритета или проигнорировать, помогает снизить уровень шума и сохранить концентрацию вашей команды.
  2. Кто получает оповещения об инцидентах с данными? Это зависит от организации, поэтому вам нужно выяснить, что лучше всего подходит для вашей команды. В некоторых командах есть один человек, назначенный для всех инцидентов с данными в качестве первой линии защиты, в то время как у других есть группа разработки данных, которая отвечает за актуальность и объем, а также группа аналитиков, которая проверяет данные. Назначение владельцев для определенных типов инцидентов или даже конкретных аспектов инцидента будет приносить дивиденды в будущем, повышая способность вашей команды работать вместе и определять первопричину проблемы. Лучшей практикой является интеграция предупреждений в рабочие процессы инженерии данных через PagerDuty, Slack, Opsgenie и другие популярные каналы, поскольку это гарантирует, что все заинтересованные стороны и конечные пользователи будут предупреждены при возникновении проблем.
  3. Как вы будете сообщать об инциденте заинтересованным сторонам и конечным пользователям? Некоторые организации подходят к этому напрямую, отправляя уведомления об инцидентах по каналам отдельных групп (например, канал Slack для инциденты, которые влияют на важные маркетинговые информационные панели). Другие организации поддерживают первую линию защиты в группе разработки данных и предупреждают заинтересованные стороны только тогда, когда становится ясно, что проблема является «реальной» и действительно влияет на потребителей данных нижестоящего уровня. Независимо от подхода, крайне важно, чтобы ваша первая линия защиты была технической - достаточной для понимания инцидента в контексте вашей среды данных и достаточной деловой смекалкой, чтобы понимать бизнес-контекст и влияние проблемы. Установка этих двух флажков очень помогает, поскольку сокращает количество операций, которые в противном случае требовались бы для эффективного информирования как о техническом масштабе, так и о влиянии проблемы на бизнес.

Шаг 2. Обнаружение инцидентов с данными

Когда конвейеры данных обрываются, первым шагом является обнаружение инцидентов.

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

Однако тестирование и другие подходы к автоматическим выключателям не позволяют группам данных, когда дело доходит до обнаружения инцидентов, которые вы не можете предсказать или учесть в производственной среде - неизвестные неизвестные. В результате тестирование данных не обеспечивает истинной сквозной наблюдаемости, которая необходима для предприятий, основанных на данных. По мере того, как конвейеры данных становятся все более сложными, количество неизвестных неизвестных будет только расти как для промежуточных, так и для производственных целей.

Вот почему данные требуют как тестирования, так и наблюдаемости, чтобы гарантировать сквозную надежность. Современные группы данных должны думать о данных как о динамическом, постоянно меняющемся объекте и применять не только строгие тесты, но и постоянное наблюдение за данными. Благодаря возможности наблюдения за данными, проблемы можно обнаруживать с помощью автоматического мониторинга данных и предупреждений и запускать на основе пороговых значений, созданных с помощью машинного обучения или установленных пользователем.

Критическим аспектом наблюдаемости данных является обнаружение аномалий, которое позволяет организациям определять, когда основные элементы состояния данных (т. Е. Объем, актуальность, схема и распределение) не соответствуют ожиданиям в производственной среде. Обнаружение аномалий полезно для предприятий, когда оно реализовано на всех этапах (например, на ваших складах, в озерах, инструментах ETL и бизнес-аналитике), а не только на одном или двух уровнях вашей платформы данных. Это даст вашей команде полное представление о состоянии данных вашей организации, поэтому, если что-то сломается, ваша команда первой узнает и решит.

Шаг 3. Настройте рабочий процесс оповещения о критических инцидентах с данными.

Если трубопровод ломается и никто не слышит об этом, действительно ли он сломался?

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

Помимо шуток, ваша команда должна быть предупреждена, когда что-то пойдет не так, а не тратить часы или даже дни на изучение проблемы вручную. Перед настройкой предупреждений ваша команда должна установить основные правила рассмотрения инцидента, кто должен получать определенные типы предупреждений и где лучше всего их получать. Эти инструкции и процессы должны быть документированы в Runbook вашей команды.

После написания вашего модуля Runbook командам следует рассмотреть возможность внедрения решений с поддержкой машинного обучения (таких как платформы наблюдения за данными) для автоматического создания предупреждений на основе исторических данных, требующих минимального подъема с вашей стороны для начала работы. Оповещения можно напрямую отправлять в Slack, электронную почту, PagerDuty, Opsgenie, Mattermost, webhooks или любой другой канал, который ваша команда использует для управления коммуникациями.

Многие команды предпочитают настроить уведомление PagerDuty или Opsgenie для важных таблиц (т. Е. Финансовых отчетов, статистики продуктов, маркетинговых расходов и операционных показателей) и уведомление Slack или по электронной почте для менее важных таблиц. Такие уведомления позволяют вашей команде сократить количество шумных предупреждений.

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

Если вы выберете нарушения правил, команды могут направить все или только некоторые нарушения правил в определенные каналы:

Наконец, вы можете выбрать фильтр клиентов, чтобы сузить набор данных или таблиц, о которых нужно уведомлять:

Хотя возможность наблюдения за данными облегчает автоматическое сквозное обнаружение аномалий в готовом виде на основе исторических закономерностей в ваших данных, некоторые группы предпочитают настраивать настраиваемые оповещения в зависимости от конкретных бизнес-потребностей. По мере развития стратегии вашей компании в области данных я рекомендую использовать и то, и другое.

Создание культуры доверия к данным

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

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

Во второй части нашей серии статей по управлению инцидентами мы поделимся нашими передовыми методами и уроками, извлеченными из практики реагирования на инциденты с данными.

Хотите узнать больше о настройке надежного процесса управления инцидентами для вашей группы данных с помощью Монте-Карло? Обратитесь к Скотту и остальной части нашей команды!