SLA выделенного сервера: что произойдёт при поломке и как выяснить срок замены

MAATRIX · Выделенные серверы · Статья 38 из 48

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

У аппаратной аварии несколько часов, и каждый отсчитывается по-своему. Есть время обнаружения, реакции, ремонта и возвращения сервиса пользователям. Хороший договор помогает понять обязательства по этим этапам. Хорошая архитектура помогает пережить разрыв между ними.

Четыре обещания, которые часто принимают за одно

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

Время диагностики — следующий этап. Нужно отличить отказ диска от проблемы контроллера, ошибки файловой системы, перегрева или неверной настройки ОС. Иногда причина очевидна по аппаратному журналу, иногда нужны дополнительные проверки. От точного момента подтверждения неисправности может начинаться отдельный срок замены, если так написано в договоре.

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

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

Полезно просить ответ именно по этим четырём пунктам. Тогда выражение «быстро восстановим сервер» приобретает измеримый смысл. Иначе каждый участник разговора может совершенно искренне подразумевать собственную скорость и собственное значение слова «сервер».

Что известно из публичных условий MAATRIX

На момент проверки, 7 октября 2026 года, на главной странице MAATRIX указано 99,9% аптайма. В публичной оферте редакции от 17 сентября 2026 года заявленный uptime описан как целевой уровень сервиса. Текст оферты посвящён прежде всего VPS/VDS и общим условиям инфраструктуры; отдельного подтверждённого срока замены компонентов выделенных серверов в проверенных материалах нет. Оферта открывается с главной страницы MAATRIX.

Поэтому из публичной цифры нельзя выводить обещание заменить SSD, память или материнскую плату за определённое число часов. Нельзя автоматически переносить на dedicated и описание восстановления виртуальных машин из резервных копий. Это разные услуги с разными границами ответственности.

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

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

Как читать процент доступности без магии

Для условного тридцатидневного месяца 99,9% доступности соответствует 43,2 минуты недоступности, если считать весь месяц и не применять исключений. Это арифметика, а не обещание конкретного времени ремонта. Договор может иначе определять расчётный период, измеряемый сервис и события, которые входят в расчёт.

Нужно понять, что именно считается доступным. Сетевой порт? Ответ на проверку с определённой точки? Возможность загрузить ОС? Веб-приложение пользователя? Даже один сервер может иметь разные показатели на этих уровнях. Машина доступна по SSH, а база не запускается — для бизнеса авария продолжается, хотя проверка сети уже зелёная.

Различие между измеряемым показателем, целевым уровнем и договорным обязательством хорошо объясняется в книге Google SRE о service-level objectives. В практическом выборе важна не терминология сама по себе, а связь обещания с измерением и последствиями нарушения.

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

И выясните, как заявляется требование о компенсации: нужны ли обращение в определённый срок, журналы, номера инцидентов и отдельный запрос. Подробный разбор такой проверки есть в статье о чтении процентов и компенсаций в SLA.

Один отказ диска — несколько разных историй

Представим три условные системы. Первая работает на одном накопителе. При его полном отказе нужно восстановить данные на исправный диск или другой сервер. Даже очень быстрая физическая замена не сокращает объём копирования и проверки приложения до нуля.

Вторая использует исправное зеркало из двух дисков. При отказе одного накопителя сервис может продолжить работу, пока массив остаётся работоспособным и нет других проблем. Но он уже находится в уязвимом состоянии, а после замены понадобится восстановление зеркала. В этот период нагрузка и доступная производительность могут измениться.

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

У NECROPOLIS заявлены два NVMe, у CARTOUCHE — два SSD. Это создаёт возможность определённых схем хранения, но не подтверждает настроенное зеркало или резервную копию. У ANKH и PYLON в предоставленном прайсе по одному NVMe. При планировании аварии учитывайте фактическую схему вашего заказа, а не предполагаемую.

Аппаратная устойчивость не ограничивается дисками. Отказ платы может остановить оба накопителя сразу. Ошибка питания, контроллера или прошивки тоже способна затронуть всю машину. Поэтому зеркало внутри одного сервера решает определённый класс отказов, а не задачу полной независимости инфраструктуры.

Сколько простоя способен выдержать ваш проект

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

В планировании восстановления используют RTO — целевой предельный срок возвращения работы — и RPO, определяющее, насколько допустимо отступить назад от момента сбоя при восстановлении данных. Эти понятия рассматриваются в руководстве NIST по планированию восстановления. Это требования к вашему сервису, а не результат измерения и не автоматическое следствие тарифа на железо.

Чтобы уложиться в RTO, оцените длительность всего пути: обнаружения сбоя, принятия решения, получения доступных ресурсов, восстановления данных, запуска и проверки. Затем проверьте оценку на учении. Если резервная копия загружается три часа, обещание поддержки ответить через несколько минут не сделает общий результат минутным.

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

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

Что передать поддержке при подозрении на поломку

Сообщение должно помогать отличить аппаратную проблему от программной. Укажите идентификатор сервера, время обнаружения и наблюдаемый симптом: нет загрузки, диск исчез, растут ошибки ввода-вывода, консоль показывает аппаратное событие. Если возможно, приложите журнал или снимок экрана без секретов.

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

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

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

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

Какие ответы стоит получить до заказа

Попросите описать порядок замены дисков, памяти, блока питания и всей машины. Уточните, есть ли подтверждённые сроки по каждой категории и с какого события они начинаются. Спросите, что считается эквивалентной заменой, сохраняются ли сетевые параметры и кто выполняет перенос данных.

Разделите стоимость компонентов и стоимость работ. В каких случаях обслуживание входит в аренду, что оплачивается отдельно и какие действия входят в администрирование? Общий термин «managed» или «поддержка 24/7» без перечня работ оставляет слишком много места для разных ожиданий.

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

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

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

Все материалы о выделенных серверах