Обращение по инциденту при замене дисков

19.03.2026 на сервере Joule один из двух NVMe-дисков выпал из RAID-1 массивов. Сервер продолжил штатную работу на оставшемся диске. 30.03.2026 было подано обращение на замену неисправного диска.

В результате действий инженеров Selectel был извлечен рабочий диск с актуальными данными. Это привело к потере дисковых данных за период 19.03–30.03.2026 и длительному процессу восстановления консистентности баз данных.

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

Клиент, не зная об особенностях чужой Rescue-среды, воспринял этот маппинг как корректный и подтвердил замену по имени из среды диагностики поддержки Selectel.

Помимо предоставления маппинга без предупреждения, поддержка прямо заявила, пообещав замену без потерь — «мы можем выполнить замену без потери данных... Для этого вам необходимо...» (31.03, 00:17), предоставила план действий по замене дисков, где сослалась на статью из базы знаний Selectel с пошаговой инструкцией по администрированию RAID при замене дисков (https://docs.selectel.ru/dedicated/troubleshooting/replace-disk-raid/). Характерно, что и в самой этой статье идентификация дисков выполняется исключительно по именам устройств (sda, sdb) — серийный номер или команды, определяющие его, не упоминаются ни разу. Таким образом, собственная документация Selectel не содержит процедуры верификации по S/N, отсутствие которой позднее было предъявлено клиенту как причина инцидента. Данные были потеряны.

В сообщении от 31.03, 13:15 Selectel сам пришёл к выводу:

В том же сообщении признано:

И в том же сообщении заявлено:

Это же сообщение от 31.03, 13:15 содержит предложение вернуть заменённый диск для восстановления данных. Однако ответ «на ключевые» вопросы, обещанный «приблизительно до 10:00» (31.03, 02:55), поступил в 13:15 — спустя более 3 часов после обещанного срока. К этому моменту проект уже функционировал в частично рабочем режиме (для части пользователей), накапливая новые данные и транзакции, всё ещё велись работы по восстановлению утраченной консистентности. Возврат диска и откат к его содержимому привёл бы к потере новых данных и повторной расконсистенции.

Важно отметить: маппинг имя→серийник — это программная идентификация, выполненная в Rescue-среде. Selectel дважды заявлял, что «не выполняет администрирование серверов». Однако предоставление программного маппинга дисков — это прямое взаимодействие с программной частью сервера, а предоставление плана действий по работе с RAID с обещанием «без потери данных» — прямое руководство по программному администрированию. Причём именно маппинг из чужой среды, транслированный клиенту как достоверный, привёл к инциденту.

Примечательно, что в первом же ответе поддержки (31.03, 00:01) было заявлено:

Замена планировалась сразу — без запроса серийного номера у клиента, без подтверждения S/N конкретного диска, автоматически по результатам диагностики в Rescue. Серийный номер на этом этапе не фигурировал ни в вопросах поддержки, ни в предложенной процедуре.

При этом в разъяснении от 31.03, 13:15 поддержка заявила:

и

Таким образом, в ночь инцидента (31.03, 00:01 и 00:17) S/N не требовался: замена планировалась поддержкой «сразу», клиенту давались инструкции по работе с RAID «без потери данных», не предполагающие идентификацию по S/N. А днём, в разъяснении по инциденту (31.03, 13:15) отсутствие S/N предъявлено клиенту задним числом как причина инцидента.

При согласовании замены второго диска (02.04, 01:09) был задан прямой вопрос:

Ответ поддержки (02.04, 01:42):

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

Поддержка сама подтвердила, что имена ненадёжны, а серийный номер — единственный корректный идентификатор. Слова «всегда отображается верно, в отличии от наименований» — прямое признание ненадёжности имён устройств.

Однако при замене первого диска верификация фактически не состоялась: поддержка предоставила программный маппинг из своей Rescue-среды, клиент воспроизвёл S/N из этого маппинга, не имея оснований сомневаться в его корректности и не будучи предупреждён о возможном расхождении имён. Независимая проверка — запрос S/N у клиента из его ОС, до предоставления собственного маппинга — не была выполнена. Данные потеряны.

Дважды — при замене первого и второго дисков — поддержка заявляла о возвращении сервера в работу, при этом:

При согласовании замены второго диска был задан прямой вопрос с отсылкой на инцидент с первым (02.04.2026, 01:09):

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

Перед заменой второго диска (S/N:S5P2NU0WA15149V) был согласован протокол из конкретных пунктов (Клиент: 02.04, 01:09; Поддержка: 02.04, 01:42). Результаты:

Поддержка неоднократно заявляла:

При этом в рамках того же тикета поддержка: