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