Хабрахабр

[Перевод] Цели уровня обслуживания — опыт Google (перевод главы книги Google SRE)

image

Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Этот перевод я готовил самостоятельно и полагался на собственный опыт понимания процессов мониторинга. В этой статье перевод Главы 4 Service Level Objectives книги Site Reliability Engineering от Google. В телеграм-канале monitorim_it и прошлом посте на Хабре я публиковал также перевод 6 главы этой же книги о целях уровня обслуживания.

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

Эти измерения описывают основные метрики, которые мы хотим контролировать и на которые будем реагировать, если не сможем предоставить ожидаемое качество сервиса. Мы используем свои интуицию, опыт и осознаём желание пользователей иметь представление об индикаторах уровня обслуживания (SLI), целях уровня обслуживания (SLO) и соглашении об уровне обслуживания (SLA). В конечном счете, выбор подходящих показателей помогает управлять правильными действиями, если что-то пойдет не так, а также дает уверенность команде SRE в здоровье сервиса.

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

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

Индикаторы

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

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

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

Часто определяется как доля успешных запросов, иногда называемых выработкой. Другим видом SLI, важным для SRE, является доступность или часть времени, в течение которого сервисом можно пользоваться. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток». (Продолжительность срока службы — вероятность того, что данные будут храниться в течение длительного периода времени, ещё важна и для систем хранения данных.) Хотя доступность на 100% невозможна, доступность близкая к 100% часто достижима, значения доступности выражаются в виде количества «девяток» процента доступности. Текущая заявленная цель доступности Google Compute Engine — «три с половиной девятки» или 99,95%.

Цели

SLO — это цель уровня обслуживания: целевое значение или диапазон значений для уровня обслуживания, который измеряется SLI. Нормальным значением для SLO является «SLI ≤ целевого значения» или «нижняя граница ≤ SLI ≤ верхняя граница». Например, мы можем решить, что мы вернем результаты поиска по произведениям Шекспира «быстро», приняв в виде SLO значение средней задержки запроса поиска меньшее 100 миллисекунд.

Во-первых, вы не всегда можете выбрать конкретное значение. Выбор подходящего SLO — сложный процесс. Для внешних входящих HTTP-запросов к вашему сервису метрика количества запросов в секунду (QPS) в основном определяется желанием ваших пользователей посетить ваш сервис, и вы не можете установить SLO для этого.

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

Дело в том, что связка QPS и задержка сильно связаны друг с другом: более высокий QPS часто приводит к большим задержкам, и обычно сервисы испытывают резкое снижение производительности при достижении определенного порога нагрузки. Опять же, это более неоднозначно, чем может показаться на первый взгляд: совсем выбрасывать QPS из расчёта не стоит.

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

Соглашения

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

SRE, однако, участвует в оказании помощи при предотвращении последствий неудачных SLO. SRE обычно не участвует в создании SLA, поскольку SLA тесно связаны с решениями для бизнеса и продуктов. Они также могут помочь определить SLI: очевидно, должен быть объективный способ измерения SLO в соглашении или возникнут разногласия.

Тем не менее, все еще есть последствия, если поиск недоступен — недоступность приводит к падению нашей репутации, а также к снижению доходов от рекламы. Google Search — пример важного сервиса, который не имеет SLA для общественности: мы хотим, чтобы все пользовались Поиском как можно более эффективно, но мы не подписали контракт со всем миром. Независимо от того, имеет ли конкретная услуга SLA, важно определить SLI и SLO и использовать их для управления службой. У многих других сервисов Google, таких как Google for Work, есть явные соглашения об уровне обслуживания с пользователями.

Так много теории — теперь к опыту.

Учитывая, что мы сделали вывод, что важно выбрать подходящие показатели для измерения уровня обслуживания, как вы теперь узнаете, какие показатели имеют значение для сервиса или системы?

О чем вы и ваши пользователи заботитесь

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

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

  • Пользовательские фронтэнд-системы, такие как интерфейсы поиска сервиса Шекспир из нашего примера. Они должны быть доступны, не иметь задержек и обладать достаточной пропускной способностью. Соответственно, можно задать вопросы: можем ли мы ответить на запрос? Сколько времени потребовалось, чтобы ответить на запрос? Сколько запросов может быть обработано?
  • Системы хранения. Для них важна низкая задержка ответа, доступность и долговечность. Соответствующие вопросы: сколько времени требуется для чтения или записи данных? Можем ли мы получить доступ к данным по запросу? Доступны ли данные, когда они нам нужны? См. главу 26 Целостность данных: то, что вы читаете, это то, что вы записали, для детального разбора этих вопросов.
  • Системы с большими данными, такие как конвейеры обработки данных, зависят от пропускной способности и задержки обработки запроса. Соответствующие вопросы: сколько данных обрабатывается? Сколько времени требуется, чтобы данные продвигались от приёма запроса до выдачи ответа? (Некоторые части системы могут также иметь задержки на отдельных этапах.)

Сбор индикаторов

Многие индикаторы уровня сервиса наиболее естественно собирать на стороне сервера, используя систему мониторинга, такую как Borgmon (см. Главу 10 Практика оповещений по данным временных рядов) или Prometheus, или просто периодически анализируя логи, выявляя HTTP ответы со статусом 500. Тем не менее, некоторые системы должны быть снабжены сбором метрик на стороне клиента, так как отсутствие мониторинга на стороне клиента может привести к пропуску ряда проблем, которые затрагивают пользователей, но не влияют на показатели на стороне сервера. Например, сосредоточенность на задержке ответа бэкэнда нашего тестового приложения с поиском по произведениям Шекспира может привести к задержке обработки запросов на стороне пользователя из-за проблем с JavaScript: в этом случае измерение того, сколько времени займет обработка страницы в браузере, является лучшим показателем.

Агрегация

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

Является ли измерение полученным конкретно один раз в секунду или это измерение усреднено по количеству запросов в течение минуты? Некоторые показатели кажутся простыми, например, количество запросов в секунду, но даже это, очевидное, прямое измерение неявно агрегирует данные по времени. Рассмотрим систему, которая обслуживает 200 запросов в секунду с четными номерами и 0 в остальное время. Последний вариант может скрыть гораздо более высокое мгновенное количество запросов, которые сохраняются всего на несколько секунд. Точно так же усреднение задержек запросов может показаться привлекательным, но скрывает важную деталь: вполне возможно, что большинство запросов будут быстрыми, но среди них окажется много запросов, которые будут медленными. Константа в виде среднего значения в 100 запросов в секунду и вдвое большая мгновенная нагрузка — совсем не одно и то же.

Например, для SLI задержки некоторые запросы будут обрабатываться быстро, в то время как некоторые всегда будут занимать больше времени, иногда намного больше. Большинство показателей лучше рассматривать как распределения, а не средние. На рисунке приведен пример: хотя типичный запрос обслуживается примерно 50 мс, 5% запросов в 20 раз медленнее! Простое среднее может скрывать эти длительные задержки. Мониторинг и оповещения, основанные только на средней задержке, не показывают изменений в поведении в течение дня, когда на самом деле существуют заметные изменения в длительности обработки некоторых запросов (самая верхняя строка).

Ось Y приведена в логарифмическом формате. image
50, 85, 95, и 99 процентили задержки системы.

Чем больше дисперсия времени отклика, тем сильнее длительные запросы влияют на пользовательский опыт. Использование процентилей для индикаторов позволяет увидеть форму распределения и его характеристики: высокий уровень процентиля, такой как 99 или 99,9, показывает наихудшее значение, а на 50 процентиле (также известном как медиана) можно увидеть наиболее частое состояние метрики. Исследования пользовательского опыта показали, что люди обычно предпочитают более медленную систему с высокой дисперсией времени отклика, поэтому некоторые команды SRE сосредотачиваются только на высоких процентильных значениях, исходя из того, что если поведение метрики на 99,9 процентиле является хорошим — большинство пользователей не будут испытывать проблем. Эффект усиливается при высокой нагрузке при наличии очередей.

Примечание по статистическим ошибкам

Это позволяет рассматривать более дисперсные значения, которые часто имеют существенно отличающиеся (и более интересные) характеристики, чем среднее. Обычно мы предпочитаем работать с процентилями, а не со средним (средним арифметическим) набором значений. В результате мы не можем принять, что среднее и медианы могут быть одинаковы или близки друг к другу! Из-за искусственного характера вычислительных систем значения метрик часто искажаются, например, ни один запрос не может получить ответ менее чем за 0 мс, а тайм-аут в 1000 мс означает, что успешных ответов со значениями, превышающими таймаут, не может быть.

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

Стандартизировать индикаторы

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

  • Интервалы агрегирования: «усредненный за 1 минуту»
  • Области агрегирования: «Все задачи в кластере»
  • Как часто проводятся измерения: «Каждые 10 секунд»
  • Какие запросы включены: «HTTP GET из заданий мониторинга черного ящика»
  • Как данные получены: «Благодаря нашему мониторингу, измеренному на сервере»,
  • Задержка доступа к данным: «Время до последнего байта»

Чтобы сэкономить усилия, создайте набор многоразовых шаблонов SLI для каждой общей метрики; они также упрощают для всех понимание того, что означает определенный SLI.
Начните с размышлений (или узнайте!), о чем заботятся ваши пользователи, а не о том, что вы можете измерить. Часто то, что беспокоит ваших пользователей, трудно или невозможно измерить, так что в итоге вы приблизитесь к их потребностям. Однако, если вы просто начнете с того, что легко измерить, вы получите менее полезные SLO. В результате мы иногда обнаруживали, что первоначальное определение желаемых целей и дальнейшая работа с конкретными индикаторами работает лучше, чем выбор индикаторов, а затем достижение целей.

Определите цели

Для максимальной ясности, должно быть определено как измеряются SLO и условия, при которых они действительны. Например, мы можем сказать следующее (вторая строка такая же, как первая, но использует SLI-значения по умолчанию):

  • 99% (усредненные в течение 1 минуты) вызовов Get RPC будут завершены менее чем за 100 мс (измеряется на всех серверах backend).
  • 99% вызовов Get RPC будут завершены менее чем за 100 мс.

Если форма кривых производительности важна, вы можете указать несколько целей SLO:

  • 90% вызовов Get RPC выполнились менее чем за 1 мс.
  • 99% вызовов Get RPC выполнились менее чем за 10 мс.
  • 99.9% вызовов Get RPC выполнились менее чем за 100 мс.

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

  • 95% запросам клиентов важна пропускная способность. Установите подсчёт RPC-вызовов выполнявшихся <1 с.
  • 99% клиентам важна величина задержки. Установите подсчёт RPC-вызовов с трафиком <1 кБ и выполнявшихся <10 мс.

Нереалистично и нежелательно настаивать на том, что SLO будут выполняться в 100% случаев: это может снизить темпы ввода нового функционала и деплоймента, потребовать дорогостоящих решений. Вместо этого лучше разрешить бюджет ошибок — долю разрешённого простоя системы и отслеживать это значение ежедневно или еженедельно. Возможно, высшее руководство будет хотеть ежемесячную или ежеквартальную оценку. (Бюджет ошибок — это просто SLO для сравнения с другим SLO).

Главу 3 и раздел «Мотивация для бюджетов ошибок»), при этом значение разницы используется в качестве входа в процесс, который решает, когда разворачивать новые релизы. Долю нарушения SLO можно сравнить с бюджетом ошибок (см.

Выбор плановых значений

Выбор плановых значений (SLO) не является чисто технической деятельностью из-за интересов продукта и бизнеса, которые должны быть отражены в выбранных SLI, SLO (и, возможно, SLA). Аналогичным образом, может потребоваться обмен информацией по поводу вопросов, связанных с укомплектованием штата персонала, временем выхода на рынок, наличием оборудования и финансированием. SRE должен быть частью этого разговора и помогать разобраться с рисками и жизнеспособностью различных вариантов. Мы прикинули несколько вопросов, которые могут помочь обеспечить более продуктивное обсуждение:

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

Будьте проще
Сложные расчёты SLI могут скрыть изменения в производительности системы и усложнят поиск причины проблемы.

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

Защитите SLO, которые вы выбрали: если вы никогда не сможете выиграть спор о приоритетах, указав конкретную SLO, вероятно, не стоит рассматривать эту SLO. Используйте как можно меньшее количество SLO
Выберите достаточное количество SLO, чтобы обеспечить хорошее покрытие атрибутов системы. Однако, не все атрибуты системы поддаются SLO: трудно подсчитать уровень пользовательского восторга при помощи SLO.

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

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

Контролируйте измерения

SLI и SLO являются ключевыми элементами, используемыми для управления системами:

  • Мониторьте и измеряйте SLI системы.
  • Сравните SLI со SLO и решите нужны ли действия.
  • Если требуется действие, выясните, что должно произойти, чтобы достичь цели.
  • Выполните это действие.

Например, если шаг 2 показывает, что время ожидания запроса увеличивается, и нарушит SLO через несколько часов, если ничего не будет сделано, шаг 3 может включать в себя тестирование гипотезы о том, что нагрузка на серверы привязана к процессорам и добавление новых серверов распределит нагрузку. Без SLO вы не знали бы нужно ли (или когда) принимать меры.

Пользователи (и потенциальные пользователи) часто хотят знать, что можно ожидать от сервиса, чтобы понять, подходит ли он для использования. Установили SLO — следом установятся пользовательские ожидания
Публикация SLO устанавливает ожидания пользователей от поведения системы. Например, люди, желающие пользоваться веб-сайтом для обмена фотографиями, могут захотеть избежать использования сервиса, который обещает долговечность и низкую стоимость в обмен на несколько меньшую доступность, хотя одна и та же услуга может быть идеально подходящей для системы управления архивными записями.

Чтобы установить реалистичные ожидания для ваших пользователей, используйте одну или обе следующие тактики:

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

Понимание того, насколько хорошо система отвечает ожиданиям, помогает решить, следует ли инвестировать ускорение системы и делать её доступнее и более устойчивой. В качестве альтернативы, если сервис слишком хорошо работает, некоторое время работы персонала должно быть потрачено на другие приоритеты, такие как погашение технического долга, добавление новых функций или ввод в эксплуатацию новых продуктов.
Создание SLA требует, чтобы бизнес- и юридические команды определяли последствия и штрафы за его нарушение. Роль SRE заключается в том, чтобы помочь им понять вероятные трудности с выполнением SLO, содержащимися в SLA. Большая часть рекомендаций по созданию SLO также применима для SLA. Целесообразно быть консервативным в том, что вы обещаете пользователям, поскольку чем их больше, тем сложнее изменить или удалить SLA, которые кажутся неразумными или трудными для выполнения.

Подписывайтесь на мой телеграм-канал о мониторинге monitorim_it и блог на Медиуме. Спасибо, что прочитали перевод до конца.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»