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