У нас в компании принят проектный подход к управлению. Он предполагает наличие регламента управления проектами с соответствующими документами и инструментами, проектного управляющего, отвечающего за систему в целом и менеджеров проектов, каждый из которых отвечает за свой модуль или группу модулей. В техническом управлении, частью которого является команда ИАП, внедрена автоматизация жизненного цикла ПО. Это сделано при помощи ряда инструментов, среди которых Microsoft Project, с помощью которого ведется корпоративное проектное управление.
Следующий элемент — детальное планирование работ. Оно производится в системе Atlassian JIRA. В ней же ведётся управление процессом разработки приложений, в том числе и управление процессом разработки ИАП. А хранение и контроль версий компонентов и модулей ИАП и сопутствующей документации производится с помощью системы SVN.
Следующий аспект — стандарты и методологии разработки, без которых невозможно проводить разработку таких масштабных систем, с большим количеством исполнителей. У нас есть бюро архитекторов, возглавляемое главным архитектором, который отвечает за разработку стандартов проектирования. В данном случае, проектирования слоев хранилища данных. Все архитекторы всех функциональных модулей должны следовать этим стандартам. Есть методология выполнения всех работ, формализованная в ряде документов. Такие методологии имеются по всем видам работ — от разработки BI до развертывания готовых приложений. Имея такие методологии, мы получаем возможность быстро вводить в проект новых исполнителей. Одним из важных аспектов всех методологий является то, что результат каждого вида работ должен быть отчуждаем от исполнителя, т.е. может быть полноценно использован без участия его автора.
Хочется ещё раз остановиться на модульности системы. Этими модулями мы движемся по проектам группы ИАП, возглавляемой проектным управляющим. Каждый проект имеет свою команду, возглавляемую менеджером проекта, и в проекте строится модуль, имеющий законченную функциональность. Например, комплект отчётов, реализация аналитической модели или функциональности.
Мы используем специальные методы оптимизации загрузки данных в хранилище, поскольку некоторые источники территориально разнесены и к тому же расположены в разных часовых поясах. Каждый источник имеет своё временное окно, когда из него можно забрать данные. Минимальное окно составляет 4 часа, среднее — 9 часов. За это время необходимо забрать и обработать данные, сделать из них объекты и сформировать витрины. Чтобы уложиться в это окно, мы используем распараллеливание задач загрузки. У нас есть архитектор ETL (Extract, Transformation, Load) и он строит дерево запусков задач загрузки, где проектирует на функциональном уровне возможность параллельного исполнения каких-то задач. Следующий уровень параллелизации находится уже внутри самого ETL-инструмента. Он не слишком сложно настраивается и тут тоже можно получить некоторый выигрыш в производительности. Третий уровень параллелизации находится в самой системе Netezza, и наши архитекторы проектируют компоненты хранилища данных таким образом, чтобы максимально использовать этот мощный ресурс оптимизации.
В целях автоматизации процессов администрирования системы мы выполняем кастомизацию системного программного обеспечения — CDC, ETL, BI-инструментов и Netezza. Кастомизация заключается в разработке на Java собственного ПО, которое позволяет выполнять оперативный мониторинг и администрирование процессов управления компонентами системы. Например, произошла сбойная ситуация — падение процесса ETL. Наш модуль контролирует процесс загрузки данных, администрирует его и оперативно перезапускает его в случае падения. Он также журналирует дерево ETL и отправляет администраторам ПФР сообщения об определенных событиях.
Мы внедрили автоматизированный SLA (Service Level Agreement — Соглашение об уровне услуги) взаимодействия с источником данных. Это ПО контролирует и фиксирует изменения в структуре источника данных. По сути, оно снимает контрольную сумму со структуры базы данных. Если в структуре базы данных источника что-то изменяется, то мы должны узнать об этом как можно раньше. У заказчика развёрнуты три среды: разработки, опытной эксплуатации и производственная среда. Такие изменения желательно поймать на более раннем этапе, чтобы минимизировать объём доработок.
В целях сокращения сроков работ и объёмов трудозатрат мы производим типизацию некоторых видов работ, она касается главным образом разработческих задач и, прежде всего, ETL-разработки. Созданы типовые ETL-загрузки — справочников, таблиц DВ2, таблиц PostgreSQL и т.п. У нас есть типовые шаблоны для решения подобных задач.
Качество программного продукта
Качество программного обеспечения — это очень важная характеристика больших автоматизированных систем. Из-за большого размера системы (1500 пользователей по всей России, а в перспективе расширение до 6000), возможная ошибка отразится на существенном количестве людей и вызовет поток входящих сообщений.
Поэтому мы уделяем вопросам качества ПО пристальное внимание и внедрили комплекс мер управления качеством, среди них: контроль качества работы аналитиков и разработчиков. Этот контроль выполняют тимлиды (руководители групп). Следующая мера — автоматизированный контроль качества в процессе разработки. В системе управления работами, в JIRA, фиксируется количество попыток и время выполнения задачи, и если они превышают определенные значение, то менеджер проекта сигнализирует о возникновении проблемы — что-то непредвиденное происходит с исполнителем или с архитектурой, и рабочая группа проводит анализ проблемы и предлагает решение. Также выполняется контроль разработки со стороны архитекторов. Они проверяют соблюдение стандартов разработки, начиная от наименования объектов, до соблюдения правил архитектуры. Также проверяется реализуемость и корректность архитектуры. Далее идёт тестирование. Мы выполняем несколько видов тестирования.
Модульное функциональное тестирование очень трудозатратно, но крайне необходимо. Оно выполняется на синтетических данных. Готовят данные аналитики, они же выполняют и тестирование. Это особенность нашего подхода к вопросу тестирования. Наши аналитики являются универсальными специалистами, они собирают бизнес-требования, выполняют бизнес-анализ, строят аналитическую модель, они же превращают бизнес-требования в результаты системного анализа, в маппинги, это уходит в разработку, результаты разработки они тестируют и смотрят, совпадает ли результат с теми бизнес-требованиями, которые они прорабатывали на начальном этапе. Получается, что аналитик является связующим контрольным звеном всех этапов работ, от сбора требований до внедрения. Аналитики готовят синтетические данные, чтобы модуль ETL прошел по всем веткам. На таких тестах мы ловим 95% ошибок. Далее идёт тестирование на выборках данных, регрессионное тестирование и нагрузочное тестирование. Сейчас мы ведем несколько разработок по автоматизации тестирования, поскольку это достаточно трудоемкий процесс. Эти разработки позволят быстрее и качественнее получать результаты тестирования.
Для контроля качества данных в хранилище мы ведем разработку модуля мониторинга метрик. Любой процесс в хранилище данных, например, ETL, как правило, довольно сложный и зачастую обращается к нескольким источникам, содержащим десятки, а то и сотни таблиц. Бывает так, что данные пришли, и заказчики говорят, запустите обработку, нам завтра надо построить реестр. А может оказаться так, что в одной таблице нет данных, другую еще не создали. Проверку таких ситуаций необходимо автоматизировать. По сути дела, это проверка предусловий выполнимости процесса. Таких процессов в хранилище данных много.
Направления развития системы
Стратегию и направления развития ИАП, как и АИС ПФР-2, определяет заказчик. Мы видим несколько направлений в которых может двигаться система. Естественным видится путь экстенсивного развития ИАП: подключение новых источников, новых предметных областей, расширение функционала существующих модулей, создание новых отчётов, вычисление новых показателей.
Другое направление — развитие функционала. Скорее всего, потребуется развитие быстрой аналитики. Зачастую заказчику нужно срочно получить какую-то информацию, что можно сделать непосредственно в слое источников хранилища данных, большую часть запросов можно выполнить очень быстро благодаря Netezza. Другие направления развития находятся в общем тренде отрасли: мобильная отчётность на планшетах и смартфонах, и предикативная и когнитивная аналитика, означающая использование алгоритмов Data Mining для прогнозирования показателей пенсионной системы.
СПЕЦПРОЕКТ КОМПАНИИ REDSYS
