Примерно раз в месяц в соцсетях появляется вопрос о том, почему цифровой сервис DVLA на ночь отключается. Почему в 21-м веке достаточно новый онлайн-сервис работает только в определённые часы суток? Чтобы каждый раз не отвечать на этот вопрос, я решил написать пост, на который смогу давать ссылку в будущем.

Кроме того, это отличный пример, демонстрирующий, почему превращение государственных сервисов в нативно цифровые может быть достаточно сложным процессом. Если только вы не стартап, вам редко приходится вести разработку с нуля: приходится считаться с легаси-технологиями и старыми практиками работы. Преобразование государственных сервисов — не такая простая задача, как пытаются представить технологические компании и миллиардеры.

...
График работы сервиса DVLA с 7 до 20 часов

Немного истории

Прежде чем переходить к подробностям, немного истории.

DVLA примерно шестьдесят лет, он занимается учётом водительских прав и транспортных данных в Англии, Шотландии и Уэльса.

Десятками лет управлением технологиями DVLA занимались на аутсорсе такие организации, как IBM и Fujitsu. В 2015 году мы перенесли сервис в государственные системы. Когда я начинал работать с DVLA в 2013 году над созданием новых цифровых сервисов, почти все технологии разрабатывались IBM и Fujitsu.

В то время многие сервисы DVLA, и в особенности связанные с водительскими правами, по-прежнему работали на старом мейнфрейме IBM 1980-х годов с гордым названием Drivers-90 (сокращённо D90). D90 был типичным мейнфремом — код на COBOL с системой управления базами данных ADABAS. Основная часть обработки данных выполнялась «офлайн», при помощи пакетных задач, запускавшихся по ночам на определённые промежутки времени.

В начале 2000-х поставщиками IT-решений DVLA была предпринята попытка по модернизации систем. Они спроектировали новое множество систем на основе Java, WebLogic и Oracle Databases, которую назвали New Systems Landscape (NSL). Чтобы ускорить миграцию, они использовали инструменты автоматического преобразования кода и структур баз данных.

Как часто случается в крупных закулисных проектах IT-модернизации, эта инициатива по апгрейду исчерпала энергию и деньги, поэтому так и не была завершена. Образовалась сложная инфраструктура — некоторые сервисы использовали новую архитектуру, часть работала на мейнфрейме, часть работала и с тем, и с другим одновременно.

Со временем начали всплывать проблемы, вызванные кодом, который написали автоматизированные инструменты — он оказался переусложнённым, ненадёжным и сложным в поддержке. Так как трансляция была автоматизированной, новая система воссоздавала процесс выполнения пакетных задач со старого мейнфрейма.

Однако в этих новых пакетных задачах существовали встроенные допущения о том, что внутренние датасеты не будут меняться в течение ночного процесса пакетной обработки. Если бы что-то поменялось, то пакетная задача могла завершиться аварийно, приводя к неопределённому или повреждённому состоянию всей базы данных. Для распутывания подобных отказов потребовалось бы несколько дней и отключение всей системы.

Вот, с чем нам предстояло иметь дело в 2013 году.


Реализация новых цифровых транспортных сервисов

В рамках программы цифровой трансформации GDS за 2013 год DVLA приступил к реализации множества новых цифровых сервисов для ведения учёта транспорта и регистрации водителей. Для реализации этих сервисов нам пришлось подстраиваться под тонкости уже используемых технологий.

Создание нового сервиса фронтенда — достаточно простая задача. Сложнее будет обновить систему транспортных данных — придётся интегрироваться с легаси-системами и сотрудничать для этого с IBM/Fujitsu. Но есть и ещё более серьёзная проблема — что делать с ночными пакетными обработками?

Нам предстояло сделать выбор: вернуться назад и потратить несколько лет на перепроектирование и перестройку фундаментальной архитектуры, чтобы избавиться от выполняемых по ночам задач, или смириться с тем, что сервисом изначально невозможно будет пользоваться по ночам.

Организации часто попадают в эту ловушку — тратят годы и огромные суммы денег на исправление фундамента, прежде чем приступить к созданию нового. Им сложно длительно концентрироваться на сложном апгрейде, особенно учитывая отсутствие видимых улучшений. Разработчики DVLA пытались пойти по этому пути в 2000-х, чтобы мигрировать с мейнфрейма. У них закончились деньги и в результате из-за переходного состояния системы ситуация стала ещё хуже.

Я всячески способствовал тому, чтобы мы выпустили сервис, который бы обычным образом работал днём и отключался на ночь. Это бы позволило нам сразу воспользоваться преимуществами системы — быстро предоставить людям доступ к новому сервису, пока мы постепенно устраняем внутренние проблемы. К счастью, политическое давление программы цифровой трансформации поддержало нас в этом.

Итак, мы создали новый сервис. Мы заплатили IBM/Fujitsu за разработку API для базы данных, чтобы мы могли обновлять данные в реальном времени. Совместно с ними мы работали над тем, чтобы максимально сузить временное окно пакетной обработки и немного сдвинуть его, чтобы сервис больше был доступен по вечерам (исследования поведения пользователей показали, что в это время люди используют сервис активнее).

За последующие несколько месяцев мы добавили новые части сервиса: теперь можно было покупать и продавать автомобили онлайн, управлять своими регистрационными номерами, изменять адрес и так далее. И всё это без бумажных бланков.

Пользователи получили новые удобные сервисы, а у DVLA снизилось количество возни с бумагами. Выиграли все.


Что было дальше?

Вскоре после запуска первого сервиса мы спроектировали и прототипировали подсистему, позволяющую сервисам работать в период ночной обработки. В дневное время сервис работал обычным образом. В ночном временном окне он временно «хранил» транзакции до момента появления доступа к легаси-системе. Это позволило сервисам работать в режиме 24/7.

К сожалению, по различным причинам агентство DVLA решило не внедрять это. Оно принялось за полное воссоздание легаси-инфраструктуры.

Когда я уволился из DVLA в конце 2015 года, эту новую инфраструктуру всё ещё проектировали.

Прошло десять лет после запуска первого сервиса. Легаси-инфраструктура, которую уже, должно быть, заменили, по-прежнему остаётся причиной отключения сервисов на ночь.

Приемлемо ли это? Не особо. Объяснимо ли это? Разумеется.

Легаси-технологии — это сложно. Они оказываются одним из самых серьёзных препятствий по пути к цифровой трансформации компаний и организаций.

Комментарии (4)


  1. ky0
    21.01.2025 07:52

    Мосэнергосбыт похожим страдает.


  1. akakoychenko
    21.01.2025 07:52

    прикольно

    всегда думал, что вот эти ночные отключения потому, что система настолько нестабильна/не защищена от взломов, что ее боятся оставлять работать, когда нет инженера техподдержки на смене, который будет заводить с пинка после очередного падения, или вовремя увидит аномалии при атаке и выключит все


  1. Kahelman
    21.01.2025 07:52

    Прикольно другое. Поскольку у нас нет специалистов по COBOL , да и похоже вообще специалистов по back-end разработке, мы тут спалили кучу бюджета не переписывание все на новом -модном js фреймворке. А Back-End ни осилили. Теперь разгребайтесь как хотите. Заказчик поди увидал сумму поддержки после отказа от доорогих IBM/Fujitsu, подофигел и решил всех новомодных скрипт Килли выгнать и больше систему не трогать. Теперь переписывают все новомодные штучки обратно на COBOL :)


  1. TomskDiver
    21.01.2025 07:52

    Уже несколько лет так.
    Уже несколько лет так.