«Обновление прошло успешно». Сколько стоит поверить этой строчке

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

Обновление платформы в компании обычно выглядит как техническая формальность. Подрядчик или своя команда запускает установщик, тот пишет «успешно», все расходятся.

Я руковожу направлением бизнес-приложений. Наши модули работают на low-code-платформе ELMA 365: договоры, согласования, корреспонденция. И недавно я увидел, как эта формальность выглядит изнутри, когда что-то идёт не так.

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

Нам нужно было проверить, есть ли в новых версиях платформы исправление одной ошибки. Проверить можно было только обновившись.

Мы обновили тестовый сервер. Только его. Сервер, на котором идёт основная разработка и откуда изменения уходят в боевую систему, не трогали вообще.

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

Четыре раза установщик написал «успешно». Четыре раза наша проверка подтвердила, что система живая.

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

Файлы в таких системах хранятся в двух местах. Сами байты лежат на складе. А в базе данных лежит каталог: как файл называется, к какому договору относится, где на складе его содержимое.

На одном из промежуточных шагов обновления из каталога исчезли все действующие записи. 1279 файлов, около 2635 папок, около 222 версий документов.

Склад при этом остался цел. Все документы физически существовали. Просто система больше не знала, что они у неё есть.

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

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

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

Это худший тип аварии. Не громкое падение, которое видно через минуту. А тихая порча, которую замечают пользователи, причём не сразу и не все.

Стоимость такой аварии складывается не из часов простоя серверов. Она складывается из остановленных процессов, ручной работы в обход системы и времени на расследование. Расследование без нужных данных может растянуться на недели. А может и вовсе закончиться ничем.

Одна скучная привычка: полная копия данных перед каждым шагом обновления, а не одна перед всем обновлением.

Благодаря этому у нас была цепочка снимков с точным временем. ИИ-агент, который вёл расследование, поднял каталог из каждого снимка и просто посчитал записи. До второго шага 1496 записей о файлах. После 217, и все они были давно помечены на удаление. Шаг нашли подсчётом, а не гаданием.

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

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

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

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

Подготовку делал ИИ-агент. Боевой запуск я выполнил сам. Результат совпал с репетицией до записи. Система заработала.

Какой именно компонент удалил записи, доказать не удалось: журналов за то окно не сохранилось. Есть сильная версия, но подтвердить её может только производитель. Это тоже урок. Если при обновлении не сохранять журналы, разбор упирается в стену.

Чуть раньше нам прислали новую версию модуля для работы с договорами. Обычное обновление.

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

Пакет ничего не удалял явно. Он просто заменил бы форму целиком. В журнале установки было бы чисто. А пользователи увидели бы, что «старая проблема вернулась».

Мы это поймали до установки. Сравнить пакет с живой системой проще, чем потом объяснять пользователям, куда делась функция.

Несколько правил, которые я теперь требую от любой команды, обновляющей корпоративную платформу. Своей в том числе.

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

Второе. Копия данных перед каждым шагом. Не одна на всё обновление. Это дёшево: место на диске стоит меньше одного дня простоя.

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

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

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

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

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