Переход с ManageEngine Service Desk Plus — практическое руководство

Любая миграция ITSM — это небольшой археологический проект. Десять лет истории заявок, три или четыре поколения пользовательских полей, наполовину забытое правило SLA, которое действует только во время заморозки на конец финансового года, — всё это должно пережить переезд, иначе операционная команда потеряет институциональную память. Это руководство написано для инженера или ИТ-менеджера, которому досталась инсталляция ManageEngine Service Desk Plus (SDP) и поручение перенести её в LinaDesk до следующего цикла продления.

Мы предполагаем, что у вас локальная версия SDP (сборка 14xxx или 15xxx), где-то между 5 000 и 200 000 исторических заявок, хранилище пользователей на базе Active Directory и небольшая горстка интеграций по email/LDAP. Если ваша версия SDP — редакция MSP, или вы используете Enterprise с плотно заполненным модулем CMDB, часть сопоставлений ниже придётся расширить — форма работы остаётся той же.

Почему организации уходят от SDP

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

• KVKK и резидентность данных. Облачная редакция SDP размещена на инфраструктуре Zoho за пределами Турции. С её локальной редакцией на этом фронте всё в порядке, но модель лицензирования подталкивает клиентов к облаку при продлении. Турецкие организации, связанные статьёй 9 закона KVKK (трансграничная передача данных), предпочитают поставщика локального решения под турецким контролем как страховку от принудительного перехода в облако.
• Траектория стоимости на одного технического специалиста. Цена SDP за одного технического специалиста стабильно растёт с 2022 года, а модульное ценообразование (дополнения для управления изменениями, проектов, CMDB) накапливается. Альтернатива с фиксированной лицензией устраняет сюрпризы при продлении.
• Эргономика интерфейса и горячих клавиш. Интерфейс SDP появился до норм дизайна эпохи Linear. Команды, чьи специалисты L1 весь день живут в очереди заявок, ощущают это ежедневно.
• Развёртывания с полной изоляцией от сети или в закрытых сетях. Государственные и оборонные заказчики не могут использовать облачные дополнения SDP; каждая нужная им функция должна работать внутри их периметра.

Причина имеет значение, потому что она диктует, что переносится. Миграция, движимая требованиями KVKK, как правило, сохраняет всё, потому что аудиторы будут об этом спрашивать. Миграция, движимая соображениями стоимости, охотно оставит позади функции, которыми никто не пользуется.

Этап 1 — Обследование (2 недели)

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

Провести инвентаризацию инсталляции SDP

Проведите честную инвентаризацию. Из консоли администратора SDP зафиксируйте следующее в общей таблице:

• Общее количество заявок с разбивкой по статусу (открыта, на удержании, решена, закрыта) и по году создания.
• Все используемые шаблоны заявок — включая те, о создателях которых уже никто не помнит.
• Все пользовательские поля по каждому модулю. Отметьте тип поля, является ли оно обязательным и какие шаблоны на него ссылаются.
• Все политики SLA с определениями рабочих часов, уровнями эскалации и критериями сопоставления.
• Все правила автоматизации (Business Rules, Field & Form Rules, Custom Triggers, Time Triggers).
• Все шаблоны писем и правила уведомлений.
• Все процессы согласования.
• Все роли с сопоставлением прав доступа.
• Каждую интеграцию: LDAP/AD, почтовые серверы, SCCM/пробники, сторонние API.

Результатом должен быть не документ, а список решений. Каждый пункт помечается как перенести, пересобрать или отказаться. Эмпирическое правило: если шаблон или пользовательское поле использовались менее чем в трёх заявках за последние двенадцать месяцев, это кандидат на отказ.

Опросить операционную команду

Обследование — это не только обход консоли администратора. Пообщайтесь с тремя специалистами L1, одним лидом L2 и руководителем службы поддержки. Спросите, какие отчёты они открывают еженедельно, какими макросами пользуются и какие поля привычно оставляют пустыми. Панели, которые никто не открывает, — это поля, которые никому не нужны.

Сопоставить зависимости интеграций

SDP часто служит хабом для смежных систем: инструмент мониторинга публикует оповещения как заявки, сканер активов записывает записи КЕ, интеграция с расчётом зарплаты запускает заявки на оформление сотрудников. Каждую из них нужно либо перенаправить на API LinaDesk, либо приостановить на время перехода. Пропустите хоть одну — и в понедельник утром вас встретит стопка осиротевших заявок.

Этап 2 — Сопоставление данных

Модели данных SDP и LinaDesk — родственники, а не близнецы. Таблица ниже — это сопоставление, которое мы используем как отправную точку; кастомизация всегда добавляет строки.

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

Этап 3 — Экспорт

У SDP есть три способа выгрузить данные: встроенные плановые экспорты, REST API v3 и прямой доступ к базе данных. У каждого есть своё место.

REST API v3 для структурированных данных

API — правильный источник для пользователей, специалистов, групп, категорий, политик SLA и любой сущности, которая нужна вам с полным набором полей. Эндпоинты стабильны, поддерживают постраничную выборку и возвращают JSON, который чисто ложится на нашу целевую схему.

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

# requires SDP TECHNICIAN_KEY with read access
$sdpUri  = "https://sdp.internal/api/v3/requests"
$authKey = $env:SDP_TECHNICIAN_KEY
$outDir  = "C:\migration\raw\requests"
New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$rowsPerPage = 100
$rowIndex    = 1

do {
  $inputData = @{
    list_info = @{
      row_count   = $rowsPerPage
      start_index = $rowIndex
      get_total_count = $true
      fields_required = @(
        "id","subject","description","status","priority",
        "created_time","resolved_time","closed_time",
        "requester","technician","group","category","subcategory","item",
        "udf_fields")
    }
  } | ConvertTo-Json -Depth 6 -Compress

  $resp = Invoke-RestMethod `
    -Uri "$sdpUri?input_data=$([uri]::EscapeDataString($inputData))" `
    -Headers @{ "authtoken" = $authKey } `
    -Method GET

  $resp.requests | ForEach-Object {
    $_ | ConvertTo-Json -Depth 12 |
      Out-File -Encoding utf8 "$outDir\req_$($_.id).json"
  }

  $total     = $resp.list_info.total_count
  $rowIndex += $rowsPerPage
} while ($rowIndex -le $total)

Эквивалентные скрипты для пользователей, групп и активов структурно идентичны. Держите их под контролем версий — вы запустите их минимум трижды: один раз во время пробного прогона, один раз во время репетиции и один раз во время самого перехода.

Прямое чтение базы данных для архивных вложений

SDP хранит вложения отдельно от тела заявки. API возвращает метаданные, но не сами блобы. Для получения самих байтов либо используйте эндпоинт файлового вложения для каждой записи (медленно, но соблюдает права доступа), либо читайте из таблицы FileAttachment в SDP плюс каталог Attachments на диске. На крупных инсталляциях (100 тыс.+ заявок с вложениями) второй вариант — единственный реалистичный; запланируйте ночной rsync.

Этап 4 — Сохранение истории заявок

Самое важное поле во всей миграции — CreatedAtUtc. Если оно молча принимает значение сейчас, десять лет истории сжимаются в один день, и каждый отчёт по SLA теряет смысл.

LinaDesk поддерживает создание заявок задним числом через эндпоинт массового импорта. Правило таково:

Каждая заявка, комментарий, переход статуса и запись аудита несёт свою исходную временную метку UTC. Ничто в пути импорта не может её перезаписать.

Конкретно: поле created_time.value в SDP — это строка Unix-времени в миллисекундах. Преобразуйте её в UTC ISO-8601 и передайте как CreatedAtUtc. Сделайте то же самое для resolved_time, closed_time и временной метки создания каждой отдельной заметки. Если у заметки есть updated_time, отличающееся от created_time, сохраните оба значения — команды аудита иногда это проверяют.

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

Этап 5 — Повторное сопоставление AD / LDAP

Пользователи почти всегда — самое сложное соединение во всей миграции. SDP внутренне идентифицирует пользователя по его REQUESTERID. Active Directory идентифицирует того же человека по его objectGUID. LinaDesk использует ExternalId (который мы рекомендуем задавать равным objectGUID из AD).

Миграция не может полагаться ни на один из первичных ключей в одиночку. Соединение, которое мы используем, в порядке приоритета:

1. UPN (userPrincipalName). Переживает переименования в AD и перемещения между лесами. Используйте как основное соединение.
2. Адрес электронной почты. Резервный вариант, если UPN отсутствует.
3. sAMAccountName. Последний вариант, поскольку уникальность не гарантирована между лесами.

Любой пользователь, не прошедший все три соединения, попадает в файл orphans.csv. В каждой реальной миграции, которую мы проводили, этот файл содержал от 20 до 400 строк — люди, покинувшие компанию, сервисные учётные записи, никогда не привязанные к AD, и заявители, отправившие одну-единственную заявку по email в 2018 году. Решите их судьбу вручную. Не пропускайте этот шаг: эти «сироты» всё ещё владеют историческими заявками, и их имена должны корректно отображаться в отчётности.

Этап 6 — Повторное сопоставление политик SLA

Модель SLA в SDP — это плоский движок правил: сопоставление по критериям заявки, применение окон реакции/решения к календарю рабочих часов. Модель LinaDesk близка, но не идентична:

• Operational Hours в SDP ↔ WorkCalendar в LinaDesk.
• Holidays в SDP ↔ WorkCalendarHoliday в LinaDesk.
• Критерии SLA в SDP ↔ условия SlaPolicyMatch в LinaDesk.
• Уровни эскалации в SDP ↔ цепочка SlaEscalation в LinaDesk.

Единственный значимый пробел касается частичных пауз. SDP позволяет ставить SLA на паузу, когда заявка находится в статусе Waiting for Requester. LinaDesk требует, чтобы то же самое поведение было явно смоделировано как массив PauseOnStatus в политике SLA. Выполните это сопоставление прямо в скрипте миграции, а не надейтесь, что значения по умолчанию совпадут — в каждой изученной нами инсталляции SDP был как минимум один нестандартный статус паузы.

Более подробное обсуждение календарной стороны проектирования SLA — в статье о проектировании SLA-календаря: описанные там решения по моделированию напрямую применимы к тому, как вы пересоберёте календарь в LinaDesk.

Этап 7 — Портал, брендинг, шаблоны уведомлений

Это не переносится. Это пересобирается.

Портал самообслуживания SDP — это сильно шаблонизированная оболочка в стиле Zoho. Портал LinaDesk — современный интерфейс на основе компонентов с той же функциональностью, но другой структурой. Скопируйте визуальные ресурсы (логотип, favicon, фирменные цвета) и тексты (приветственное сообщение, объявления на главной странице, описания категорий), и дайте дизайнеру два дня на пересборку портала в административном интерфейсе LinaDesk.

С шаблонами уведомлений та же история. Извлеките каждый шаблон письма из SDP в виде HTML плюс список переменных, затем пересоберите их в редакторе шаблонов LinaDesk. Синтаксис переменных LinaDesk выглядит как {{Ticket.Number}}; в SDP — $Request.RequestID. Синтаксис можно перевести автоматически; текст нужно проверить вручную.

Этап 8 — Четырёхнедельный параллельный запуск

Переход за один выходной — это игра в орлянку. Параллельная работа SDP и LinaDesk в течение четырёх недель — уже нет, она превращает орлянку в инженерную задачу.

Рекомендуемая нами последовательность:

1. Неделя -4: LinaDesk развёрнут. Исторические данные импортированы. У всех специалистов L1 есть учётные записи, и они прошли 90-минутное обучение. Маршрутизация почты всё ещё указывает на SDP.
2. Неделя -3: Ночные повторные импорты выполняются через дельта-API SDP, удерживая LinaDesk в пределах 24 часов от SDP. Специалистов просят выборочно проверять десять новых заявок в день в LinaDesk и заводить баг-репорты. Портал остаётся выключенным.
3. Неделя -2: Пятнадцать процентов входящей почты направляется в LinaDesk. Специалисты обрабатывают обе очереди. Отчёты формируются параллельно в обеих системах и сравниваются.
4. Неделя -1: Пятьдесят процентов входящей почты направляется в LinaDesk. Бета-версия портала открыта для небольшой группы пилотных заявителей. Любое расхождение уровня P0/P1 блокирует переход.
5. Выходные перехода: Финальный дельта-импорт. Маршрутизация почты переключается на 100% LinaDesk. Портал открывается для всех заявителей. SDP переводится в режим только для чтения; остаётся онлайн 90 дней для целей аудита.

90-дневный период только для чтения имеет значение. Регуляторы (и внутренний аудит) время от времени задают вопросы, требующие посмотреть, как выглядела заявка в исходной системе на конкретную дату. Удаление SDP на следующий день после перехода — ошибка, которую мы видели дважды, и оба раза она заканчивалась неудобным разговором о сохранении данных по требованию юристов (legal hold).

Чек-лист проверки после миграции

Прежде чем подписывать завершение проекта:

• Количество заявок совпадает: SDP.count(status=Closed, year=2024) равно LinaDesk.count(status=Closed, CreatedAtUtc between 2024-01-01 and 2024-12-31) с точностью до ±0,1%.
• Заявители-«сироты» учтены: каждый пользователь из orphans.csv либо имеет заглушку в LinaDesk, либо явно исключён, а его исторические заявки показывают сохранённое имя заявителя в теле заявки.
• Паритет отчётов SLA: выгрузите отчёт о соответствии SLA за предыдущий квартал из SDP и из LinaDesk; цифры должны совпадать с точностью до ±1%. Большие расхождения указывают на неверную настройку календаря или статуса паузы.
• Целостность вложений: выберите случайную выборку из 200 заявок за последние пять лет и проверьте, что каждое вложение открывается.
• Поиск по базе знаний: найдите пять самых просматриваемых статей базы знаний в LinaDesk и убедитесь, что они появляются в топ-5 результатов поиска.
• Интеграции: каждый перенаправленный вебхук, синхронизация LDAP и исходящий вызов API были замечены успешно сработавшими минимум дважды.

Типичные ошибки

Функции, которые есть в SDP, но отсутствуют в LinaDesk v1

Честный список. LinaDesk v1 не включает:

• Модуль управления проектами. Субмодуль Projects в SDP используют примерно 15% клиентов SDP; если вы среди них, это решение о границах проекта, а не задача для обходного пути.
• Уровень многоарендной (multi-tenant) архитектуры для MSP. LinaDesk по замыслу однотенантный — каждый клиент управляет своей собственной инсталляцией.
• Нативное мобильное приложение. Веб-интерфейс LinaDesk адаптивен для мобильных устройств, но нативная оболочка стоит в дорожной карте версии 1.2, а не в v1.

Если что-то из перечисленного критично для вашей работы, решите это на этапе обследования, а не за неделю до перехода.

Недооценка объёма миграции пользовательских полей

В каждой изученной нами миграции было как минимум одно пользовательское поле, заполненное в 60% исторических заявок, но лишь в 3% заявок за последний год. Кто-то перестал им пользоваться годы назад, и никто его не удалил. Перенесите его всё равно — осиротевшие данные всё ещё видны для аудита.

Доверие интерфейсу экспорта «по диапазону дат» в SDP

Интерфейс экспорта SDP в некоторых сборках молча ограничивает число строк до 5 000, а в других — до 10 000, и никакой ошибки при этом не возникает — только усечённый CSV. Всегда используйте API для всего, что превышает несколько сотен строк.

Похожие материалы

• Почему локальные ITSM-системы переживают подъём в 2026 году
• Проектирование SLA-календарей, устойчивых к смене графика и праздникам
• LinaDesk против ServiceNow, ManageEngine, Freshservice — таблица сравнения
• Безопасность и соответствие LinaDesk