Аудит 1С - в это понятие сегодня можно много чего вложить. Как аудит бухгалтерского и налогового учета, так и аудит баз данных, железа, на котором расположены эти базы, доработок, кода и прочее.
Когда приходишь на новое рабочее место, программистом, бухгалтером, аналитиком, тимлидом - хочешь или нет, аудит будешь проводить. Хотя бы чтобы понять, что и в каком состоянии тебе досталось)
В статье хочу описать свой опыт проведения 1С аудита. Может, кому пригодится.
- Первичный осмотр
| Платформа | ||
|---|---|---|
| Конфигурация | ||
| Количество пользователей | ||
| Режим совместимости | ||
| Архитектура | клиент серверная/Файловая /SQL и кластер в одном месте или нет | |
| Тестовые базы/контуры | Где находятся? Не мешают ли рабочим? | |
| Лицензии | Проверяю утилитой ring | |
| Наличие бэкапов | Наличие/Расположение/Периодичность |
Сравнение конфигурации БД с конфигурацией поставщика - если включена возможность редактирования.
Посмотреть - может все и не плохо вовсе)
Если возможность редактирования включена, проверяем измененные объекты - сразу понимая, что можем вынести в расширение - выносим все, что так или иначе будет мешать обновлению. Естественно, все неоднозначно и зависит от множества факторов, например:
- Найдется код, который стоит оптимизировать и перенести в общие модули
- Найдется код, который пора убрать, как архаизм
- Найдется, то, что и оставить надо
Встречаются ситуации, когда в базе большое количество расширений, каждое из которых при первичном осмотре необходимо проверить. Я обычно к каждому расширению составляю список доработок, потом все переношу в таблицу и понимаю:
- какие расширения нужно объединить между собой,
- из каких код и добавленные объекты надо перенести в основную конфигурацию,
Про расширения:
https://v8.1c.ru/platforma/rasshireniya/?
//infostart.ru/1c/articles/442003/?ysclid=lybk7ltj7c206357256#queue
Но это первичный осмотр, при котором просто намечаем некоторые шаги.
2. APDEX
При первичной настройке целей у меня две:
- Определить неиспользуемый код и отключить (архаизмы)
Во все дополнительные отчеты и обработки, а так же добавленные в конфигурацию обработки и отчеты добавляем код замеров (если конфигурация самописная, можно просто добавить в нее из БСП подсистему “Оценка производительности”)
Более подробно можно почитать на ИТС или тут:
//infostart.ru/1c/articles/1686856/?ysclid=lt9xm6hn19297174663
Таким образом через какое то время (зависит от обработок и отчетов - есть истории, которые используются ежеквартально или вообще раз в год) можно получить информацию о том, что используется, а что есть архаизм и можно удалить. Рекомендую не рубить с плеча, просто убрать из интерфейса на какое-то время, только потом удалять все, что не используется, не стоит держать слишком долго, резервные копии никто не отменял, всегда можно достаточно быстро восстановить из копии все удаленные отчеты и обработки.
- Начать сбор статистики для последующей оптимизации
Тут надо добавлять замеры не “втупую” при открытии/формировании/нажатии кнопок, как делала в первом случае, а поумнее.
Как поступила я:
- Поговорила с ключевыми пользователями, из разговора выделила “медленные” процессы
- Составила список ключевых процессов, которые не нравятся пользователям.
- На каждый процесс подвесила APDEX, на некоторые сделала ручной замер.
В моем аудите, одной, конкретно взятой базы я настроила APDEX:
- Доработанный (не типовой) механизм проведения РТиУ - в том числе и по самописным регистрам. Замеры ставила на запись движений в каждый регистр отдельно.
- Открытие/создание на сервере формы документа Заявка на оплату
- 4 отчета - на которые показали пользователи
Для начала, все, буду корректировать сбор данных по мере необходимости и понимания что еще нужно.
Вручную - замером производительности прошла по 2м документам:
-
РТиУ - модуль объекта - обработки записи и проведения
-
Заказ поставщику - обновление формы, реакции кнопок на определенные действия пользователя.
3. SonarQube - Использовала модуль BSL
При настройке использовала статью: //infostart.ru/1c/articles/1661973/#_Toc1
И очень благодарна ребятам в группе https://t.me/SonarQube_1C_APK
Так как у меня тестовый сервер не самый модный, тут пришлось подождать, но оно того стоило.
Хвастаться пока нечем. Но!
Можно оценить технический долг и начать планировать исправления. А это то, зачем Sonar при аудите базы. Тут, конечно, надо поразбираться и времени потратить достаточное количество, в Sonar очень удобно и гибко можно настраивать проверку. Я при первом приближении решила не акцентировать свое внимание на дефекты кода, такие как:
- названиях не по стандартам 1С,
- длины строк,
- Модификатор Знач,
- опечатки и пр.
Сконцентрировалась на разделе “Ошибки”
Проанализировала его и получила отличный объем работ.
4. 1С АПК
Проверка кода на соответствие правилам разработки 1С. Эта конфигурация так же, как и Sonar, выполняет статическую проверку кода, в ней, так же как и в Sonar, есть свои ограничения, плюсы и минусы. Про нее тоже есть статьи с подробным описанием, как выполнять и анализировать, например:
https://v8.1c.ru/tekhnologii/1s-avtomatizirovannaya-proverka-konfiguratsiy/
Это полностью 1Сная история, для разработчика 1С она понятнее, чем Sonar, но у этой конфигурации есть серьезное ограничение, проверяет она только файловые базы, то есть если говорим про большие базы, проверить их быстро не удастся. Если проверить все же хочется, есть время и желание, можно попробовать, ключевое слово ПОПРОБОВАТЬ поступить следующим образом:
- Из cf создать новую файловую базу
- Выделить для этой операции максимальное количество ресурсов (можно определить, проверив сначала типовую БУХ или ЗУП)
- Попробовать запустить проверку
Я, в рамках эксперимента, выполняла и проверку Sonar, и проверку АПК - моя конфигурация прошла обе проверки, но проверку АПК раза с третьего, по причине нехватки ресурсов моей машины.
Результаты получились сопоставимыми лишь условно. В результате я решила опираться на результаты Sonar.
5. Аудит обменов опишу кратко:
- Проверка наличия описания логики
- При отсутствии описания, проверка логики работы + опрос пользователей
- Проверка обменов на безопасность (например: бывает, программисты используют оператор: Выполнить() - не проверяя, что за база подключается, что выполняет - фактически в нее можно передать любой код)
- План по оптимизации обменов (например: есть организации, в которых до сих пор обмен через файл - как со сторонними системами, так и обмен 1С-1С)
- По необходимости: План по рефакторингу и переработки логики работы обмена
- Переход на современные сервисы(web, http)
6. Выводы.
В процессе аудита:
- Определен технический долг
- Список процессов к оптимизации
- Намечена работа по оптимизации разработки
- Определен неиспользуемый код к отключению
В целом, благодаря проделанной работе, я смогла изучить базу, наметить план оптимизации и развития. Результаты аудита собрала в таблицы. Определила список первоочередных задач.
Пока все!
