Обязательства по эксплуатации

Все инциденты проходят одну и ту же последовательность: подтверждение и назначение руководителя реагирования в течение 15 минут, подключение инженеров, обновления не менее одного раза в 60 минут и письменный разбор инцидента в течение 7 календарных дней после каждого инцидента, затронувшего клиента.

1. Подтверждение

   Мы подтверждаем инцидент и назначаем руководителя реагирования в течение 15 минут. Руководитель реагирования является тем единственным человеком, который координирует ответные действия.

2. Привлечение специалистов

   Служба эксплуатации сети подключается в течение 15 минут в любое время суток, а инженеры площадки или remote hands подключаются в течение 45 минут.

3. Обновления

   Пока инцидент открыт, вы получаете обновления не менее одного раза в 60 минут.

4. Разбор инцидента

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

Разбор инцидента представляет собой письменный отчёт о нём: что произошло, почему это произошло и что делается, чтобы это не повторилось.

О плановых работах с риском мы объявляем не менее чем за 7 календарных дней, изменения проходят по документированной процедуре управления изменениями, а эталонный реестр оборудования фиксирует ваш кластер вплоть до каждого кабеля.

Уведомление о плановых работах

Уведомление относится к неэкстренным работам с высоким риском и даёт вам время перенести задачи или сохранить контрольную точку до начала работ. На экстренные работы срок уведомления не распространяется. Со стороны площадок мы запрашиваем у используемых нами дата-центров уведомление о работах с высоким риском за 14 дней.

Управление изменениями и доступ

Документированная процедура управления изменениями означает, что изменения в вашем кластере вносятся по описанному процессу и оставляют письменный след. Внеполосный доступ, то есть канал управления, который обращается к серверу через его BMC ниже уровня операционной системы, подлежит аудиту.

Реестр оборудования

Мы ведём эталонный реестр, в котором учтены все стойки, узлы, GPU, сетевые адаптеры, накопители, коммутаторы, порты, трансиверы и кабели, и предоставляем вам его машиночитаемую выгрузку. Изменения состояния становятся видны в течение 5 минут. Обнаружение отклонений сравнивает кластер с согласованной базовой конфигурацией, поэтому любое незапланированное изменение становится заметным.

Мы разрабатываем собственное ПО платформы для реестра оборудования, мониторинга и автоматизации нагрузочного прогона на основе компонентов с открытым исходным кодом. Клиентский портал и публичный API входят в эту работу и пока недоступны.

Мы находим и устраняем неисправности оборудования, площадки, охлаждения и фабрики и немедленно выводим в карантин GPU с фатальным сбоем.

Карантин выводит затронутое оборудование из эксплуатации до устранения неисправности, чтобы на него не попадали задачи. Причиной XID 13 и XID 31 может быть приложение, а не GPU, поэтому мы реагируем на них, когда число повторений превышает согласованное количество. Когда задача NCCL зависает, мы проверяем события в фабрике, произошедшие в тот же момент, чтобы можно было найти неисправность канала или коммутатора, вызвавшую зависание. Скрытое повреждение данных относится к самым трудно обнаруживаемым сбоям, потому что о нём ничто не сообщает, и именно поэтому узел под подозрением остаётся в карантине. NVMe-накопители заменяются до того, как они достигнут предела своего ресурса, а не после отказа.

Если в вашем кластере используется система хранения данных (СХД) под управлением производителя, спецификация закрепляет такие обязательства: архитектура, поддерживаемая производителем, эскалация 24/7, закреплённые значения пропускной способности и задержки для каждого уровня хранения, прозрачные данные об использовании и квоты, проверенное восстановление.

• Архитектура, поддерживаемая производителем. СХД от VAST Data, WEKA или DDN строится по архитектуре, которую поддерживает её производитель.
• Эскалация 24/7. Проблему с хранилищем можно эскалировать в любое время суток.
• Пропускная способность и задержка для каждого уровня. Для каждого уровня хранения закреплены значения пропускной способности и задержки, поэтому вы можете планировать задачи и контрольные точки по известным цифрам.
• Использование и квоты. Использование и квоты видны, поэтому ёмкость не закончится незаметно.
• Проверенное восстановление. Восстановление проверяется на практике, а не только описывается в документации.

Оба варианта хранилища, СХД и узлы хранения для вашего собственного ПО, описаны на странице «Хранилище и сеть».

Мы собираем телеметрию оборудования по внеполосному каналу, храним операционную телеметрию не менее 30 дней, а историю инцидентов и состояний храним не менее 12 месяцев.

Внеполосная телеметрия поступает от BMC серверов через Redfish, поэтому она продолжает передавать данные, даже когда операционная система этого не делает. Телеметрия сети и площадки собирается там, где она доступна. Благодаря истории инцидентов и состояний не менее чем за 12 месяцев сбой, который повторяется с интервалом в несколько месяцев, всё равно можно связать с его предыдущими случаями.

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