Развернуть Service Desk на своих серверах и эксплуатировать без вендора
Мастер первичной настройки, Helm-чарт для Kubernetes, адреса health и metrics, профиль нагрузки и сценарии на случай инцидента — что нужно службе эксплуатации.
На демонстрации системы обсуждают возможности. На внедрении выясняется, что решение принимает не тот, кому эти возможности нужны, а тот, кому потом с системой жить.
Вопросы у ИТ-службы другие. Кто выполнит первичную настройку и сколько это займёт. Куда смотреть, чтобы понять, что система жива. Что делать в три часа ночи, когда она не отвечает. Сколько пользователей и обращений она выдержит на выделенном железе. Можно ли откатиться, если релиз оказался неудачным.
Если ответов нет, внедрение либо не начинается, либо превращается в постоянную зависимость от поставщика. Ниже — что предусмотрено в поставке, чтобы этого не происходило.
Первый запуск ведёт мастер
Пустая инсталляция раньше встречала администратора деревом из тридцати разделов настроек. Формально всё было доступно, практически — непонятно, с чего начинать и что обязательно, а что подождёт.
Теперь первый вход открывает мастер первичной настройки. Он последовательно проводит по обязательному минимуму: организация, учётная запись администратора, первая очередь обращений, канал приёма заявок. Каждый шаг объясняет, зачем он нужен. После завершения система готова принять первое обращение.
Остальное — правила уведомлений, интеграции, разграничение прав, база знаний — настраивается позже и по мере необходимости. Разница в том, что теперь очевидно, что относится к минимуму, а что к развитию.
Kubernetes и одиночный сервер
Поставка включает Helm-чарт для развёртывания в кластере и конфигурации Docker Compose для установки на один сервер. Выбор зависит от того, что уже эксплуатирует ваша команда, — навязанного варианта нет.
Горизонтальное масштабирование поддержано. При подключении Redis события реального времени — появление нового обращения, изменение статуса, новое сообщение — корректно расходятся между несколькими экземплярами приложения. Без этого пользователи, попавшие на разные экземпляры, видели бы разное состояние одних и тех же данных.
Отдельно предусмотрен демонстрационный стенд с заполненными данными: обращения, проекты, статьи базы знаний, пользователи с разными ролями. Поднимается одной командой. Это удобно, чтобы показать систему коллегам, проверить сценарий до внедрения или потренировать сотрудников, не трогая рабочий контур.
Чем мониторить
Три служебных адреса закрывают типовые потребности эксплуатации.
Первый — проверка живости процесса. Отвечает быстро и не обращается к базе данных: его задача — сказать оркестратору, что процесс не завис. Второй — проверка готовности принимать трафик: он учитывает доступность базы и других зависимостей. Разделение важно: приложение может быть живым, но временно неспособным обслуживать запросы, и перезапускать его в этот момент не нужно.
Третий адрес отдаёт метрики в формате, который понимают стандартные системы сбора. Дашборды и правила оповещения строятся привычными инструментами, отдельного агента ставить не требуется.
Логи структурные. Это означает, что разбор инцидента не превращается в чтение сплошного текста: записи фильтруются по уровню, по организации, по конкретному запросу.
Сколько выдерживает
Опубликован профиль нагрузки: какие объёмы проверялись, на какой конфигурации, где начинается деградация. Указаны количество одновременных пользователей, объём обращений в базе, размер и число вложений.
Это нужно, чтобы рассчитать ресурсы заранее, а не выяснять пределы на боевом контуре. Если ваши объёмы заметно больше проверенных, честнее обсудить это до внедрения — включая вариант с выделенной инсталляцией.
Что делать при сбое
Подготовлены сценарии на случай инцидента, и написаны они как последовательность действий, а не как общие рекомендации.
Разобраны: подозрение на утечку данных, компрометация внешнего контура, откат неудачного релиза, ротация секретов, потеря доступа к учётной записи с двухфакторной аутентификацией. Для каждого сценария указано, что проверить в первую очередь, что сделать немедленно, а что может подождать до утра.
Отдельно описан порядок ротации ключей — с предупреждением о неочевидном побочном эффекте: смена основного секрета делает нечитаемыми секреты двухфакторной аутентификации, и пользователям придётся настроить её заново. О таких вещах лучше узнавать из документации, а не из опыта.
Что это меняет
Ни один из перечисленных пунктов не является функцией продукта в привычном смысле — их не показывают на демонстрации и не выносят в коммерческое предложение. Но именно они определяют, сможет ли ваша ИТ-служба работать с системой самостоятельно.
Все материалы входят в поставку и доступны службе эксплуатации заказчика без дополнительных условий.