Ответ.

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

Базовые шаги:

1. Определяются бизнес-критичные метрики: время отклика, доступность, процент ошибок, время восстановления.
2. Архитектура включает средства мониторинга для автоматического сбора этих метрик.
3. SLA согласовывается с заказчиком, результаты — основа для построения мониторинга и алертов.

Пример определения SLA для веб-сервиса:

• Доступность: 99.9% (downtime не более 43 минут в месяц)
• Время отклика API: не более 200ms в 95% запросов
• Уровень ошибок: не более 0.5%

Ключевые особенности:

• SLA влияет не только на техническую архитектуру, но и на процессы эксплуатации и поддержки.
• SLA часто документируется в спецификациях и договорах.
• Автоматический мониторинг, алерты, отчёты позволяют достоверно фиксировать выполнение SLA.

Вопросы с подвохом.

Можно ли строить SLA только на технических метриках (например, ошибках и отклике)?

Ответ: Ошибочно. Необходимо учитывать и бизнес-метрики (например, успешность совершённых бизнес-операций), чтобы SLA соответствовал ожиданиям бизнеса.

---

Является ли достижение SLA статичным процессом и не требует корректировок после запуска системы?

Ответ: Нет. SLA пересматривается с изменением бизнеса, возросшей нагрузкой и появлением новых требований.

---

Может ли мониторинг SLA базироваться только на результатах внешних систем (ping, http-check) без агентов внутри сервисов?

Ответ: Не рекомендуется. Внешний monitoring важен, но внутренний gathering (агенты, собирающие внутренние метрики) позволяет обнаружить скрытые проблемы раньше, чем они станут заметны снаружи.