Как в Kitsoft разрабатывали портал "Дия" - большая история
Александр Ефремов, СЕО Kitsoft, в колонке для "AIN.UA" рассказал о разработке портала, технологиях и особенностях работы на украинском рынке GovTech.
Фото: Александр Ефремов ain.ua
С чего все началось
Так как много лет мы специализируемся на создании электронных государственных сервисов, мы создали и развивали собственную платформу на базе BPMN (англ. Business Process Model and Notation - нотация и модель бизнес-процессов). Ее основная цель - разрабатывать сервисы быстро и качественно.
Платформу можно представить как маркетплейс различных госуслуг, каждая из которых является отдельным приложением. Сервисы на ней могут настраивать дизайнеры, аналитики и конфигуратор, а участие программистов минимально.
Это позволяет очень быстро масштабироваться. Несколько команд могут одновременно разрабатывать десятки различных сервисов, не мешая друг другу. Они используют одинаковые подходы и стандартный набор интеграции с внешними сервисами. При этом с точки зрения кода нет взаимного влияния, они не блокируют друг друга.
Почему это так важно? Разрозненность информационных решений является одной из самых больших проблем госуслуг. Каждый ресурс разрабатывался различными командами, которые проходили полный цикл разработки, очень долго и дорого.
В сентябре 2019 года было создано Министерство цифровой трансформации и одним из первых проектов инициировано создание единого портала электронных услуг "Дия". Мы предложили свое решение и выиграли тендер на разработку.
первые шаги
На старте мы провели анализ по интеграции со всеми реестрами, приняли участие в создании дизайна и подготовили движок для запуска первых услуг.
Для этого мы создали электронный кабинет гражданина, подтягивает информацию из различных реестров. -За большого количества особенностей работы каждого из них и низкого качества информации, это стало практически самым сложным. Но сегодня в "Дия" интегрировано уже около десятка внешних ресурсов.
UI и UX дизайн первых услуг на портале разрабатывали Fedoriv и Spiilka. Мы, в свою очередь, предоставляли консультации со стороны разработчика: как услуги могут работать, насколько те или иные элементы возможно реализовать на платформе. Анализ и проектирование были необходимы, чтобы понять, какие изменения вносить в систему.
Параллельно наша команда занималась налаживанием процессов на платформе, чтобы не просто запустить сервисы, но и правильно их тестировать, аудировать ход оказания услуг, быстро отслеживать проблемы и ошибки.
Поскольку в "Дия" процессы не замкнуты внутри системы, а взаимодействуют с внешними ресурсами, ошибки здесь неизбежны и их нужно правильно обрабатывать. У нас нет недель для того, чтобы разработчики исправили ошибку и залили новый софт. Поэтому мы подготовили необходимые средства отладки, чтобы подстраиваться под внешние факторы "на лету". Сократить время разработки нам удается за счет внедрения DevOps-практик.
Как разрабатываются новые онлайн услуги
Всего в проект "Дия" в Kitsoft работает 15 человек.
Фото: ain.ua
Возьмем, например, услугу "Помощь по безработице", которую мы реализовали совместно с проектом TAPAS.
Первый этап - это проектирование сетевых служб. Для начала мы изучили нормативную базу и стандартную процедуру: гражданин заполняет бумажные бланки, подает их в центр занятости, на основе этого предоставляется услуга. Но в таких заявках встречаются большие анкеты, юридические формулировки и целые абзацы из законов. Поэтому наша задача - не просто перевести бланк в онлайн форму, а трансформировать, упростить услугу.
В заявке на "Пособие по безработице" мы отказались от ненужных полей, переформулировали сложные вопросы на простые ответы "Да/Нет", подключили реестры, чтобы подтягивать данные автоматически. А чтобы человек не запутался, на каждом этапе дали объяснения, что напоминает онлайн-консультацию.
Кроме того, если бумажный бланк гражданин заполнит некорректно, ему откажут в услуге. Поэтому в онлайн сервисе важно было не дать пользователю ошибиться. Для этого мы определили возможные причины отказа и учли это в анкете. Например, если на этапе заполнения выяснится, что он трудоустроен или зарегистрирован как СПД, то же получит сообщение о том, что не может претендовать на статус безработного.
Подобные автоматические проверки на этапе заполнения формы экономят время и человека, который обращается за услугой, и администратора центра занятости.
На втором этапе конфигуратор описывают процесс, настраивают услугу на платформе, при необходимости создают необходимые реестры и справочники. Например, для услуги "Помощь по безработице" был создан реестр всех центров занятости, реестр администраторов и реестр заявок.
Третий этап - тестирование. Сначала мы проверяем новую онлайн услугу самостоятельно. Кроме ручного тестирования, как правило, делаем автотест. При внесении изменений это позволяет повторное тестирование проводить гораздо быстрее. Далее тестируют наши заказчики.
Если услуга более сложная, дополнительно запускаем бета-тестирование, когда доступ есть только у ограниченного числа реальных пользователей. При этом платформа построена так, что часть услуг проекта может находиться в бета-тесте, а часть уже полноценно работать.
Финальный этап - запуск и мониторинг. Если вдруг окажутся ошибки, которые были обнаружены на этапе тестирования, оперативно устраняем.
Мы постоянно взаимодействуем со службой поддержки Минцифры и отслеживаем обратную связь по качеству предоставления услуги, определяем какие сложности возникали у пользователей, и при необходимости вносим изменения.
Для аналитиков мы создаем отчет по обработке услуги. Например, если какая-то область справляется с предоставлением услуги "Помощь по безработице" хуже, это сразу видно в статистике, и руководители могут принять соответствующие меры.
Ценность "Дия"
"Дия" - это новый уровень качества услуг. Построить систему управления качеством каждого из отдельных сервисов - это очень долго, дорого и требует огромных ресурсов. Настроить одну систему управления качеством, одну систему мониторинга и унифицировать процесс создания услуги - гораздо эффективнее.
Сейчас запуская новую услугу, уже не нужно думать, как будет работать поддержка - есть отработанная система. Нет необходимости заново настраивать все мониторинг, разворачивать систему на серверах, отдельно их поддерживать, выделять новых людей.
"С каждой новой услугой нужно все меньше ресурсов для ее запуска. Это экономит деньги и высвобождает время".
Кроме того, продвигать единый бренд "Дия" - очень эффективное, на мой взгляд, решение Минцифры. Ведь часто бывает, что создается электронный сервис, но люди по привычке ходят по кабинетам, так как ждут от государства нового качества. Услышав о мобильном приложении, гражданин затем зайдет и воспользуется электронными услугами на портале. Так же, как он приходит в супермаркет и выбирает различные товары, так и в "Дия" - он уже знает куда идти, заходит на один сайт, авторизуется и может заказать все необходимые услуги.
Что под капотом
Платформа состоит из ряда логических подсистем и адаптирована к высоким нагрузкам, гибкого управления и возможности параллельно разрабатывать большое количество услуг одновременно. При разработке мы использовали такие технологии.
-
Внешний сайт diia.gov.ua - удобный и быстрый каталог услуг с поиском на ElasticSearch.
-
Электронный кабинет my.diia.gov.ua является средой для работы гражданина в системе, доступа к персональным данным из госреестра и получения услуг.
-
Сервис идентификации на госпорталах. Проект "Дия" интегрирован с id.gov.ua, это позволяет зайти в электронный кабинет через BankID, MobileID и электронная подпись гражданина.
-
Сервис сообщений. Когда документ готов или когда наоборот, по запросу чиновника нужно предоставить дополнительную информацию, система сообщает это пользователю через email или смс.
-
Платформа BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов), которая лежит в основе портала. Это отдельная подсистема, которая позволяет все сервисы формализовать, обрабатывать их стандартными методами через стандартные элементы и взаимодействовать с внешними системами.
Создание услуги на такой платформе требует минимум программирования, только правильного описания процессов и изменения форм, которые затем становятся доступными гражданам и администраторам услуг.
BPMN-платформа сохраняет данные в реестрах, взаимодействует с ними, подтягивает необходимую информацию. Это дирижер всей системы. В основе ее брокер сообщений - RabbitMQ. Это позволяет обрабатывать очередь сообщений с реестрами и гарантировать, что процессы не прервутся, а будут обработаны даже в случае неполадок при взаимодействии с внешними системами.
Последний элемент, о котором хочется рассказать, это платформа реестров, которая позволяет хранить в себе структурированные и неструктурированные данные. Там могут находиться справочники, используемые на формах ввода; хранятся данные результатов обработки услуг; загруженные файлы пользователем или полученные как результат оказания услуги. Она отвечает за их обработку и хранение.
Каждая из этих компонент содержит ряд микросервисов, что позволяет их горизонтально масштабировать и разделять - то, что называется responsibility segregation. Каждый из микросервисов имеет свою роль и абстрагированы от других элементов системы. Для взаимодействия с внешними сервисами, фронтенда и бэкенд мы в основном используем Restful API.
Для всех микросервисов ведутся логи - файлы, содержащие информацию о работе платформы. Настраивается их глубина и ротация. Все логи собираются через FileBit, агрегируются в Elasticsearch и визуализируются на панели Kibana для анализа работы системы. Также мы собираем и бизнес-метрики, которые обрабатываем и визуализируем с помощью InfluxDB и Grafana.
Elasticsearch используется не только для анализа и поиска по логам, но и для быстрого поиска по большим реестров. Это очень важный момент, потому что платформа универсальная, и мы не знаем заранее структуру всех реестров. В процессе создания услуги мы создаем схему реестра и наполняем данными. Для того, чтобы быстро работал поиск, информация реестров индексируется в Elasticsearch и позволяет быстро получать доступ к этим данным.
Мы используем только технологии с открытым кодом. Для разработки используется Node.js для backend и React.js для frontend.
Через GitLab мы обновляем все среды - тестовую, Препродакшн и продакшн. У нас есть процесс как по обновлению услуг, так и по обновлению ядра системы. Благодаря этому мы можем очень быстро адаптироваться к изменениям и очень быстро создавать новые услуги. Скорость достигается активным использованием Автотест на проекте. Для автотестов интерфейса мы используем Selenide, для тестов API - REST Assured, управление процессом тестирования - Jenkins. Результаты тестов падают прямо в Slack (наш корпоративный мессенджер).
"Услугу "Пособие по безработице" мы создали и запустили всего за 3 недели без риска для других элементов системы. При этом классическое разработке подобной услуги - около полугода."
Особое внимание мы уделяем защите персональных данных. Для гарантии целостности и защиты информации на портале используется криптографические библиотеки. Персональные данные, которые вносит пользователь, хранятся в отдельных от других данных средах (уточню, что для мобильного приложения персональные данные не сохраняются вообще). Данные, полученные порталом из реестров, не сохраняются.
Для защищенной интеграции с внешними реестрами используется система взаимодействия между государственными ресурсами - "Трембита" (аналог эстонской Х-Road), которая дополнительно гарантирует целостность и выполняет шифрование передаваемых данных.
Кроме того, мы регулярно тестируем портал на всевозможные утечки данных, а мониторинг уязвимостей является частью нашего процесса Автотест.
Вызовы
Во время работы над проектом мы столкнулись с несколькими вызовами, поэтому приходилось быстро адаптироваться.
1. Множество правил и ограничений внешних ресурсов и систем, с которыми нужно интегрироваться.
Хороший кейс интеграции различных государственных реестров - сервис "еМалятко", который объединяет 8 услуг и взаимодействует с различными государственными органами.
В то же время это был очень сложный проект, потому что у каждого государственного реестра свои правила, многие из них построены достаточно архаично. Иногда чтобы изменить несколько полей реестра, нужно было ждать месяца. Но мы прошли этот этап, я считаю, успешно. Хотя это раскрыло большую потребность реинжиниринга таких внутренних систем, чтобы в будущем они стали работать эффективно.
2. Необходимость разбираться в различных государственных направлениях. Для для этого мы выработали методику анализа, чтобы при разработке услуг учитывать существенные факторы и отсеивать несущественные. Сейчас наши сервис-дизайнеры и аналитики готовы быстро, "по полочкам" разобрать всю нормативку и собрать крутую онлайн услугу в новой сфере.
3. Очень короткие сроки внедрения. У нас нет времени на раскачку, нет одного-двух лет на разработку, отладку и запуск. Нужно запускаться очень быстро, чтобы услуги приносили пользу уже. Во время карантина открыть-закрыть ЧП можно было только через портал «Дия». Это тоже очень подстегнуло по скорости, не говоря уже об услуге пособия по безработице.
4. Меняющиеся требования. Часто вступали в дело факторы, которые изначально не были приняты во внимание. Если изучать только нормативные акты, их не видно. Но когда мы углубились в процессы госуслуг, оказалось, что существует устоявшаяся практика, которую нельзя игнорировать. Например, в одной из служб нужно было распечатывать все дела для архива, при том, что кроме внутренних приказов это нигде не прописано.
Как повлиял карантин
Хотя психологически решение перейти на удаленную работу было достаточно сложным, во время карантина мы лучше структурировали процессы. Если раньше мы просто могли собраться командой и быстро решить вопрос, то теперь должны были построить процесс, чтобы вся информация на момент принятия решения исполнителю предоставлялась системно. Поэтому мы улучшили документирования, больше формализировали процессы, и сейчас уже можно говорить с уверенностью, это дает больше эффективности.
Особый акцент мы сейчас делаем на развитие в сторону ChatOps - это методология в которой все основные события по проекту (сборники, инциденты, отчеты Автотест) из ботов отражаются в корпоративном чате. При этом с использованием команд со стороны разработчиков прямо из чата те же боты могут выполнять Деплой и тесты на различных средах. Это очень наглядно и удобно для всей команды.
Особистий драйвер
Государство - это не что-то отдельно существующее и живет по своим законам. Граждане создают государство для себя сами. Чтобы прежде всего им было удобнее, легче и безопаснее. Именно так мы относимся к нашему государству и государственным системам. Это такая большая корпорация, акционерами которой являются все граждане Украины. Мы хотим внедрить простые эффективные подходы из корпоративного мира. Это позволит государственных услуг быстро развиваться и адаптироваться.
Государственный софт не обязательно старый и неудобный, он может быть очень классным и прогрессивным. И это напрямую зависит от подхода. Те подходы для построения систем, которые эффективны в корпоративном секторе, могут быть эффективны и в государстве. Для этого надо максимально использовать потенциал наших IT-специалистов и визионеров.
Политики - политиками, они меняются там наверху. Но все мы заинтересованы в том, чтобы государство было удобным инструментом для гражданина, реализации его потребностей и возможностей.
Что дальше
На портале "Дия" уже разрабатываются новые сервисы. Я не буду их анонсировать, это прерогатива Минцифры. Могу сказать, что украинских граждан ждут много новых и полезных государственных услуг.
Читайте также: Всю инфраструктуру поддержки бизнеса планируют оцифровать
