Яка відстань до “горизонту” в багах?

Bug Horizon

Ще одна історія про дефекти в ПЗ, які мали значний вплив на життя людей.

У 1999 році Пошта Великобританії впровадила в мережі своїх відділень нову систему “Horizon”, розроблену японською компанією Fujitsu. Ця система поєднувала в собі як софт, так і “залізо”. Приблизно 40,000 терміналів підключених до Horizon, було встановлено в поштових відділеннях по всій країні. Початкове впровадження Horizon обійшлося британським платникам податків у 700 млн фунтів, в подальші роки експлуатація системи довела загальну суму до більше ніж 1 млрд фунтів. Ця система, звісно вже суттєво перероблена з тих часів, й досі забезпечує бухгалтерський облік, інвентаризацію та проведення транзакцій між ~11,500 відділень та головним офісом пошти.

В період з 2000-го по 2014-й Британська Пошта звинуватила 736 співробітників своїх відділень у шахрайстві, відмовляючись визнавати те, що справжньою причиною невідповідностей у фінансових показниках числених відділень були дефекти системи “Horizon”.

Частина звинувачених поштарів збанкрутували через п’ятизнакові штрафи від пошти (приклад для розуміння: 38,000 фунтів), частину було ув’язнено, дехто перезакладав свої домівку щоб сплатити суми штрафів виконавчим службам, дехто не зміг влаштуватися потім на іншу роботу через “кримінальну” справу в історії праці. Іншими словами – суттєвій кількості людей спаскудили життя.

Як це виглядало для працівників поштових відділень (доречі, в них поштові відділення працюють ніби як за франшизою, тому кажу “працівник” – маю на увазі “власник”):

😱 Прокинувся зранку у 2000-му році й побачив що баланс не сходиться на 6000 фунтів не на твою користь. Почав розбиратися й завдяки IT бекграунду побачив що через нічний апдейт софта – продублювався один з видів пенсійного депозиту на 5000. Відправив корегуючу транзакцію, чим пофіксив цю частину нестачі. Про залишок нестачі у 1000 фунтів ти повідомив службу підтримки, де тобі збрехали що серед десятків тисяч працівників ти єдиний маєш таку проблему. Пізніше тебе почали пресувати виконавчі служби головного офісу на тему повернення “боргу”. Ти сперечався, прохав показати логи, тобі не показували. За два роки цю 1000 списали, нічого не пояснюючи тобі, але сказали що маєш сплатити 1400 фунтів іншої нестачі, про яку ти взагалі ні сном ні духом. Ти не погоджувався нічого платити, поки не покажуть логи – знову не показали. Ще за рік контракт з тобою розірвали.

Лише рік тому, у 2020-му році об’єднання колишніх поштарів, яке займається колективними позивами до Пошти досягло певного успіху в визнанні Поштою своєї неправоти. Цей “певний” успіх на даний момент вимірюється 58 мільйонами фунтів, які Пошта погодилась виплатити постраждалим.

Звідки ж брались всі ці кримінальні справи проти співробітників поштових відділень?

Згідно досліджень сторонньої компанії Second Sight, якій довірили аудит системи – найпроблемнішими місцями Horizon були:

🟣 Відношення менеджменту Пошти до систематичних фінансових невідповідностей у відділеннях: замість ретельного аналізу будь які проблеми з Horizon заперечувались, й винуватими майже автоматично вважались очільники відділень.

🟣 Погане навчання та підтримка: не надто детальні інструкції, та часто нездатність й небажання підтримки розібратись з проблемою. Найчастіша відповідь в підтримці: “не хвилюйтесь, автоматична корекція вирішить вашу проблему.” – а що блін, якщо ні?! (с)

🟣 Відсутність Traceability та Accountability: до того як впровадили Horizon кожну окрему транзакцію можна було ідентифікувати по окремому папірчику, заповненому вручну. Після ж того як Horizon впровадили у відділення не було можливості подивитись перелік всіх транзакцій, лише агреговану суму на кінець дня. Тому дуже важко було з’ясувати де бува провтикав.

🟣 Також схоже – доступність даних: за 42 дні (трохи згодом – 60 днів) дані по транзакціях у відділенні ставали недоступними, й тому наприклад, якщо корекція по якійсь транзакції приходила пізніше цього терміну, то працівники відділення вже не мали змоги перевірити що саме корегує ця корегуюча транзакція, й не мали іншого виходу як її прийняти.

🟣 Підтримка лише однієї валюти: Horizon знав лише про фунти. В той самий час в багатьох відділеннях можна було обмінювати валюти. Й навіть попри наявність спеціального пристрою, який вмів в транзакційність – в Horizon наприкінці дня вводився лише підсумок, й лише в фунтах-стерлінгах. Тобто якщо у відділенні продали валюту не по затвердженому рейту – то в головному офісі не мали можливості побачити окремі транзакції. Тому в головному офісі придумали відразу закладати 5% збитку на такі операції. Й ці 5% автоматично перекладались на відділення (sick)

🟣 Придбані квитки національної лотереї іноді не враховувались системою: справа в тому що скретч-карти продавали ще й після закриття каси, й наступного ранку вони так і лишались “активними” в одній системі й “неактивними” в Horizon.

🟣 Транзакції створені не у відділенні: хоча Пошта заперечувала будь яку можливість створення транзакцій не авторизованих персоналом відділення – пізніше з’ясувалось, що персонал Fujitsu (розробника системи) мав можливість “підхачити” дані що відносяться до відділення, й схоже на те що зрідка цією супер-адмінською силою користувався в деяких випадках що потребували коригування.

🟣 “Односторонні” транзакції – доволі часто через поганий зв’язок у віддаленій місцевості, пошта отримує гроші, а вони “не доходять” до банку, або навпаки. Більшість таких проблем потім реконціліюються (вибачте за запозичення), але не всі, й знову ж таки за замовчуванням винним вважається відділення.

🟣 Проблеми з “залізом”: його як встановили у 1998-му році, так воно 10 років (а часто й більше) там й стояло. Принтери на касі, модеми, старезні тач-скріни й інше – все це глючило, ламалось й також не давало можливості розслабитись.

Ну й на закуску, видання ComputerWeekly.com яке одним з перших досягло публічного розголосу проблеми нечесного поводження Пошти зі своїми працівниками, в одній зі статей присвячених цій темі, згадує слова своїх анонімних джерел про те, що система Horizon мала в своїй основі нереляційну базу даних, яку й базою даних назвати було складно. А складно – тому що це було просто місце для зберігання XML без заздалегідь узгодженої структури. Тобто, якщо наприклад відвідувач поштового відділення придбав поштову марку, термінал у відділенні, на якому ця операція була зареєстрована – відправив повідомлення у певному форматі, то після якогось з апдейтів, цілком могло статись так, що на ту ж саму подію термінал тепер відправляв повідомлення у трохи іншому форматі, у якому воно могло бути проігнороване, або ж опрацьоване невірно. Зрештою це фіксилось супортом, а потім накатувався наступний апдейт з фіксами.

Мораль така: якщо ваш менеджмент дуже хоче вірити в те, що багів немає, та в тестування до виходу продукту в прод – не інвестував, то вам кранти.

Сподіваюсь вам сподобалась ця історія, й ви так само праведно гнівались через скалічені багами людські долі як і я, поки шукав та перечитував силу силенну статей та документів на цю тему. Більше того – мені тепер стало страшенно цікаво: а як поставлені процеси тестування у наших поштових операторів, особливо в найбільших з них: УкрПошті, Новій Пошті. А вам цікаво? Може маєте інсайди?

Джерела:

Позначки:,
17 Травня 2021
Автор: 
  • Improving test process
  • Regression Obsession
  • 🦠Коронавірус та Excel 📈
  • QAFest 2019 – огляд виступів

Залишити коментар

Залишити вiдгук