От Agile до SRE: полный цикл современной разработки на 1С в МТС

Меня зовут Марат Мустафин, я ведущий системный архитектор в «Стрим 1С» группы МТС. Мы поддерживаем и развиваем внутреннюю 1С-экосистему для дочерних компаний, обслуживаем около 1000 пользователей и выпускаем релизы раз в неделю. В этом материале расскажу, как мы выработали подход, сочетающий современные практики DevOps (Development & Operations — разработка и эксплуатация/поддержка) со спецификой платформы, а также поделюсь процессами разработки и нашими ключевыми принципами.

«Стрим 1С» появился в группе МТС в 2021 году как продуктовая команда, которая закрывает автоматизацию ключевых внутренних бизнес-процессов дочерних компаний. У нас работают около 50 специалистов: разработчики, аналитики, архитекторы, QA-инженеры, а также Product Owners и CTO. Функции DevOps в основном закрываем силами архитекторов, но иногда привлекаем профильные команды под конкретные задачи. Формально наш «Стрим 1С» состоит из нескольких команд, отвечающих за свои продукты, но об этом расскажу чуть подробнее дальше.

За время существования «Стрим 1С» мы собрали экосистему, которая обеспечивает:

• еженедельные релизы с высоким уровнем качества, автоматизированный путь от разработки до публикации и надежной инфраструктурой с георезервированием;

• разделение ответственности между продуктовыми командами, отлаженные Agile-процессы с регулярными ретроспективами, а также культуру код-ревью (code review — проверка кода другим разработчиком) и коллективной ответственностью за качество;

• современный стек мониторинга и наблюдаемости, комплексное автоматизированное тестирование и инфраструктура как код через Jenkins и Gitlab CI.

В этом нам помогли несколько принципов:

• Автоматизация рутины. Мы отслеживали повторяющиеся действия от сборки релизов до развертывания тестовых контуров и старались уменьшить число ручных операций. За счет этого команда тратит больше времени на бизнес-задачи.

• Культура качества. Многоуровневый контроль через код-ревью, автотесты и повторное тестирование помогает держать прод стабильным при высокой скорости изменений.

• Наблюдаемость системы. Комплексный мониторинг позволяет заранее замечать проблемы и разбирать их по данным.

• Распределенная экспертиза. Разделение ответственности с инфраструктурными командами дает возможность каждому уровню делать свою работу профессионально, без распыления и в итоге повышает общую эффективность.

В этом материале я покажу, как мы реализуем эти принципы, как встроены в корпоративные процессы и как развили разработку 1С до полноценного направления.

---

Что собой представляет работа с 1С в МТС

Команды организационно разделены на продуктовые направления 1С: ЗУП (1С:Зарплата и управление персоналом), бухгалтерия (1С:Бухгалтерия КОРП Бит-Финанс), ФХД (1С:Управление холдингом и 1С:Документооборот), Управление арендными обязательствами (внутреннее решение 1С:Аренда), первая линия поддержки и внедрение новых компаний в экосистему МТС. За каждой командой закреплена своя зона ответственности. 

Инфраструктура рассчитана примерно на 1000 пользователей, поэтому мы также делим продуктовые и тестовые контуры — так разработки и проверки не задевают рабочие базы. Поскольку контур закрытый, работаем в клиент-серверной схеме с публикацией баз, а пользователь заходит через HAProxy, который по шаблону имени базы маршрутизирует запросы в нужный контур 1С. Для каждого продукта — свой отдельный продуктовый контур. Тестовый контур включает отдельные среды под разработку, сборку баз и тестов и копий баз.

Стек «Стрим 1С» собран под типовые задачи: 

• платформа — актуальный релиз 1С:Предприятие КОРП;

• серверы приложений 1С и СУБД — Windows Server 2019, часть окружений в Oracle Linux;

• базы данных и отказоустойчивость — MSSQL с AlwaysOn, PostgreSQL в интеграциях с каталогом данных и DQ NEO;

• обмены и очереди интеграций в RabbitMQ;

• журнал регистрации 1С в ClickHouse, а технологический журнал в OpenSearch;

• метрики и наблюдаемость через Telegraf + Victoria Metrics + Grafana;

• скрипты, тесты и автоматизация рутины — OneScript + gitsync, vrunner, vanessa, add;

• конвейеры сборки в Jenkins;

• конвейеры безопасности через Gitlab CI;

• сбор и трекинг ошибок через Sentry;

• статический анализ и контроль качества кода — SonarQube;

• репозитории и код-ревью лежат в GitLab, а «секреты» и доступы через HashiCorp Vault.

Отдельно выделю, что мы интегрированы с другими сервисами МТС как напрямую через REST/SOAP/RabbitMQ/Kafka, так и через интеграционную платформу MWS Octapi ^[1]. Общие интеграционные механизмы выносятся во внутреннюю библиотеку (Работа с RabbitMQ, MWS Octapi).

Workflow разработки 

Мы выпускаем релизы раз в неделю, поэтому наш процесс устроен так, чтобы скорость не съедала качество, и наоборот. Раньше он держался на «героизме» отдельных людей, теперь же — на автоматизации CI/CD-конвейера, который превращает задачу в рабочую функциональность за несколько дней.

Но, как и любой сложный механизм, конвейер требует внимания ^[2]. Путь от задачи до прода редко бывает идеально гладким. Даже при отлаженных процессах мы регулярно сталкиваемся с неожиданностями: сбой в кластере серверов 1С в момент сборки, глюк утилиты ibcmd при выгрузке конфигурации, внезапный отказ расширения собраться из-за скрытой зависимости.
Мы научились готовиться к релизу как к операции: проверяем ключевые узлы, добавляем обработку ошибок в пайплайны и держим под рукой чек-листы для ручного вмешательства. Особенно ярко это проявляется, когда нужно обновить 20 однотипных баз бухгалтерии: во всех все проходит гладко, а в последней возникает уникальная ошибка ^[3], требующей точечной диагностики.
Так что танцы с бубном и героизм отдельных специалистов никуда не исчезли — они просто стали управляемыми и осознанными. Автоматизация не отменила сложность, но дала нам инструменты, чтобы с ней справляться.

Требования и общая синхронизация

Исходной точкой является квартальное планирование. Пул задач формируется из нескольких источников: прямые обращения пользователей и инициативы, выявленные владельцем продукта при общении с заинтересованными сторонами. 

Этот пул представляет собой сбалансированный бэклог, куда входят новые функциональные требования, работы по техническому долгу и исправлению инцидентов. Далее каждая задача детализируется: основная информация фиксируется в Jira, а для сложных или объемных кейсов подготавливается дополнительная спецификация в Confluence, включающая схемы интеграций, пользовательские сценарии и диаграммы бизнес-процессов.

Дальше проходит покер планирования. Мы коллективно обсуждаем требования всей командой, в которую входят разработчики, аналитики и тестировщики. На этом этапе вытаскиваем узкие места в логике ^[4] и договариваемся о деталях реализации, чтобы потом не ловить классическое «я думал, ты имел в виду другое».

Вынос разработки за рамки хранилища 1С 

Используя Git через инструменты синхронизации (gitsync), мы получили: 

• полную историю изменений с возможностью diff и blame;

• пул-реквесты (Pull Request, PR — запрос на слияние) для код-ревью по задачам;

• единую точку входа для всей последующей автоматизации — тестов, сборок и развертывания. 

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

Код-ревью, Jenkins и пирамида автотестов

Код не уходит в основную ветку без ревью, поэтому после первичного тестирования со стороны аналитика создается пул-реквест. Ежедневно в 17:00 у нас проходит общий созвон, где мы смотрим открытые PR и оцениваем архитектуру, читаемость, соответствие стандартам и потенциальные риски. Этот формат хорошо «разносит» знания между командами и заметно ускоряет адаптацию новичков.

Важно: ветку в develop «сливает» не автор, а дежурный разработчик. Так меньше субъективности и больше общей ответственности за качество.

После принятого ревью задачу подхватывает Jenkins. Тестирование у нас многоуровневое — вся логика построена на том, чтобы ловить регрессии как можно раньше. В пирамиду входят unit-тесты на YAxUnit, интеграционные и сквозные сценарии на Vanessa-Automation и smoke-тесты после каждого слияния в develop.

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

Релизный цикл 

После того как все тесты успешно проходят, начинается развертывание: 

• В пятницу дежурные разработчики сливают одобренные задачи в develop и собирают тестовые релизы. Это быстро подсвечивает конфликты слияния. 

• На выходных автоматика гоняет полный набор тестов по этим релизам.

• В понедельник и вторник идет стабилизация — тестировщики и аналитики проводят приемку, разработчики закрывают критичные баги. Конвейеры Jenkins сами разворачивают сборки на нужные стенды.

• Во вторник вечером мы запускаем финальный пайплайн. Он автоматически сливает develop в master, ставит версионный тег, например v2.1.5, и формирует итоговую конфигурацию под прод.

Казалось бы, процесс отлажен до автоматизма. Но на практике каждый релиз — это маленькое приключение. У нас шесть продуктовых контуров, порядка 10 отдельных проектов и 50 баз. Конечно, не всегда все проходит идеально гладко. Мы не скрываем: за кадром остаются чаты в 12 часов ночи, экстренные фиксы или ручная заливка расширений в отдельные базы. Но именно благодаря автоматизации мы свели эти ситуации к управляемым инцидентам, а не к еженедельному хаосу. Наши пайплайны неидеальны — они живые, и мы постоянно их доращиваем, добавляя обработку очередного сюрприза в следующий релиз.

В итоге, как я писал выше, релизы выходят раз в неделю, ошибки мы ловим раньше, чем они попадают пользователям, а процесс остается воспроизводимым. Все можно запускать и поддерживать, минимизируя «синдром единственного хранителя знаний».

Однако стабильность в проде — это не только про безупречные релизы. Чтобы система работала без сбоев, мы внедрили практики Site Reliability Engineering (SRE, инженерное обеспечение надежности систем).

SRE-практики

Разработка и DevOps закрывают только половину задачи. В проде система должна работать стабильно, а проблемы нужно ловить раньше, чем их заметят пользователи. Для этого инцидент должен быстро обнаруживаться, причина — быть понятной, а действия по восстановлению — заранее описаны и воспроизводимы. Поэтому мы собрали многоуровневую систему мониторинга. 

Подход у нас гибридный. С одной стороны, агентский мониторинг дает детальные метрики с серверов и сервисов. С другой — безагентский (blackbox) регулярно проверяет доступность критичных эндпоинтов так, как это видит внешний пользователь.

Сбор метрик у нас начинается с Telegraf: агент стоит на всех ключевых узлах и снимает базовые системные показатели CPU, RAM, Disk I/O и сеть, а также тянет данные от самих сервисов. Здесь начинается самое интересное: стандартный мониторинг инфраструктуры не отвечает на вопросы «Сколько пользователей онлайн?», «Не копится ли очередь в RabbitMQ?» и «Какое среднее время проведения документа?». 

Чтобы закрыть эту задачу, мы сделали универсальную подсистему «Метрики» в общей библиотеке конфигураций. Она поднимает HTTP-сервис, который по запросу отдает данные в формате Prometheus — стандарте де-факто для современных систем мониторинга. Работает все довольно просто: 

• разработчик пишет алгоритм получения метрики и выводит результат в таблицу значений;

• Telegraf по расписанию опрашивает HTTP-эндпоинт сервиса метрик;

• полученные значения уходят в VictoriaMetrics, где хранятся как временные ряды.

Раньше, чтобы контролировать учетные записи со стандартной аутентификацией, приходилось проверять каждую базу отдельно. Сейчас график «Пользователи со стандартной аутентификацией» висит на общем дашборде в реальном времени. 

Дальше метрики превращаются в дашборды. В Grafana они разделены по ролям. Например, для команды SRE и админов есть общая картина здоровья инфраструктуры и сервисов 1С, для разработчиков — динамика ключевых показателей и производительность их модулей, а для аналитиков — тренды активности пользователей. 

Стоит признать, что построение этой системы наблюдаемости — не разовый проект, а непрерывный процесс. Работа над дашбордами никогда не заканчивается: часть метрик со временем оказывается избыточной, на другие команда перестает реагировать ^[5] — и пороги требуют пересмотра. Мы постоянно учимся, оттачивая «сигнал» и отфильтровывая «шум».

Критичные метрики по доступности, ошибкам и исчерпанию ресурсов завязаны на уведомления (алерты), которые уходят не только на почту, но и прямо в общий командный чат в Telegram. Это позволяет за минуты среагировать на инцидент. Когда уведомления срабатывает и проблема подтверждается, нужно понимать, что делать дальше. Для этого на каждый продуктивный контур у нас есть Disaster Recovery Plan (DRP) — пошаговый ранбук (runbook — детальное пошаговое руководство по выполнению типовых ИТ-процедур) под конкретные сценарии отказа, с порядком действий «шаг за шагом», назначенными ответственными и целевым временем восстановления (RTO). По такой схеме мы уже проработали несколько типовых сценариев:

• отказ одного сервера в кластере 1С с исключением узла через админку и проверкой балансировки — здесь RTO меньше 15 минут;

• проблемы с СУБД с понятным алгоритмом переключения на standby-реплику; 

• критическая ошибка после релиза с экстренным откатом на стабильную сборку из Git. 

При всей нашей подготовке, мониторинг и алерты — это страховка, а не панацея. Самые болезненные проблемы часто возникают там, где их не ждешь: например, при массовом обновлении баз бухгалтерии в одной из них может упасть расширение на сборке из-за ошибки в работе RAS, кластера 1С или утилиты ibcmd.
Такие инциденты требуют не только автоматического реагирования, но и глубокого понимания платформы, умения быстро принимать решения и, да, иногда ручного вмешательства «в обход» автоматики. Наши DRP-сценарии и runbook’и рождаются именно из таких ситуаций: каждый новый сюрприз превращается в документированную процедуру на будущее.

Зоны ответственности в инфраструктуре

Наблюдаемость и недельный релизный цикл не работают сами по себе — им нужна инфраструктура, которая выдерживает нагрузку и нормально восстанавливается. У нас вся система развернута на виртуальных серверах в контуре МТС, с географическим резервированием между ЦОД. Это закрывает непрерывность бизнес-процессов даже при серьезных инцидентах на уровне площадки.

От модели, где команда 1С отвечает за все, мы ушли сознательно: держим четкое разделение компетенций и работаем со специализированными командами. Так проще сопровождать сложную систему, потому что на каждом уровне есть своя экспертиза и понятные точки взаимодействия: 

На этом фундаменте наша зона — прикладная часть 1С и ее работа в бизнес-сценариях. Мы управляем кластерами серверов 1С (балансировка, рабочие процессы, контроль сессий и лицензий), ведем конфигурацию информационных баз (обновления и параметры), поддерживаем интеграционный контур (обмены через RabbitMQ, веб-сервисы и HTTP-сервисы, включая сервис бизнес-метрик под Prometheus).

Отдельно инфраструктурные команды следят за «здоровьем» железа и ОС, а мы смотрим на состояние процессов — временем отклика ключевых операций пользователей, статусом и очередью интеграционных обменов и прикладными метриками, вроде среднего времени проведения документа или количества активных сессий по подразделениям.

В целом, если в Grafana срабатывает уведомление по росту времени отклика проведения документа, наша команда действует сразу на нескольких уровнях: 

• мы начинаем с уровня 1С и своих метрик;

• если на нашей стороне причина не локализуется, подключаем команду DBA и передаем конкретику — ID проблемных сессий и временные метки, чтобы вместе разобрать медленные запросы; 

• при необходимости запрашиваем данные мониторинга со стороны ОС или инфраструктуры у смежных команд.

За счет такого разделения ответственность остается прозрачной, а расследование не превращается в длинную переписку. Каждая команда приносит данные на своем уровне, и это ускоряет диагностику и восстановление.

Архитектурная целостность

Скорость разработки и стабильность прода зависят не только от процессов и инфраструктуры. Если в каждой новой конфигурации заново собирать интеграции и сервисные куски, неизбежно появляются «велосипеды», разъезжается стиль, а поддержка превращается в отдельный вид спорта. 

Для этого мы сделали внутреннюю библиотеку 1С. Она встраивается во все наши конфигурации и работает как универсальный адаптер между бизнес-логикой и инфраструктурой. Внутри библиотеки собраны ключевые модули:

• Метрики. Через библиотеку у нас реализована подсистема, которая поднимает HTTP-сервис и отдает бизнес- и технологические метрики в формате Prometheus. Дальше Telegraf забирает их напрямую из 1С, и за счет этого мы получаем наблюдаемость не только «по железу», а по реальному состоянию процессов.

• Настройки и константы. Это единый механизм управления конфигурацией, который помогает держать консистентность между окружениями и не плодить разрозненные «таблички параметров» в каждой базе.

• Интеграция с Sentry. Ошибки и исключения собираются и отправляются автоматически, поэтому разбор инцидентов получается быстрее и менее зависимым от ручных логов.

Под инфраструктурные компоненты мы реализовали стандартизированные коннекторы. Для ClickHouse библиотека стала единым способом анализировать данные журнала регистрации. Для каталога данных — унифицированным механизмом формирования метаданных и справочной информации. А для сердца наших асинхронных обменов — коннектора RabbitMQ — она предоставила надежный и отказоустойчивый механизм для постановки и обработки сообщений. Все это критично для построения событийно-ориентированной архитектуры. 

Благодаря библиотеке новая конфигурация или сервис сразу получают готовые механизмы под весь стек, без отдельной разработки вокруг RabbitMQ, метрик или трекингов. Ошибки и улучшения живут в одном месте, а фиксы из библиотеки автоматически попадают во все конфигурации. 

Кроме того, команды используют одинаковые API и подходы, поэтому поддержку и совместную работу проще организовать без «перевода с диалекта на диалект». Так разработчики меньше времени тратят на интеграции и больше на бизнес-логику.

Взгляд в будущее: ИИ в помощь разработчику и продукту

Отдельным и крайне перспективным направлением для нас стало внедрение практик искусственного интеллекта ^[6] и машинного обучения ^[7]. Мы рассматриваем ИИ на двух уровнях:

1. Как инструмент повышения эффективности команды. Мы активно экспериментируем с генеративным ИИ для автоматизации рутинных задач: он помогает проводить первичный код-ревью, генерировать шаблоны модульных тестов и анализировать legacy-код, что экономит время разработчиков для решения более сложных проблем.

2. Как будущая возможность для продукта. Мы исследуем и анализируем, какие возможности ИИ могут быть интегрированы в наши решения — как для внутренних разработчиков (например, умный помощник по коду), так и для конечных пользователей (прогнозная аналитика в отчетах). Ключевая задача здесь — оценивать технологический стек, ROI и, что критично, риски, связанные с безопасностью и качеством.

Практический пример — использование ИИ-инструментов для ускорения разработки тех самых вспомогательных утилит на Go для мониторинга. ИИ помог быстро прототипировать и внедрить новые инструменты, закрыв инфраструктурные пробелы.

Самый главный фактор успеха

Инструменты, конвейеры и дашборды сами по себе ничего не гарантируют — все упирается в людей. На рынке сложно найти 1С-специалиста, который одновременно уверенно чувствует платформу и при этом работает в логике современной инженерной разработки, поэтому мы сделали ставку на рост сотрудников внутри команды. 

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

Собрав сильную команду и убрав рутину, мы научились управлять сложностью и построили адаптивную систему, которая не боится сбоев. Да, у нас есть автоматизация, CI/CD, мониторинг и отлаженные процессы, но мы еще иногда ловим сюрпризы при обновлениях, вмешиваемся руками и ходим на ночные дежурства. 

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