SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. В этой статье перевод Главы 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, является доступность или часть времени, в течение которого сервисом можно пользоваться. Часто определяется как доля успешных запросов, иногда называемых выработкой. (Продолжительность срока службы — вероятность того, что данные будут храниться в течение длительного периода времени, ещё важна и для систем хранения данных.) Хотя доступность на 100% невозможна, доступность близкая к 100% часто достижима, значения доступности выражаются в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток». Текущая заявленная цель доступности 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 обычно не участвует в создании SLA, поскольку SLA тесно связаны с решениями для бизнеса и продуктов. SRE, однако, участвует в оказании помощи при предотвращении последствий неудачных SLO. Они также могут помочь определить SLI: очевидно, должен быть объективный способ измерения SLO в соглашении или возникнут разногласия.

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

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

Индикаторы на практике

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

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

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

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

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

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

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

Агрегация

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

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

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

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

Использование процентилей для индикаторов позволяет увидеть форму распределения и его характеристики: высокий уровень процентиля, такой как 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).

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

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

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

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

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

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

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

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

SLO могут и должны стать основным драйвером в определении приоритетов работы для SRE и разработчиков продуктов, поскольку они отражают заботу о пользователях. Хорошее SLO — это полезный инструмент принуждения команды разработчиков. Но плохо продуманная 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 и блог на Медиуме.

Источник: habr.com

ProHoster Консультант, Технический специалист

A technical specialist at ProHoster with over six years of experience in server administration, VPN solutions, and network security. I manage infrastructure setup and support, monitor service stability, and implement solutions to protect client data. I also contribute to performance optimization and compliance with modern security and privacy requirements.

See Full Bio

VPN VPS Shared Hosting SSL