Как построили DevOps вокруг медицинской информационной системы
Эта история началась с проекта, который многие сочли бы слишком сложным для небольшой команды. Клиника почти два десятилетия использовала медицинскую информационную систему на базе 1С 7.7. За годы эксплуатации она обросла функциональностью, учитывала специфику учреждения и была хорошо знакома сотрудникам. Однако технологически решение безнадёжно устарело: изменения вносились вручную, интеграции требовали обходных решений, а формирование некоторых отчётов занимало десятки минут.
Особенно заметны проблемы стали при работе с XML, REST и большими объёмами табличных данных. Даже срочное исправление приходилось выполнять в окно, когда всех пользователей отключали от системы. Возможности динамического обновления, привычные для современных платформ, в старой конфигурации 1С 7.7 фактически отсутствовали.
В 2020 году руководство клиники приняло решение обновить технологическую основу проекта. В 2021-м начали привлекать разработчиков, а основным направлением стала миграция с 1С 7.7 на 1С 8.3. Выбор был практически предопределён: платформа обладала зрелой экосистемой, широким набором инструментов и понятным рынком специалистов.
При этом задача не сводилась к переходу на готовое отраслевое решение. Требовалось сохранить привычную логику работы сотрудников, интерфейсы документов и существующие бизнес-процессы. Заказчик не планировал перестраивать деятельность клиники ради новой программы - система должна была максимально точно повторить то, что пользователи привыкли видеть за двадцать лет.
Почему проект пришлось перестраивать
В 2023 году к работе подключился новый руководитель проекта. К тому моменту предыдущая команда почти полтора года пыталась адаптировать разработку под реальные потребности клиники, но результат заказчика не устраивал. По его оценке, новая версия уступала старой практически во всём: от скорости расписания врачей до процесса записи пациента на приём.
Команда была небольшой. В неё входили руководитель проекта, разработчик среднего уровня и начинающий специалист, который работал на половину ставки, совмещая разработку с обязанностями бухгалтера. Последняя роль оказалась полезной: сотрудница хорошо понимала учётные процессы и одновременно выполняла функции аналитика.
Со стороны клиники были назначены ответственные представители медицинского, финансового, материального, кадрового и зарплатного направлений. Они формировали требования и участвовали в тестировании. Существенную помощь оказывал системный администратор: виртуальные машины, доступы и инфраструктурные вопросы решались без заметных задержек.
Документации по старой системе не существовало. Поэтому анализ выполняли непосредственно по коду 1С 7.7 и интервью с сотрудниками. Работа велась удалённо, а коммуникацию сначала организовали в Google Meet. После того как сервис стал работать нестабильно и начал блокироваться, команда настроила локальный механизм взаимодействия средствами 1С.
Этот опыт подробно раскрывает практическая история о том, как строились DevOps для 1С и автоматизация разработки в небольшом проекте, где не было возможности содержать отдельные команды тестирования, инфраструктуры и релиз-инженеров.
От разрозненной работы к управляемому процессу
1С долгое время развивалась несколько обособленно от массовой инженерной культуры. В веб-разработке контроль версий, код-ревью, автоматические проверки и CI/CD давно стали стандартом. В проектах на 1С эти практики нередко воспринимались как необязательное усложнение, подходящее только крупным компаниям.
Однако небольшая команда особенно нуждается в прозрачном процессе. Когда один человек одновременно анализирует требования, пишет код, исправляет ошибки и выпускает обновления, ручные операции быстро становятся источником потерь. Любая забытая проверка или неточный релиз способны остановить работу клиники.
Поэтому внедрение DevOps в компании начали не с покупки большого набора инструментов, а с описания фактического процесса. Команда разобрала, как появляются задачи, кто формулирует требования, каким образом изменения попадают в систему и где возникают задержки. После этого работу разделили на этапы: постановка задачи, разработка, проверка, согласование, сборка и публикация.
Для управления задачами выбрали Redmine. Он позволил связать требования пользователей с конкретными изменениями, назначать ответственных и фиксировать результаты тестирования. Для медицинской системы это особенно важно: ошибка может затронуть расписание, расчёты, документы или сведения о пациентах, поэтому история изменений должна оставаться доступной.
Контроль версий и автоматические проверки
Следующим шагом стала работа с GitLab и EDT. Конфигурацию начали хранить в системе контроля версий, а изменения - оформлять отдельными ветками и объединять через merge request. Такой подход сделал обязательными просмотр кода и обсуждение спорных решений до их попадания в общую ветку.
Постепенно сформировался конвейер CI/CD. При создании merge request выполнялись базовые проверки, после успешного объединения изменений запускалась сборка DEV-окружения. Отдельный сценарий отвечал за сборку и выпуск master-ветки, ещё один - за развёртывание на промышленном контуре.
Автотесты стали важной частью процесса. Их задача заключалась не только в поиске новых ошибок, но и в защите уже работающей функциональности. При миграции с 1С 7.7 на 1С 8.3 это особенно ценно: новая реализация может выглядеть логично, но незаметно изменить поведение знакомого пользователям процесса.
Тестирование проводили совместно с представителями клиники. Ответственные сотрудники проверяли не абстрактные сценарии, а реальные операции: запись пациента, формирование расписания, расчёты, движение материалов, начисления и кадровые документы. Благодаря этому техническая проверка дополнялась оценкой бизнес-результата.
Производительность и промышленный запуск
Отдельное внимание уделили скорости работы. Производительность нельзя было оценивать только по времени выполнения отдельных запросов: важнее было, насколько быстро пользователь проходит полный рабочий сценарий. Анализировали запросы, структуру данных, отчёты, загрузку сервера и сетевое взаимодействие.
В ряде случаев ускорение достигалось не переписыванием всего модуля, а изменением алгоритма: ограничением объёма выбираемых данных, переносом обработки на сервер, корректировкой запросов и устранением повторных обращений к базе. Такой подход позволил сохранить привычное поведение системы и одновременно снизить нагрузку.
Промышленный запуск выполняли поэтапно. Перед публикацией проверяли резервное копирование, права доступа, сценарий отката и готовность пользователей. Это снизило риск остановки клиники и позволило быстрее реагировать на замечания первых рабочих дней.
Результатом стала не просто новая конфигурация, а управляемый цикл поставки изменений. Разработка медицинской информационной системы получила единые правила: задачи фиксируются, код проходит проверку, сборка повторяется автоматически, а релиз можно воспроизвести и при необходимости откатить.
Что дала новая модель
Главным приобретением стала предсказуемость. Команда перестала зависеть от памяти конкретного разработчика и ручных действий при каждом обновлении. Новые сотрудники получили понятную структуру проекта, а заказчик - возможность видеть статус задач и понимать, какие изменения входят в очередной релиз.
Потери тоже были. Пришлось отказаться от части старых решений, потратить время на обучение и принять тот факт, что автоматизация не устраняет необходимость в профессиональном анализе. Некоторые процессы сначала замедлились из-за дополнительных проверок, но впоследствии это компенсировалось сокращением числа аварийных исправлений.
Этот опыт показывает, что DevOps-подход не обязательно требует большой инфраструктуры и отдельного штата специалистов. Даже небольшая команда может использовать Git, code review, тесты, трекер и автоматические пайплайны, если внедрять их постепенно и связывать с конкретными проблемами проекта. Подробное описание организации такого процесса, включая структуру сборки и сценарии поставки, представлено в материале о построении DevOps вокруг системы для клиники.
В конечном счёте модернизация заключалась не только в переходе на 1С 8.3. Платформа стала основой для изменения всей культуры разработки: от хаотичных ручных исправлений команда перешла к контролируемому выпуску, а от зависимости от отдельных специалистов - к воспроизводимому процессу. Для клиники это означало более устойчивую информационную систему, а для разработчиков - возможность развивать её без постоянного риска нарушить работу пользователей.
