SLA на практике: что на самом деле стоит за цифрой 99,9 %

На бумаге — это набор формулировок: доступность сервиса не ниже 99,9 % (не более ~4 часов простоя в год) и поддержка 24/7.  Но чтобы эти гарантии соблюдались, одной подписи в договоре мало. Нужны зрелая архитектура и выстроенные процессы эксплуатации.

Разберемся, из каких технических и организационных элементов складывается высокий SLA.

1. Горячий резерв и дублирование критичной инфраструктуры

Первое, на чём держится SLA, — отказоустойчивая архитектура.

Любое «железо» рано или поздно выходит из строя. Поэтому все узлы, от которых зависит доступность сервисов, должны быть продублированы и работать в режиме горячего резерва.

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

Выход из строя одного диска или даже двух — рабочая ситуация. Кластер и СХД должны это переживать без заметных эффектов для клиентов

— отметил руководитель Центра мониторинга и технической поддержки CORTEL Алексей Ревенко.

Типичный кейс — отказ блока управления СХД. Один модуль выходит из строя, но сервисы продолжают работать за счёт второго. Для клиента ничего не меняется: ни простоя, ни потери данных.

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

— объяснил Алексей Ревенко.

2. Проактивный контроль состояния инфраструктуры

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

В основе такого подхода — глубокий мониторинг и регулярный анализ данных: метрики нагрузки, ошибки оборудования, задержки на каналах, состояние дисков и контроллеров.

По этим сигналам видно, где запас по мощности заканчивается, где растёт количество предупреждений, а где оборудование подходит к концу ресурса.

Как мы действуем на опережение:

• увеличиваем ресурсы кластера или СХД до того, как начнутся регулярные перегрузки;
• планово меняем диски и модули, по которым растёт число ошибок;
• перераспределяем трафик и настраиваем обходные маршруты при росте задержек на отдельных каналах;
• меняем конфигурации сервисов, если по логам видныо систематические проблемы.

«Наша задача —  перехватить проблему на этапе предупреждения в мониторинге. Большинство потенциальных отказов мы переводим в статус плановых работ

— отметил Ревенко

3. Оперативная замена компонентов и блоков 

Отказы отдельных узлов —  рутина, а не ЧП.

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

Для этого у провайдера должен быть ЗИП — комплект запасных частей под используемое оборудование: диски, блоки питания, контроллеры СХД, модули коммутаторов, оптика.

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

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

Если для замены критичного блока нужно сначала найти поставщика, оформить заказ и несколько недель ждать логистику, о понятных сроках восстановления говорить уже нельзя

— предупредил Ревенко

4. «Живые» регламенты

Даже с идеальной архитектурой исход аварии зависит от людей. Чтобы в критический момент команда действовала грамотно нужны чёткие инструкции.

В них прописывают:

• порядок обработки инцидентов и маршрутизации обращений;
• правила эскалации между первой, второй и третьей линиями поддержки;
• взаимодействие с сетевыми инженерами, архитекторами, эксплуатацией ЦОД;
• сценарии действий в нетипичных ситуациях — массовые аварии, инциденты «на стыке» с другими поставщиками, проблемы на каналах связи.

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

После серьёзных инцидентов у нас всегда два результата: восстановление сервиса и изменения в регламентах. Если второй части нет, значит, мы не извлекли урок

Такой подход снижает зависимость от отдельных специалистов и «устных договорённостей». Действия команды становятся предсказуемыми, а клиент получает понятные сроки реакции даже в самых сложных кейсах.

5. Прозрачная коммуникация: почему молчание хуже простоя

Для заказчика важно не только то, как быстро решается проблема, но и как с ним работают в процессе. 

При равной технической базе именно коммуникация часто определяет, будет клиент доверять провайдеру или начнет искать нового после первого же сбоя.

Обычно здесь три элемента:

• Понятная точка входа. Клиент должен точно знать, куда обращаться при инциденте. Это может быть портал, личный кабинет, дежурная почта или телефон. Не должно быть ситуации «непонятно, куда писать и кто отвечает».
• Резервирование каналов связи. Если один канал недоступен или работает нестабильно (например, почта задерживает письма), должны быть альтернативы: телефон, чат в личном кабинете или в мессенджерах.
• Понятные правила коммуникации. Заказчик знает: через сколько времени будет первый ответ, как часто обновляется статус работ, в каком формате приходят обновления (краткий статус, расширенный отчёт), кто инициирует связь

В процессе устранения аварии самое страшное для бизнеса — неизвестность.

Клиент должен видеть динамику: запрос принят, идет диагностика, мы нашли причину, мы тестируем решение. Если заказчик вынужден сам пинговать поддержку вопросом «Ну что там?», значит, процесс коммуникации сломан

Зрелый SLA работает не только во время «пожаров». Это инструмент планирования: уведомления о регламентных работах, обсуждение архитектурных изменений и сценариев миграции до того, как они станут проблемой. Так SLA превращается из «страховки» в инструмент развития сервиса.

6. «Серые зоны»: аварии за периметром

Часть инцидентов возникает не внутри облачной платформы, а на стыке с другими участниками: у оператора связи, у стороннего сервиса, в инфраструктуре самого клиента.
Формально SLA часто ограничивает зону ответственности облачного или сервисного провайдера только своим контуром. Но бизнесу всё равно, кто виноват — сервис не работает.

Зрелый подход в таких ситуациях выглядит так:

• техподдержка фиксирует, что проблема действительно вне контура облака (по трассировкам, логам, метрикам);
• подключает внешнего поставщика — оператора связи или сервис, через который идёт интеграция;
• остаётся в процессе до полного восстановления доступности, а не передаёт клиенту контакты «идите сами разбирайтесь».

Фраза “это не наша зона ответственности” с юридической точки зрения может быть корректной, но клиенту от неё не легче. Наша задача — довести инцидент до решения, даже если источник проблемы вне нашего периметра

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

Так клиент покупает не просто инфраструктуру, а экспертизу по разбору сложных цепочек. SLA расширяется от «нашего оборудования» до «работоспособности бизнес-сервиса в целом».

Этот пример показывает суть настоящего SLA: использовать свои технические возможности, чтобы решить «чужую» проблему ради доступности своего сервиса.

7. Когда сервис формально доступен, но управлять им нельзя

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

Снаружи всё хорошо: виртуальные машины отвечают, пользователи работают в 1С или CRM, сайты открываются. Но внутри паралич: недоступен портал управления или API облака. В итоге:

• нельзя перезапустить часть сервисов;
• нельзя оперативно увеличить ресурсы;
• откладываются плановые операции (обновления, переносы, изменения конфигурации).

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

Зрелый провайдер:

• учитывает такие случаи как отдельный тип инцидентов;
• анализирует причины и влияние на клиентов;
• по результатам дорабатывает архитектуру управляющих компонентов, мониторинг и процессы;
• фиксирует в отчётах не только факт «формальной доступности», но и период деградации управляемости.

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

8. Структура обращений в поддержку как индикатор качества SLA

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

Хорошо, когда в статистике мало реальных аварий и критичных инцидентов, а значительная часть обращений связана с:

• изменениями конфигурации;
• плановыми работами;
• консультациями по лучшим практикам;
• вопросами «как сделать без простоя и безопасно».

Это означает, что клиенты воспринимают поддержку как технических консультантов и партнеров по развитию, а не как «аварийную бригаду». Они приходят заранее, чтобы предотвратить проблемы, а не по факту, когда всё упало.

Если же большая часть ресурсов поддержки уходит на постоянное «тушение пожаров», а консультаций почти нет — это тревожный сигнал. Даже если проценты SLA формально соблюдаются, система работает на пределе возможностей, и запас её прочности минимален.

Выбирая провайдера, смотрите не только на заявленный процент доступности. Но и на то, как выстроена эта инженерная «кухня».

Если хотите глубже разобраться в теме SLA, надёжности сервисов и техподдержки, читайте другие статьи:

— Всё о природе SLA
— Метрики надежности: чем SLI отличается от SLO и SLA
— Процессы: как устроена техподдержка в методологии ITSM