Понимаю, звучит сильно, но давайте расскажу, как мы это сделали.
Платформа 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.
Если ошибка логическая, рано или поздно тормозящий запрос попадёт в дашборд либо пользователи пожалуются на неправильное поведение запроса и это попадёт к поддержке или аналитику.
Если проблема системная, например, изначально была одна архитектура, а через два года она изменилась, но база данных осталась прежней, то, когда начнутся проблемы, это заметит архитектор и сможет принять решение о необходимости переработки системы.
То есть независимо от того, есть замечания пользователей или нет, мы исправляем ошибки по журналу регистрации, занимаемся оптимизацией, закрываем технический долг и исправляем замечания по архитектуре. Всё это очень чётко работает, потому что проверки прозрачные и всем понятные и есть постоянная прозрачная отчётность.
Сводная информация по техническому долгу и динамике исправления
В итоге вот таким инструментом можно организационно и технически выстроить процесс устранения технического долга в одном отдельно взятом домене. Мы до этого пробовали разные варианты и нашли, как нам сейчас кажется, золотую середину, когда мы имеем объективную картину о техдолге и управляем объёмом этого долга.
Вместо заключения
Организовать и координировать работу больших команд и разные конфигурации очень непросто, нужен чёткий набор правил первичной гигиены и контроля. Вот так это устроено у нас. А у вас как?
