Рубрика «Эксперты Solar inRights»: Разработка. Мы способны делать лучше, чем написано в ТЗ!

Разработка программного обеспечения (ПО) для IdM/IGA-систем – это сложный процесс, включающий проектирование, создание, развертывание и обслуживание ПО. Получение высокой оценки от заказчиков требует от нас владения методами и технологиями, которые могут ускорить развертывание программного обеспечения, повысить его качество и эффективность.

О процессе разработки IdM/IGA-решения, о слаженной работе команды, о передовых трендах и методиках, которые используются для разработки систем управления доступом, рассказывает руководитель отдела разработки Solar inRights Кирилл Хацкевич.

Есть ли специфика по разработке решений IdM?

Бывают решения, которые разрабатываются специально под одного заказчика. Как правило, это какие-то самописные решения, спроектированные под требования одного клиента.

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

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

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

Какие ключевые требования вы готовы реализовать для заказчика?

Есть несколько ключевых технических требований, которым соответствуют реализуемые нами IdM-системы:

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

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

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

• Требования к производительности, масштабируемости, отказоустойчивости, различным уровням виртуализации для инсталляции нашей системы. У нас есть крупные заказчики с количеством пользователей более нескольких сотен тысяч. Мы внимательно следим за тем, чтобы наша система имела задел на гибкую масштабируемость и при этом высокую консистентность данных. В этом нам отлично помогают такие вещи, как, например, In-Memory Data Grid[1], решение под названием Hazelcast[2] или оркестратор контейнеров Kubernetes[3].

  
  

Какой стек технологий вы используете при разработке IdM-решения?

У нас самописное решение на Java, фронт[4] на ExtJS[5].

Java –язык Enterprise production ready, с многолетней историей, огромной практикой эксплуатации в системах Mission Critical[6] и большим Сommunity. Все заказчики понимают, что это и умеют это саппортить.

Что касается Front-end – ExtJS по факту сейчас уже наследие. В этом году у нас будет смена стека – переход на VueJS[7]. Фронтовые библиотеки и движки в рейтинговой таблице популярности меняются очень быстро. Главное, что мы закладываем архитектурно правильные подходы, позволяющие менять Front-end-стек без высоких накладных расходов, приобретая на выходе новые возможности этих движков и Good User Experience.

Активно внедряем и используем DevOps-практики[8], что позволяет снижать накладные расходы на доставку ПО до различных стендов и площадок, а также развиваем автотестирование, что сильно экономит нам ресурсы на регрессионных проверках.

Мы используем анализаторы кода и анализаторы зависимостей: Dependency-Track[9], SonarQube[10]. Понятно, что если система, реализующая безопасность, будет сама небезопасна, то она не будет удовлетворять главным нефункциональным требованиям к подобного рода системам.

Как выстроен процесс работы команды в Solar inRights?

В нашем департаменте несколько команд. Каждая команда кросс-функциональна.

Основополагающие роли – Product Owner и Delivery Manager. Внутри команды есть архитекторы, аналитики, дизайнеры, разработчики, тестировщики, инженеры. У каждой группы компетенций есть лиды.

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

Delivery Manager уже отвечает за то, как мы реализуем задачи, распределяет их между членам команды, отвечает за сроки постановки задач.

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

Должен ли разработчик понимать общую картину по достижению цели?

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

Разработчики в Solar inRights трудятся в удаленном формате? 

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

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

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

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

Без каких знаний и навыков не обойтись разработчику и где их получить?

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

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

Специальные курсы длительностью 3–6 месяцев под конкретный язык программирования наиболее эффективны, на мой взгляд.

Какие личные качества необходимы хорошему разработчику?

Я считаю, что хороший разработчик отличается от посредственного следующим:

• открыт всему новому; 
• мыслит out of scope – на перспективу; 
• действует проактивно; 
• постоянно задает вопросы: «Зачем я это делаю?», «Почему у меня такое задание?», «Что это принесет команде, проекту, продукту, компании?»;
• готов работать в команде.

Можно ли выявить подобные качества на собеседовании? На самом деле да. Очень важная часть встречи – это вопросы от кандидата. Эта часть важна не только кандидату, но и работодателю: вопросы обязательно должны быть. И хорошо, если они касаются не только, например, кода, но и бизнеса, который этот код автоматизирует. Как выстроена работа в команде, как часто общаются, как часто мы смотрим в сторону модернизации стека, почему выбран именно этот стек. Если кандидат задает подобные вопросы, значит, он интересуется и думает о развитии.

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

Какие у вас планы на будущее?

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

Точки, где мы продолжим развитие:

• DevOps-практики: автоматизация производства во всех ее проявлениях с различными Quality Gates[11], будь то автотесты или проверка на уязвимости.

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

• Горизонтальное масштабирование в разных слоях системы.

• Современные методологии разработки и горизонтальное масштабирование.

[1] In-Memory Data Grid – это распределённое хранилище данных в оперативной памяти, схожее по интерфейсу с обычной многопоточной хэш-таблицей.

[2] Hazelcast – одна из реализаций In-Memory Data Grid с открытым исходным кодом, написанная на Java.

[3] Kubernetes – открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями.

[4] То же, что Front-end – клиентская сторона пользовательского интерфейса к программно-аппаратной части сервиса.

[5] ExtJS – JavaScript библиотека для разработки веб-приложений и пользовательских интерфейсов.

[6] Системах Mission Critical – системы высокого уровня критичности, остановка или перебои в работе которых несут серьезные последствия для организации.

[7] VueJS – прогрессивный фреймворк для разработки пользовательских интерфейсов.

[8] DevOps – методологии и практики автоматизации процессов разработки и развертывания программного обеспечения.

[9] Dependency-Track – платформа для анализа зависимостей сторонних библиотек на риски к угрозам информационной безопасности.

[10] SonarQube – платформа для анализа качества программного кода на оптимальность и безопасность.

[11] Quality Gates – критерии качества, определяющие пороговые значения для продвижения продукта по конвейеру разработки.