Разворачиваем iTop 3.2 на своём сервере: пошаговое внедрение от установки LAMP до первых заявок

Сайзинг: какой сервер нужен под iTop на 50 рабочих мест

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

Начнём с приятного: iTop нетребователен. Реальные цифры с наших инсталляций для компании до 50 пользователей и примерно полутора тысяч конфигурационных единиц:

База растёт медленно: с включённой историей изменений и потоком 150–200 заявок в месяц — порядка одного-двух гигабайт в год. Никакого кластера, балансировщика и выделенного сервера БД не нужно: один LAMP-сервер спокойно тянет и консоль техников, и портал пользователей. Единственное, на чём не стоит экономить, — SSD: мастер установки и апгрейды заметно упираются в диск.

Подготовка площадки: Ubuntu 24.04 + Apache + PHP 8.3 + MariaDB

iTop 3.2 официально дружит с PHP 8.1–8.3, так что штатный PHP 8.3 из репозиториев Ubuntu 24.04 подходит без танцев со сторонними PPA. С базой мы берём MariaDB 10.11 — тоже прямо из репозитория.

Пакеты, без которых установщик не пройдёт

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

sudo apt update
sudo apt install -y apache2 mariadb-server \
  php php-cli php-mysql php-xml php-mbstring php-curl \
  php-soap php-gd php-ldap php-zip unzip acl

Комментарии к неочевидным пунктам: php-xml обязателен — с ветки 3.2 без расширения DOM установка не стартует; php-curl обязателен с 3.1; php-soap нужен для SOAP-веб-сервисов, php-ldap — для будущей авторизации через Active Directory (поставьте сразу, чтобы потом не перезапускать setup), php-gd — для картинок в HTML-полях и автоуменьшения вложений.

Тюнинг php.ini

Правим /etc/php/8.3/apache2/php.ini (и на всякий случай те же значения в /etc/php/8.3/cli/php.ini — cron-задания iTop работают через CLI):

memory_limit = 512M
max_execution_time = 300
upload_max_filesize = 32M
post_max_size = 32M
session.gc_maxlifetime = 14400

512 мегабайт памяти — не перестраховка: компиляция датамодели при установке и апгрейдах реально столько ест. Лимиты загрузки в 32 МБ выбраны под вложения к заявкам — пользователи любят прикладывать видео экрана.

База и пользователь

sudo mysql
CREATE DATABASE itop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'itop'@'localhost' IDENTIFIED BY 'СложныйПароль';
GRANT ALL PRIVILEGES ON itop.* TO 'itop'@'localhost';
FLUSH PRIVILEGES;

Почему MariaDB, а не MySQL 8? Обе поддерживаются, но с MySQL 8 мы дважды ловили сюрпризы с collation по умолчанию (utf8mb4_0900_ai_ci против utf8mb4_unicode_ci) при переносе баз между серверами. С MariaDB таких приключений не было, поэтому в нашем стандарте — она. Если берёте MySQL, задайте collation явно при создании базы.

Раскладываем файлы

cd /tmp && wget -O itop.zip \
  https://sourceforge.net/projects/itop/files/latest/download
sudo mkdir -p /var/www/itop
sudo unzip itop.zip -d /tmp/itop-dist
sudo cp -r /tmp/itop-dist/web/* /var/www/itop/
sudo chown -R www-data:www-data /var/www/itop

Дистрибутив также лежит на GitHub в релизах Combodo — берите официальный zip, а не чьи-то «сборки». VirtualHost для Apache — классический, с DocumentRoot /var/www/itop и разрешённым AllowOverride All; HTTPS вешаем сразу, у нас это wildcard-сертификат или Let's Encrypt.

Мастер установки: выбор модулей — самое важное решение

Открываем https://itop.вашдомен/setup/ и проходим мастер. Первые шаги очевидны: проверка требований (если готовились по предыдущему разделу — всё зелёное), принятие лицензии, параметры БД, пароль администратора. Русский язык выбирается прямо в мастере — и интерфейс, и данные примеров будут на русском.

А вот дальше — развилка, которая определит вашу жизнь на годы: выбор модулей. Мастер спрашивает про три блока: Configuration Management (состав CMDB), Service Management (модель услуг) и Ticket Management (типы тикетов). Наш стандартный профиль для компании на 50 рабочих мест:

• CMDB — полная. Все классы CI, включая договоры и поставщиков: именно ради связей «сервис — договор — подрядчик» всё и затевается.
• Service Management for Service Providers — если внедряет аутсорсер (наш случай: услуги в разрезе договоров с клиентами). Для внутреннего ИТ-отдела достаточно варианта for Enterprises.
• User Request + Incident Management — да. Портальные заявки и инциденты с SLA.
• Known Errors / FAQ — да. База типовых решений окупается за месяц.
• Problem Management, Change Management, Ticket Approval — нет. На 50 РМ это оверхед: процессы будут стоять пустыми и мозолить глаза в меню.

Пункт «установить демо-данные» на проде отключаем: вычищать потом виртуальную компанию Demo из живой CMDB — занятие на любителя.

Первые 5 настроек после установки: наш чек-лист внедрения

Свежепоставленный iTop — это пустая сцена. Вот что мы настраиваем в первый день, по порядку.

1. Организации и каталог услуг

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

2. Профили и права

Три роли покрывают 95% случаев: Support Agent — инженеры, Portal User — все сотрудники клиента, Service Manager — руководитель, которому нужны отчёты по SLA. Административный доступ — только техдиректору и старшему инженеру, и это не паранойя: случайная правка датамодели админом-энтузиастом обходится дороже любой аварии.

3. Почтовый канал

Расширение Mail to Ticket Automation (бесплатное, ставится тем же мастером setup) забирает письма с ящика вида support@ и превращает их в заявки. Подробную настройку с фильтрами от почтовых петель разберу в следующей статье про интеграции — здесь просто зафиксирую: без почтового канала портал не взлетит, пользователи будут слать письма «как привыкли» ещё год.

4. SLA и SLT под реальный договор

В iTop SLA собирается из SLT (Service Level Target) — целевых показателей: время взятия в работу (TTO) и время решения (TTR) по приоритетам. Заводим ровно те цифры, что написаны в договоре обслуживания, привязываем к контракту клиента — и таймеры начинают тикать сами, а отчёт «сколько заявок мы просрочили» перестаёт быть предметом веры.

5. Брендинг и уведомления

Логотип на портале, тема писем, шаблоны уведомлений на человеческом русском («Ваша заявка №123 принята, инженер Алексей взял её в работу») вместо канцелярита по умолчанию. Мелочь, но именно по письмам пользователи судят, «работает система или нет».

Наполняем CMDB и не сходим с ума

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

С чего начинать: 4 класса

1. Серверы и виртуалки — имя, роль, IP, ОС, на чём работает (связь с гипервизором).
2. Рабочие места — имя компьютера, пользователь, ОС. Без серийников мониторов на первом этапе.
3. Сервисы/ПО — 1С, почта, файловый сервер, СЭД: то, о чём звонят, когда «не работает».
4. Договоры и поставщики — интернет-провайдер, поддержка МИС/1С, аренда оборудования: у кого какой номер договора и телефон поддержки.

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

Правило глубины связей

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

Русификация до конца: языковой пакет сообщества

Официальный русский перевод в дистрибутиве полный, и для большинства внедрений его достаточно. Но есть нюанс терминологии: часть формулировок официального пакета звучит переводно. Русскоязычное сообщество iTop (сайт itop-itsm.ru и его форум) поддерживает собственный обновляемый языковой пакет с более живыми формулировками и переведённую документацию. Пакет ставится как обычное расширение — копируете в extensions/, прогоняете setup, выбираете в списке модулей. Туда же, на форум сообщества, стоит идти с вопросами: шанс получить ответ на русском по конкретной ошибке там выше, чем на англоязычном форуме SourceForge.

Грабли, на которые мы наступили

Честный список из наших внедрений — в порядке убывания набитых шишек.

• Права на каталоги. Setup падает или зависает на записи конфигурации, если conf/, data/, log/ и env-* не принадлежат www-data. Симптом коварный: мастер доходит до конца и молча не может сохранить конфиг. Лечится chown -R www-data:www-data до запуска мастера.
• cron.php обязателен. Без него не работают SLA-таймеры, эскалации, отложенные уведомления и опрос почтового ящика. Это не «желательно», это часть системы. Наш вариант — systemd-таймер:

  # /etc/systemd/system/itop-cron.service
  [Unit]
  Description=iTop background tasks
  [Service]
  Type=oneshot
  User=www-data
  ExecStart=/usr/bin/php /var/www/itop/webservices/cron.php \
    --param_file=/var/www/itop/conf/cron.params
  
  # /etc/systemd/system/itop-cron.timer
  [Unit]
  Description=Run iTop cron every 5 minutes
  [Timer]
  OnCalendar=*:0/5
  [Install]
  WantedBy=timers.target

  В cron.params — логин и пароль сервисного пользователя с правами администратора, файл закрываем правами 600. Проверка: страница «Обслуживание фоновых задач» в консоли должна показывать свежие отметки запуска.
• Toolkit на проде. Инструмент разработчика датамодели (iTop toolkit) удобен на стенде, но на боевом сервере это дыра: он позволяет менять модель данных без аутентификации уровня приложения. Правило: на проде каталога toolkit/ быть не должно.
• Апгрейд PHP. После обновления PHP (например, при переезде на новый релиз Ubuntu) iTop может встретить вас ошибкой: скомпилированная конфигурация привязана к окружению. Лечение штатное — повторный прогон setup, он пересоберёт окружение под новую версию.
• Бэкап — это не только БД. Дамп MariaDB плюс каталоги conf/, data/ и extensions/ — вот полный комплект восстановления. Мы дампим базу ежедневно и забираем на внешний бэкап-сервер вместе с файлами.

XML-датамодель: первое касание кастомизации

Рано или поздно захочется своё поле. Философия iTop: ядро не патчим никогда, все правки — отдельным модулем-расширением, тогда апгрейды проходят безболезненно. Мини-пример: добавляем серверу поле «Дата окончания гарантии». Создаём каталог extensions/my-warranty/ с двумя файлами. Манифест module.my-warranty.php объявляет модуль, а рядом кладём datamodel.my-warranty.xml:

<?xml version="1.0" encoding="UTF-8"?>
<itop_design xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             version="3.2">
  <classes>
    <class id="Server">
      <fields>
        <field id="warranty_end" xsi:type="AttributeDate"
               _delta="define">
          <sql>warranty_end</sql>
          <is_null_allowed>true</is_null_allowed>
        </field>
      </fields>
    </class>
  </classes>
</itop_design>

Прогоняем setup, ставим галочку напротив нового модуля — и у класса Server появляется поле с датой, доступное в списках, фильтрах и CSV-импорте. Ключевое слово здесь _delta="define": мы не переписываем класс, а декларируем дельту к нему. По этому же принципу добавляются целые классы, меню и правила — но это уже материал для отдельной статьи.

Критерии успешного запуска: как понять, что внедрение состоялось

Технически поставить iTop — вечер работы. Внедрить — две-три недели. Наши метрики приёмки, по которым мы сами решаем, что проект закрыт:

1. 100% заявок идут через портал или почту. Ни одной задачи «позвонили лично админу на мобильный» за контрольную неделю. Это самый трудный пункт — и самый важный.
2. CMDB отвечает на три контрольных вопроса без привлечения памяти инженеров: что работает на этом гипервизоре; какие рабочие места у бухгалтерии; по какому договору и телефону чинить интернет.
3. SLA-отчёт за месяц собирается в два клика и не вызывает споров: цифры взятия в работу и решения считает система, а не Excel дежурного.

Директору клиента на сдаче мы показываем ровно две вещи: граф зависимостей его главного сервиса (обычно 1С) и отчёт по заявкам за месяц с процентом уложившихся в SLA. После этого вопрос «за что мы платим за внедрение» больше не поднимается.

В следующей статье серии — интеграции: авторизация через Active Directory, автотикеты из Zabbix, приём заявок с почты и миграция многолетнего учёта из Excel в CMDB. А если хочется получить работающую систему без чтения гайдов — обращайтесь, развернём и наполним под ключ.