Kitsoft — украинская компания, которая специализируется на цифровых технологиях для государства. Компания разрабатывала платформу для портала государственных услуг Дія. Александр Ефремов, СЕО Kitsoft, в колонке для AIN.UA рассказал о разработке портала, технологиях и особенностях работы на украинском рынке GovTech.
С чего все началось
Так как много лет мы специализируемся на создании электронных государственных сервисов, мы создали и развивали собственную платформу на базе BPMN (англ. Business Process Model and Notation — нотация и модель бизнес- процессов). Ее основная цель — разрабатывать сервисы быстро и качественно.
Платформу можно представить как маркетплейс различных госуслуг, каждая из которых является отдельным приложением. Сервисы на ней могут настраивать дизайнеры, аналитики и конфигураторы, а участие программистов минимально.
Это позволяет очень быстро масштабироваться. Несколько команд могут одновременно разрабатывать десятки различных сервисов, не мешая друг другу. Они используют одинаковые подходы и стандартный набор интеграций с внешними сервисами. При этом с точки зрения кода нет взаимного влияния, они не блокируют друг друга.
Почему это так важно? Разрозненность информационных решений является одной из наибольших проблем госуслуг. Каждый ресурс разрабатывался разными командами, которые, проходили полный цикл разработки, что очень долго и дорого.
В сентябре 2019 года было создано Министерство цифровой трансформации и одним из первых проектов инициировано создание единого портала электронных услуг «Дія». Мы предложили свое решение и выиграли тендер на разработку.
Первые шаги
На старте мы провели анализ по интеграции со всеми реестрами, приняли участие в создании дизайна и подготовили движок для запуска первых услуг.
Для этого мы создали электронный кабинет гражданина, который подтягивает информацию из разных реестров. Из-за большого количества особенностей работы каждого из них и низкого качества информации, это стало практически самым сложным. Но на сегодня в «Дія» интегрировано уже около десятка внешних ресурсов.
UI и UX дизайн первых услуг на портале разрабатывали Fedoriv и Spiilka. Мы, в свою очередь, консультировали со стороны разработчика: как услуги могут работать, насколько те или иные элементы возможно реализовать на платформе. Анализ и проектирование были необходимы, чтобы понять, какие изменения вносить в систему.
Параллельно наша команда занималась отладкой процессов на платформе, чтобы не просто запустить сервисы, но и правильно их тестировать, аудировать ход оказания услуг, быстро отслеживать проблемы и ошибки.
Поскольку в «Дія» процессы не замкнуты внутри системы, а взаимодействуют с внешними ресурсами, ошибки здесь неизбежны и их нужно правильно обрабатывать. У нас нет недель для того, чтобы разработчики исправили ошибку и залили новый софт. Поэтому мы подготовили необходимые средства отладки, чтобы подстраиваться под внешние факторы «на лету». Сократить время разработки нам удается за счет внедрения DevOps-практик.
Как разрабатываются новые онлайн услуги
Всего по проекту «Дія» в Kitsoft работает 15 человек.
Возьмем, к примеру, услугу «Помощь по безработице», которую мы реализовали совместно с проектом 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-специалистов и визионеров.
Политики — политиками, они меняются там наверху. Но все мы заинтересованы в том, чтобы государство было удобным инструментом для гражданина, реализации его потребностей и возможностей.
Что дальше
На портале «Дія» уже разрабатываются новые сервисы. Я не буду их анонсировать, это прерогатива Минцифры. Могу сказать, что украинских граждан ждут много новых и полезных государственных услуг.
Автор: Александр Ефремов, СЕО Kitsoft
