О чём вообще речь

Десять-пятнадцать лет назад типовая инфраструктура была проще: пара стоек, несколько VLAN, один домен, один «главный» сервер. Да, и тогда всё ломалось, но хотя бы было понятно, где искать причину.

Сегодня даже в небольшой компании легко встретить набор: VPN, облачные сервисы, несколько провайдеров, контейнеры, CI/CD (Continuous Integration/Delivery), WAF (Web application firewall), мониторинг, куча интеграций и десятки «маленьких» настроек, которые критичны для бизнеса. И почти всё меняется постоянно — иногда незаметно.

В результате «управление изменениями» перестало быть «про CAB и согласования». Это стало вопросом устойчивости: умеем ли мы контролировать изменения и понимать конфигурацию сервиса.

Почему стало сложнее: три причины из практики

Сервис теперь состоит из множества компонентов

Даже один сайт может включать: балансировщик, nginx, приложение, очередь, БД, кеш, внешние API, DNS, сертификаты, CDN. Изменение в любом месте может проявиться «на другом конце»:

• включили HTTP/3 (QUIC — Quick UDP Internet Connections) — пользователям стало хуже в сети с фильтрацией UDP 443;
• поменяли DNS upstream — часть клиентов получила другой CDN-поп, выросла задержка;
• обновили сертификат — где-то осталась старая цепочка, и половина клиентов начала ругаться.

Изменения стали частыми и мелкими

Большие изменения обычно помнят: «мы переезжали», «мы обновляли». А мелкие — нет. Именно они чаще всего и создают дрейф. Пример из жизни: кто-то временно «для диагностики» меняет таймаут в reverse proxy и забывает вернуть. Потом на пике нагрузки всё начинает падать. Формально — «ничего не меняли». По факту — меняли.

Безопасность и соответствие требованиям стали ежедневной задачей

Даже если у тебя нет формального комплаенса, всё равно есть реальность: пароли, ключи, группы, доступы, правила firewall. Их меняют. Иногда правильно. Иногда — «на минутку». И это напрямую влияет на работоспособность. Особенно в инфраструктуре, где много VPN, сегментаций и ограничений.

Что именно следует считать «изменением»

Плохая новость: изменением является не только RFC в системе. Хорошая: можно договориться о разумной границе.

Минимально полезный список:

• изменения сетевых политик (ACL/NAT/маршруты, DNS-перехват, настройки VPN);
• изменения конфигов приложений и версий (пакеты, контейнеры, параметры runtime);
• изменения учётных записей/групп/прав;
• изменения интеграций (URL, токены, сертификаты, таймауты);
• изменения мониторинга/алертинга (потому что «сломался мониторинг» часто важнее, чем кажется).

Два «вредных мифа»

Миф 1: «У нас есть бэкапы, значит всё хорошо»

Бэкап — это возможность восстановиться. Но он не отвечает на вопрос «что изменилось». В инциденте нужно не только восстановить, но и понять причину, иначе завтра будет повтор.

Миф 2: «Всё важно, давайте контролировать всё»

Контроль всего — это шум, который съедает внимание. Лучше начать с малого: критичные компоненты и критичные параметры. Затем — расширять.

Как это выглядит в расследовании инцидента

Типовая картина: пользователи жалуются на «медленно», мониторинг показывает странности, техподдержка перезапускает сервисы, становится лучше, потом снова плохо.

Что обычно помогает быстро:

• понимать, какая конфигурация была «нормальной» (baseline);
• видеть, что именно поменялось (даже если это одна строка);
• связывать изменение с компонентом услуги (не «в инфраструктуре что-то», а «на роутере изменили policy», «на nginx включили http3»).

Минимальный набор практик, которые дают эффект

Если хочется сделать «по-взрослому», но без тяжёлых проектов:

1. Список критичных компонентов — 10–20 единиц (DNS, VPN, ядро сети, ключевые БД, фронтенды).
2. Набор фактов — что именно фиксируем (команды, файлы, версии).
3. Регулярность — например, раз в сутки + после важных изменений.
4. Порог шума — не каждый diff = пожар. Но каждый diff должен быть объясним.
5. Привязка к инцидентам — если был инцидент, изменения вокруг времени инцидента изучаются первыми.

Заключение

Управление изменениями и конфигурациями стало критически важным не потому, что так написано в ITIL. А потому что инфраструктура стала сложнее, изменений стало больше, а последствия «маленьких» правок стали дороже.

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

Нет коментариев