Введение

Если упростить, то управление изменениями в ИТ — это попытка ответить на один очень бытовой вопрос: «что именно поменялось перед тем, как всё сломалось?»

ITIL 4 называет это Change Enablement (практика, которая помогает проводить изменения с приемлемым риском) и рядом ставит Service Configuration Management (практика, которая помогает поддерживать актуальную картину конфигураций и зависимостей). На бумаге всё выглядит аккуратно: есть RFC (Reqeust for Change), есть согласование, есть запись в CMDB. На практике же много изменений происходит «между делом»: кто-то поправил ACL (Access Control List) на роутере, кто-то перезапустил службу, кто-то «чуть-чуть подправил» nginx на проде.

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

Почему «дрейф» — источник скрытых инцидентов

Скрытый инцидент — это не обязательно авария. Чаще это «странность», которая потом внезапно становится аварией:

• нагрузка на CPU «почему-то» выросла на 15%;
• в логах «иногда» начали появляться таймауты;
• VPN «по вечерам» отваливается у части пользователей;
• в Zabbix начинают мигать триггеры, но само проходит.

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

Что именно нужно контролировать (кроме «конфига»)

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

• настройки сети (маршруты, NAT, ACL, MTU, DNS-перехват, DoH/DoT и т.п.);
• настройки приложений (конфиги, переменные окружения, версии контейнеров, параметры JVM/.NET);
• политики безопасности (учётки, группы, права, ключи, сертификаты);
• интеграции (кто куда ходит, какие URL, какие токены, какие таймауты);
• данные (да-да: изменение схемы БД или параметров пулов соединений — тоже «конфигурация»).

То есть «управление конфигурацией» — это не про красивые карточки в CMDB. Это про способность быстро ответить: что изменилось, когда, кем и какой компонент задело.

Пример 1: Keenetic — DNS «вроде работает», но приложения ведут себя странно

Домашние и офисные роутеры — отдельный источник сюрпризов. Например, включили перехват DNS или поменяли режим обработки IPv6, и внешне «интернет есть». Но:

• часть приложений начинает зависать на API;
• curl по IPv4 работает, по IPv6 — нет;
• DNS отвечает, но периодически в логах "bad rdata", потому что на 53 прилетает мусор/не DNS/сканы.

На практике это выглядит как «почему-то перестало подключаться только одно приложение», а реальная причина — изменение в перехвате DNS или в политике маршрутизации/фильтрации QUIC/UDP 443.

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

Кейс 2: Linux — одно «невинное» значение sysctl и странные таймауты

Ещё один частый сценарий: кто-то «подкрутил» параметры ядра. Например, изменил поведение TCP или лимиты сокетов. На сервисе внезапно начинается деградация, но снаружи всё выглядит как нагрузка/сеть/провайдер.

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

uname -a
sysctl -a
iptables -S
ip route
systemctl list-unit-files --state=enabled

Да, это много текста. Но в расследовании это экономит часы.

Где тут ITIL и зачем он вообще нужен

ITIL полезен не «процессами», а терминологией и рамкой мышления:

• Change Enablement — как провести изменение так, чтобы риск был приемлемым;
• Service Configuration Management — как понимать, из чего состоит услуга и как связаны ее компоненты;
• Incident Management — как восстанавливать сервис быстро;
• Problem Management — как не повторить то же самое завтра.

Дрейф конфигурации — это мост между инцидентами и проблемами: он объясняет «почему внезапно стало иначе».

Практическая методика «без фанатизма»

Если не хочется превращать жизнь в бесконечную бюрократию, можно начать с простого:

• выбераем 10–20 критичных компонентов (ядро сети, VPN, DNS, балансировщики, ключевые приложения);
• для каждого определяем, какие команды/файлы отражают «суть конфигурации»;
• фиксируем снимок регулярно и после важных изменений;
• при расхождении понимаем: это ожидаемо или нет.

Эти шаги не отменяют Change Enablement. Но делает его практичным: когда случился инцидент, у нас есть фактура.

Заключение

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

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