Состояние отчётов, незавершённые действия и принятая ответственность важнее длинного пересказа смены. Разбираем передачу дежурства на условном сбое загрузки.
Смена закончилась, задача ещё продолжается
Представим условную загрузку заказов. Утренний отчёт опаздывает, часть данных уже получена, повторный запуск пока отложен. Один специалист заканчивает дежурство, другой его принимает. Сообщение «загрузка иногда падает, посмотри» не объясняет, что именно сейчас происходит и какое действие уже было выполнено. Следующая смена рискует начать расследование с нуля или повторить опасную операцию.
В руководстве Google SRE по дежурствам описаны чтение передачи предыдущей смены в начале работы и подготовка передачи в конце. Дежурство — период, когда назначенный человек принимает сообщения о проблемах и реагирует в согласованных пределах. Перенесём этот организационный принцип на наш пример с данными, не предполагая одинаковых обязанностей во всех командах.
Сначала описать фактическое состояние
Для нашего случая начнём с короткой сводки: какой результат задержан, кто им пользуется и что уже доступно. Полезно отдельно указать время последней проверки. Формулировка «всё нормально» без момента наблюдения быстро теряет смысл. Если отчёт восстановлен только частично, это должно быть видно в первых строках, а не спрятано в переписке.
Дальше разделим подтверждённые факты и предположения. Например, известно, что новая порция не пришла; причина её отсутствия пока не установлена. Это точнее, чем объявить источник сломанным до проверки. В передаче смены важно сохранить степень уверенности, чтобы новая смена не воспринимала рабочую гипотезу как окончательный диагноз.
Незавершённое действие нуждается в следующем шаге
В условной ситуации повторная загрузка отложена до подтверждения владельца источника. Передадим, какого ответа ждём, кто должен его дать и что делать после получения. Если действие уже запущено, отметим его состояние и способ проверки завершения. Просьба «проверить позже» оставляет следующему человеку слишком много незаданных вопросов.
Отдельно перечислим временные ограничения: какой автоматический повтор остановлен, какой результат нельзя передавать пользователям и кто разрешает возобновление. Это предлагаемый состав передачи для нашего процесса. Полную инструкцию действий при сбое переписывать сюда не нужно: достаточно актуальной ссылки и описания того, на каком шаге команда остановилась.
Передача ответственности должна быть явной
В главе Google SRE об управлении инцидентами передача руководства требует явного подтверждения принимающего. Там же описан общий документ текущего состояния. Для нашего разбора применим более узкое правило: отправленная заметка ещё не доказывает, что следующий дежурный её прочитал и принял незавершённые задачи.
Перед завершением смены предложим коротко подтвердить, кто продолжает наблюдение и кто принимает решение о следующем действии. Если есть отдельный руководитель инцидента, дежурный не должен незаметно подменять его роль. Контакты и границы полномочий стоит указывать так, чтобы их можно было понять без знания всей истории команды.
Передаётся рабочая сводка, а не весь архив переписки
В нашем примере достаточно ссылок на текущую задачу, состояние загрузки и договорённость с получателем отчёта. Нужные наблюдения лучше изложить рядом с выводом, чем отправить десятки сообщений без пояснений. Следующему дежурному важно быстро понять, какое из них последнее и какое решение остаётся действующим. Секреты доступа в такую сводку помещать не требуется.
Если срочных проблем нет, это тоже полезно зафиксировать вместе с результатом последней проверки. Но отсутствие сообщения об ошибке не равно доказанной готовности всех отчётов. Состав наблюдений согласуют заранее. При появлении новой проблемы её последствия и срочность можно оценить по правилам критичности сбоя данных.
Как проверить качество передачи
Попросим принимающего своими словами назвать текущее состояние, ближайшее ожидаемое событие и ответственного за действие. Если это нельзя сделать по сводке, её стоит уточнить до окончания передачи. Такая проверка не обещает отсутствия будущих ошибок; она обнаруживает конкретную недосказанность в момент смены ответственного.
Работу с надёжностью процессов и взаимодействием команды можно изучать на программе DataOPS инженер. Начать можно с одной незавершённой задачи: следующий человек должен понимать, что уже известно, что ему предстоит проверить и чего пока делать нельзя.
