День 1888. #ProjectManagement
Что Такое SLI, SLO и SLA
При проектировании архитектуры ПО мы должны учитывать как функциональные, так и нефункциональные требования. Сегодня разберём SLO, SLA и SLI и как они влияют на жизненный цикл ПО.
1. Индикатор уровня обслуживания (Service Level Indicator - SLI)
Измеримая мера некоторого аспекта уровня предоставляемого обслуживания: процент времени безотказной работы, время ответа или частота сообщений об ошибках. SLI используются для объективного измерения производительности сервиса и для проверки SLO.
Как отслеживать?
- Тщательно определите проверяемые метрики. Например «ошибки HTTP» - недостаточно чётко. Какие именно? 404, 401 и 500 — обозначают ошибки, но их появление может как указывать, так и не указывать на ошибки в системе.
- Определите функции для проверки качества релизов, чтобы гарантировать, что новый релиз не ухудшит существующие значения SLI.
2. Целевой уровень обслуживания (Service Level Objective - SLO)
Целевой уровень обслуживания между поставщиком услуг и конечным пользователем, который измеряется конкретными показателями. Если SLI —фактическое значение измерения, SLO — конечная цель, которую необходимо достичь для этого SLI. SLO - желаемая цель для некоторых показателей (обычно производительности и надёжности), которых стремится достичь сервис. Вы можете указать значение SLO для каждой метрики, которая важна для вас и ваших клиентов. Например:
- 99% запросов к веб-сервису должны иметь задержку менее 300 мс;
- 99,9% запросов к определённой конечной точке должны иметь задержку менее 100 мс;
- 99,9% запросов должны возвращать успешный код состояния.
SLO являются конкретными, подробными и измеримыми. Например, заявление: «Запросы, как правило, должны быть быстрыми» - слишком расплывчато, и его невозможно измерить.
Как отслеживать?
- Создайте информационную панель для измерения каждого из определённых вами SLO.
- Отправляйте оповещения, если значение достигает порога.
- Спроектируйте архитектуру с учётом значений SLO: например, если необходимо обеспечить низкую задержку для запросов, можно спроектировать асинхронную связь между сервисами или решить развернуть приложение близко к местоположению пользователей.
3. Соглашение об уровне обслуживания (Service Level Agreement - SLA)
Официальное соглашение между поставщиком услуг и клиентом. В отличие от SLO, SLA имеют юридическую силу и предусматривают последствия несоблюдения. Если продукт не соответствует SLA, это может вести к штрафам, неустойкам и т.п. Примером SLA является скорость реагирования техподдержки, например, закрывать открытую клиентом заявку в течение 24 часов.
Взаимодействие между SLO, SLA и SLI существенно влияет на решения по архитектуре ПО:
- SLO и SLI помогают архитекторам определить показатели надёжности и производительности, которым должна соответствовать система. Это влияет на выбор технологий и шаблонов, позволяющих достичь этих показателей. Микросервис или монолит? С# или Rust? Локально или в облаке?
- Для соблюдения требований SLO системе может потребоваться обрабатывать большое количество запросов в секунду, что требует масштабируемых архитектур, таких как микросервисы или бессерверные вычисления.
- Необходимость соблюдения SLA может привести к внедрению механизмов резервирования и аварийного переключения для обеспечения высокой доступности и минимизации времени простоя.
- SLI требуют надёжных систем мониторинга и оповещения для отслеживания производительности услуги в режиме реального времени и уведомления, когда SLO подвергаются риску нарушения.
- Необходимость удовлетворять SLO может влиять на распределение ресурсов, что приводит к принятию решений о балансировке нагрузки, сегментировании базы данных или использовании сетей доставки контента (CDN).
- Штрафы, связанные с SLA, могут повлиять на стоимость, побуждая архитектуру быть более экономичной, при этом соответствуя уровням обслуживания.
Источник: https://www.code4it.dev/architecture-notes/sli-vs-slo-vs-sla/
>>Click here to continue<<