iTop в эксплуатации: бэкапы, обновления 2.7 → 3.2, безопасность и типовые сбои — регламент аутсорсера

Модель эксплуатации: что вообще может сломаться

Меня зовут Семёнов Евгений Сергеевич, я технический директор ITfresh. В обзоре iTop я рассказывал, почему мы выбрали эту систему ядром учёта инфраструктуры наших клиентов, а в гайде по установке — как поднять её на Ubuntu 24.04 за вечер. Сегодня — про то, о чём почти никто не пишет: что происходит после установки. По моему опыту, поставить систему — это процентов двадцать работы. Остальные восемьдесят — годы тихого, скучного и абсолютно обязательного сопровождения. Делюсь нашим внутренним регламентом целиком: забирайте и пользуйтесь.

Начинаю любой регламент с карты рисков — списка того, что в конкретной системе может сломаться и что при этом теряется. Для iTop-инсталляции карта выглядит так:

• База данных MySQL/MariaDB — главная ценность. Здесь живёт вся CMDB: конфигурационные единицы, связи, тикеты, история изменений. Потеря БД — это потеря памяти инфраструктуры: кто с чем связан, что когда меняли, какие договоры к чему привязаны.
• Каталог conf/ и кастомные модули в extensions/ — конфигурация инсталляции и все доработки датамодели. Без них восстановленная база поднимется, но с «голым» iTop.
• Cron-задачи — самый коварный пункт. Через cron.php в iTop работает всё асинхронное: расчёт SLA-таймеров, отправка почтовых уведомлений, забор писем для создания тикетов. Если cron умирает, система внешне полностью работоспособна — а SLA молча не тикают и уведомления не уходят.
• Диск под вложениями — пользователи прикладывают к тикетам скриншоты и документы, и за пару лет это съедает десятки гигабайт.
• TLS-сертификаты — просроченный сертификат не убивает данные, но закрывает портал для пользователей, и доверие к системе тает на глазах.

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

Бэкапы: наша схема 3-2-1 для iTop

Что бэкапить — и что бэкапить не нужно

Полный бэкап iTop-инсталляции — это дамп базы плюс три каталога: conf/, data/ (вложения) и extensions/ (кастомные модули). Каталог env-production/ копировать не нужно: это скомпилированная среда, которую setup пересобирает из конфигурации и расширений за минуту. Многие бэкапят весь корень веб-сервера «на всякий случай» — вреда нет, но объём растёт впустую.

Штатный itop-backup против своего скрипта — почему мы делаем оба

В iTop есть штатное расширение резервного копирования: оно по расписанию складывает zip с дампом БД и конфигурацией в data/backups/. Это удобно — но это бэкап на том же диске, что и сама система. Сгорел диск — сгорело всё вместе. Поэтому у нас двухслойная схема: штатный механизм оставляем включённым (он выручает при «мягких» авариях вроде неудачной правки датамодели), а поверх него работает наш скрипт, который делает независимый дамп и увозит его с машины.

Ночной скрипт с ротацией и выгрузкой на FTP

Скелет нашего скрипта — ничего секретного, обычная связка mysqldump + tar + lftp:

#!/bin/bash
set -euo pipefail
TS=$(date +%F)
DST=/var/backups/itop
mkdir -p "$DST"
mysqldump --single-transaction --routines itopdb | gzip > "$DST/itopdb-$TS.sql.gz"
tar czf "$DST/itop-files-$TS.tar.gz" -C /var/www/itop conf data extensions
find "$DST" -name '*.gz' -mtime +14 -delete
lftp -e "mirror -R --only-newer $DST /itop-backup; quit" \
     -u backup_user,"$FTP_PASS" ftp.example-storage.ru
echo "OK $(date -Is)" >> "$DST/backup.log"

Ключевые моменты: --single-transaction снимает консистентный дамп InnoDB без блокировки таблиц (пользователи ночью всё равно спят, но привычка полезная), ротация локальных копий — 14 дней, на внешнем FTP храним 60 дней. Итого классическая схема 3-2-1: три копии (рабочая база, локальный дамп, внешний FTP), два типа носителей, одна копия вне площадки. Для клиентов, у которых iTop живёт в виртуалке на нашем гипервизоре, добавляется четвёртый слой — снапшот-бэкап всей ВМ средствами Veeam.

Ежеквартальный тест восстановления — регламент на 30 минут

Моё твёрдое убеждение: бэкап без теста восстановления — это лотерейный билет. Выглядит как бэкап, шуршит как бэкап, но выиграете ли вы при аварии — узнаете только при аварии. Поэтому раз в квартал инженер по чек-листу разворачивает последний бэкап на чистой виртуалке: поставить LAMP, залить дамп, распаковать каталоги, прогнать setup в режиме обновления, открыть портал, найти вчерашний тикет. На отлаженной процедуре это занимает полчаса. Дважды за годы практики этот тест находил проблему раньше, чем она стала бы катастрофой: один раз дампы молча обрезались из-за таймаута, второй раз на FTP кончилось место и заливались нулевые файлы.

Обновления внутри ветки: минорные релизы 3.2.x

Combodo выпускает минорные релизы регулярно, и значительная их часть — security-фиксы. Свежий пример: в 3.2.3-1 закрыта пачка CVE 2026 года — отражённый XSS в дашбордах, слабая генерация секретов, перечисление пользователей через форму логина. Наше правило: security-обновления накатываем в течение недели после выхода, функциональные — накопительно, раз в квартал, в общее окно обслуживания.

Порядок минорного обновления у нас отработан до автоматизма:

1. Анонс клиенту — письмо за день: «завтра с 13:00 до 13:30 портал заявок будет недоступен».
2. Снапшот ВМ — моментальная точка отката на уровне гипервизора.
3. Свежий бэкап — прогоняем ночной скрипт руками, не дожидаясь ночи.
4. Распаковка новой версии поверх — архив с itop.com, файлы поверх старых (conf и data не трогаются).
5. Setup в режиме upgrade — мастер сам видит существующую инсталляцию и обновляет схему БД.
6. Чек-лист из 10 проверок — портал открывается, логин работает, тикет создаётся, почта уходит и забирается, cron отработал, SLA-таймеры тикают, поиск ищет, дашборды рисуются, кастомные модули на месте, в логах чисто.

Реальный простой — 15–20 минут. Делаем в обеденное время или после 18:00: заявки в это время почти не идут, а инженер на связи ещё пару часов на случай сюрпризов.

Мажорный прыжок LTS 2.7 → 3.2: инструкция по выживанию

Почему вообще прыгать

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

Путь официального апгрейда — через промежуточные версии

Прямой прыжок 2.7 → 3.2 одним движением Combodo не поддерживает: официальная документация требует пройти миграционные заметки каждой мажорной ступени — 2.7 → 3.0, затем 3.0 → 3.1, затем 3.1 → 3.2. Мы делаем это буквально: последовательно накатываем 3.0, прогоняем setup, проверяем, затем 3.1, затем 3.2. Да, это дольше, чем хотелось бы. Нет, срезать угол не стоит: на ступени 2.7 → 3.0 происходит самая болезненная перестройка датамодели и портала, и если что-то сломается на «слепом» прыжке через две версии, вы даже не поймёте, на каком этапе.

Что ломается чаще всего: кастомные модули и портальные твики

Стандартный iTop переезжает между версиями на удивление гладко. Ломаются доработки. Топ проблем из нашей практики: XML-модули, использующие устаревшие конструкции датамодели (deprecated-поля и классы, которые в 3.x окончательно удалили); твики портала, сделанные под старый портал 2.7 — новый портал 3.x собран иначе, и их приходится переписывать с нуля; сторонние расширения, авторы которых забросили проект и не выпустили версию под 3.x — таким ищем замену или переписываем сами.

Репетиция на клоне — обязательна

Мажорный апгрейд мы никогда не делаем сразу на проде. Сначала — полная репетиция на клоне: разворачиваем копию из бэкапа на отдельной ВМ и проходим весь путь 2.7 → 3.0 → 3.1 → 3.2, записывая каждый шаг и каждую ошибку. Свежий кейс: клиентская инсталляция с четырьмя кастомными модулями. На репетиции два модуля из четырёх отказались компилироваться в 3.x — в одном лечилось заменой пары deprecated-тегов, второй пришлось переписать наполовину. На репетицию ушло полдня, на боевой апгрейд после неё — два часа по готовому конспекту. Без репетиции эти два часа превратились бы в сутки простоя с нервным клиентом на телефоне.

Безопасность: iTop смотрит в интернет только через мой труп

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

• iTop живёт в LAN или за VPN. Админский интерфейс не публикуется наружу никогда. Инженеры и админы ходят через тот же VPN, что и к остальной инфраструктуре.
• Наружу — только пользовательский портал, и только при явной необходимости. Если у клиента есть удалённые сотрудники без VPN, публикуем портал через reverse-proxy на отдельном vhost, а бэк-офис остаётся внутри.
• TLS обязателен — Let's Encrypt с автопродлением, HTTP жёстко редиректится на HTTPS.
• fail2ban на форму логина — банальная защита от перебора, настраивается за десять минут по логам веб-сервера.
• Отдельная админская учётка с длинным паролем, а там, где портал опубликован, — дополнительная аутентификация на уровне прокси перед формой iTop.
• Подписка на анонсы безопасности Combodo. Security-релизы выходят регулярно, и упомянутые выше CVE — лучший аргумент, почему их нельзя копить.
• Права на файлы: после завершения setup каталог conf/ переводим в read-only — это и рекомендация вендора, и защита от части атак на исполнение кода.

Харденинг MariaDB и PHP под iTop

Несколько конкретных настроек, которые мы применяем на каждой инсталляции. По базе данных:

• bind-address = 127.0.0.1 — база слушает только локальный интерфейс. iTop и MariaDB у нас всегда на одной машине, снаружи базе делать нечего.
• Отдельный пользователь БД без GRANT-прав — учётка, под которой работает iTop, умеет ровно CRUD по своей базе. Права на создание пользователей и раздачу привилегий ей не нужны.
• innodb_buffer_pool_size — под размер базы. Для типовой CMDB на 300–500 конфигурационных единиц и пары тысяч тикетов в год хватает 1–2 ГБ; когда буфер вмещает всю базу, интерфейс заметно отзывчивее.
• Slow query log на первые месяцы — включаем после запуска и смотрим, какие запросы тормозят. Обычно всплывают тяжёлые кастомные отчёты — их и оптимизируем.

По PHP: expose_php = Off (незачем сообщать версию в заголовках), включённый OPcache — на iTop он даёт заметное ускорение интерфейса практически бесплатно, и session.cookie_secure = On, раз уж TLS у нас обязателен. Отдельно слежу за лимитами memory_limit и max_execution_time: их дефолты периодически роняют setup при апгрейдах на больших базах.

Мониторинг самого iTop

Здесь есть приятная ирония: в статье об интеграциях я рассказывал, как Zabbix создаёт тикеты в iTop. Теперь замыкаем круг — Zabbix следит за системой, которая регистрирует его алерты. Наш шаблон проверок:

Самая ценная строка здесь — вторая. Проверку «жив ли cron» не делает почти никто, а именно она ловит самый частый и самый тихий сбой iTop, о котором ниже.

Типовые сбои из нашей практики и их разбор

Топ-5 инцидентов, которые мы ловили на iTop-инсталляциях за годы сопровождения. По каждому — симптомы, диагностика, лечение и профилактика.

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

2. Cron молча умер после смены пароля сервисной учётки. Наш самый поучительный инцидент. У клиента сменили пароль учётной записи, под которой крутился cron.php, — и неделю SLA не тикали, уведомления не уходили, письма в тикеты не превращались. Внешне система выглядела полностью здоровой. Обнаружили случайно, по жалобе «мне не пришло письмо о закрытии заявки». С тех пор проверка возраста cron-маркера — обязательный пункт мониторинга на каждой инсталляции, а сервисные учётки живут в менеджере паролей с пометкой «при смене — обновить в X, Y, Z».

3. Апгрейд PHP хостинг-панелью сломал расширения. Панель управления сервером услужливо обновила PHP до новой мажорной версии — и часть расширений iTop посыпалась с fatal error. Лечение: откат версии PHP, затем плановое обновление расширений и уже потом PHP. Профилактика: автообновление PHP на машине с iTop выключено, версия меняется только руками в окно обслуживания.

4. Почтовая петля: 400 тикетов за ночь. Классика жанра. Автоответ внешней системы полетел на адрес, из которого iTop создаёт тикеты; iTop на каждый тикет отправлял уведомление, на которое приходил новый автоответ. Утром нас ждали четыре сотни одинаковых заявок. Лечение: выключить забор почты, вычистить мусор пакетно, настроить фильтры на auto-submitted-заголовки и отправителей типа no-reply. Профилактика — те же фильтры плюс алерт на аномальную скорость создания тикетов.

5. «Оптимизация» БД руками убила collation. Админ клиента (не наш, до начала обслуживания) решил «оптимизировать базу» и прогнал конвертацию таблиц, заодно сменив collation. Результат — крякозябры в кириллице и падающие запросы. Лечение оказалось долгим: восстановление из бэкапа с потерей дня работы. Мораль, которую я повторяю каждому новому инженеру: в базу iTop руками не лазим вообще, все изменения — только через setup и штатные механизмы.

Регламент сопровождения одним листом

Сводная таблица — что и когда мы делаем на каждой обслуживаемой инсталляции iTop:

Если сложить, честная цифра сопровождения одной iTop-инсталляции — порядка 30–35 часов в год, включая квартальные тесты восстановления и одно окно минорных обновлений в квартал. Мажорный апгрейд раз в пару лет добавляет ещё день-полтора с репетицией. На фоне ценности, которую даёт живая CMDB, — это, на мой взгляд, лучшая инвестиция в порядок, какую может сделать компания на 20–50 рабочих мест.

Ключевая мысль напоследок. Все сбои из этой статьи объединяет одно: ни один из них не был внезапным. Диск заполнялся месяцами, cron умер в конкретный день смены пароля, петля разгонялась часами. Система сопровождения нужна не для героического тушения пожаров, а для того, чтобы пожары не начинались: мониторинг видит тление, регламент не даёт дровам накапливаться, а проверенный бэкап превращает худший сценарий из катастрофы в неприятность на полчаса.