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


Чем является цель уровня обслуживания (SLO)?


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


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


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


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


Что такое индикатор уровня обслуживания (SLI)?


SLI это мера выполнения SLO. Это значит, что без SLI не будет и SLO.


Возвращаясь к примеру онлайн сервиса, — если соглашение между поставщиком и клиентом (SLA) обещает обеспечение 99.95 процентов, тогда ваш SLO также будет 99,95 процентов. Ваш SLI это и есть действительное обеспечение, отправляемое вашей системой.


Если ваш SLI больше 99,95 процентов, это значит, что вы выполнили обязательства перед клиентом. Когда 100 процентов выполнения невозможны, целью становится получить цифру, максимально приближающуюся к 100%.


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


Какие выгоды получает команда по техническому обеспечению надежности сайта (SRE) от SLO и SLI?


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


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


Лучшие практики для SLO и SLI


Когда вы соотносите ваш SLO с вашим SLA, очень важно обратить внимание на следующие пункты:


Принимать во внимание ожидания клиентов


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


Использовать максимально упрощённый язык


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


Не каждая метрика это SLO


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


Не обещайте луну с неба, если не сможете ее достать


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


Составьте продуманный план аварийного восстановления


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

Комментарии (2)


  1. r3code
    14.12.2021 22:45
    +2

    Почему вы так смешиваете sla и slo?

    Если у вас есть slo, то он жестче чем sla быть должен. Иначе времени исправиться не остается. Разработчики должны спохватиться раньше.


  1. r3code
    14.12.2021 22:50
    +1

    Выгода есть когда смотришь за error budget (=1-slo) и его расходованием.

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