Релиз выкатили вечером, а ночью посыпались ошибки: не оформляются заказы, отваливается оплата, каталог отдаёт пятисотки. Дежурный в панике пытается понять, что сломалось, а часы простоя капают прямыми убытками. И самый страшный вопрос в этот момент — не «что случилось?», а «как быстро мы вернём как было?». Если ответа нет заранее, авария превращается в катастрофу.
Эта статья — о плане отката (rollback) для сайта на 1С-Битрикс: как сделать релиз обратимым, откатить код через Git и разобраться с изменениями в базе, где резервные копии, а где обратимые миграции, и как выстроить регламент, чтобы решение принималось за минуты. Инфраструктуру для быстрого отката мы настраиваем в рамках услуги rollback и Git-workflow для Битрикс.
Коротко
- План отката — это про деньги: скорость возврата рабочей версии прямо определяет ущерб от аварии.
- Откат состоит из двух частей: код (легко, через Git) и база (сложно, нужны обратимые миграции и бэкапы).
- Релиз нужно проектировать обратимым заранее, а не искать способ откатиться под давлением.
- План без репетиции — это предположение; процедуру отката прогоняют на тесте регулярно.
Почему план отката — вопрос денег
Любой релиз несёт риск. Даже идеально протестированное изменение может повести себя иначе на боевых данных и нагрузке. Вопрос не в том, случится ли когда-нибудь проблемный релиз, — он случится, — а в том, сколько будет стоить возврат к рабочему состоянию. И этот срок вы определяете заранее, а не в момент аварии.
Считайте прямо: если магазин делает N заказов в час, то каждый час простоя — это N потерянных заказов плюс испорченная репутация и просадка в поиске из-за недоступности. План отката превращает потенциальную многочасовую катастрофу в управляемый инцидент на несколько минут. Это не «страховка на всякий случай», а прямая экономия, которую видно в деньгах при первой же серьёзной проблеме.
Две части отката: код и база
Ключ к пониманию отката — разделить его на две принципиально разные части. Их путают, и из-за этого рушатся планы.
| Аспект | Откат кода | Откат базы данных |
|---|---|---|
| Обратимость | Почти всегда простая | Зависит от изменений |
| Инструмент | Git, предыдущий деплой | Обратимые миграции, бэкап |
| Скорость | Секунды–минуты | Минуты–часы |
| Риск потери данных | Нет | Есть при откате из бэкапа |
| Планирование | Достаточно Git-workflow | Нужно заранее для каждой миграции |
Вывод: код откатывается легко, база — нет. Поэтому основные усилия плана концентрируются на изменениях базы. Если релиз не трогает структуру данных, откат почти тривиален. Если трогает — именно эту часть нужно продумать до выката.
Откат кода через Git
Откат кода — самая простая часть, если проект живёт в Git и деплой автоматизирован. Смысл в том, чтобы вернуть предыдущую известно-рабочую версию файлов быстро и предсказуемо.
- Каждый релиз — помеченная версия. Тег или фиксированный коммит, к которому можно мгновенно вернуться.
- Деплой атомарный. Новая версия разворачивается рядом и переключается целиком, а не поверх работающей.
- Откат = переключение. Возврат к предыдущему релизу — это переключение на прошлую версию, а не ручная правка файлов.
- Никаких правок на бою. Изменения только через Git, иначе откат затрёт «горячие» фиксы и откатывать станет некуда.
Именно поэтому дисциплина Git-workflow — фундамент отката. Как выстроить ветки, деплой и автоматический возврат версии, мы подробно разбираем в статье про CI/CD и деплой на Битрикс. Без этой основы даже простой откат кода превращается в ручную операцию с риском ошибиться.
Обратимые миграции базы данных
Самая опасная часть релиза — изменения структуры базы. Добавили колонку, переименовали поле, перелили данные — и простой возврат кода уже не спасает: новый код ушёл, а изменённая схема осталась. Решение — обратимые миграции: каждое изменение схемы сопровождается заранее написанным скриптом отмены.
- Каждая миграция парная. Есть скрипт применения и скрипт отмены — «добавить колонку» и «удалить колонку».
- Аддитивные изменения безопаснее. Добавление нового поля обратимо и не ломает старый код; удаление — нет.
- Разделяйте схему и данные. Изменение структуры и перелив данных — разные шаги с разной обратимостью.
- Необратимое — в отдельный поздний шаг. Удаление старой колонки делают уже после того, как убедились, что новый код стабилен.
Резервные копии и точки восстановления
Резервная копия — последний рубеж отката, к которому прибегают, когда точечная обратимость невозможна. Но у бэкапа есть цена: восстановление из полной копии теряет всё, что произошло после её снятия, — заказы, регистрации, изменения. Для активного магазина это часы реальных данных.
- Свежая копия перед релизом. Прямо перед выкатом снимают точку восстановления — минимальное окно потерь.
- Проверенная восстановимость. Бэкап, который не разворачивали, — это иллюзия защиты; его нужно тестировать.
- Отдельно код, база и файлы. Загруженные файлы (медиа, документы) бэкапятся отдельно от базы и кода.
- Понятное окно потерь. Команда заранее знает, сколько данных теряется при откате из копии.
Полный откат из бэкапа — крайняя мера именно из-за потери данных. Хороший план стремится к точечной обратимости: откатить только проблемное изменение, сохранив накопленные заказы. Инфраструктурная часть — где и как хранятся копии, как быстро разворачиваются — тесно связана с хостингом; про это мы писали в статье про инфраструктуру на BitrixVM.
Проектируем релиз обратимым
Лучший откат — тот, который заложен в сам релиз. Обратимость проектируется до выката, а не ищется под давлением аварии. Несколько принципов, которые делают релиз откатываемым по определению:
- Мелкие релизы. Чем меньше изменений в одном выкате, тем проще понять причину проблемы и откатить именно её.
- Обратная совместимость. Новый код умеет работать со старой схемой, пока миграция не завершена полностью.
- Флаги функций. Новую логику включают флагом, который можно выключить без отката кода.
- Разделение выката и включения. Код разворачивают заранее, а функцию активируют отдельно, когда убедились в стабильности.
Флаги функций особенно ценны: они позволяют «откатить» проблемную фичу мгновенным переключением, не трогая деплой вообще. Это превращает откат из инфраструктурной операции в изменение настройки — самый быстрый и безопасный вариант.
Режим обслуживания как буфер
Не всякую проблему можно откатить за секунды. Иногда команде нужно время: понять причину, откатить миграцию, восстановить данные. В эти минуты выбор простой — показывать клиентам сломанный сайт с ошибками или корректную страницу обслуживания. Второе почти всегда лучше.
Режим обслуживания — это буфер, который защищает и клиентов, и данные. Заглушка не собирает недооформленные заказы, не показывает битую витрину и даёт понятное сообщение «скоро вернёмся». В 1С-Битрикс есть штатный режим профилактики, и в план отката заранее закладывают, как его включить и что он содержит.
Регламент: кто, когда, по каким критериям
Техническая возможность отката бесполезна без регламента принятия решения. В аварии время уходит не на сам откат, а на споры «чиним или откатываем». Регламент убирает эти споры.
- Ответственный за решение. Заранее известно, кто принимает решение об откате и кто его выполняет.
- Критерии отката. Какие ошибки и метрики означают «откатываем немедленно», а не «понаблюдаем».
- Лимит времени. Если за отведённые минуты причина не ясна — откатываемся, разбираемся потом.
- Каналы связи. Где команда собирается в инцидент и как оповещает бизнес.
Главное правило: при неопределённости откатываемся к рабочей версии. Разбираться в причинах на спокойную голову дешевле, чем чинить вслепую на боевом магазине под капающими убытками. Регламент отката — часть более широкой культуры релизов, о которой стоит договориться со всей командой.
Особенности отката на 1С-Битрикс
У 1С-Битрикс есть своя специфика, которую план отката обязан учитывать:
- Кэш. После отката кода нужно сбросить кэш — иначе часть страниц продолжит отдавать старую (уже новую-сломанную) версию.
- Обновления модулей. Обновление ядра и модулей меняет файлы платформы и записи в базе; такой откат сложнее и требует отдельного плана.
- Обмен с 1С. Во время отката обмен лучше приостановить, чтобы не смешать данные разных версий схемы.
- Агенты и очереди. Фоновые задачи могут работать по новой логике; при откате их состояние тоже учитывают.
- Композитный кэш. Статические копии страниц надо инвалидировать, чтобы клиенты увидели откаченную версию.
Особенно осторожно планируют откат обновлений ядра: они затрагивают и файлы, и структуру базы одновременно. Такие релизы всегда сопровождают свежей копией и репетируют откат на тесте. Работа с данными платформы и структурой инфоблоков через современный слой описана в статье про D7 ORM в Битрикс.
Репетиция отката на тесте
Откат, который никогда не запускали, — это не план, а предположение. Слишком часто выясняется в разгар аварии, что бэкап не разворачивается, скрипт отмены миграции содержит ошибку, а деплой не умеет переключаться на прошлую версию. Единственная защита — репетиция.
- Прогон на тестовом окружении. Полная процедура: откат кода, откат миграций, восстановление из копии.
- Замер времени. Сколько реально занимает откат от решения до рабочего сайта.
- Проверка данных. Что теряется, что сохраняется, корректно ли работает откаченная версия.
- Обновление регламента. По итогам учений уточняют критерии, роли и шаги.
Регулярные учения превращают откат из стрессовой импровизации в отработанный рефлекс. Команда, которая репетировала откат, в реальной аварии действует спокойно и быстро — а это и есть разница между инцидентом на минуты и катастрофой на часы.
Частые ошибки
- Плана нет вообще. Откат придумывают в момент аварии под давлением — самый дорогой сценарий.
- Забыли про базу. Откатили код, а изменённая схема осталась — сайт всё равно сломан.
- Ставка только на полный бэкап. Восстановление теряет все заказы после снятия копии.
- Правки прямо на бою. Ручные фиксы вне Git затирают откат — возвращаться становится некуда.
- Нет критериев решения. Команда спорит «чиним или откатываем», а часы идут.
- Бэкап не проверен. В аварии выясняется, что копия не разворачивается.
- Забыли про кэш и обмен. После отката старый кэш и активный обмен с 1С воспроизводят проблему.
- План не репетировали. Процедура существует на бумаге, но на деле не работает.
Чек-лист плана отката
- Git-workflow налажен. Каждый релиз помечен, деплой атомарный, откат — переключение на прошлую версию.
- Миграции обратимы. Для каждого изменения схемы есть скрипт отмены; необратимое вынесено в поздний шаг.
- Свежая копия перед релизом. Точка восстановления снимается прямо перед выкатом и проверена.
- Релиз спроектирован обратимым. Мелкие изменения, обратная совместимость, флаги функций.
- Режим обслуживания готов. Известно, как включить заглушку и что она содержит.
- Регламент описан. Ответственный, критерии отката и лимит времени зафиксированы.
- Специфика Битрикс учтена. Кэш, обмен с 1С, агенты и композит в плане отката.
- Процедура отрепетирована. Откат прогнан на тесте, время замерено, регламент обновлён.
Вывод
План отката — это не бюрократия, а прямая экономия, которую видно в деньгах при первой серьёзной проблеме. Он превращает потенциальную многочасовую катастрофу в управляемый инцидент на минуты. Ключ — разделить откат на две части: код откатывается легко через Git, а изменения базы требуют обратимых миграций, свежих копий и осторожного проектирования релиза.
Но техническая возможность отката мертва без регламента и репетиции. Заранее определите, кто принимает решение и по каким критериям, держите наготове режим обслуживания как буфер и регулярно прогоняйте процедуру на тесте. Тогда неудачный релиз — а он рано или поздно случится — станет не катастрофой, а рутинным «откатились, разобрались, выкатили заново». Именно так выглядит зрелая работа с релизами на 1С-Битрикс.
