Записки юного архитектора или Айсберг архитектуры 1С

Меня зовут Камиль Хайрутдинов, я технический архитектор в компании IEK Group.

Мне 27 лет, и в архитектуре 1С я уже 4 года, поэтому и название моей статьи – «Записки юного архитектора»: я расскажу свой опыт и понимание этой роли.

Для начала давайте разберемся: кто же такой архитектор 1С, и чем он занимается.
 

Вокруг роли архитектора в мире 1С существует много заблуждений.

• Его часто представляют как универсального специалиста, который знает все об 1С и процессах внутри нее.

• Считается, что архитектор может заменить разработчика, аналитика, а заодно починить принтер или разобраться, почему не работает Word или Windows.

• Еще одно распространенное заблуждение – что архитектор 1С полноценно управляет процессом разработки.

И это объяснимо, потому что в мире 1С еще до сих пор не сформировалось понятие об отличиях junior, middle и senior разработчика, а тут еще одно нововведение – архитектура.

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

Что, на мой взгляд, должен уметь технический архитектор 1С?

• Естественно, он должен разбираться в технической части 1С – желательно, на уровне 1С:Эксперта.

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

• Он должен иметь широкий кругозор, читать новости и знать различные инструменты – как в мире 1С, так и за его пределами.

• Он должен поддерживать работоспособность системы и уметь прогнозировать, как она будет развиваться – какой она станет через год, через два и так далее.

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

Расскажу, как я вообще попал в компанию IEK – почему меня пригласили.

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

У меня был именно такой случай – бизнес поставил передо мной три конкретные задачи:

• Повысить производительность основной оперативной базы. В моем случае это была одна база. Не будем относить сюда БП, ЗУП и так далее, потому что их производительность не настолько влияет на результаты работы бизнеса и его прибыль.

• Навести порядок в инфраструктуре 1С и том, что вокруг нее происходит: базы, серверы, кластеры.

• Выстроить процесс разработки с учетом новых веяний – автоматизировать релизные циклы, внедрить DevOps и так далее.

Во что вылились эти задачи на практике, я и хочу рассказать.

Мой рассказ будет построен по принципу концепции «айсберга»:

• Вначале мы поговорим о самых очевидных задачах архитектора, которые находятся на вершине этого айсберга: повышение производительности; анализ работы СУБД; поиск узких мест; устранение блокировок.

• А потом рассмотрим те неявные вопросы, которые скрываются под «толщей воды». Сюда относится: мониторинг; событийная интеграция; DevOps; управление и выстраивание процессов разработки; огромный пул дополнительных инструментов и технологий – S3, Vault, Docker, Grafana, Prometheus, Onescript/1С Исполнитель; особенности работы платформы – регламентные и фоновые задания, HTTP; а также перечень психологических трудностей – как самого архитектора, так и всей команды.

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

«Основные» задачи архитектора

Итак, с чего начинается работа архитектора?
 

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

Удобнее всего это делать в нотации C4 – до второго уровня декомпозиции. Если вы с этим знакомы – идеально. Если нет – достаточно простого описания: вики-страницы, схемы, диаграммы. Главное, чтобы с этим можно было дальше работать.
 

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

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

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

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

Важно: на этом этапе мы пока еще ничего не меняем. Мы просто фиксируем состояние системы «ДО», чтобы потом было с чем сравнивать. И только после этого приступаем к необходимым действиям.
 

Резюмируем – что нам помогло навести базовый порядок:

• мы перенастроили кластер;

• добились того, что 1С ожила – возможно, для этого что-то пришлось проапгрейдить;

• выявили самые популярные операции – зафиксировали их для себя на будущее;

• ускорили несколько тяжелых запросов;

• и самое главное – описали инфраструктуру.

Казалось бы, все рекомендуемые действия архитектора для ускорения 1С мы уже выполнили, получили +10 баллов к карме, и на этом уровне знания 1С-ника в принципе заканчиваются.

Но это еще не все – дальше мы начинаем копать в сторону СУБД.
 

СУБД. Microsoft SQL Server
 

В общедоступных источниках можно найти достаточно информации о том, как правильно настраивать ту или иную СУБД.

Мы в качестве СУБД используем MS SQL Server, а для нее базовые параметры, которые требуют тонкой настройки под каждую конкретную систему – это настройки параллелизма и конфигурации tempdb.
 

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

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

Также важно проанализировать индексы: какие действительно полезны, а какие – лишние; какие накладывается средствами 1С, а какие – вопреки требованиям лицензионного соглашения – средствами СУБД.

Следует учитывать, что в крупных компаниях за обслуживание базы 1С отвечают независимые подразделения: отдел СУБД (DBA) и отдел 1С. Между этими отделами нужно грамотно расписать:

• границы ответственности между админами, поддержкой и технической архитектурой;

• взаимодействие между этими отделами: кто когда что делает или не делает;

• регламенты по обслуживанию базы – по статистике, по индексам и так далее.

Какие результаты нам дает более глубокое погружение на сторону СУБД:

• Мы добавили индексы из 1С, заменив ими индексы из СУБД – там, где это было возможно. Очень ждем, когда 1С даст возможность управлять индексами полноценно.

• Удалили ненужные индексы из 1С.

• Определили самые активные по чтению и записи таблицы, чтобы потом уделить им особое внимание.

• Выявили самые большие и тяжелые таблицы – эти знания нам тоже понадобятся в будущем.

• И, надеюсь, не поругались с DBA за все это время.

Это даст вам еще +10 к самоуверенности и скорости 1С.

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

Мониторинг. Grafana + Prometheus (PDE, Irac и др.)

Для регулярного мониторинга можно использовать классические инструменты: Grafana, Prometheus, PDE и другие.
 

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

Далее запускаем в docker контейнеры для мониторинга:

• Prometheus;

• Grafana;

• И необходимый набор экспортеров – так называемых грабберов, которые будут получать информацию для анализа загрузки оборудования и операционной системы. Например, Node Exporter или Apache Exporter.

Все это можно разворачивать и настраивать буквально в пару кликов с помощью заранее написанных файлов docker-compose.yml – например, по инструкции.
 

Далее устанавливаем экспортеры для получения метрик с кластера серверов и отправки их в Prometheus. Здесь можно использовать

• 1C exporter

• Самописный контейнер на базе winow, который получает метрики с кластера серверов с помощью библиотеки irac на OneScript.

• Или подсистему PDE, которая устанавливается на любую базу 1С с БСП и позволяет отправлять метрики в Prometheus прямо из 1С.
   

Следующим шагом настраиваем дашборды и алерты.

Получив в Prometheus сводные данные с помощью экспортеров мы можем визуализировать необходимые показатели на графиках в Grafana и задать оповещения по критически важным параметрам.

Grafana поддерживает отправку алертов в Telegram, другие мессенджеры и на электронную почту.

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

Как итог:

• Мы контролируем все железо в одном месте.

• Видим все, что происходит с СУБД – можем получать все данные в динамике и в периодике.

• Наблюдаем за кластерами 1С, а также за самой 1С – за всеми ее критически важными процессами, такими, как фоновая обработка, отложенные процессы и очереди.

• И самое главное – нам приходят сообщения, если есть проблемы. Эти сообщения грамотно переводятся в инциденты и решаются.

Все это дает нам +15 к зрению.

Но это опять не все. После того как мы выстроили инфраструктуру и ее мониторинг, начинаем все это анализировать.
 

Событийная интеграция. RabbitMQ, событийно-объектная модель

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

Было принято решение пересмотреть существующий подход к интеграциям и обратиться на темную сторону – в сторону событийных подходов.
 

Чтобы прийти к событийной интеграции, архитектору 1С нужно понимать, какие подходы для нее используются. Я выделяю для себя два ключевых варианта:

• Объектная модель интеграции – когда конечное сообщение содержит состояние объекта на момент времени.

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

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

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

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

• Что будет входить в состав заголовков и свойств сообщений, чтобы обеспечивался удобный сквозной анализ передачи данных.

• Каким должно быть именование полей.

• По каким правилам должны передаваться пустые значения.

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

• Как обрабатывать события CREATE, CHANGE, DELETE – нужно ли их отделять и вообще ими обмениваться.

• Ну и самое главное – кто отвечает за администрирование RabbitMQ?
   

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

После того как мы разработали свою подсистему интеграции, мы:

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

• Предоставили все инструменты службе поддержки, и, главное, обучили их работе с этими инструментами.

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

Естественно, все сразу перевести на асинхронную модель интеграции не получится. Но мы хотя бы навели порядок и избавились от скачкообразной нагрузки и ненужных соединений – сделали нагрузку на систему планомерной. И получили +20 к интеграциям и диффузиям – осталось только работать.

Дополнительно мы решили несколько сопутствующих задач.

• Мониторинг показал, что огромное количество регламентных заданий запускаются одновременно, создавая неравномерную нагрузку и оставаясь непрозрачными в исполнении. Кроме того, было непонятно, каким образом накладываются их расписания и т.д. Чтобы решить эту проблему, мы написали подсистему контроля регламентных заданий – контроль запусков, наложение их расписаний и полное описание в Wiki.

• Внедрили Vault для хранения паролей, отказавшись от захардкоженных учетных данных в коде.

• Проанализировав таблицы, мы выявили, что самая большая и самая тяжелая таблица содержит двоичные данные прикрепленных файлов – PDF-ки сертификатов соответствия и так далее. Было принято решение перенести все это из 1С в S3. Теперь мы используем S3 для хранения двоичных данных, а также для передачи больших пакетов информации через подсистему обмена.

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

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

Оперативная работа. DevOps, архитектурный надзор, код-ревью, план развития компетенций сотрудников

Переходим к оперативной работе архитектора – выстраиванию контура разработки, процессов выпуска релизов, кода-ревью, архитектурного надзора и так далее.
 

Здесь тоже предстоит выбрать и настроить инструменты:

• В качестве основного инструмента разработки мы используем GitLab – он служит не только системой хранения версий, но и платформой для запуска пайплайнов и джоб в качестве GitLab CI.

• Работа с GitLab дополняется классическим стеком Atlassian – Jira и Confluence, которые отвечают за ведение проектов, управление задачами и документацией.

• SonarQube используется для статического анализа кода.

• А связывает все это и автоматизирует наш любимый OneScript.
   

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

Этот слайд отражает три самых массивных «кита», на которых строится процесс разработки.

• Регламент разработки описывает полный цикл – от постановки задачи до размещения рабочего кода в продуктовой базе. Он включает в себя используемый набор инструментов. Например, если используется классическое хранилище, к нему подключается прокси-сервер хранилища, Gitsync и перенос года в GitLab. Из GitLab запускаются сборки, выполняется статический анализ, дымовые и сценарные тесты. Это все в совокупности можно назвать регламентом разработки.

• К регламенту разработки подшиваются еще два дополнительных:

  • Регламент проведения код-ревью. На старте проверку кода может выполнять один технический архитектор, но со временем лучше перейти к формату peer-to-peer, чтобы люди могли учиться – как проверяя, так и будучи проверяемым.

  • Регламент архитектурного надзора. Он описывает порядок согласования архитектуры: начиная с этапа функциональных требований и заканчивая финальной проверкой уже реализованного решения в продуктовой или в предпродуктовой базе.

Как итог:

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

• Качественно подняли уровень компетенций в отделе.

• Повысили качество кода.

• И не делаем сотню «демонических» обновлений в день – и это, я думаю, уже хорошо.

Правда, все это дало нам +100500 психологических травм, и я объясню, почему.
 

Архитектор – тоже человек

Важно понимать, что архитектор – это не только новатор, который агитирует применять современные технологии, но и живой человек.

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

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

Что еще нужно архитектору?

• Конечно же, дружить, но при этом всячески отстаивать свою позицию – идти на компромисс, доказывая ценность принятых решений фактами.

• Нивелировать предпосылки к революции, чтобы отдел разработки в конце концов не сказал: «Нам архитектор не нужен, мы будем работать по-старому».

• Ну и самому не уволиться.
   

Вывод

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

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

Поэтому учитесь, развивайтесь, агитируйте за то, что действительно полезно, учите других, ломайте всяческие стены! Тогда через год даже те, кто был против, скажут вам «Спасибо» за этот опыт.
 

Вопросы и ответы

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

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

В таких случаях обязанности распределяют по зонам ответственности. Один архитектор отвечает за СУБД, второй – за DevOps-контур, третий – за процесс разработки и тестирования. Нужно пробовать.

Как убедить бизнес в необходимости всех этих изменений и работы архитектора, если их эффект не всегда очевиден и напрямую не ощущается?

На практике результат работы архитектора чаще всего виден через сравнение «До» и «После». В моем случае это подтверждалось фиксированием состояния системы.

Обычно к вопросам технической архитектуры обращаются, когда возникает проблема. Например, код, который корректно работал при 100 сеансах, начинает тормозить, когда сеансов становится 150 – возникают взаимоблокировки и долгие запросы, и бизнес теряет деньги. В этот момент становится очевидно – нужна архитектура и специалист, который сможет обозначить векторы развития и оптимизации.

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

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

На практике держать этот баланс в процессах автоматизации сложно.

Яркий пример – избыточное тестирование. Я не считаю, что юнит-тесты или глубокое бизнес-тестирование бесполезны, но иногда они создают дополнительные трудозатраты на написание и поддержку тестов, не давая заметного эффекта. Потому что вероятность критической ошибки в рабочем коде настолько мала, что усилия не окупают себя. То же самое относится к задержкам релизов из-за код-ревью – это тоже нехорошо.

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

Как оценить эффективность работы архитектора на средних и крупных проектах, где работают несколько управленцев, и сложно понять, какой вклад в успех или неудачу проекта вносит именно технический архитектор, а не руководитель аналитиков или менеджер проекта?

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

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

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

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

Можно ли назвать того архитектора, о котором вы говорили, словом техлид? Это то же самое? Или между этими ролями все-таки есть различие?

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD & CIO EVENT.