Понимаю, звучит сильно, но давайте расскажу, как мы это сделали.

Платформа 1С — одна из ключевых платформ для бизнес-автоматизации в Росатоме. Выбрали 1C потому, что нужны отечественные системы, способные выдерживать большую нагрузку и масштабироваться.

Сейчас на поддержке и в разработке у нас 28 централизованных систем, каждая из которых содержит под капотом десятки, а иногда и сотни информационных баз. Всего для их обслуживания задействовано более 600 серверов: это серверы лицензирования, серверы среднего звена и серверы СУБД. Каждая система развивается и насчитывает не менее 8–12 % изменений в год, а иногда и больше. Всем этим занимается 750+ сотрудников.

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

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

Я Заяна Ачинова, директор по стратегическому развитию 1С в Гринатоме, и отвечаю за стратегию развития направления 1С в Росатоме.

Что такое техдолг в нашем понимании

Это всё, что мешает нашей системе работать хорошо. Ошибки, которые мы видим в логах, когда что-то идёт не так. Программы, которые работают медленно и требуют больше времени, чем нужно. Замечания от систем, которые проверяют качество нашего кода. Ну и проблемы с архитектурой — когда мы что-то не учли или сделали не так, как следовало бы. В общем, это то, что нужно исправить, чтобы всё работало лучше и быстрее и чтобы эксплуатация не усложнялась со временем из-за неверного технического решения.

Вообще, организация эксплуатации — основа успешного функционирования систем. У нас к этому крайне трепетное отношение.

Как образуется техдолг

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

Конечно, ошибки совершают все и полностью избавиться от техдолга невозможно. Но мы должны его контролировать и создавать надёжную систему мониторинга и планомерного уменьшения техдолга. В этом и состоит победа.

А что если не контролировать

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

Но зато, когда мы будем закрывать в учётной системе год, мы с ужасом обнаружим, что ошибка была допущена в феврале, целый год система выдавала погрешность в расчётах и мы должны выполнить перерасчёт за весь год.

Точно по этой же причине мы не можем быть уверены, что пользователи при работе в системе, столкнувшись с сообщениями об ошибках, обязательно сообщат об этом службе поддержки. Да и заметить деградацию в производительности 1 % в день сложно. И если объективными средствами не контролировать скорость работы системы, то за 100 дней эксплуатации в нашем примере система будет работать ровно в 2 раза медленнее, а в год уже в 3,5 раза.

Если с ошибками в журнале регистрации и мониторингом производительности всё понятно, то возникает вопрос, зачем нужно проверять качество кода, если система работает и пользователи не видят сам код. Проблема в том, что, если мы не следим за стандартами разработки, это может привести к трудностям при доработке системы, усложнить её поддержку и задержать передачу кода между разработчиками. В итоге даже небольшие изменения могут превратиться в сложный проект, где придётся долго и неприятно разбираться в логике работы системы.

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

Система мониторинга и при чём тут СППР

В 1С-среде очень распространена СППР — система проектирования прикладных решений. Это что-то вроде системы бэк-трекинга по всей цепочке проектной работы.

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

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

Что мы получаем:

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

Ошибки журнала регистрации по всем продуктивным системам

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

Вот как мы это решаем:

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

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


Анализ медленных операций по всем системам

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

Статический анализ кода

Это процесс проверки программного кода на соответствие установленным стандартам.
Разработчики что-то поменяли, и каждый вечер изменения конвертируются в закладки для Git. Все закладки затем подаются в SonarQube. Это софт, который выполняет анализ прикладного кода и возвращает то, что именно не соответствует заранее установленным правилам разработки. То есть днём написали код — утром следующего дня получили что-то вроде «а вот здесь у вас запросы идут в цикле, так не надо». Эта информация отображается в 1С СППР — и любой разработчик видит техдолг, который сам накопил. То есть на каждом висят замечания, которые можно разбирать, игнорировать или передавать кому-то ещё. У нас проводится более 1000 таких проверок ежедневно.

В СППР мы видим:

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

Так мы отслеживаем качество кода и работу разработчиков.


Сводная информация по техническому долгу и динамике исправления

По каждому замечанию в СППР отображается информация по описанию ошибки и показываются статьи с информационно-технологических систем (ИТС) с пояснением, к чему ошибка может привести.


Пример замечания и описание ошибки

Организационно работа по исправлению ошибок статического анализа построена так:

• разработчикам даётся время, чтобы исправить ошибки, выявленные системой статического анализа кода;
• новые стажёры и джуны, приходящие в Центр 1С Росатома, в первые один-два месяца занимаются разбором и исправлением ошибок. Это помогает им освоиться с разработкой, изучить необходимые инструменты и на практике понять, как правильно писать код.

Это очень важная часть работы стажёров и джунов. Дело в том, что каждое замечание
статического анализатора автоматически снабжается пояснением, в чем тут ошибка и ссылкой на статью с объяснениями по этой ошибке в базе знаний. А там — что именно плохо, к чему это может привести на проде, как это лучше всего исправить — и пара примеров хорошего кода на практике.

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


Пример того, что правят стажёры

Архитектурные проверки

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


Пример архитектурных проверок

Вот один из самых ярких примеров с исправлением ошибки в типах реквизита. Разработчик скопировал один из реквизитов и по невнимательности забыл удалить лишние типы данных. Система хорошо работала, но при достижении больших объёмов в одной из таблиц скорость выполнения запроса к дополнительным реквизитам стала катастрофически деградировать. Удаление лишних типов у реквизита даже без переписывания запроса увеличило скорость его выполнения более чем в 30 раз.

А эти проверки мы проводим в еженедельном режиме:

• поиск объектов, на которые в конфигурации нет ссылок;
• метаданные с программно-включённой историей изменений;
• регистры с большим количеством измерений;
• незакрываемые регистры накопления остатков;
• документы без проведения или движений;
• метаданные с некорректной длиной кодов / номеров;
• регистры с пустыми ресурсами;
• объекты, для которых не созданы роли доступа.

Всего у нас разработано и применяется на практике более 80 типов проверок.

Что получается в итоге

Эти направления позволяют контролировать наличие грубых просчётов. Если кто-то написал кривой код не по стандарту — мы это увидим в выводах SonarQube.

Если ошибка логическая, рано или поздно тормозящий запрос попадёт в дашборд либо пользователи пожалуются на неправильное поведение запроса и это попадёт к поддержке или аналитику.

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

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


Сводная информация по техническому долгу и динамике исправления

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

Вместо заключения

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