SLA, SLO и SLI: в чем разница?

Что такое SLA?

SLA (соглашение об уровне обслуживания) — это соглашение между поставщиком и клиентом об измеримых показателях, таких как время безотказной работы, время реагирования, а также мерах ответственности.

Эти соглашения обычно составляются новыми юридическими и бизнес-командами компании. В них включаются обещания, которые вы даете клиентам, а также последствия, которые повлечет за собой невыполнение этих обещаний. Как правило, последствия включают в себя штрафы, компенсации или продление лицензий.

Задача SLA

Как известно, SLA сложно измерить, представить в отчете и выполнить. Эти соглашения (обычно их пишут люди без детальных знаний о технологиях) часто содержат обещания, которые командам трудно измерить. Они не всегда соответствуют текущим и постоянно меняющимся бизнес-приоритетам и не учитывают всех тонкостей.

Например, соглашение SLA может содержать обещание, что команды решат проблемы с продуктом X в течение 24 часов. При этом в SLA не оговаривается, что произойдет, если клиенту потребуется 24 часа на отправку ответов или снимков экрана, необходимых команде для диагностики проблемы. Означает ли это, что 24 часа, отведенные команде, пропали из-за медлительности клиента? Или отсчет времени начинается после получения отклика от него? В SLA должны быть ответы на эти вопросы, но часто их нет. Поэтому многие менеджеры ИТ относятся к соглашениям неодобрительно.

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

Кому нужны соглашения SLA?

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

Что такое SLO?

SLO (цель уровня обслуживания) — это соглашение в рамках SLA о конкретном показателе, например о времени безотказной работы или времени реагирования. Таким образом, если соглашение SLA является формальным соглашением между вами и клиентом, то SLO — это отдельные обещания, которые вы даете клиенту. Соглашения SLO формируют ожидания клиентов и показывают командам ИТ и DevOps, каких целей они должны достичь и на какие показатели ориентироваться.

Задачи SLO

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

Кому нужны соглашения SLO?

Если соглашения SLA актуальны только для платных клиентов, соглашения SLO могут быть полезны как для платных, так и для бесплатных аккаунтов, а также для внутренних и внешних клиентов.

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

Что такое SLI?

Индикатор уровня обслуживания (SLI) измеряет соответствие цели уровня обслуживания (SLO). Например, если в SLA указано, что системы будут доступны 99,95 % времени, то в качестве SLO, вероятно, будет выбрано время безотказной работы 99,95 %, а в качестве SLI — фактическое измеренное время безотказной работы. Возможно, оно составит 99,96 %. Или 99,99 %. Чтобы удовлетворять требованиям SLA, индикатор SLI должен соответствовать обещаниям, зафиксированным в этом документе, или превосходить их.

Задачи SLI

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

Создайте подробный план аварийного восстановления

Что вы будете делать, когда столкнетесь с простоем? Если вы еще не знаете ответ на этот вопрос, значит, ваш ответ — «Терять драгоценное время, пытаясь понять, что делать».

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

Кому нужны индикаторы SLI?

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

Согласуйте SLA с ожиданиями клиентов

Каждая часть соглашения с клиентом должна создаваться с учетом того, что важно для клиента. Фактически инцидент может требовать рассмотрения 10 различных компонентов. Но клиенту важно только, чтобы система функционировала согласно его ожиданиям.

Соглашения SLA и SLO должны отражать эту ситуацию. Не усложняйте соглашения, углубляясь в детали и давая отдельные обещания по каждому из этих 10 компонентов. Ограничьтесь обещаниями в отношении функциональных возможностей верхнего уровня, ориентированных на пользователя. Это повысит удовлетворенность клиентов и не запутает их, а кроме того, облегчит работу ИТ-специалистам, ответственным за выполнение обещаний SLA.

Пишите SLA простым языком

Клиенты не всегда будут сами обращаться за разъяснениями. Поэтому если соглашение SLA написано слишком сложным языком, в будущем вас могут ожидать неприятные недоразумения. Чем проще язык, тем меньше вероятность конфликтов с клиентами в будущем.

Чем меньше SLO, тем лучше

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

Не каждый отслеживаемый показатель должен стать SLI

Аналогичным образом, отслеживание работы системы по 10 компонентам для каждого из 10 соглашений SLO очень быстро станет неподъемной задачей. Вместо этого мыслите стратегически: выберите действительно важные показатели для основных соглашений SLO и направьте свою энергию на их эффективное отслеживание.

Учитывайте факторы, не зависящие от ИТ-команды

Что происходит, когда решение проблемы задерживается по вине клиента? Если эта ситуация четко не оговорена в SLA, команда будет стремиться к невыполнимому стандарту, пытаясь решить проблему без участия клиента.

Предусмотрите бюджет ошибок

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

Кстати, компания Google рекомендует использовать остаток бюджета ошибок на плановые простои. Это помогает выявлять непредвиденные проблемы (например, ненадлежащее использование серверов со стороны сервисов) и поддерживать соответствующие ожидания клиентов.

Не ставьте перед собой труднодостижимые цели

Just because your team can probably maintain 99.99% uptime doesn’t mean that 99.99% should be your SLO number. It’s always better to under-promise and overdeliver. This is especially true for agile teams who want to launch early and often and need an error budget to keep up that quick pace.

Как это влияет на SRE?

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

Соблюдайте соглашения SLA с помощью Jira Service Management: решайте запросы на основе приоритетов, используйте правила автоматической эскалации, чтобы отправлять уведомления нужным участникам команды и предотвращать нарушения SLA.