Архітектурні комітети, налагодження тестування та «інфраструктура-космодром». Як відбувається ІТ-трансформація Держмитниці
ІТ-процеси є не лише в бізнесі. Вони є і в державному секторі. Редакція DOU вирішила розібратися: у чому різниця між роботою в бізнес-структурі та державному органі і чи є вона взагалі? І що мотивує ІТ-фахівців працювати на державу?
Ми поспілкувались з Євгеном Єнтісом, радником з ІТ-трансформації «Нової митниці» та фактично керівником реформи в ІТ-структурі Державної митної служби України, про те, як відбувається діджиталізація системи, хто стоїть за змінами та що чекає на митницю найближчим часом.
Дисклеймер: стаття написана до призначення нового виконувача обов’язків голови Держмитниці.
Далі — розповідь Євгена.
Спершу поясню, як заплановано реформу «Нова митниця» в ІТ-відділі. В департаменті ІТ працює наразі 62 фахівці у двох управліннях та чотирьох окремих відділах: розробки, адміністрування розробки, супроводження програмного забезпечення, телекомунікацій (адміністрування мереж і сервісів). На сьогодні майже всі спеціалісти підтримують внутрішні проєкти, вони не займаються розробкою нового функціоналу. Але найближчим часом я планую залучати всіх охочих до нових проєктів.
Якщо говорити про позаштатних працівників, які, власне, творять реформу, то вони перебувають на донорському фінансуванні, що забезпечує ринковий рівень зарплат. Зараз таких посад 20. Проте основною мотивацією займатися реформуванням ІТ-системи митниці є амбіції та можливість бути в команді висококваліфікованих спеціалістів. Як доказ: завжди є охочі приєднатись до команди, але поки що шукаємо лише тестувальників.
У серпні 2019 року я зустрівся з Максимом Нєфьодовим, на той час головою Держмитслужби, він і запросив мене долучитись до команди. Тоді я працював у Prozorro і вже задумувався про зміну роботи: хотілося нових викликів. Я розглядав кілька пропозицій на роль консультанта з діджиталізації як у комерційному секторі, так і в державному. Проте раніше мав досвід співпраці з Максом і вирішив допомогти реформувати митницю. У команді тоді були лише техлід Максим Корженевський та власне Максим Нефьодов. Я ж взяв на себе організаторські функції, став розширювати команду. До кінця 2019 року ми зібрали її кістяк з 4 людей.
Ковель. Аналізумо ІТ-процеси
З чого почали реформу: аналіз ІТ-системи Держмитслужби
Наступним кроком став поверховий аналіз систем. Це не можна назвати аудитом, бо за законом його проводить лише Держспецзв’язок. Мені з командою було непросто отримати доступ до системи: довелось чекати три місяці, поки Мінфін через робочу групу з представників СБУ, Мінфіну, ДФС і Держмитслужби надав дозвіл (хоч і дуже обмежений). Ми навіть розглядали варіант видати постанову Кабміну за підписом тогочасного прем’єра Олексія Гончарука, бо ніхто не хотів, щоб ми проводили технічний аналіз ІТ-системи. До того зовнішні спеціалісти не отримували доступи. Останній аналіз зробила компанія Deloitte в червні 2019 року (всього фінансового блоку). Вона написала 420 сторінок документації, дуже поверхової та неконкретизованої, адже доступу до систем не мала.
Аналіз зайняв два місяці. Над ним і працювала новостворена команда: бізнес-аналіз — Роман Ланський, BA; телекомунікаційне та серверне обладнання — Артем Карась, архітектор високонавантажених систем; аналіз даних — Євген Копилов; архітектура — Максим Корженевський (техлід Prozorro) та Павло Жук, архітектор eHealth, раніше працював у Facebook.
У результаті написали звіт «айтішним жаргоном», за який Мінфін ще довго «цькував» усю команду. Та важливіше те, що висновок звіту засвідчив: чинну систему АСМО «Інспектор-2006» неможливо модернізувати. Її створили ще у
І це не єдина проблема. Відсутність нормального тестування, документації, повноцінного логування та моніторингу систем, відомостей, де лежить код і як отримати до нього доступ, унеможливлювала стабільність і безпеку. Та найважливіше: вендор-лок підтримують
Єдина автоматизована інформаційна система (ЄАІС), у межах якої діє «Інспектор-2006», має більше даних, проте все одно її модернізація неможлива: через відсутню документацію, застарілі технології та архітектуру.
Структура ІТ-команди
Команда спроєктувала архітектуру нової системи та поділила командні ролі. Вийшла cross-delivery team: CTO, Tech Lead, UX/UI дизайнери, Business Analysts, Product Owners, DevOps та команда окремих стримів:
- Customs.Back — те, з чим будуть працювати фахівці митниці під час митного оформлення;
- Customs.Front — інтерфейс взаємодії під час митного оформлення, зокрема адміністративні послуги, митне оформлення та взаємодія з органами під час отримання дозвільних документів. Те, з чим будуть працювати декларанти та контролюючі органи, наприклад, «кабінет користувача» і «єдине вікно» для зовнішніх спеціалістів;
- BIRMA — стрим ризиків, аналізу даних за допомогою BI, інтеграція із зовнішніми системами та відкриті дані;
- international: транзитна система NCTS, AEO, обмін інформацією та взаємодія з іншими країнами.
PO разом із BA кожного зі стримів формує бачення системи, спілкується зі стейкхолдерами, проводить аналіз, формує концептуальне бачення свого стриму, усуває зайві процеси, розробляє технічне завдання, запускає та супроводжує розробку систем. Є техліди, тестувальники, розробники, UX/UI, техрайтери, девопси. Усього в ІТ-напрямі працює близько 40 фахівців. Формат співпраці з розробниками — і аутсорс, і аутстаф.
Розробка Core-системи відбувається у форматі аутстаф, бо там треба швидко реагувати на зміни та формувати завдання на тиждень. На аутсорс віддали розробку вебпорталу, «кабінету користувача» та «єдиного вікна» (фактично це отримання електронного рішення про перевірку товарів, які переміщуються через кордон). Розробники працюють віддалено на постійній основі.
Процес розробки
Перший етап, без якого розробка за кошти донора не може розпочатись, — створення робочого плану для затвердження донором. Потім треба підготувати Concept Note — високорівневий документ, який підписують донори, фінансисти та технічні спеціалісти з його боку. Потім відбувається акцептування: Держмитслужба надає лист, що розробка цього продукту є необхідною. Тільки після цього пишуть технічне завдання, яке проходить внутрішнє погодження ДМСУ. На цій основі складають лист до донорів і у разі схвалення оголошують закупівлю.
Наступний крок — розгляд і підписання договору, створення календарного плану розробки. Опісля — здавання проєкту та акцептування в ДМСУ, зрештою взяття розробки на баланс. Весь процес від етапу формування потреби до підписання договору займає від 5 до 7 місяців. Тому ІТ-реформу не вдається провести так швидко, як би хотілося.
Після однієї з презентацій у Мінфіні. На фото: Роман Ланський (зліва), Євген Єнтіс (за столом), Сергій Кулик (справа)
Такий тривалий бюрократичний процес зумовлений потребою залучати донорські кошти. Держбюджет не виділяє грошей, натомість існує фінансування від Public Finance Management Support Programme for Ukraine (EU4PFM). Крім того, Максим Нефьодов зміг залучити кошти The USAID/UK project Transparency and Accountability in Public Administration and Services (TAPAS) та The USAID project Competitive Economy Program (CEP).
За процес розробки відповідають PO і BA. Працюємо за Agile, спринт триває тиждень, оскільки є потреба бачити результати швидко. Всі завдання ведуться в Jira, ми її модернізували, додали купу плагінів. Наприклад, на кожне завдання є definition of done. Загалом команда має виконати 20 завдань DoD під час здавання розробки, а саме:
Документація:
- нормативне технічне завдання;
- BPMN-діаграма(и) з описом процесів/бізнес-логіки;
- детальна L2/L3-топологія системи у вигляді діаграм (якщо є потреба);
- інструкція з розгортання, оновлення та відновлення системи;
- схема потоків даних + структура бази даних + ER-діаграма;
- функціональний опис системи;
- інструкція адміністратора та користувача (кожна роль) системи;
- програма та методика комплексних випробувань;
- протокол комплексних випробувань.
Технічна частина:
- Helm charts та/або Ansible-плейбуки на розгортання, оновлення та відновлення системи;
- автотести (мінімум 85%) + протоколи тестування;
- Unit-тести (мінімум 90%) + протоколи тестування;
- стрес-тести + протоколи тестування;
- навантажувальні тести + протоколи тестування;
- політики та процедури SDLC у вигляді магістралей (pipelines) у Gitlab CI/CD із використанням GitLab Runner;
- код у Gitlab;
- коментування коду для показу у Swagger;
- логування роботи системи та отримання логів у центральній системі з використанням ELK-стеку;
- моніторинг роботи системи та надсилання інцидентів у месенджер.
Від розробників очікують активного коментування коду, логування, ведення документації для того, щоб у разі потреби інші могли швидко підхопити проєкт і вести його далі. Це необхідно робити, хоч через це вартість проєкту зростає. Також вимагають перевірку на вразливості, проведення функціональних тестів, навантажувальних тестів тощо — об’єм покриття ними має становити близько 90 відсотків. Код зберігається у внутрішньому GitLab, уся розробка відбувається тільки там. Це одна з основних вимог.
Налаштували повноцінні CI/CD-процеси. Баги, якість коду та можливі вразливості аналізує автоматично один з пайпланів. Найближчим часом плануємо побудувати процес QA.
Щотижня проходить архітектурний комітет за участі всіх чотирьох PO та техлідів стримів, адже у розробці всі проєкти перетинаються і часто зміни залежать одна від одної. За два дні до засідання команда узгоджує план і питання, які виноситиме на обговорення, щоб зустріч не тривала
Якщо порівнювати з інфраструктурою Prozorro, то у митниці вона складніша: це Kubernetes з усіма «плюшками» — наскрізним моніторингом, логуванням, брокерами гарантованої доставки повідомлень, що схоже на космодром. Уся документація та протоколи розробляються та зберігаються в Confluence, щоб у разі змін нічого не втратити та не створювати вендор-лок.
Ключові проєкти
Наразі ІТ-напрям запустив та допрацьовує кілька основних проєктів.
Онлайн-калькулятор вартості митного оформлення авто
Сервіс підтягує дані щодо мінімальної, середньої та максимальної вартості вказаного авто на основі реальної інформації моделей машин за історичними даними митниці. Це не інноваційний інструмент, на ринку такі калькулятори давно існують. Однак він необхідний: є потреба показувати статистичні дані під час оформлення автомобілів. Процес розробки зайняв два місяці. Усю розробку можна переглянути тут.
Онлайн-система скарг на роботу Держмитслужби
Після створення митниці постало питання опрацьовувати скарги. Оскільки на той час у Держмитслужбі не було готового рішення, запропонували зробити доступний інструмент. Коли митниця і податкова роз’єднались, кол-центр перейшов до останньої. Митниця домовилась із Дмитром Дубілетом про загальний проєкт з єдиного кол-центру, що приймав би скарги та звернення щодо служби. Ми розробили власний софт, тепер скаргу можна подати онлайн. Усю розробку можна переглянути тут. Також доступна аналітика щодо скарг.
Customs.Front та «єдине вікно»
Проєкт TAPAS із розвитку механізму «єдиного вікна» профінансувало Агентство США з міжнародного розвитку (USAID). Проєкт іще в розробці, очікуємо його завершення у вересні-жовтні. Це «вікно» по суті є кабінетом декларанта й дає можливість самостійно подавати декларації. Архітектура системи передбачає можливість інтеграції з іншими державними реєстрами та сервісами. Вони відбуваються на рівні обміну стандартизованих пакетів даних з бекендом взаємодіючих систем і реєстрів.
Розробку віддали на аутсорс, але через чутливість внутрішніх процесів залучили PO і двох BA. Ми продемонстрували готовий функціонал керівництву митниці та Мінфіну: авторизацію з id.gov.ua, подачу заяви на отримання брокерської ліцензії та інші адміністративні послуги. А ще частково показали, як подавати декларацію на авто. І почали інтеграцію з ЄДР для автоматизації заповнення великої кількості інформації в заявках (наприклад, заповнення заявки на брокерську ліцензію буде повністю автоматичним). Розробляємо з використанням Angular 9, Java 11, Kafka, PostgreSQL 12.
Функціональна схема модулів ІТС Customs.Front
BI-система
У квітні 2020 року ми запустили аналітичний інструмент зі статистичних даних Держмитниці з товарообігу: обсяги імпорту та експорту України з будь-якою країною та щодо будь-якого товару (читати детальніше).
Ідея проєкту — дати можливість працювати з актуальними даними в режимі 24/7 з використанням сучасних інструментів аналізу. Бізнес і спільнота чекали на цей інструмент десятиліттями, адже до впровадження рішення необхідно було вручну зібрати дані, нормалізувати, підібрати рішення і лише потім починалася робота з аналізу даних, трендів під задачі бізнесу. У гіршому разі база митниці просто «купувалась на Петрівці».
Перший реліз дав позитивні відгуки від бізнесу з Норвегії, Чехії, Тайваню та України. За нашими останніми даними, ВІ надає сервіс 500 користувачам щодня, і це практично без потужного промоушену. Такий фідбек користувачів мотивує розвивати цей сервіс і далі. Проте зараз це, на жаль, на паузі — необхідне погодження Держмитслужби та фінансування.
Автоматизована система управління ризиками
Одним із найважливіших елементів функціонування митниці є виявлення порушень законодавства у процесі оформлення митної декларації. АСУР дає змогу прискорити митне оформлення товарів завдяки вибірковості митного контролю — митні органи концентруватимуть увагу на найбільш ризикових зовнішньоекономічних операціях.
Для ефективної організації роботи з ризиками з погляду захисту держави (надходження, заборонені перевезення та інше) та бізнесу (прозорі та єдині правила проходження митниці для всіх СЗЕД) потрібно було перебудувати наявну систему «Інспектор». Це, своєю чергою, сприяло створенню нової системи АСУР 2.0, що дає можливість митниці керувати ризиками без або з мінімальним залученням ІТ-спеціалістів.
Крім цього, закладено архітектуру ієрархічного доступу до системи, де всі дії фіксуються. І це лише перший крок, далі плануємо впровадити новітні методи оцінювання та управління ризиками, а також застосування технологій машинного навчання.
Вебпортал
Спершу провели маркетингове дослідження за участі різних груп користувачів і розробили дизайн-портал. Він створений на Python 3.6, PostgreSQL, 10 HTML5, CSS3, jQuery, Nginx. CMS має допрацьований під потреби UI — кросплатформову та відкриту систему Odoo (версія 13). Її підтримка безкоштовна, а можливості для подальших доробок — необмежені. Є інтеграція з Google API, функціонал для людей із порушенням зору, Elasticsearch. Розробка разом з дослідженням почалась у середині березня і закінчилась на початку червня.
Мапа митної інфраструктури
Сервіс показує актуальний стан і детальні паспорти всіх пунктів пропуску, місць митного оформлення, місць міжнародного поштового обміну, сортувальних станцій із можливістю аналізувати цю інформацію функціоналом мапи. Мапа — це реєстр для усіх цих типів локацій, що є частиною запланованої ІТ-системи. Розробка: Vue, PHP. Зараз заповнено майже 100% інформації.
Плани та перспективи
Найближчим часом, окрім допрацювання вищеперелічених проєктів, команда зосередиться на таких ключових моментах.
Оптимізація серверів. На початку реформи системи запускали на серверах митниці. Тоді ж система почала працювати нестабільно, як виявилось, через недосконалість інфраструктури. Через відсутність моніторингу і логування неможливо було оперативно реагувати на інциденти. Сервіс перенесли в Amazon і за півтори години заново розгорнули всю систему, підняли моніторинг і логування, побачили помилки і виправили їх. І зрозуміли: інфраструктура митниці не підготовлена до нових викликів.
Цього року ми придбали послуги дата-центру, що надав інфраструктуру, в якій ми розмістили ландшафт, ПЗ, сервіси. Зараз ведемо перемовини, щоб отримати дозвіл розгортати все в інфраструктурі Мінфіну. На це є щонайменше дві причини: хороша інфраструктура та підпорядкування митниці цьому органу.
Також на розгляді парламенту закон про хмарні послуги, що може внести корективи у діяльність ІТ-систем і допоможе зняти останні бар’єри в розміщенні даних державних органів.
Розробка. На листопад-грудень 2020 року запланували створити ядро системи, кабінет та нову систему ризиків АСУР для митного оформлення і поступово додавати новий функціонал. Щодо Customs.Back, то наразі триває робота над створенням оновленої системи АСМО 2.0 (Customs.Back), що прийде на заміну АСМО «Інспектор-2006» та ЄАІС. Впровадження АСМО 2.0 буде відбуватись поетапно, починаючи від окремих груп товарів (автомобілі в режимі імпорту) до покриття усієї номенклатури товарів у режимах імпорту, експорту, транзиту. Найближчим часом плануємо реліз і тестування «кабінету інспектора», «журналу пункту пропуску» та фінансового модуля.
Інформаційна безпека. Наразі всі зміни в систему відбуваються через Git, а розробники не мають доступу до продуктового середовища. Мета — впровадити повноцінне логування та моніторинг. Логи не повинні модифікуватись, а у продуктове середовище має входити мінімум людей. Плануємо запустити тестування на вразливість і проєкт з білого хакінгу за досвідом Prozorro. А також побудувати Security Operations Center для оперативного реагування на кіберінциденти та захисту інформації.
Відкриті дані. Завершили основну розробку щодо відкритих даних для проведення експортно-імпортних операцій. Сам сервіс — DWH та API із документацією на базі Swagger і відмовостійким кластером БД на базі MongoDB. Держмитслужба має врегулювати нормативні питання: внести зміни в постанову № 835 та затвердити порядок роботи сервісу. На жаль, розробка вже «лежить» близько двох місяців. На мою думку, ніхто не хоче відкривати дані. Потрібно бачити динамічні дані, щоб уникнути махінацій, з якими митниця і має боротись. Тож щоб розв’язати це питання, доводиться багато дискутувати та доводити органу переваги відкритих даних.
«АСМО 2.0. Пошта». Щороку в Україну надходить
Фото з робочої зустрічі з представниками «Укрпошти» щодо інтеграції систем
Проблеми
На мою думку, найбільша проблема — відсутність взаємодії та боротьба зі штатними розробниками. Вони не розуміють, для чого створювати нове, якщо старе і так працює. А для нас основним є прозорість, документування, тестування та дотримання світових найкращих практик і вимог. Тому, на мій погляд, вони й не йдуть на співпрацю.
Також для успішної реформи потрібні люди, які добре розумітимуть процеси в митниці та разом з нами впроваджуватимуть нові проєкти. Для зменшення ризику недостатнього розуміння процесів ми активно занурюємось у це: формуємо фокус-групи, їздимо і спілкуємось з людьми на місцях, розповідаємо про реформу.
Серед помилок можу назвати поспіх. Наприклад, уже під час демонстрації нашого бачення декларації ми дізналися, що є міжнародні стандарти, яким вигляд декларації суперечить. Довелося повертатись, розбиратись, вчитись. Звісно, за активної участі профільних фахівців-митників процес був би простішим. Сподіваюсь, найближчим часом це налагодимо.
ІТ-фахівці «Нової митниці» про свою роботу
Редакція DOU також запитала у Product Owner’ів напрямів та бізнес-аналітиків про те, як потрапили в ІТ-команду «Нової митниці» та чим займаються на своїх посадах.
Сергій Кулик, PO на митниці із січня 2020
Володимир Чугай, PO на митниці з січня 2020 року
А так ми відпочиваємо :) На фото — Володимир.
Роман Ланський, Program Manager, відповідальний за створення нової ІТ-системи, на митниці з грудня 2019 року
Павло Шкурихін, PO на митниці з грудня 2019 року
Максим Корженевський, Tech Lead
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
3 коментарі
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.