У подкасті The Pragmatic Engineer головний інженер Octopus Deploy Роберт Ерез, який понад десятиліття будує системи CI/CD і відповідає за розгортання у великомасштабних середовищах, детально розбирає одну з найболючіших тем продакшн‑інцидентів — «магічні ролбеки». Ба більше, він формулює позицію, яка суперечить звичним уявленням: зрілі команди взагалі намагаються не говорити про rollback і будують процеси так, ніби його не існує.
Мрія про кнопку rollback і реальність стану
Ерез визнає: запит на «великий червоний» ролбек‑батон звучить постійно. Клієнти приходять із простим запитом: якщо система вміє задеплоїти версію, чому не може так само просто відкотити її назад?
Це працює у дуже вузькому класі систем — там, де все справді статлес. Якщо немає стану, немає баз даних, немає збережених даних, які живуть довше, ніж процес застосунку, — відкат зводиться до заміни артефакта. У таких сценаріях GitOps чудово демонструє свою силу: є декларативний опис бажаного стану, робимо git revert, агенти знову приводять кластери до попередньої конфігурації, і на цьому історія закінчується.
Але, підкреслює Ерез, «реальність для більшості систем інша». У грі завжди є стан: бази даних, збережені сутності, інформація, яку «не можна просто взяти й відкотити». Саме тут і руйнується ілюзія універсального ролбеку.
Ключова проблема — схема БД. Типовий деплой змінює не тільки код, а й структуру даних. Якщо ми відкачуємо версію застосунку, але не повертаємо назад схему, отримуємо код, який розраховує на стару модель, але працює з новою: інші колонки, таблиці, індекси. Формально «деплой назад» відбувся, фактично — система в непередбачуваному стані.
Теоретично можна супроводжувати кожну міграцію «анти‑міграцією», яка здатна повернути схему назад. Практично це далеко не завжди можливо: складні зміни, втрати даних, конфліктуючі оновлення, дані, що вже живуть у новому форматі. Запит «зробіть кнопку ролбеку» в такій реальності перетворюється на небезпечну ілюзію контролю.
Показовий момент, на який звертає увагу Ерез: багато команд впевнено кажуть, що «регулярно роблять ролбеки», але при першому ж запитанні про відкат версії зі зміною схеми завмирають і раптом розуміють, що їм просто щастило — вони ще не в’їхали в глухий кут.
Від «відкотити» до «просунутися вперед»
Octopus Deploy цілеспрямовано відходить від поняття rollback у розмовах з клієнтами. Формулювання Ереза жорстке й однозначне: «ви маєте уникати розмов про roll back. Це завжди roll forward».
Логіка проста. Якщо в продакшні виявлено баг, найнадійніший шлях — якнайшвидше внести зміну, яка його виправляє, і задеплоїти цю зміну. Не повертати систему в минулий стан, а рухатися до наступного, кращого стану.
У цій парадигмі версії мисляться інакше. Якщо, умовно, версія 2 впала, «ролбеком» вважається не повернення до версії 1, а вихід на версію 3, де проблема вже виправлена. Саме це і є roll‑forward‑підхід: помилилися — виправили — швидко розгорнули нову, безпечнішу версію.
Тут критичну роль відіграє швидкість зворотного зв’язку та готовність процесу до хотфіксів. Команда має мати змогу вийти за рамки звичайного «довгого» циклу dev–staging–prod із погодженнями і формальностями, коли поспіху немає, і увімкнути прискорений шлях для критичного виправлення. У таких ситуаціях вузьким місцем стає вже не організація, а сама збірка: час, за який CI/CD проганяє пайплайн і видає нову версію.
Ерез визнає: якщо інцидент спричинений саме механізмом деплоймента або якимось кроком у процесі розгортання, час відновлення буде коротшим. Але при вадах бізнес‑логіки чи схем даних стратегічно безпечнішим виявляється саме рух уперед, а не спроба повернутися до «учора», коли продакшн уже в іншому стані.
Фічефлаги як справжній «ролбек» без ролбеку
В ідеальному світі, каже Ерез, відкот функціональності відбувається не через версії, а через фічефлаг. У цій моделі ми не змінюємо версію застосунку, не намагаємося повернути кодову базу у минуле — ми змінюємо шлях виконання всередині поточної версії.
Фічефлаг дозволяє тримати в одному релізі дві (або більше) гілки коду: стару, стабільну та нову, експериментальну. Перемикачем стає зовнішня конфігурація, що визначає, якою саме гілкою піде виконання: новим кодом користуються лише певні сегменти трафіку, окремі групи користувачів або взагалі ніхто, поки команда не буде готова.
Саме це вирішує кілька фундаментальних проблем, які роблять версійні ролбеки такими болючими.
По‑перше, узгодженість із схемою даних. Якщо зміни в БД проєктуються разом із новою кодовою гілкою, можна організувати код так, щоб кожна гілка була самодостатньою щодо поточного стану схеми. Умовно кажучи, незалежно від того, вмикаємо ми фічу чи вимикаємо, код, який працює зі схемою, очікує саме ту структуру, яка є в базі тут і зараз. Флаг не відмотує схему, він вибирає логіку, яка з нею коректно працює.
По‑друге, час реакції. Відкат через фічефлаг — це секунди. Не потрібно згортати середовище, перезнімати інстанси, чекати завершення деплоймента. Достатньо змінити значення флага в системі керування фічами — і новий (насправді старий, стабільний) шлях виконання починає застосовуватися миттєво. Це критично, коли інцидент трапляється в «2:00 ночі», а інженер у стресі намагається мінімізувати шкоду.
По‑третє, передбачуваність. Коли реліз фічі прив’язаний до викочування версії, команда змушена підлаштовуватися під час деплоймента: бути в онлайні, моніторити логі, слідкувати за метриками саме в момент, коли новий код фізично потрапляє у продакшн. Фічефлаги відокремлюють ці моменти. Код можна спокійно задеплоїти, скажімо, у понеділок, а фічу увімкнути у вівторок, коли команда в повному складі, все підготовлено, спостереження налаштовані.
І, нарешті, точність таргетингу. Класичні підходи на кшталт канарних деплойментів працюють з одиницею «версія застосунку»: разом виходить все, що було закомічено з попереднього релізу. Фічефлаг ж дозволяє вмикати й вимикати окремі зміни з дуже тонкими правилами — наприклад, лише для конкретної країни чи певного сегмента користувачів.
У цій картині світобудови фічефлаг і є тим «справжнім ролбеком», тільки реалізованим без відкату версій.
Як жити без ролбеку і не зламати собі процеси
Позиція «ролбеків не існує» звучить радикально, але в інтерпретації Ереза вона не про заборону, а про зміну мислення. Кілька ключових наслідків цього підходу вимальовуються прямо з його аргументів.
По‑перше, доводиться серйозніше ставитися до змін схеми даних. Якщо відкат «на версію назад» не розглядається як реалістична опція, команди мусять ретельніше планувати еволюцію БД, розбивати її на етапи, проєктувати міграції так, щоб кожен проміжний стан був життєздатним. Це підвищує вимоги до зрілості команд, але й різко знижує шанси на катастрофічні інциденти через невідкатну схему.
По‑друге, хотфікси перестають бути «винятковою подією» і стають повноцінним сценарієм життєвого циклу. Пайплайн має вміти швидко пропускати критичні виправлення, а команда — розуміти, де межа прийнятного ризику, коли можна скоротити формальні кроки заради швидкості відновлення.
По‑третє, важливо не плутати два різних інструменти: roll‑forward як спосіб руху між версіями й фічефлаги як спосіб оперативно керувати поведінкою системи всередині однієї версії. Вони доповнюють одне одного. Якщо загальний «злам» у версії — потрібен новий реліз. Якщо збій локалізовано у фічі — найшвидший «ролбек» пройде саме через вимкнення флага.
Зрештою, підхід, який описує Ерез, чесно визнає реалії сучасних систем. Там, де немає стану, відкот — це проста операція над артефактом. Там, де є бази даних, довгоживучі дані та складні міграції, сподівання на універсальну кнопку rollback — небезпечна омана. Замість шукати магічний батон, зрілі команди будують процеси довкола roll‑forward, хотфіксів і гнучкого керування функціональністю через фічефлаги — і вчаться завжди рухатися тільки вперед.