Начинаем с Help Desk, остальное подключается модулями
Первый этап IT GID Enterprise Core — система приёма и обработки заявок с контролем сроков и учётом ИТ-активов под ней. Ядро с самого начала умеет передавать события во внешние сервисы, поэтому сканеры, внешняя разведка и комплаенс подключаются к готовой системе, не затрагивая то, что уже работает.
Полный жизненный цикл заявки — и ничего сверх этого
Критерий готовности один: заявка проходит путь от сообщения сотрудника в Telegram до закрытия с зафиксированными сроками реакции и решения, и весь этот путь виден в рабочем интерфейсе инженера. Всё, что не работает на этот сценарий, отнесено к следующим этапам — так первая версия выходит быстрее и обходится дешевле.
Входит в первый этап
- Заявки. Категории и услуги, статусы, приоритеты, назначение на инженера, переписка с сотрудником, внутренние заметки, вложения
- Контроль сроков. Рабочие календари и праздники, матрица «приоритет — услуга», таймеры реакции и решения, пауза на время ожидания ответа, эскалация при просрочке
- Рабочее место инженера. Очередь заявок с фильтрами и сохранёнными подборками, карточка заявки, групповые действия
- Личный кабинет сотрудника. Подача заявки, список своих обращений, переписка, оценка после закрытия
- Telegram-бот. Подача заявки диалогом, проверка статуса, уведомления, привязка к учётной записи
- Учёт ИТ-активов. Типы объектов учёта, карточки активов с расширяемым набором характеристик, связи между активами, привязка актива к заявке
- Права и журнал действий. Роли руководителя по безопасности, системного администратора, инженера и заявителя; неизменяемый журнал всех изменений
- Подключение внешних сервисов. Передача событий по защищённому каналу, сервисные ключи доступа, описание программного интерфейса
- Отчётность. Соблюдение сроков, нагрузка на инженеров, срез по услугам, выгрузка в таблицу
Не входит в первый этап
- Приём заявок по электронной почте. Разбор почтовой переписки даёт много частных случаев; на старте достаточно сайта и Telegram
- База знаний и самообслуживание. Снижает нагрузку на поддержку, но для запуска не требуется
- Учёт трудозатрат и биллинг. Востребован сервисными компаниями — идёт сразу после запуска
- Согласования и визуальный конструктор маршрутов. На старте маршрутизация настраивается правилами, назначение выполняется вручную
- Мгновенное обновление интерфейса. Заменено автообновлением раз в 20 секунд: для пользователя разница незаметна, в разработке заметно дешевле
- Конструктор отчётов и дашборды. На старте — готовый набор отчётов
- Мобильное приложение. Адаптивный интерфейс закрывает работу с телефона
- Сетевые сканеры, внешняя разведка, аналитика. Подключаются отдельными модулями к уже работающей системе
Технологии подобраны так, чтобы первая версия вышла быстрее
Каждое решение сокращает объём разработки на первом этапе и не мешает наращивать систему дальше. В правой колонке — варианты, которые рассматривались, и причина отказа от них.
| Направление | Решение | Обоснование | Отклонённый вариант |
|---|---|---|---|
| Архитектура | Единое приложение с модульной структурой |
Границы между модулями заданы на уровне кода и внутренних интерфейсов, при этом система устанавливается одним пакетом. Вынос модуля в отдельный сервис выполняется позже и только там, где у него принципиально иная нагрузка — например, у сетевого сканера. | Разделение на микросервисы с самого начала: усложняет отладку и сопровождение, увеличивает объём разработки примерно на четверть |
| Серверная часть | Python 3.12, Django 5 и DRF |
Встроенная панель администрирования закрывает работу со всеми справочниками без отдельной разработки интерфейсов — это порядка 60 часов экономии. Управление правами, миграции базы и аутентификация также входят в комплект. | FastAPI: быстрее в обработке запросов, но панель администрирования, права и формы пришлось бы разрабатывать отдельно |
| База данных | PostgreSQL 16 | Хранение расширяемых характеристик активов с индексированным поиском по ним и разграничение данных между подразделениями на уровне самой базы. Соответствует требованиям к отечественному программному обеспечению. | MySQL: слабее в работе с расширяемыми структурами данных |
| Интерфейс | HTMX и Alpine.js на шаблонах Django |
Одна кодовая база вместо связки «сервер плюс отдельное веб-приложение»: нет дублирования логики, отдельной сборки и расхождения версий. Требуемая интерактивность очереди заявок обеспечивается полностью. | Отдельное приложение на React: добавляет 80–110 часов к первому этапу. Вернёмся к нему на этапе визуализации связей и дашбордов |
| Фоновые операции | Celery и Redis | Отсчёт сроков по заявкам, эскалации, рассылка уведомлений и передача событий во внешние системы с повторными попытками и очередью недоставленного. | Планировщик операционной системы: нет повторных попыток и контроля выполнения, сбои остаются незамеченными |
| Telegram | aiogram 3, отдельный процесс |
У бота другой режим работы и другой характер отказов. Он обращается к системе через внутренний интерфейс с сервисным ключом, поэтому сбой бота не влияет на работу веб-части. | Бот внутри основного приложения: один сбой выводит из строя оба канала приёма |
| Расширяемость | События во внешние системы и гибкие поля |
Перечень событий, подпись запросов, защита от повторной обработки, повторные попытки с нарастающей паузой. Подключаемый модуль записывает данные в собственную именованную область карточки актива, поэтому основные таблицы системы остаются неизменными. | Свободная запись в гибкие поля без описанной структуры: за несколько месяцев данные становятся неуправляемыми |
| Установка | Docker Compose, единый файл настроек |
Облачный кабинет и установка на сервере заказчика — одна и та же сборка, разница только в настройках. Работа в закрытом контуре без доступа в интернет поддерживается. | Kubernetes: избыточен для установки на один сервер |
Первые шесть компонентов составляют всю установку на первом этапе: это один сервер и одна команда запуска. Каждый следующий модуль добавляется рядом и обменивается данными с ядром только через описанный интерфейс, поэтому включается и отключается настройкой, без пересборки системы.
Восемь недель от старта до запуска
План рассчитан на одного разработчика полного цикла при загрузке 30 часов в неделю. Работы идут последовательно: каждый следующий блок опирается на данные и интерфейсы предыдущего. Три контрольные точки — моменты, когда результат можно посмотреть и оценить.
Диаграмма прокручивается по горизонтали.
240 часов первого этапа, разложенные по составу работ
Оценка построена на разработке с ИИ-ассистентом по знакомому набору технологий. На типовой части — модели данных, формы, миграции, административные экраны, тесты — это даёт реальный выигрыш в скорости, и он уже учтён в цифрах ниже. Скрытого резерва в оценке нет: она предполагает согласованный до старта регламент сроков и неизменный объём работ. При расширении объёма по ходу срок и стоимость пересматриваются отдельно.
| Состав работ | Направление | Что входит | Часы |
|---|---|---|---|
| Каркас и инфраструктура | Основа | Структура проекта, сборка и установка одной командой, разделение настроек для облака и сервера заказчика, автоматическая проверка кода | 12 |
| Права доступа и журнал | Основа | Организации, сотрудники, подразделения, роли и области видимости, неизменяемый журнал действий с защитой от правки задним числом | 18 |
| Учёт ИТ-активов | Основа | Типы объектов учёта, карточки активов с расширяемым набором характеристик, связи между активами, привязка к заявке | 16 |
| Заявки | Основа | Карточка обращения, статусы и переходы, приоритеты, услуги и категории, назначение исполнителя, переписка и внутренние заметки, вложения | 26 |
| Контроль сроков | Основа | Рабочие календари и праздники, матрица приоритетов, отсчёт времени реакции и решения, пауза на ожидании ответа, пересчёт при смене приоритета, эскалации | 24 |
| Рабочее место инженера | Интерфейс | Очередь заявок с фильтрами и сохранёнными подборками, карточка заявки, быстрые и групповые действия | 28 |
| Личный кабинет сотрудника | Интерфейс | Подача заявки, список своих обращений, переписка с поддержкой, оценка качества после закрытия | 14 |
| Дизайн-система | Интерфейс | Единый набор стилей и компонентов в фирменном оформлении IT GID, адаптация под экраны разного размера | 16 |
| Telegram-бот | Интеграции | Привязка учётной записи, подача заявки диалогом, проверка статуса, уведомления об изменениях | 16 |
| Уведомления | Интеграции | Электронная почта и Telegram, шаблоны сообщений, правила отправки по событиям | 10 |
| Интеграционный интерфейс | Интеграции | Перечень событий, передача во внешние системы с подписью и повторными попытками, сервисные ключи доступа, публикация описания интерфейса | 14 |
| Отчётность | Основа | Соблюдение сроков, нагрузка на инженеров, срез по услугам и подразделениям, выгрузка в таблицу | 10 |
| Перенос данных | Интеграции | Загрузка сотрудников и активов из таблиц, синхронизация учётных записей с Active Directory | 8 |
| Тестирование и доработки | Запуск | Проверка расчёта сроков и прав доступа, сквозной сценарий обработки заявки, исправления по итогам приёмки | 20 |
| Документация и запуск | Запуск | Руководство администратора, инструкция инженера, установка и настройка, обучение сотрудников | 8 |
| Итого по первому этапу | 240 ч | ||
Каждый следующий этап опирается на данные предыдущего
Порядок этапов выстроен так, чтобы система как можно раньше начала наполняться данными самостоятельно. Поэтому автоматическая инвентаризация сети идёт раньше внешней разведки: без неё карточки активов пришлось бы заполнять вручную, а именно на этих данных затем считаются риски и приоритеты. После каждого этапа система остаётся законченным продуктом, и решение о следующем принимается отдельно.
Зрелая служба поддержки
- Приём заявок по электронной почте 22 ч
- База знаний и самообслуживание 26 ч
- Учёт трудозатрат и биллинг 24 ч
- Согласования и правила маршрутизации 20 ч
- Дашборды и конструктор отчётов 28 ч
- Мобильная версия 16 ч
- Единый вход через Active Directory 10 ч
Автоматический учёт и контроль уязвимостей
- Сканирование сети и автозаполнение учёта 42 ч
- Определение операционных систем 14 ч
- Контроль уязвимостей: CVE, БДУ ФСТЭК, НКЦКИ 56 ч
- Справочники MITRE ATT&CK и нормативной базы 16 ч
- Автоматические задачи и закрытие по факту 28 ч
Внешняя киберразведка
- Подключение Shodan, Censys, SecurityTrails 34 ч
- Проверка утечек по адресам и телефонам 14 ч
- Карточка внешнего периметра и оповещения 24 ч
- Согласия и журнал разрешений на проверку 16 ч
Управление требованиями и рисками
- Разделение инфраструктуры на области 16 ч
- Соответствие 152-ФЗ, 187-ФЗ, ГОСТ Р 57580 56 ч
- Расчёт рисков по данным инвентаризации 28 ч
- Учёт организационных мер защиты 22 ч
Мониторинг социальных медиа и предиктивная аналитика
Эти четыре модуля отличаются от остальных по классу задачи: это не надстройка над ядром, а самостоятельный продукт со своей инфраструктурой сбора данных, хранилищем большого объёма и обучаемыми моделями. Оценивать их теми же мерками, что и остальные модули, было бы некорректно. Практичных вариантов два: сузить задачу до конкретного сценария — отслеживание ограниченного набора упоминаний бренда по нескольким источникам, около 120 часов, — либо подключить готовое отраслевое решение по программному интерфейсу. Выбор стоит сделать до начала четвёртого этапа, поскольку он влияет на состав предложения.
Решения, которые важно принять до начала работ
Срок в 8 недель и оценка в 240 часов действительны при определённости по пунктам ниже. Первые три желательно закрыть до старта: они влияют на структуру данных, а её изменение на поздних этапах обходится дороже всего.
Разделение по организациям и подразделениям
Облачный кабинет обслуживает несколько организаций одновременно, а внутри организации данные разделяются по подразделениям и контурам. Это разделение должно появиться в структуре данных на первой неделе: добавление его позже означает переработку выборок во всей системе. Поэтому управление областями перенесено из пятого этапа в основу первого.
Регламент контроля сроков
Рабочие календари, праздники, порядок остановки таймера на время ожидания ответа от сотрудника, пересчёт при смене приоритета — 24 часа разработки и самый частый источник замечаний на приёмке. Согласованный регламент до начала работ снимает большую часть последующих доработок.
Порядок расширения карточек активов
Гибкие поля дают модулям свободу и без правил быстро превращаются в неуправляемый набор данных. Правила вводятся с первого дня: отдельная именованная область для каждого модуля, описанная структура этой области, индексы для поиска, а характеристики, по которым регулярно фильтруют и сортируют, переносятся в обычные поля.
Работа в закрытом контуре
При полной изоляции от интернета Telegram-бот недоступен, а базы уязвимостей требуют регулярного обновления. Понадобится резервный канал приёма заявок — электронная почта или внутренний мессенджер — и порядок передачи обновлений подписанными файлами. Решение принимается до начала третьего этапа.
Юридическая рамка внешних проверок
Внешние сервисы разведки получают ваши домены и корпоративные адреса, а сканирование сети без письменного разрешения владельца недопустимо. Понадобится поручение на обработку данных и журнал разрешений на проверку внутри самой системы — соглашения о неразглашении для этого недостаточно.
Требования к отечественному программному обеспечению
Если планируется включение в реестр Минцифры, состав технологий влияет на выбор на старте, а не на поздних этапах. Выбранный набор — Python, PostgreSQL, Docker — этим требованиям соответствует и работает на Astra Linux и РЕД ОС без ограничений.