Если у вас есть продукт, то у вас есть обязательства перед конечными пользователями. В этом случае SLA (соглашение об уровне обслуживания) — это отличный инструмент. Он помогает сфокусировать внимание разработчиков продукта на том, что больше всего нужно вашим клиентам.
Перевели статью, автор который делится практическими советами при создании SLA. Они помогут лучше понять эту задачу. Автор касается вопросов: что измерять, как измерять где и, самое главное, какие целевые пороги установить.
SLA — это основная концепция SRE (Site Reliability Engineering). Хотя "S" в SRE означает "Site", ничто не ограничивает SLA веб-сайтами или API. Поэтому я считаю, что
Буква "S" в слове SRE должна означать сервис
Давайте начнем с простого. Например, у вас есть служба, которая предоставляет конечным пользователям конечную точку через интернет.
Возможности пользовательских подключений
Между вашим публичным эндпоинтом и конечным пользователем существует сложная сеть маршрутизаторов, интернет-провайдеров (ISP) и сред передачи данных (спутники, оптоволоконные кабели, беспроводные сети и т. д.), и они постоянно выходят из строя. Это важно, потому что по статистике средний пользователь не имеет подключения к Интернету в течение 30 минут в месяц. То есть даже если бы ваша услуга имеет невозможный SLA в 100 %, то конечный пользователь все равно будет получить ее как 99,93 %.
В определенных условиях есть способы обойтись без использования публичного интернета. Например, если ваш клиент — это бизнес-приложение, работающее на одном и том же облачном провайдере, трафик необязательно должен проходить через публичный интернет.
Если клиент может себе это позволить, Azure ExpressRoute или AWS DirectConnet предлагают физическое выделенное соединение непосредственно с клиентом, которое более стабильно, чем общедоступный интернет.
Но для конечного пользователя все равно есть риски, ведь он получает доступ к сервису через Wi-Fi или 5G-соединение, а электромагнитные волны еще менее надежны, чем провода.
Юридический и финансовый аспект
Основное различие между SLO и SLA заключается в том, что SLA имеет договорной характер и является юридическим обязательством, которое ваша компания берет на себя перед клиентом.
Часто в них присутствуют финансовые условия. Например, вот как различные продукты баз данных обязуются "кредитовать" клиента в случае нарушения SLA о доступности:
Нет ничего плохого в том, чтобы попросить внутренние команды стремиться к 99,999% доступности, но это цель, а не соглашение. Разница в том, что:
SLO — это цель, используемая внутри компании между командами.
SLA — это юридическое обязательство, используемое на внешнем уровне между бизнесом и клиентами, часто влекущее за собой штраф в качестве гарантии.
В качестве компенсации за нарушение SLA компании обычно предоставляют кредит, а не возвращают деньги. Это способ удержать клиента.
Стоимость
Даже самые стабильные сервисы, такие как S3, официально объявляют о белантировании, если их SLA опускается ниже 3 девяток. SLA на 100 % — это всего лишь мечта. Требование высокого SLA от высшего руководства — это, как правило, реакция на недовольство пользователей из-за гораздо более низкого текущего SLA, например 98% с плохим MTBF (Mean Time Between Failures — среднее время между сбоями или авариями в работе сервиса). У меня есть хорошие и плохие новости. Хорошая новость заключается в том, что компания серьезно относится к отзывам пользователей. Плохая новость заключается в том, что повышение надежности — это пошаговый процесс, требующий времени, энергии и денег. Нельзя просто так в одночасье перескочить с 98 % на 99 % или даже с 99 % на 99,9 %.
Как правило, на каждые 9 баллов, которые добавляются к SLA, операционные и организационные расходы увеличиваются в 10 раз.
Так происходит потому, что:
Стоимость инфраструктуры. Более высокий SLA обычно требует более избыточной или мощной инфраструктуры для достижения более высокой надежности.
Сложность. Архитектура будет более сложной, что повышает стоимость обслуживания.
Производительность. Изменения — один из основных источников проблем. Командам разработчиков придется тратить больше времени на обеспечение качества и выпускать продукты относительно реже, что в конечном итоге означает меньшее количество функций и исправлений ошибок для конечных пользователей (возможно, команда разработчиков — это не короткий путь).
Например, высокодоступная система (Highly Available system или HA) часто имеет сложный график избыточного переключения в случае отказов и механизмы высокопроизводительного резервного копирования для устранения единственной точки отказа (SOP). HA подразумевает избыточность и накладывает дополнительные сложности, которые конфликтуют с другими целями, такими как удобство обслуживания и периодичность выпуска новых функций. Это не бесплатно, и не у каждого предприятия есть возможности и/или основания для HA.
Поднимитесь на ещё ступеньку выше, и вы окажетесь в сфере отказоустойчивых (Fault Tolerant или FT) систем, которые могут переносить различные аппаратные и программные сбои и восстанавливаться автоматически. FT, как правило, еще дороже, чем HA, и требует программно-аппаратной архитектуры, созданной с учетом этих требований с нуля.
Вполне возможно, что при прочих равных условиях лучше заплатить случайный штраф, чем перерасходовать средства или замедлить работу.
Существует закон убывающей отдачи для SLA: слишком высокий SLA необязательно гарантирует соответствующую рентабельность инвестиций (ROI).
Когда вы думаете о Netflix, вы, вероятно, не представляете себе сервис с низким временем безотказной работы. Тем не менее Дейв Хан, бывший менеджер по SRE, говорит, что они не стремятся к "безотказной работе любой ценой". Если у вас есть время, посмотрите видео целиком (это как комедия в стиле стендап для технарей).
Перекладывание ответственности на третьих лиц
При принятии обязательств по SLA для своих клиентов важно знать SLA и модель компенсации услуг, на которые полагается ваш бизнес. Например, если вы полагаетесь на надёжность на S3, AWS обязуется обеспечить доступность на уровне 99,9 % и компенсирует до 100 % стоимости в случае, если доступность упадет ниже 95 %. Это должно компенсировать часть денег, которые вы должны заплатить своим клиентам, и снизить риски для бизнеса, но не устранить их.
Если у вашего сервиса нет стратегии резервного копирования, любая зависимость от сторонних поставщиков может повлиять на SLA. Хотя они могут компенсировать затраты, вы всё равно можете остаться в минусе, так как заплатите своим пользователям. Имейте это в виду, когда будете устанавливать модель компенсации за нарушение SLA.
Бизнес-согласование
Поскольку SLA имеет юридический и финансовый аспект, хорошо, чтобы при его согласовании с вами были юристы и финансисты. Их консерватизм может помочь опираться на факты бизнеса слишком амбициозным менеджерам.
Если продукт предназначен для здравоохранения, контроля аэропортов, банковской сферы или вооруженных сил, SLA на уровне 5 девяток или выше может иметь смысл. Если речь идет о многопользовательской видеоигре, социальной сети или потоковой платформе, то нет причин сжигать бюджет на нереалистичные SLA, которые не соответствуют бизнесу.
Два ключевых вопроса, которые необходимо задать:
1. Какой SLI является ключевым для работы ваших клиентов? Обычно это доступность, но это может быть любой другой golden signal или даже что-то другое.
2. Какое минимальное SLA-обязательство вы можете выполнить? Учитывайте стоимость, возможности команды и вашу бизнес-модель.
Другой способ взглянуть на это - определить, что является приемлемым перерывом в обслуживании без серьезного влияния на вашу склонность к риску?
Например, если вы являетесь новостным сайтом:
Если сайт не может показать новости или работает слишком медленно, читатели могут получить свои новости с другого сайта. 30 минут простоя в месяц могут быть приемлемыми, но 5 часов простоя могут превратиться в саму новость!
Если реклама не отображается, вы можете потерять часть доходов от рекламы. 1 день может быть приемлемым, но не целая неделя. Возможно, вы не обязаны платить рекламодателям, но вы теряете доход от рекламы.
Если функциональность paywall нарушена, пользователи могут читать некоторые платные статьи бесплатно, и это снижает конверсию. Неделя может быть приемлемой, но не целый месяц.
Если не работает функция входа, платные подписчики могут не иметь возможности читать платные статьи. В этом случае вам, возможно, придется их кредитовать.
Знайте свои риски. Отделяйте штрафы, влияющие на бизнес, от штрафов, влияющих на пользователей. По общему правилу, если нет смысла выплачивать компенсацию клиентам, это не SLA, а SLO.
Прагматизм
Прагматичный способ установить SLA — посмотреть на исторические операционные данные по услуге и на их основе вывести бюджет ошибки. Например, большинство сервисов ежемесячной подписки имеют оценочное окно в один месяц для своего SLA. Идея заключается в следующем: сколько некачественного UX придется вытерпеть пользователям, прежде чем они решат отдать свои деньги вашим конкурентам.
Другими словами:
Каково максимальное количество минут, в течение которых пользователи будут спокойно терпеть плохое обслуживание?
Если вы ниже этого уровня, они будут кричать. Если вы выше этого уровня, то обратной связи по этому поводу не будет.
Допустим, в течение последних 30 дней у нас была следующая доступность сервиса:
В этом примере эндпойнт не работал в течение 62 + 17 + 184 + 44 = 307 минут. Учитывая, что в месяце 43800 минут, SLA доступности составляет 100 * (43800-307)/43800 = 99,29 %.
Является ли SLA в 99,29 % разумным, зависит от типа продукта, конкуренции и стратегии штрафов.
Например, если это сервис потокового онлайн-видео, пользователи могут быть не рады платить абонентскую плату за весь месяц, если их любимое шоу не будет воспроизводиться в течение 5 часов в месяц (307м~5ч).
Календарный месяц в сравнении с Lookback window
Бюджет ошибок для многих SLA рассчитывается за календарный месяц. Например, в SLA S3 упоминается "в течение любого месячного биллингового цикла". Это звучит нормально, пока вы не поймете, что реальный опыт пользователей может быть другим.
Например, предположим, что у нас есть служба, SLA доступности которой составляет 99,9 %. Это допускает 43 минуты простоя в месяц. Но что, если простой происходит в конце одного месяца и продолжается в следующем?
В этом сценарии пользователи испытывают 86 минут простоя, но для бизнеса SLA не нарушается.
Это означает, что у команды осталось 3 минуты в бюджете на ошибки в марте, и она может развернуть новый код, который потенциально может нарушить работу сервиса еще больше с точки зрения пользователей.
Другой способ установить окно оценки — использовать 30-дневный Lookback window, то есть с оглядкой на предыдущие периоды. Таким образом, в любой момент времени бюджет на ошибки рассчитывается на основе инцидентов за последние 30 минут, и если он находится в пределах бюджета, команде разрешается развернуть код.
Cреднее время между сбоями или авариями в работе сервиса (MTBF)
В реальности простои могут происходить ночью, когда их испытывает меньше пользователей. Или же оно может быть разбросано в виде более коротких периодов в течение всего месяца, как в данном случае:
Несмотря на их влияние на работу конечного пользователя, в SLA эти факторы обычно не учитываются. Сосредоточение внимания на среднем времени между отказами (MTBF) может облегчить эту проблему.
MTBF является важной метрикой для систем с длительными непрерывными сеансами. Например, при просмотре фильма паузы "Loading..." могут серьезно ухудшить впечатления пользователя.
С другой стороны, для транзакционных сервисов, таких как REST API, MTBF может быть менее важен, потому что на стороне клиента могут действовать другие модели отказоустойчивости, например повторные попытки. В этом примере сокращение MTTR (среднего времени решения проблемы) имеет более высокий приоритет для пользовательского опыта.
Время работы (Runtime)
Существуют и другие факторы, влияющие на SLA. Допустим, у сервиса есть один единственный экземпляр. В декабре 2021 года в AWS произошло несколько инцидентов с большим радиусом поражения. Даже если в сервисе или его конфигурации не было никаких изменений, конечная точка все равно может оказаться недоступной для конечного пользователя, что повлияет на SLA:
Есть и более мелкие сбои, которые не попадают в новости, но все равно влияют на SLA и находятся вне вашего контроля. Стихийные бедствия — один из тех случаев, когда требуется стратегия аварийного восстановления. Есть несколько способов построить более надежную систему поверх менее надежной среды исполнения:
Поскольку регионы AWS изолированы друг от друга, обычно сбой происходит только в этом регионе. Один из способов повысить надежность - обеспечить избыточность в нескольких регионах.
Еще более надежным (и дорогостоящим) решением является стратегия с несколькими провайдерами, когда сервис реплицируется на нескольких облачных провайдеров. Недостатком такого решения является отказ от использования функций конкретного производителя для создания переносимого решения. Такой отказ может ограничить решение "неуправляемыми" сервисами, что может привести к снижению SLA.
Обратите внимание, что сторонние страницы со статусами могут не рассказать всей истории.
Можно наивно полагать, что локальная среда исполнения может гарантировать лучший SLA. AWS — крупнейший поставщик облачных услуг, и вся их бизнес-модель зависит от надежности сервиса. Они знают свое дело, но все равно ошибаются. Нет никакой гарантии, что решение, созданное на месте или на заказ, сможет превзойти AWS, если только у вас нет огромного бюджета и армии экспертов.
Инструмент измерения
Еще один аспект — способ измерения SLA. Такие компании, как Pingdom или DataDog, строят всю свою бизнес-модель на надежном мониторинге, однако и они время от времени терпят неудачу. Некоторые компании в целях экономии средств создают собственные инструменты мониторинга. Это может быть просто преждевременной оптимизацией затрат для потенциального масштабирования или вполне обоснованной. Но чаще всего инструментарий не соответствует коммерчески доступному, и это вредит наблюдаемости, которая является средством выявления и устранения проблем с надежностью. Кроме того, когда инструмент SLA выходит из строя одновременно с самой системой, которую он должен контролировать, вы практически работаете вслепую:
В этом сценарии наблюдаемый SLA составляет 99,48 % вместо фактических 99,29 %. Разница может быть невелика, но она может стать решающим фактором, стоит ли развертывать новые изменения или подождать, пока не будет достаточно бюджета на ошибки.
Место измерения
Еще один важный аспект — место измерения SLI. Например, доступность SLI может быть измерена в любом из этих мест:
Изнутри кластера. Например, подсчет количества успешных проверок работоспособности Kubernetes, разделенный на общее количество проверок работоспособности. Это не дает хорошего представления о времени работы с точки зрения пользователя. Кроме того, неудачная проверка работоспособности — это сигнал планировщику Kubernetes, и нет никакой гарантии, что она вообще повлияет на конечного пользователя.
Вне кластера, но в том же облачном провайдере. Если облачный провайдер столкнется с проблемами, это может повлиять как на сервис, так и на инструмент мониторинга, и мы будем работать вслепую.
Использование стороннего провайдера через публичный интернет. Если сторонний провайдер работает не только с тем же облачным провайдером, это может дать хороший сигнал о пользовательском опыте. С другой стороны, эти сторонние провайдеры обычно имеют несколько ограниченных локаций, из которых они запускают свои тесты. Кроме того, связь этих сторонних производителей с Интернетом обычно более стабильна, чем, скажем, у пользователей Wi-Fi.
От клиентского приложения пользователя. Дает наиболее точный сигнал, поскольку измеряет время падения системы с точки зрения конечного пользователя. С другой стороны, он может загрязнить ваши данные, основываясь на любой не относящейся к делу проблеме подключения, которая может возникнуть у конечного пользователя и не находится под вашим контролем.
В зависимости от продукта и степени риска вы можете выбрать одно или несколько из этих мест измерения.
Страница состояния
Иногда хорошее сообщение об ошибке может компенсировать плохую производительность. Это действительно так. Если системы клиентов ломаются из-за нарушения SLA, самое меньшее, что вы можете сделать, — это помочь им определить причину и избавить их от необходимости ломать голову.
Наличие страницы состояния, которая активно отслеживает конечные точки, может улучшить опыт клиента. Нет смысла это скрывать.
Укрепляйте доверие при каждом инциденте.
Вот как это делает AWS, а вот список сторонних тулз, которые могут создать страницу состояния для ваших конечных точек.
Выборка (Sampling)
Сбор, хранение и анализ полного набора данных для расчета SLA может быть дорогостоящим с точки зрения затрат. Это может даже навредить другим критическим показателям, таким как производительность или задержка.
Например, система мониторинга датчиков IoT с высоким трафиком в реальном времени может получать миллионы точек данных в секунду. Если предположить, что показатель Error Rate SLI является чем-то достойным SLA, то может возникнуть соблазн отслеживать каждую точку данных. На практике это может замедлить работу системы в зависимости от архитектуры. Кроме того, огромное количество данных может не соответствовать требуемому разрешению SLA.
Если система стремится к SLA на уровне 99 %, а в секунду поступает 1-5 миллионов заявок, то для вычисления SLA с достаточным разрешением достаточно выбрать всего 0,1 % данных. Это все равно дает нам 1-5 тыс. точек данных в секунду, что позволяет измерять SLI с разрешением 0,1.
При выборке вместо анализа всего набора данных очень важно убедиться, что выборка представляет все данные статистически. То есть вы не получаете данные только с одного узла, который, как оказалось, работает нормально, а остальные испытывают проблемы.
Синтетические и реальные потоки
Многие инструменты, такие как UptimeRobot или Pingdom, позволяют создавать синтетические запросы к вашим сервисам для измерения SLA. Metrist.io — это более продвинутая версия, позволяющая исследовать более сложные аспекты, например все возможные действия в S3. Кроме того, существуют такие инструменты, как DataDog synthetics и NewRelic synthetic, которые позволяют создавать сценарии синтетического путешествия пользователя по нескольким страницам/конечным точкам.
Все это хорошо, но это синтетика. Более реалистичные данные (и, по общему признанию, более сложные) получаются при измерении реального пользовательского опыта.
Синтетические измерения проще, дешевле и более предсказуемы, но у них есть несколько недостатков:
Оно может не отражать реальные впечатления пользователей от вашего сервиса в полном объеме и давать ложное чувство уверенности.
Даже если он моделирует пользовательский опыт с хорошей точностью, когда он был создан, он может отклониться от реального потока по мере развития продукта.
Это создает ложную нагрузку на систему, и необходимо принять дополнительные меры, чтобы отфильтровать эти данные от реальных бизнес-показателей (например, количества активных пользователей в день). Это может даже увеличить расходы, поскольку синтетическая нагрузка вызывает ненужное масштабирование или препятствует выходу сервиса из эксплуатации.
Не только доступность
В этой статье основное внимание уделяется SLI доступности (он же uptime), потому что обычно, когда люди говорят об SLA, они думают именно об этом.
Однако сервис может работать медленно или ошибаться, что негативно сказывается на впечатлениях клиентов.
SLA может быть установлен для любого SLI, который оказывает непосредственное влияние на клиентский опыт или факторы бизнес-риска. В отличие от SLO, который определяется для каждого SLI, SLA может быть определен только для некоторых SLI. Помните, что это чревато юридическими и финансовыми санкциями.
Как правило, SLI, которые напрямую связаны с вашими бизнес-рисками, являются хорошими кандидатами на SLA.
Пример:
Github: если запуск отправки коммита занимает слишком много времени, это может нарушить конвейеры CI/CD и испортить репутацию Github до такой степени, что люди могут задуматься о переходе к конкурентам, таким как BitBucket или GitLab. Поэтому они могут определить SLA для задержки отправки коммитов.
CNN: если слишком много рекламы не отображается должным образом или не видна на странице, возможно, существует какая-то проблема на стороне клиента, которая вредит доходам от рекламы. Поэтому они могут определить SLA для частоты ошибок при показе рекламы.
Одно известное агентство из 3 букв: если слишком много людей переходят на Linux, потому что агент сбора данных, встроенный в другие операционные системы, потребляет слишком много процессора или пропускной способности сети, это уменьшает количество точек наблюдения и увеличивает риск национальной безопасности! Поэтому они могут определить SLA для показателей насыщенности процессора/сетей.
Заключение
Реальный мир неоднороден, и существует множество переменных, которые могут повлиять на надежность системы. Хорошее SLA должно учитывать соответствующие показатели, которые согласуются с клиентским опытом, бизнес-моделью и рисками.
Если вы услышите, что кто-то говорит: "Мне нужно 5 девяток", а ресурсов на 2 девятки, не смейтесь. Отправьте им эту статью. Но не стесняйтесь выйти из комнаты, если они просят 100 %!
В идеальном мире SLA должны устанавливаться совместно с образованными командами маркетологов и юристов, которые понимают, что такое толерантность пользователей, и готовы в случае нарушения SLA принять меры.
Если вы SRE, то приходите на курс SRE: Observability. Научитесь агрегировать SLO/SLI в одну или несколько высокоуровневых метрик, работать с алертами и инцидентами, оценивать надёжность, рассчитывать error budget.