Миф: работает — не трогай

MAATRIX

«Работает — не трогай» звучит как здравый смысл, а не как ошибка: зачем рисковать стабильностью ради изменения, которое никто не просил. Проблема в том, что это правило хорошо работает как тактика на один вечер («не буду сейчас лезть в прод перед выходными») и плохо — как стратегия на годы. Если система не тронута годами, у неё не становится меньше рисков — просто риски перестают быть видимыми, пока не сработают все разом.

Зерно правды: осторожность — это не паранойя

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

Более того, часть этой осторожности объективно правильная. Не стоит вносить изменения в прод в пятницу вечером без крайней необходимости. Не стоит переписывать рабочий скрипт «для красоты», если он и так делает своё дело и его никто не собирается расширять. Не стоит гнаться за модной технологией только потому, что она модная. Разумный консерватизм в инфраструктуре — это фильтр, который отсекает изменения ради изменений и оставляет только те, что несут понятную пользу.

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

Технический долг копится в тишине, пока никто не смотрит

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

# сколько пакетов реально отстало от актуальных версий
apt list --upgradable 2>/dev/null | wc -l

# когда система в последний раз обновлялась целиком
grep " upgrade " /var/log/apt/history.log | tail -5

Если этот список пуст или короткий — хорошо. Но на серверах, которые действительно годами не трогали «потому что работает», такая команда часто выдаёт три-четыре сотни строк, и среди них почти наверняка есть закрытые за это время уязвимости — конкретные CVE, для которых давно вышел патч, который просто никогда не накатывали. Проверить это по факту, а не на глазок, помогает регулярное сканирование уязвимостей сервера: список известных проблем, привязанных к вашим версиям пакетов, обычно отрезвляет быстрее любого абстрактного разговора про риски.

Здесь важна не сама по себе устаревшая версия — она может годами не создавать проблем, — а то, что риск копится незаметно и односторонне. Каждый день без патча — это ещё один день, когда публично описанная и растиражированная в эксплойт-фреймворках дыра остаётся открытой на вашем сервере, а сканеры ботов проверяют весь диапазон IP не целенаправленно, а по расписанию. Подробный разбор механики этого накопления — в статье про цену отложенного обновления и технический долг инфраструктуры: там же честно оговорено, что не каждый CVE применим к конкретной конфигурации, но узнать это можно, только если кто-то регулярно смотрит на список, а не считает, что раз не ломалось — значит не уязвимо.

Чем дольше не трогать, тем страшнее и сложнее становится любое изменение

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

Год назад обновление этой системы означало один шаг между соседними версиями с коротким changelog. Сегодня, после года простоя, это уже прыжок через несколько версий с десятками изменившихся конфигов, устаревших флагов и, возможно, сменившимся способом установки пакетов вообще. Через два года — это уже не «обновление», а фактически миграция на новую систему, потому что промежуточные версии из репозиториев исчезли, а прямого пути между старой и текущей веткой у вендора может не быть вовсе.

# для Ubuntu/Debian: сколько релизов вы фактически пропустили
lsb_release -a
# и когда вышла текущая версия — если давно, разрыв с актуальной уже большой

Эта нелинейность работает и на людях, не только на пакетах. Пока разрыв небольшой, человек, который последний раз трогал систему год назад, всё ещё способен быстро в неё вернуться — контекст свежий, логика решений понятна. Через три-четыре года «не трогай» тот же человек (если он вообще ещё в компании) уже не помнит деталей, а новый инженер видит чёрный ящик, к которому страшно прикасаться, потому что неизвестно, что он сломает. Страх перед изменением растёт не потому, что система стала объективно более хрупкой в моменте — она растёт потому, что цена ошибки при таком разрыве становится непредсказуемой, а непредсказуемость пугает сильнее любого конкретного риска.

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

Знание о системе испаряется быстрее, чем кажется

Третья издержка — самая недооценённая, потому что она не про софт, а про людей. Система, которую годами не открывают, не только физически устаревает — она перестаёт быть понятной кому бы то ни было. Знание о том, зачем стоит именно этот параметр в конфиге, почему cron-задача запускается именно в такое время и что произойдёт, если отключить вот этот сервис, живёт не в документации (которую в режиме «не трогай» обычно тоже не ведут), а в голове одного-двух человек.

# типичная картина на нетронутом годами сервере:
crontab -l
ls -la /etc/cron.d/
# половина задач — без комментариев, без понятного автора, без описания цели

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

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

Когда «работает» тихо превращается во «внезапно сломалось»

Четвёртая издержка — это момент истины, к которому ведут первые три. Система, которую не трогали годами, не становится от этого более надёжной — она становится системой с непроверенной надёжностью, разница между которыми видна только в момент отказа.

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

И вот тут проявляется вся цена накопленного бездействия разом. Патчи безопасности не ставились — значит, восстановление придётся делать на версии с известными дырами, которые ещё и надо будет закрывать параллельно с устранением аварии. Разрыв версий большой — значит, обычное восстановление превращается в миграцию вслепую. Знания о системе не осталось — значит, разбираться в логике придётся с нуля, читая код и конфиги как археолог, а не как человек, который помнит замысел. Ни бэкапа под рукой (потому что «зачем, всё же стабильно»), ни пути отката, ни понимания, какие зависимости критичны, а какие нет. Разбор именно такого сценария, когда откат внезапно оказывается не готов заранее, — в статье про план отката миграции: принцип тот же — путь назад нужно продумывать до того, как он понадобится, а не в момент, когда он уже понадобился.

Где проходит грань: разумная осторожность и полный отказ от поддержки

Из всего сказанного не следует вывод «трогайте всё постоянно» — это была бы такая же крайность, только с обратным знаком, и она создаёт свои риски: нестабильность из-за изменений ради изменений, усталость команды от бесконечных апдейтов без видимой пользы, риск регрессии там, где её реально можно было избежать. Смысл не в отказе от осторожности, а в том, чтобы отделить осторожность от паралича.

Практическая граница выглядит примерно так:

Ключевой критерий: если откладываемое действие не создаёт растущий во времени риск (устаревание, потеря знаний, окно уязвимости) — паузу можно держать сколько угодно. Если создаёт — пауза не убирает риск, а копит его на будущее, и рано или поздно решение перестанет быть добровольным. Тот же принцип, только применительно конкретно к обновлениям софта, подробнее разобран в статье про миф, что обновления ломают больше, чем чинят — там же и практика: тестовый контур, снапшот перед изменением, поэтапная раскатка. Узкий частный случай того же мифа — убеждение, что Linux и так стабилен и его не нужно обновлять, разбит отдельно, потому что звучит особенно правдоподобно именно про ядро и системные компоненты.

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

Частые вопросы