Як в 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-фахівців і візіонерів.
Політики - політиками, вони змінюються там нагорі. Але всі ми зацікавлені в тому, щоб держава була зручним інструментом для громадянина, реалізації його потреб і можливостей.
Що далі
На порталі "Дія" вже розробляються нові сервіси. Я не буду їх анонсувати, це прерогатива Мінціфри. Можу сказати, що українських громадян чекають багато нових і корисних державних послуг.
Читайте також: Всю інфраструктуру підтримки бізнесу планують оцифрувати
