Обновления как источник отказов: почему «стало хуже после апдейта» — не совпадение

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

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#operations#upgrade#troubleshooting

Обновления как источник отказов: почему «стало хуже после апдейта» — не совпадение

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

Механизм 1: изменилось умолчание#

Самый неприятный, потому что он невидим в вашей конфигурации.

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

Реальный пример: серверная реализация ввела минимальную допустимую версию клиента, и в одной из сборок значение по умолчанию стало ненулевым. Сервер начал отклонять клиентов старее порога. Со стороны пользователя — «не подключается», без объяснений. Со стороны сервера — всё в порядке, он честно отверг несовместимого клиента.

БЫЛО                          СТАЛО
сервер: минверсия = (нет)     сервер: минверсия = X
клиент 1.8 ──► ✓ принят       клиент 1.8 ──► ✗ отвергнут
клиент 2.4 ──► ✓ принят       клиент 2.4 ──► ✓ принят

конфигурация не менялась. изменилось умолчание.

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

Механизм 2: параметр переехал#

Обновление перенесло настройку в другую секцию конфигурации. Старое место больше не читается.

Ключевая деталь: большинство разборщиков конфигурации не ругаются на лишние поля. Параметр в старом месте не вызывает ошибку — он просто игнорируется.

Результат: конфигурация загружается, сервис стартует, в логах чисто. И работает без той настройки, которую вы задавали.

Что вы видите Что происходит
конфигурация принята лишнее поле молча отброшено
сервис запустился ошибок нет, потому что ошибки нет
в логах чисто игнорирование не логируется
поведение изменилось настройка не применена

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

Механизм 3: ужесточилась проверка#

Обновление стало строже к тому, что раньше проходило.

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

Здесь отказ обычно консистентен — не работает у всех сразу. Это, парадоксально, хорошая новость: сплошной отказ диагностируется быстрее выборочного.

Механизм 4: разъехались версии#

Самый частый в многоузловых установках.

Панель управления обновили, узлы — нет. Или наоборот. Между ними образовался разрыв версий, и протокол взаимодействия у них перестал совпадать.

ПРАВИЛЬНЫЙ ПОРЯДОК          НЕПРАВИЛЬНЫЙ
1. панель                   1. половина узлов
2. проверка                 2. паника
3. один узел                3. остальные узлы
4. проверка                 4. панель
5. остальные узлы           5. непонятно, что сломалось

Порядок «сначала управляющая часть, потом исполнители, по одному, с проверкой между» — не бюрократия. Он даёт то, чего не даёт массовое обновление: на каждом шаге понятно, что именно изменилось.

Почему это выглядит как блокировка?#

Все четыре механизма дают одну и ту же наблюдаемую картину: было — стало не работать. Отличить одно от другого помогает не сам отказ, а то, кто именно затронут и помогает ли откат версии.

Различить их от блокировки помогает несколько признаков.

Признак Скорее обновление Скорее блокировка
Момент совпадает с апдейтом не связан
Кто затронут по версиям клиента/узла по географии, оператору
Другие адреса тоже не работают часть работает
Другая сеть не помогает часто помогает
Откат версии помогает не помогает

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

Числовой пример#

Установка из панели и девяти узлов. После обновления жалобы от части пользователей.

Группа Затронуто Что общего
Узлы 1–3 (обновлены) 100 % жалоб новая версия
Узлы 4–9 (не обновлены) 0 % жалоб старая версия
Пользователи с приложением ≥ 2.4 0 % жалоб новее порога
Пользователи с приложением < 2.4 100 % жалоб старее порога

Пересечение двух строк даёт ответ за минуту: ломается только сочетание «новый узел + старый клиент». Это механизм 1, а не блокировка. География не участвует вовсе.

Если бы это была блокировка, разделение прошло бы по операторам и регионам, а не по номерам версий.

Что делать до обновления#

Записать, что работает сейчас. Не «всё нормально», а измеримое состояние: какие маршруты проверены, с какими результатами. Без этого после обновления не с чем сравнивать.

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

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

Держать путь отката. Не теоретический («вернём версию»), а проверенный: известно, куда откатываться, и что при этом произойдёт с данными.

Что делать после#

Сравнить действующую конфигурацию с поданной. Механизм 2 ловится только так.

Проверить с клиентом старой версии. Механизм 1 ловится только так.

Повторить те же измерения, что до. Разница между «до» и «после» — единственное, что интерпретируется однозначно.

Вывод#

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

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

И перед тем как искать блокировку — попробуйте откат. Если помогло, вы уже нашли причину.

Термины#

  • Изменение умолчания - смена значения, подставляемого для параметра, который вы не задавали.
  • Разрыв версий - состояние, при котором управляющая часть и исполнители работают на несовместимых версиях.
  • Действующая конфигурация - разобранное состояние, с которым сервис реально работает, в отличие от поданного файла.

FAQ: частые вопросы#

Как отличить последствие обновления от блокировки?#

Откатить версию. Откат не лечит блокировку, поэтому если он помог, причина была внутри установки.

В каком порядке обновлять?#

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

Почему в логах нет ошибки?#

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

Что читать дальше#