Установка SLO (Service Level Objective, целевых уровней обслуживания) — одна из базовых задач SRE. По этим показателям удобно оценивать надежность службы. Противоположность SLO — бюджет на ошибки, то есть какой уровень ненадежности считать допустимым. Когда мы определим эти показатели и установим SLO, нужно проверить их реалистичность с учетом архитектуры приложения и рабочих практик. Мы точно сможем их достичь? На что, скорее всего, уйдёт наш бюджет на ошибки?

SRE-инженеры из Google отвечают на эти вопросы при выпуске нового сервиса, когда проводят PRR (Production Readiness Review — проверку готовности продукта). Мы анализируем риски не для того, чтобы изменить SLO. Скорее, мы хотим приоритизировать риски для сервиса, чтобы прикинуть, сможем ли мы достичь наших SLO с учетом изменений сервиса или без них. Кроме того, с помощью анализа мы определим самые важные риски. Определяя и снижая риски, мы повышаем надежность сервиса.

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

Какие риски следует рассмотреть?

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

• У нас есть пробелы в наблюдаемости? 

• У нас настроены оповещения для конкретных индикаторов SLI? 

• Мы вообще собираем эти метрики? 

Проследите все зависимости мониторинга и оповещений. Например, что будет при сбое системы, которой управляет поставщик?

В идеале стоит определить риски, связанные с каждой точкой отказа для каждого критического компонента критического пути пользователя (critical user journey, CUJ). Определив риски, приступайте к их измерению:

• На какой процент пользователей повлиял этот сбой?

• Как часто будет происходит сбой?

• Сколько времени ушло на обнаружение сбоя? 

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

• Из-за ошибки в конфигурации возникла перегрузка и стали теряться запросы.

• Новый релиз повлиял на некоторые запросы; ошибка была обнаружена только на следующий день; потребовался быстрый откат.

• Произошел сбой виртуальных машин или сети в одной зоне облачного провайдера.

• Произошёл региональный сбой виртуальных машин или сети облачного провайдера.

• Оператор случайно удалил базу данных, потребовалось восстановление из бэкапа.

Не забудьте оценить факторы риска — глобальные факторы, которые влияют на общее время обнаружения (time to detection, TTD) и время восстановления (time to repair, TTR). Обычно это операционные факторы, из-за которых может потребоваться больше времени для обнаружения сбоев (например, при использовании метрик на основе логов) или для оповещения дежурных инженеров. Ещё один пример — отсутствие плейбуков и документации или недостаточная автоматизация. Например:  

• Расчётное время обнаружения (ETTD) увеличивается на 30 минут из-за повышенной нагрузки, например избытка оповещений.

• Сбои случаются на 10% чаще, потому что мы не делаем постмортемы и не принимаем меры.

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

Следуйте простым рекомендациям для эффективного мозгового штурма: 

• Начните с общей блочной схемы сервиса, его пользователей и зависимостей. 

• Соберите людей из разных команд, которые пересекаются с сервисом под другим углом. Следите, чтобы высказаться могли все стороны. Спросите участников, каким образом каждый элемент схемы может привести к ошибке. Объедините похожие причины в одну категорию риска, например «сбой базы данных».

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

Составление каталога рисков 

Не увлекайтесь при составлении списка рисков. 7–12 рисков на каждый индикатор SLI будет достаточно. Делайте акцент на риски с высокой вероятностью наступления и критические риски. 

• Лучше всего начать с реальных сбоев. Это может быть просто недоступность сервиса или сети, от которых зависит ваш продукт.

• Запишите проблемы со стороны инфраструктуры и программной части. 

• Подумайте, какие риски могут повлиять на SLI, время обнаружения, время восстановления и частоту сбоев.

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

Вот несколько примеров рисков: 

• Новый релиз повлиял на некоторые запросы; ошибка была обнаружена только на следующий день; потребовался быстрый откат.

• Новый релиз влияет на большую группу запросов, автоматического отката нет.

• Ошибка конфигурации привела к нехватке ресурсов или из-за незамеченного роста потребление достигло потолка.

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

Анализ рисков

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

Мы расставим приоритеты по четырем аспектам: время обнаружения, время восстановления, время наработки на отказ (TBF) и влияние на пользователей.

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

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

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

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

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

Если у вас надежный конвейер CI/CD, вы сможете уверенно развертывать изменения и откатывать их, чтобы ограничить влияние на клиентов (см. главу 8 о релизах в книге про SRE). Интегрированный процесс ревью кода и тестирования поможет обнаруживать проблемы еще до того, как их заметят пользователи. 

Чтобы сократить время обнаружения, нужно как можно раньше отлавливать проблемы. Расчетное TTD показывает, сколько времени требуется, чтобы оповестить кого-то о проблеме. TTD включает любые задержки до обнаружения, например обработку данных. Допустим, мы используем оповещения на основе логов, а данные поступают в логи через пять минут, значит TTD для каждого оповещения будет больше на 5 минут.

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

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

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

Общее описание анализа рисков 

Начните с обсуждения рисков для каждого SLO и даже для каждого SLI, потому что у индикаторов будут разные риски. На следующем этапе начните постепенно составлять каталог рисков.

1. Составьте лист анализа рисков для двух-трех SLI по этому шаблону. См. статью о том, как приоритизировать и обсуждать риски.

2. Обсудите, что влияет на ваши SLO, и соберите начальные данные. Сначала позовите инженеров, а затем привлеките команду по продукту.

3. Листы анализа рисков для каждого SLI должны включать ETTD, ETTR, влияние и частоту. Учитывайте глобальные факторы и предполагаемые риски. Укажите, допустимы ли эти риски.

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

5. Обновите имеющиеся данные с учетом инцидентов в продакшене.

Принятие рисков

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

В статье о том, как приоритизировать и обсуждать риски рассказывается об их ранжировании, с помощью которого можно прикинуть, во что вам обойдется тот или иной риск, и можно ли считать его приемлемым для определенного SLO. Например, если в этом шаблоне указать все риски как приемлемые, надежность будет на уровне 99,5%, если приемлемыми будут некоторые риски, то 99.9%, а если ни один — 99.99%. Если риск неприемлем, потому что не впишется в бюджет на ошибки для этого SLO, стоит потратить драгоценное время, чтобы устранить его причину или создать другое решение.

Данные о сбоях и инцидентах позволят уточнить ETTD на основе фактического значения TTD, и то же самое можно сделать с ETTR. Обновляйте данные после инцидентов и сверяйтесь с расчетными показателями. Периодически пересматривайте их. Эти риски еще актуальны? Расчетные показатели верны? Добавились новые риски? Непрерывное совершенствование — один из важных принципов SRE. Вам придётся проделывать это снова и снова, но оно того стоит!