Перейти к содержанию

🟡 Статус: Design draft · v0.1

Подход правильный, но конкретный код, конфиги или пороги требуют валидации в вашем окружении.

10. SLA и сервисный каталог

Глава о том, что такое SLA, чем он отличается от SLO/OLA/UC, почему его нельзя подписывать без 3 месяцев исторических данных, и как показать бизнесу стоимость каждой «девятки».

Это глава с пометкой 🟡 design draft — концепции стабильные и взяты из ITIL/SRE-практики, но конкретные цифры по сервисам (1С, Exchange, AD, файловые шары) — отправные точки. Их обязательно калибровать по вашим реальным историческим данным.

Сервис ≠ компонент. Главная путаница

Это первое что нужно понять.

Сервис — то, что потребляет бизнес. Описывается в бизнес-терминах, не в технических. Компонент — то, что эксплуатирует ИТ. Описывается технически.

❌ Неправильно (компоненты, выдаваемые за сервисы) ✅ Правильно (сервисы)
MSSQL 1C-ERP (учётная система)
Exchange Server Корпоративная почта
File Server Общий доступ к документам
Active Directory Единый вход в системы
Print Server Печать документов
Veeam Резервное копирование данных

Бизнесу плевать, лежит ли MSSQL — ему не плевать, что «в 1С нельзя провести документ». Это разные плоскости.

Service Definition — из чего состоит описание сервиса

Минимальный набор полей, без которых сервис не описан:

Поле Пример (Email)
Имя сервиса Корпоративная электронная почта
Описание для бизнеса Отправка/получение почты, календарь, задачи. Доступ из веба, мобильных и Outlook
Бизнес-владелец Директор по корпоративным коммуникациям
ИТ-владелец Руководитель отдела инфраструктуры
Категория Основной (mission-critical / business / supporting)
Часы работы 24x7 (или 06:00-22:00 будни)
Пользователи Все сотрудники, ~2400 учётных записей
Точки доступа OWA по mail.plant.local, Outlook, мобильные ActiveSync
Критичность P1
Компоненты 4 сервера Exchange 2016 в DAG, 2 LB, AD, DNS, СХД для БД, Veeam
Зависимости AD (без неё нет аутентификации), DNS, сеть, интернет (для внешней почты)
Метрики SLI доступность OWA, e2e отправка-получение, размер очереди
Целевой SLO 99.5% в рабочее время
SLA (если есть формальный с бизнесом)
Регламент поддержки 24/7 для P1, 8x5 для остального
Связанные runbook'и ссылки
Документация ссылки

Без этого описания SLA подписывать нельзя. Это «о чём договариваемся».

Каталог сервисов — как обычно делают

Подход 1: «Снизу вверх» (от инфраструктуры) ❌

Инженер смотрит, что есть в инфраструктуре, и пишет: - Сервис «MSSQL» - Сервис «AD» - Сервис «Файловые шары»

Это не каталог сервисов, это перечень компонентов. Бизнесу непонятно, обсуждать нечего.

Подход 2: «Сверху вниз» (от бизнеса) ✅

Опрос бизнеса: «Какие ИТ-системы вам критичны для работы?». На выходе примерно такой ответ: - «1С чтобы документы проводить» - «Почта» - «Сетевые папки с чертежами» - «Принтеры» - «Интернет»

Далее каждый такой «сервис» декомпозируется на компоненты. Каталог = бизнес-перспектива + техническое наполнение.

Подход 3: Гибридный

Сначала выбираются топ-10 систем, известных бизнесу, и описываются как сервисы. Остальное — «инфраструктурные сервисы» (AD, DNS, сеть, бэкапы) — описывается отдельным разделом, с нотацией: «это сервисы для других сервисов, бизнес их не видит».

Реальный размер каталога

Размер организации Сервисов в каталоге
Небольшое предприятие (300 чел) 8-15
Средний завод (3000 чел) 20-40
Крупный холдинг 100-300
Госкорпорация 500-1000+

Для завода типичные 15-25 бизнес-сервисов + 5-10 инфраструктурных. Не 200. Если у вас «150 сервисов» — это компоненты в маске сервисов.

SLA, SLO, OLA, UC — иерархия (по ITIL)

Термин С кем Кто кому обещает
SLA (Service Level Agreement) ИТ ↔ Бизнес ИТ обещает бизнесу
SLO (Service Level Objective) внутри ИТ внутренняя цель ИТ, может быть строже SLA
OLA (Operational Level Agreement) команда ИТ ↔ команда ИТ сетевая команда обещает команде инфраструктуры
UC (Underpinning Contract) ИТ ↔ внешний поставщик провайдер обещает ИТ

Почему важна иерархия

SLA с бизнесом:    Email доступен 99.5%
   │
   └─ SLO внутри ИТ:        99.7% (запас!)
         │
         ├─ OLA от сетевой команды:  99.9% сетевая связность
         ├─ OLA от DBA:         99.8% БД доступна
         └─ UC от провайдера:   99.5% интернет

SLA не может быть лучше, чем худший из его некомпенсированных компонентов. Если интернет от провайдера 99.5% и нет резервного канала — вы не можете обещать почту 99.9%. Если есть два независимых провайдера с 99.5% каждый — суммарная доступность через резервирование выше, чем у одного. Резервирование поднимает потолок SLA, но требует архитектурных решений.

И наоборот: SLO внутри ИТ должен быть чуть строже SLA с бизнесом — чтобы был запас на флуктуации.

Структура нормального SLA

То, что должно быть в любом SLA-документе:

# SLA: Корпоративная электронная почта

## 1. Стороны соглашения
Поставщик: Отдел ИТ
Заказчик: <бизнес-подразделение или вся компания>
Действует с: 2026-09-01
Пересмотр: ежегодно

## 2. Описание сервиса
[ссылка на Service Definition]

## 3. Часы предоставления сервиса (Service Hours)
24x7, кроме окон технических работ:
- Плановые работы: первая суббота месяца, 22:00-04:00
- Уведомление за 5 рабочих дней

## 4. Целевые показатели (Service Levels)

### 4.1 Доступность (Availability)
Цель: ≥ 99.5% в часы предоставления сервиса
Измеряется: синтетика OWA каждые 5 минут с 2 точек
Расчёт: (success_checks / total_checks) × 100
Не учитывается в downtime: плановые окна, форс-мажор

Уточнения в SLA (иначе возникнут споры):
- **No data:** проверка не получила ответа → засчитывается как failure или исключается?
- **Одна точка из двух упала:** сервис считается недоступным или нет? (рекомендуется: только если обе точки)
- **Длительность инцидента:** считается ли один failed check (5 мин) downtime или нужно N последовательных?

### 4.2 Производительность (Performance)
Время доставки внутреннего письма: ≤ 60 секунд (медиана за месяц)
Время открытия почты в OWA: ≤ 3 секунды (95-й перцентиль)

### 4.3 Время реакции на инциденты
| Severity | Реакция | Восстановление |
|----------|---------|----------------|
| P1 (полный отказ)| ≤ 15 мин | ≤ 4 часа |
| P2 (деградация) | ≤ 1 час   | ≤ 8 часов |
| P3 (одиночный) | ≤ 4 часа  | ≤ 2 рабочих дня |

## 5. Исключения
SLA не действует в случае:
- Форс-мажора (стихийные бедствия, отключение электричества от поставщика)
- Действий третьих лиц (атаки, действия провайдера за пределами OLA)
- Запросов изменений вне согласованной процедуры
- Использования сервиса не по назначению

## 6. Отчётность
- Ежемесячный отчёт SLA — до 5 числа следующего месяца
- Квартальный обзор — на встрече с бизнесом
- Доступ к real-time дашборду — постоянный

## 7. Эскалация при неисполнении
Не достижение цели в месяц:
- 1-й раз: уведомление CIO + анализ причин
- 2-й раз подряд: формальный пересмотр процессов
- 3-й раз: пересмотр SLA или дополнительное финансирование

## 8. Подписи и согласования
[бизнес-владелец] [CIO] [дата]

Если в SLA нет хотя бы одного из пунктов 3, 4, 5, 6 — это не SLA, это пожелание. И ИТ, и бизнес потом друг друга обвиняют.

Главный вопрос — как измеряется

Это где обычно всё рушится. Бизнес пишет «почта 99.9%», админ кивает, через месяц спор.

Что считается «недоступным»

Возьмём Email и распишем варианты:

Что измеряется Кто обычно так считает Когда срабатывает
OWA выдаёт 5xx на login страницу Правильно для пользователя login сломан
Все 4 Exchange-сервера отвечают по ICMP Неправильно (ping ≠ работа) редко
Очередь на отправку < 1000 Технический индикатор внутреннее
Полный e2e цикл: login → отправить себе → получить за 2 мин Идеал, золотой стандарт реальный отказ
Mailbox database mounted на каждой ноде Внутренняя метрика DAG DAG-уровень, не пользователь

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

Часы работы — главный читерский трюк

99.5% за 24x7 = 3.6 часа downtime/месяц
99.5% за рабочее время (8x5x12 = ~240ч) = 1.2 часа/месяц

То же число «99.5%» означает разные обязательства. Всегда в SLA пишется конкретное определение часов. «В рабочее время в будние дни». Без этого — бесполезный документ.

Плановые работы — не downtime (если согласованы заранее)

В правильном SLA согласованное заранее окно работ не считается downtime. Иначе любая нормальная эксплуатация (патчи, апгрейды) убивает SLA. Ключевое слово — «заранее»: уведомление за N дней, явное согласование с бизнес-владельцем.

Аварийные работы не исключаются из SLA задним числом. Аварийное окно = downtime. Иначе любой инцидент можно будет ретроспективно объявить «незапланированными работами».

Согласованное окно: первая суббота 22:00-04:00 = 6 часов в месяц
Не учитываются в knockoff из 99.5%

Партиальная деградация

Что если у 5% пользователей не работает, а у остальных норм? Это: - 100% downtime? - 5% downtime? - 0% (кому-то же работает)?

Должно быть в SLA: «Сервис считается недоступным, если функция недоступна более чем 10% пользователей» — конкретный порог.

Практические примеры с разбором

Пример 1: Email / Exchange

Что хочет бизнес: «Почта работает, 99.9%, 24/7».

Что реально достижимо: 99.5%-99.7% в рабочее время для on-premise Exchange с DAG, при условии хорошей сети и инфраструктуры.

Реальный SLA (правильный):

Service: Корпоративная почта
Service Hours: 24x7 (фактическое использование 90% в 06:00-22:00 будни)
Availability target: 99.5% (∼3.6 часа downtime в месяц)
Measurement: синтетика OWA login + отправка-получение каждые 5 минут
Performance: внутреннее письмо доставлено за ≤60 сек, медиана
Maintenance window: первая суббота месяца 22:00-04:00 (6ч)
Response time: P1 — реакция 15 мин, восстановление 4 часа

Подводные камни: - Если бизнес настаивает на 99.99% — нужен второй ЦОД, репликация в реальном времени, LB через несколько провайдеров. Это +50% к стоимости. Покажи цифры. - ActiveSync для мобильных часто ломается отдельно от OWA — отдельный SLI или явное исключение - Outlook через MAPI/RPC over HTTPS — отдельный канал, отдельный риск - Внешняя почта зависит от MX, DNS, провайдера — это OLA или UC

Пример 2: 1C-ERP

Что хочет бизнес: «1С работает всегда, особенно когда конец месяца, и быстро».

Что реально: Зависит от конфигурации, нагрузки, обновлений. Очень сложно держать высокий SLA.

Реальный SLA:

Service: 1C-ERP (учётная система)
Service Hours: 06:00-22:00 будни + субботы при закрытии периода
Availability target: 99.0% в часы работы (∼2 часа downtime/месяц)
Measurement: синтетика — login пользователя + создать/удалить тестовый документ
Performance: ответ интерфейса ≤3 сек на типовых операциях (95-й перцентиль)
Maintenance windows:
  - Еженедельные: пятница 22:00-00:00 (тех. обновления)
  - Месячные: вторая суббота, 4 часа (релизы)
  - ЗАПРЕТ на работы: 25-31 числа каждого месяца, годовой период (15 декабря - 15 января)
Response time: P1 — реакция 15 мин, восстановление 2 часа
Frozen period: с 25 по 5 число — никаких изменений (закрытие периода)

Подводные камни: - 1С-обновления (платформа, конфигурация) — отдельный change-процесс, не в обычном maintenance - Регламентные задания (закрытие месяца) — иногда блокируют пользователей. В SLA — отдельное окно, не «недоступность» - Лицензии HASP — единая точка отказа. Это технический риск, требует mitigation (HA hasp-сервер) - «1С тормозит» — самая частая жалоба. Чёткое определение performance-SLI в синтетике, иначе спор бесконечный - Базы данных (MSSQL/PG) — отдельный OLA от DBA-команды

Пример 3: Файловые шары / DFS

Что хочет бизнес: «Папки доступны».

Реальный SLA:

Service: Общие сетевые папки
Service Hours: 24x7
Availability: 99.0% — это РЕАЛИСТИЧНО (∼7 часов/месяц)
Measurement: синтетика — mount + read + write тестового файла, каждые 10 минут с 3 точек сети
Performance: открытие тестового файла ≤2 сек, запись 1 МБ тестового файла ≤3 сек (95-й перцентиль; конкретные пороги — по базовому уровню в вашей инфраструктуре)
Maintenance: ночные окна по необходимости, уведомление за 24 часа
Recovery: для удалённых файлов — восстановление из снапшота TrueNAS (≤7 дней назад)

Подводные камни: - DFS-репликация при деградации может «не отдавать» актуальную версию — пользователь видит старый файл, считает что «работает». Это сложно поймать в SLI - ACLs — частый источник «не работает»: пользователь не видит папку, говорит «всё лежит». Это не availability, это access management - Антивирус на шарах может тормозить — performance проблема

Пример 4: Печать

Что хочет бизнес: «Принтеры работают всегда».

Реальный SLA:

Service: Печать документов
Service Hours: 06:00-22:00 будни
Availability: 95% (это ОЧЕНЬ хороший SLA для печати)
Measurement: доступность Print Spooler (служба), состояние очереди (через SNMP или WMI), доступность Print Server; редкое тестовое печатное задание — только в контролируемых условиях и не как постоянная синтетика (тратит бумагу, тонер, мешает очереди)
Caveat: не покрывает физические проблемы принтера (бумага, тонер) — это отдельный процесс снабжения
Response time: замена картриджа в день обращения, замена принтера в 2 рабочих дня

Подводные камни: - Это самая ненадёжная часть инфраструктуры в любой компании. Принтеры мрут, бумага кончается, кто-то застрял. SLA выше 95% — нереалистично. - В SLA честно прописать: «зависит от расходных материалов и физического обслуживания» - Бизнес часто хочет тут 99%+ — покажи статистику фейлов, объясни почему

Пример 5: SCADA-bridge (для завода)

Что хочет производство: «Обмен данными АСУ ТП и корпоративной сетью без сбоев».

Реальный SLA:

Service: Шлюз АСУ ТП ↔ корпоративная сеть
Service Hours: 24x7 (производство непрерывное)
Availability: 99.9% (это критичный сервис — ∼43 минуты/месяц)
Measurement: TCP-доступность OPC-сервера, ICMP до bridge-хоста — это технический SLI шлюза, не бизнес-SLI обмена данными. Соответствие 99.9% требует подтверждения исторических данных. Для реального SLI обмена нужны метрики приложения (OPC-сессии, теги данных, задержка тегов) — только по согласованию с АСУ ТП
Performance: задержка обмена сообщениями ≤5 сек (95-й перцентиль; верифицировать с командой АСУ ТП)
Maintenance: только в плановое технологическое окно завода (согласовывается с производством)
Special: НЕ ИЗМЕНЯТЬ в одностороннем порядке — все работы согласуются с АСУ ТП

Подводные камни: - Это смежная зона ответственности с АСУ ТП. SLA должен быть подписан тремя сторонами: ИТ + АСУ ТП + Производство - В формулировке SLI никакого вторжения внутрь SCADA. Только внешние индикаторы - Любой инцидент — потенциально регулируемое событие (КИИ)

Как договариваться с бизнесом — процесс переговоров

Принцип: показывай выбор, не диктуй

Никогда не приходи с одним числом «99.5%». Приходи с вилкой и стоимостью:

Корпоративная почта — варианты SLA:

Вариант A: 99.0% (∼7 часов downtime/месяц)
  Стоимость: текущая инфраструктура, ничего не меняем

Вариант B: 99.5% (∼3.6 часа/месяц) ← рекомендуем
  Стоимость: +1 admin-час/неделю на профилактику + апгрейд бэкапов

Вариант C: 99.9% (∼43 минуты/месяц)
  Стоимость: дополнительный сервер, второй интернет-канал, +2М рублей CapEx, +500K/год OpEx

Вариант D: 99.99% (∼4 минуты/месяц)
  Стоимость: второй ЦОД, репликация, гео-балансировка, +50М CapEx, +5M/год OpEx

90% бизнес-владельцев после такой таблицы сами выбирают вариант B. Когда видят цену 99.99%, страсть к нему пропадает.

Принцип: меряем без обязательств 3 месяца

«Подписывать SLA сразу нельзя — мы не знаем реального поведения системы. Давайте 3 месяца меряем по предложенным метрикам, потом обсудим, что обещать.»

Это даёт базовый уровень, защищает обе стороны. Никогда не подписывай SLA без 3 месяцев исторических данных.

Принцип: бизнес-владелец, не техлид

SLA подписывает бизнес, не ИТ. Если просят подписать ИТ-руководителя обеих сторон — это не SLA, это OLA, и работать он не будет.

Как делают в реальности (нелицеприятная правда)

Маленький бизнес / средние компании

  • Формальных SLA нет. Есть «ожидания» и регулярные крики
  • ИТ-директор живёт в режиме «всё должно работать», бюджета на нормальную инфраструктуру нет
  • Когда что-то ломается — обвинения, никакого error budget
  • Решение: даже неподписанный «черновик SLA» лучше ничего. Хотя бы внутри ИТ договоритесь о приоритетах.

Заводы / промышленные предприятия

  • SLA часто формально есть, но никто не меряет по факту
  • Бумаги подписаны, цифры взяты с потолка («99.9% — а сколько надо?»)
  • Реальный мониторинг — отсутствует или не сходится с SLA
  • Часто SLA жёстче чем реально достижимо — из-за этого все живут в режиме «нарушения», ИТ всегда виновата
  • Решение: провести «честный аудит SLA» — какие реалистичны, какие — фикция. Обновить с реальными цифрами. Это политически сложно.

Госорганизации

  • SLA как часть договора с подрядчиком — всегда есть, и всегда жёсткий
  • Внутри своего ИТ — формализм, реальная работа без оглядки на цифры
  • Решение: для подрядных SLA — отдельный процесс, не путать с внутренним

Крупный частный бизнес / банки

  • Формальные SLA + реальный мониторинг + ежемесячные обзоры
  • Зрелый процесс с пенальти и эскалациями
  • Зачастую SLA → SLO + Error Budget (современный подход)
  • Это где «как надо» в реальности

IT-сервис-провайдеры

  • SLA — это товар. Они продают именно SLA, не сервис
  • Жёсткие пенальти за невыполнение, иногда возврат денег
  • Решение: изучай как они формулируют SLA — это эталон для практики

Современный подход: SLO + Error Budget

В крупных IT-компаниях (Google, Spotify, и т.д.) от SLA отходят к концепции Error Budget.

Идея

Если SLO 99.5%, то 0.5% — это бюджет на ошибки. Это: - 3.6 часа в месяц на 24x7 - 1.2 часа в рабочее время

Этот бюджет можно тратить осознанно: - На рискованные релизы - На технический долг - На эксперименты

Правило

Если в этом месяце Error Budget исчерпан:
  → замораживаем релизы новых фич
  → команда чинит стабильность
  → пока budget не восстановится в следующем месяце

Это меняет культуру: ИТ и бизнес вместе управляют балансом «надёжность ↔ скорость изменений», а не воюют.

Применимость к заводу

⚠️ Скорее всего нет, в первый год точно. Это для зрелых организаций где есть: - Регулярные релизы - Команды разработки - Business buy-in на компромиссы

Для типичного завода — это аспирация на год 3-5. Сейчас — обычные SLO без error budget.

Что НЕ делать

  • ❌ Подписывать SLA без 3 месяцев данных. Гадать на кофейной гуще.
  • ❌ «Доступность 99.99% по умолчанию». Это число берётся не из воздуха — оно требует архитектуры.
  • ❌ SLA без определения часов работы. Бесполезный документ.
  • ❌ SLA без методологии измерения. Мерь себя сам, это нечестно.
  • ❌ SLA без исключений. Тогда любая плановая работа = нарушение.
  • ❌ Один SLA на все сервисы. «Все системы 99.5%» — лень и непонимание.
  • ❌ Performance в одном числе с availability. Это разные плоскости, мерь отдельно.
  • ❌ SLA для сервиса, у которого нет owner'а. Пустая формальность.
  • ❌ Подписывать SLA «вверх», не имея OLA «вниз». SLA рухнет от первого инцидента у поставщика.
  • ❌ Менять SLA каждый месяц. Ежегодный пересмотр — оптимально.

Минимальный практический подход для вашего завода

Если бы я внедрял на этом заводе с нуля, делал бы так:

Месяц 1-2: Никаких SLA. Только Service Definition для топ-10 сервисов. Просто описать что есть.

Месяц 3-5: Меряем SLI для этих сервисов через synthetic monitoring. Накапливаем baseline.

Месяц 6-7: Внутри ИТ согласовываем SLO (внутренние цели) на основе реальных данных. Бизнес-владельца сервиса полезно вовлечь уже на этом этапе в определение SLI и приемлемых порогов — не для подписания, а для согласования метрик. Это сократит разрыв ожиданий при финальном SLA.

Месяц 8-12: Если SLO стабильно держатся — предлагаем бизнесу формальный SLA. С запасом ±0.5% от SLO.

Год 2: Регулярный обзор, корректировка, обсуждение Error Budget.

Никогда: не подписывать SLA в первые 3 месяца. Это бомба замедленного действия.

Шаблон сервиса (бери и копируй)

Для вашего использования прямо сегодня:

# Service: <Название>

## Описание
<2-3 предложения для бизнес-человека>

## Owners
Business owner: <ФИО, должность>
IT owner: <ФИО, должность>
Reviewer: <CIO>

## Users and access points
Users: <количество, кто>
Access: <откуда подключаются — внутри сети, VPN, веб>

## Hours of operation
<24x7 или конкретные часы>

## Components (technical)
- <компонент 1>
- <компонент 2>
- ...

## Dependencies
- <от чего зависит работа>

## Service Level Indicators (SLI)
| Метрика | Описание | Способ измерения |
|---------|----------|------------------|
| Availability | ... | ... |
| Performance | ... | ... |

## Service Level Objectives (SLO) — внутренние
| SLI | Target |
|-----|--------|
| Availability | 99.X% |
| Performance | <Y сек |

## SLA — внешние обязательства
<Если есть — ссылка на SLA-документ. Если нет — "Не определено" или "В разработке">

## Maintenance windows
<Когда плановые работы>

## Incident response
<Severity matrix, времена реакции, контакты>

## Runbooks
- <ссылки>

## Recent changes
<2-3 последних значимых изменения>

Используйте как болванку — за пару часов опишете топ-10 сервисов, дальше уже разговор на встречах.

Как Zabbix Services работает с SLA

В Zabbix есть нативный механизм Zabbix Services + SLA:

  • Zabbix Service — это объект в дереве сервисов (Services → Services). У него есть алгоритм расчёта состояния (наихудший дочерний, N из M, custom).
  • SLA-политика создаётся отдельно (Services → SLA). Она привязывается к Service через service tags (не event tags!) и определяет: период (Service Hours), цель доступности, исключаемые downtime.
  • Состояние Zabbix Service меняется через problem tags в service tree. Событие с тегом, совпадающим с тегом Service, влияет на состояние сервиса.
  • SLA-отчёт доступен через: Services → SLA report + нативный виджет на Zabbix дашборде (SLA report widget).

Это не полностью заменяет внешний synthetic monitoring, но для отчётности по SLA использовать нативный механизм Zabbix разумнее, чем строить custom scripts.

Связь с остальными главами