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

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

Симптом

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

Почему так

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

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

Репетиция на копии

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

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

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

Если база большая, отдельно стоит замерить, сколько идёт преобразование данных. От этого числа зависит длина окна.

План отката

План отката пишется до работ и состоит из трёх частей.

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

Условия отката. Заранее записанные признаки, при которых работы останавливаются. Например: преобразование базы идёт вдвое дольше, чем на репетиции, или сервисы не поднялись за отведённое время. Решение принимается по списку, а не по настроению в четыре утра.

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

Порядок в окно работ

  1. Предупредить пользователей и закрыть вход в систему.
  2. Дождаться, пока обработаются очереди и остановятся фоновые процессы.
  3. Остановить сервисы.
  4. Сделать резервную копию базы и зафиксировать состояние хранилища документов. Убедиться, что копия дописана и лежит на другом хранилище.
  5. Обновить сервисы и выполнить преобразование базы по записанному на репетиции порядку.
  6. Опубликовать пересобранную прикладную разработку.
  7. Запустить сервисы и пройти проверки, пока вход для пользователей закрыт.
  8. Открыть вход.

Если копия на шаге 4 делается дольше, чем позволяет окно, это повод заранее пересмотреть способ резервного копирования, а не пропустить шаг.

Что проверить после

До того как пустить пользователей:

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

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

Чего не делать

  • Не обновлять прод без репетиции. Время и поломки доработок должны быть известны заранее.
  • Не начинать без проверенной копии. Копия, которую не разворачивали, откатом не считается.
  • Не решать про откат на месте. Условия остановки пишутся до работ.
  • Не забывать время отката в длине окна. Иначе к утру не будет ни новой версии, ни старой.
  • Не копить версии. Чем больше пропущено, тем больше изменений приходит за один раз и тем труднее найти, какое из них сломало работу.