Самый дорогой уровень поддержки нужен не каждому устройству. Разделите оборудование по последствиям отказа: где допустим простой на день, а где восстановление требуется в течение нескольких часов.
Начните с карты сервисов, а не списка серверов
Свяжите каждое устройство с бизнес-сервисами: системой расчетов, производственной линией, файловым ресурсом, тестовой средой. Один физический сервер может поддерживать десятки виртуальных машин, поэтому его критичность выше стоимости самого оборудования.
| Класс | Допустимое влияние | Подход к сервису |
|---|---|---|
| Критичный | Остановка ключевого процесса или обязательств | Круглосуточный прием, короткая реакция, согласованное восстановление и локальный ЗИП |
| Важный | Заметное снижение производительности или ручной обход | Расширенное окно поддержки и контролируемая замена |
| Стандартный | Есть резерв или допустима пауза | Базовый уровень с плановым обслуживанием |
| Лабораторный | Не влияет на production | Экономичный уровень и восстановление по согласованию |
Оцените стоимость одного часа простоя
Сложите прямую потерю выручки или выпуска, простой сотрудников, договорные последствия, восстановительные работы и влияние на клиентов. Не требуется точность до рубля: диапазон уже позволяет сравнить дополнительную стоимость сервиса с риском нескольких часов ожидания.
Разделите реакцию, решение и восстановление
Время регистрации или первой реакции не равно времени возвращения сервиса. В договоре должны быть понятны часы покрытия, момент начала отсчета, уровни приоритета, время диагностики, доставка детали, работы на площадке и условия приостановки таймера. Отдельно уточните, является ли время восстановления обязательством или целевым показателем.
SLA работает только при готовой эксплуатации
- Актуальный список оборудования и серийных номеров
- Назначенные контакты и схема эскалации
- Удаленный доступ и выгрузка диагностических журналов
- Пропускной режим для инженеров
- Согласованное место хранения ЗИП
- Резервные копии конфигурации и понятный план возврата сервиса
Пересматривайте критичность после изменений
Тестовый сервер может стать production-узлом, а одиночный сервис — переехать в кластер. Пересматривайте уровни не реже раза в год и после крупных миграций. Используйте статистику обращений: повторяющиеся инциденты могут требовать изменения архитектуры, а не только более быстрого выезда инженера.
- Классифицировать бизнес-сервисы
- Привязать оборудование к сервисам
- Определить допустимый простой
- Посчитать диапазон ущерба
- Сопоставить времена реакции и восстановления
- Проверить географию и ЗИП
- Зафиксировать эскалацию и отчетность
Коротко о главном
Частые вопросы
Время реакции — это время ремонта?
Нет. Реакция обычно означает начало обработки обращения. Условия диагностики, доставки и восстановления нужно проверять отдельно.
Нужен ли круглосуточный SLA для резервного узла?
Зависит от того, сколько система может работать без восстановленного резерва и каков риск второго отказа в этот период.
Можно ли одинаково поддерживать все оборудование?
Можно, но это часто экономически неэффективно. Рациональнее назначать уровень по критичности сервиса и роли конкретного узла.