Про якість, що впливає на долю людей - історія British Post Office

Згенеровано DALLE (ChatGPT)

В 2023 році завершився скандально відомий судовий процес проти Британської Поштової Служби. Здавалося б - при чому тут тестування та якість до поштової служби? А що, як я скажу, що саме софт та баги стали причиною великої кількості незаконних обвинувачень для купи простих жителів Великої Британії?

Про поштову службу та Horizon

Існує така собі японська технологічна компанія Fujitsu. Заснували її ще в 1935 році. Досить довгий час вона працює в сфері розробки софту на замовлення інших великих корпорацій. В 1999 році компанія Fujitsu заключила контракт з Британською поштовою службою та почала постачання модернової системи електронного обліку під назвою Horizon.

Система Horizon повинна була рахувати баланси грошей та товарів як в головному офісі та і в десятках тисяч відділень пошти по всій Британії. Відділення пошти в Британії зазвичай управляються субконтракторами, а не співробітниками. Але завдяки софту - облік ведеться та контролюється з головного поштового офісу.

Помилки людей та їх покарання

На початку 2000х років, як тільки нову систему обліку додали у відділення, головний офіс пошти почав помічати невеличкі проблеми у фінансових відомостях. Спочатку ці проблеми були не помітні, бо система реєструвала мільйони транзакцій на день.

Проблема заключалася в тому, що облік товарів та коштів у відділеннях та у головному офісі не "сходився". Почали знаходити розбіжності в тисячі фунтів. Як результат - десятки, а потім сотні субконтракторів були звинувачені у шахрайстві. Хтось відбувся лише штрафом, а декого відправили до в'язниці. Причому усі звинувачені стверджували, що гроші не брали.

Про систему обліку тоді ніхто одразу не думав. Бо облік - "це ж просто операції додавання та віднімання". Комп'ютер повинен легко та без помилок працювати з таким.

Але люди продовжували стверджувати, що невинні. Вони давали інтерв'ю в газетах та інших медіа. Тож в 2012 році незалежна слідча компанія Second Sight почала розслідування інциденту. Розслідування тривало декілька років, протягом яких поштова служба намагалася перешкодити роботі слідчих: винищувала або губила репорти, не давала ключі від сховищ, та ін. Результатом росзлідування стало подача позову проти поштової служби. Подав його Алан Бейтс - колишній власник одного з відділень пошти, якого звільнили на початку 2000х та ще й призначили штраф.

Що відкрилося в ході слідства

Слідство виявило, що проблема в нестачі коштів була саме через систему обліку Horizon. Як не дивно - в системі були баги (тобто помилки). Причому такі, що напряму впливають на кінцеві фінансові розрахунки. Можливо у розробників й були якісь тести, але як розповім далі, багато з циї тестів не враховували той факт, що Horizon - це розподілена система.

Маленька ремарка про транзакції

В світі баз даних (а особливо розподілених) є такі принципи, як ACID.

  • atomicity - транзакція або повністю виконується, або повністю відкатується назад

  • consistency - властивості системи повинні постійно виконуватись (наприклад в кінці дня кількість доходів та витрат повинні дорівнювати очікуваним)

  • isolation - виконання транзакції в одній частині системи не повинно одночасно впливати на виконання транзакцій в іншій.

  • durability - коли зміна в базі виконана - користувач повинен бути в цьому впевненим.

Ці принципи забезпечують валідність та стабільність даних в базі.

То ж які баги були в Horizon

  1. Транзакція реєструється на одній машині та віправляється на інші (в головний офіс). На шляху щось трапляється, й перша машина вважає транзакцію невалідною та робить повторну. А машина-отримувач успішно реєструє першу транзакцію, а потім і другу. Причому ID транзакцій подекуди були однаковими. (atomicity)

  2. Коли користувач у відділенні запускає друк репорту за день і в цей час приходить ще одна транзакція ззовні - вона не реєструється зовсім. Тому - легко губиться. (isolation)

  3. Коли користувач системи робить транзакцію в підсистему та в досить невчасний момент натискає кнопку Cancel - система ламається повністю. (consistency)

  4. Система Horizon у відділеннях була зв'язана також з банком - та мала доступ до аккаунтів людей. Бували ситуації, коли людина приходила в банк та знімала там готівку. А повідомлення про зменшення балансу не доходить до Horizon. Тож баланс в Horizon той самий. То ж людина приходила ще й в поштове відділення та спокійно знімала ще грошей. А повертати ці гроші люди зазвичай не дуже раді. (durability)

Крім того - проблеми з логами

Horizon на кожній робочій станції у відділенні підтримував свій власний audit log. Коли ви підключали нову машину вмережу - вона сінхронізувала ці логи з іншими машинами. Плюс раз в деякий час - логи сінхронізувались з головним офісом.

Проблема була в тому, що часто часові мітки (timestamps) в логах не відповідали дійсності, а опис операцій - був не зрозумілий.

До того ж, логи на кожній окремій машині записувались тільки від одного юзера. Тож коли хтось у відділенні захотів би "підправити звітність" - в логах винуватцем був тільки "адмін" конкретної машини (власник відділення).

Чим все закінчилось

Спочатку Британська поштова служба разом з Fujitsu все заперечувала. Бо ж визнання провини вдарить по репутації обох. (А також по ціні на акції). Після декількох тяжких судів, коли тікати стало нікуди - поштова служба намагалася перекинути провину виключно на Fujitsu та їх софт.

Головна проблема була в тому, що обидві компанії знали про баги в софті та навмисно їх приховували. Й продовжували заперечувати свою провину до останнього.

Але в результаті справедливість відновили. Незаконно обвинувачені люди отримали компенсацію. Але то був довгий та тяжкий шлях боротьби та неетичної поведінки компаній. Поведінки, що зламала долі багатьох людей.

P.S. Більше про цей скандал можна почитати у вікіпедії. Також, про всю цю ситуацію навіть зняли невеличкий документальний серіал - Mr Bates vs The Post Office

Поділись своїми ідеями в новій публікації.
Ми чекаємо саме на твій довгочит!
Test Engineering Notes
Test Engineering Notes@TestEngineering

Про складні речі в тестуванні

1.2KПрочитань
4Автори
14Читачі
На Друкарні з 27 червня

Більше від автора

Вам також сподобається

  • Партиціювання у Kafka

    Пост про партиції в Kafka. Офсети. Визначення партиції. Динамічне розширення. Порядок і усунення дублікатів. Скільки треба вибирати партциій для топіка? Стратегії партиціювання.

    Теми цього довгочиту:

    Kafka
  • Explicit wait: явне очікування або fluent wait швидкого приготування

    Що ж, в попередніх постах було описано imlicit wait(неявне очікування) та fluent wait(впевнене очікування, хоча такий переклад — це радше відсебеньки), а це означає, що настав час для останнього з трьох — явного очікування.

    Теми цього довгочиту:

    Qa
  • Українська освіта

    За 3 роки змішаного навчання(онлайн/офлайн) я побачив всі недоліки нашої освіти піднялися, як підводні гори (навіть не камені).

    Теми цього довгочиту:

    Освіта

Коментарі (0)

Підтримайте автора першим.
Напишіть коментар!

Вам також сподобається

  • Партиціювання у Kafka

    Пост про партиції в Kafka. Офсети. Визначення партиції. Динамічне розширення. Порядок і усунення дублікатів. Скільки треба вибирати партциій для топіка? Стратегії партиціювання.

    Теми цього довгочиту:

    Kafka
  • Explicit wait: явне очікування або fluent wait швидкого приготування

    Що ж, в попередніх постах було описано imlicit wait(неявне очікування) та fluent wait(впевнене очікування, хоча такий переклад — це радше відсебеньки), а це означає, що настав час для останнього з трьох — явного очікування.

    Теми цього довгочиту:

    Qa
  • Українська освіта

    За 3 роки змішаного навчання(онлайн/офлайн) я побачив всі недоліки нашої освіти піднялися, як підводні гори (навіть не камені).

    Теми цього довгочиту:

    Освіта