Кто отвечает за то, что сделала программа

После июльского сбоя CrowdStrike на Hacker News спорили, с кого спрашивать за последствия. Одного из участников треда раздражало, что после таких аварий виноватыми обычно называют менеджеров или тестировщиков, но почти никогда — самих программистов. Плохая организация работы в компании вполне может сочетаться с небрежностью конкретного человека, однако авторов кода от ответственности всякий раз освобождают заранее.

Инженер Knight Capital при выкатке новой версии торговой системы обновил семь серверов из восьми. На пропущенной машине остался старый код: флаг, которому в обновлении дали другое назначение, там по-прежнему включал давно не использовавшуюся функцию Power Peg. Получив команду, старый код продолжал отправлять заявки на биржу даже после исполнения клиентского поручения.

Утром 1 августа 2012 года, еще до открытия рынка, внутренняя система отправила сотрудникам 97 писем об ошибке, но на них никто не отреагировал — эта рассылка не предназначалась для экстренных оповещений. Когда начались торги и в систему пошли ошибочные ордера, про утренние письма тоже не вспомнили. За 45 минут из 212 клиентских поручений выросли миллионы заявок. Попытка откатить релиз только усугубила сбой: сотрудники снесли обновление с остальных семи серверов, и Power Peg заработал уже на всех восьми машинах сразу. Проще было вообще отключить шлюз от биржи, но в тот момент до этого не додумались — система так и оставалась подключенной к торгам.

Ошибочно открытые позиции обошлись Knight Capital более чем в 460 миллионов долларов, а год спустя компания согласилась на 12 миллионов долларов штрафа и независимую проверку своих процедур. В решении SEC имя инженера, забывшего про восьмой сервер, даже не упоминается. Комиссия установила, что в компании плохо контролировали тестирование и установку обновлений. Автоматических проверок, которые блокировали бы заявки при превышении общего лимита капитала, в системе не было, как и понятных письменных инструкций на случай аварии.

У медицинского ускорителя Therac-20 были независимые механические предохранители, которые физически не давали облучить пациента лишней дозой радиации. Благодаря этой простой защите никто годами не замечал, что в самой программе сидит опасный баг: ошибка в коде периодически срабатывала, но каждый раз упиралась в аппаратную блокировку.

Проблема вскрылась только на следующей модели, Therac-25, где в 1985–1987 годах произошло шесть известных аварий, в которых часть пациентов погибла от переоблучения, а другие получили тяжелые травмы. Как объясняют Нэнси Левесон и Кларк Тернер в работе 1993 года, новый аппарат унаследовал часть кода от Therac-20 вместе со старым дефектом, но при проектировании производитель отказался от механических блокировок и полностью положился на проверки в самом софте. Когда после первого же случая пациентка сказала врачам, что аппарат ее обжег, ни персонал клиники, ни производитель поначалу не поверили, что машина с компьютерным управлением могла причинить такую травму. Другие больницы тогда не получили своевременного предупреждения.

На Boeing 737 MAX первая версия системы MCAS использовала показания только одного из двух датчиков угла атаки — сверки со вторым датчиком не было. Если задействованный сенсор ошибочно сообщал о слишком большом угле, MCAS перекладывала стабилизатор на пикирование, чтобы опустить нос самолета. Пилот мог противодействовать автоматике переключателями электропривода стабилизатора на штурвале. Однако через пять секунд после отпускания кнопок система при сохранении ошибочного сигнала снова давала команду на пикирование, и этот цикл мог повторяться многократно.

Сравнение показаний обоих датчиков, как и ограничения на ход стабилизатора, Boeing добавила в логику MCAS только после двух катастроф. В отчете FAA за 2020 год отдельно разобрано время реакции экипажа: при предсказуемом отказе системы управления стабилизатором безопасность полета не должна зависеть от того, за сколько секунд пилоты успеют среагировать на аварию.

Учетная система Horizon, которую использовала британская почтовая служба Post Office, могла показывать недостачу из-за программных ошибок, даже если деньги и товар оставались на месте. Тем не менее ее данные годами служили основанием для уголовного преследования руководителей почтовых отделений, пока весной 2021 года Апелляционный суд Англии и Уэльса не отменил 39 обвинительных приговоров по этим делам.

В самой Post Office знали о серьезных сомнениях в надежности Horizon, но в судах продолжали настаивать на правильности расчетов. По британским законам почтовое ведомство само вело уголовное преследование без участия полиции, а значит, обязано было расследовать сообщения о сбоях и передавать защите сведения, способные поставить обвинение под сомнение. Суд установил, что компания этих обязанностей не выполнила, лишив подсудимых возможности полноценно оспорить данные системы.

В обсуждении на Hacker News тогда спрашивали: деньги вообще пропали? От обвинения требовали сначала проверить расчет другим способом, вместо того чтобы уверять подсудимых в надежности закрытой программы и ждать, пока они сами найдут в ней баг.

Инженер Volkswagen Джеймс Лян специально настраивал прошивку дизельных двигателей так, чтобы она распознавала стендовые экологические испытания и временно меняла режим работы, помогая машине пройти проверку. На следствии он признал и то, что вместе с коллегами помогал скрывать обман от американских регуляторов, когда те заинтересовались реальными выбросами при обычной езде. В 2017 году суд в США приговорил Ляна к 40 месяцам тюрьмы за участие в сговоре и махинации с тестами.

Для массовых сбоев Windows 19 июля 2024 года хватило рядового обновления конфигурации для уже установленного Falcon Sensor. Как следует из технического отчета CrowdStrike, такие правила передаются через шаблоны: в схеме одного из них было заявлено 21 входное поле, тогда как сам код сенсора передавал интерпретатору только 20 значений. Прежние правила допускали любое значение в последнем поле, поэтому интерпретатор к нему не обращался и расхождение между схемой и кодом оставалось незаметным.

Источник: Wikimedia Commons. Источник фотографии ↗

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

При этом в отчете нет ни слова о том, кому именно поручили писать проверки, как тестировали шаблон и знал ли кто-то в команде о расхождении полей перед выпуском. Спросить с конкретного разработчика по такому документу все равно не выйдет — снаружи просто нет данных о том, что происходило внутри команды.

В споре об инженерной ответственности создатель языка D Уолтер Брайт отмечал, что желание наказать за случившееся лишь подталкивает участников скрывать проблемы. В ответ ему напомнили, что без свидетельств самих разработчиков разбор все равно остается неполным, даже когда отчет пишут без обвинительного тона. Пока рядовые исполнители молчат, о том, как проверяли тот же шаблон в CrowdStrike перед выкаткой, приходится судить только по официальному пересказу самой компании.