Продолжаем говорить о дежурствах. Как проходит дежурство инженера данных и какие инструменты ему помогают?
Обычно план дежурного на день такой:
1. Собрать актуальный список инцидентов и определить приоритет их обработки;
2. Обрабатывать их в порядке приоритета, периодически проверяя, не появилось ли новых критичных инцидентов.
В зрелых инженерных командах есть система инцидент-менеджмента, которая собирает инциденты в одном месте, определяет их критичность и позволяет инженеру коммуницировать с пользователями, централизованно уведомляя их о проблемах и сроках их устранения.
Идеальный расклад, когда дежурный просто берёт инциденты подряд из очереди, которая волшебным образом уже отсортирована в этой системе. Но в реальности дежурный всё равно должен включать голову и самостоятельно корректировать приоритеты. В первую очередь потому, что помимо критичности задачи важна ещё и скорость ее устранения. Например, часто бывает выгодно за полчаса сделать пару чуть менее срочных задач, прежде чем приступить к самой критичной, которая займёт весь день. Но оценка сложности решения — это задача творческая, автоматизировать которую не так-то просто.
Что делать, когда такой системы нет? Попытаться её создать 🙂
А до тех пор дежурному инженеру придётся постоянно переключаться между тремя «экранами»: панелью мониторинга пайплайнов, списком входящих обращений и алерт-сообщениями. Объединяя информацию из этих трёх точек, инженер составляет полный список инцидентов.
Разберёмся подробнее, что скрывается за каждым из этих «экранов»:
💻 Панель мониторинга пайплайнов
Обычно это стартовая страница оркестратора (например, Airflow), где видно все пайплайны и их статус, и можно быстро понять, какие из них упали или зависли. Отсюда можно провалиться в конкретный пайплайн, посмотреть подробные логи и попытаться локализовать быстро проблему, т. е. найти её причину.
В процессе локализации часто приходится также обращаться к дашбордам с техническими графиками, когда есть подозрение, что ошибки связаны не с данными или кодом пайплайнов, а с софтом или железом. Такие дашборды инженеры часто делают отдельно в Grafana — своём любимом инструменте мониторинга систем.
💻 Список входящих обращений
Иногда бывает так, что проблема есть, но мониторинг/алертинг по каким-то причинам её не подсвечивает. В таком случае входящие обращения — единственный способ обнаружить проблему. Они могут поступать в таск-трекер, чат поддержки, на почту или куда-то ещё. И дежурный должен просматривать и реагировать на них, особенно если есть срочные запросы от пользователей. Но наличие нескольких разных чатиков и трекеров, с которыми надо работать, серьёзно снижают скорость решения проблем.
💻 Алерт-сообщения
У инженеров часто настроен автоматический алертинг: об ошибках в работе пайплайнов, о проблемах в самих данных, о критических состояниях платформы. Алерты отправляют в Telegram-бота или специальный приватный канал в рабочем мессенджере. Они очень удобны для оперативного обнаружения критичных проблем, особенно в течение дня (вы ведь не будете каждые 5 минут смотреть на панель мониторинга).
Однако часто в канал льются вперемешку все ошибки, включая неприоритетные, и этот «экран» превращается в свалку. Важно не допускать этого и по-разному алертить об инцидентах разного уровня критичности.
За скобками остался сам процесс локализации решения инцидента, но это отдельный вид искусства, о котором можно говорить часами.
Зеленых пайплайнов вам, друзья! До встречи на курсе «Инженер данных» 🙂
📊 Simulative