Технология, которой доверили человеческие жизни
В начале 1980-х годов в медицинских учреждениях появился аппарат Therac-25 - современная установка для проведения лучевой терапии. Она объединяла функции рентгеновского аппарата и ускорителя электронов, позволяя врачам выбирать подходящий режим лечения для разных видов опухолей.
Предполагалось, что новая модель станет более удобной, быстрой и безопасной по сравнению с предыдущими версиями.
Разработчики сделали ставку на программное управление. Если в ранних системах значительная часть защитных механизмов была реализована аппаратно, то в Therac-25 многие из них перенесли в программный код. Такой подход должен был упростить конструкцию и снизить стоимость производства.
Однако вместе с этим критически важные функции безопасности оказались зависимы от качества программного обеспечения.
Опасная уверенность в надежности
Проблема заключалась не только в отдельных ошибках, но и в отношении к самой системе.
Программисты считали, что код предыдущих моделей уже достаточно проверен, поэтому при создании Therac-25 часть решений фактически перенесли в новую программу.
При этом старые аппаратные блокировки убрали, полагаясь на программные проверки. Такое решение стало серьезной уязвимостью. В системе оказалось недостаточно независимых механизмов, способных остановить аппарат при ошибке.
Если программа неправильно определяла выбранный режим, последствия могли быть крайне тяжелыми: пациент получал не лечебную дозу излучения, а многократно превышавшее норму облучение.
Как ошибка оператора стала катастрофой
Одним из источников опасности была последовательность быстрых действий оператора. При настройке процедуры сотрудник мог выбрать неподходящий параметр, а затем почти сразу исправить его с клавиатуры.
На экране отображалось уже правильное значение, но аппарат не всегда успевал корректно обработать изменения.
В результате система могла запустить мощный электронный пучок в режиме, который не соответствовал выбранной процедуре. Оператор при этом не видел явных признаков неисправности.
Иногда аппарат сообщал об ошибке и прекращал работу, однако пациент уже мог получить опасную дозу радиации.
Первые сигналы не привели к немедленной остановке
В течение нескольких лет в разных медицинских центрах произошли случаи, когда пациенты получили тяжелые лучевые поражения.
Некоторые из них умерли. Медицинский персонал сообщал производителю о необычных сбоях и подозрительно высокой дозе облучения, но поначалу эти сведения не воспринимались как доказательство системной проблемы.
Ситуацию усугубляло отсутствие полноценного журнала событий. После сбоя было сложно точно установить, что произошло внутри аппарата и почему сработала именно такая последовательность команд.
Кроме того, сообщения пользователей нередко объясняли ошибками операторов, хотя позднее выяснилось, что главную роль играли недостатки программной архитектуры.
Почему Therac-25 стал символом опасного программирования
История Therac-25 показала, что программное обеспечение в критически важных системах нельзя проверять по обычным меркам. Ошибка в офисной программе может привести к потере данных или сбою работы. Ошибка в медицинском оборудовании способна стоить человеку жизни.
Особенно опасным стало сочетание нескольких факторов: чрезмерная вера в надежность уже существующего кода, недостаток независимых защитных механизмов, слабая диагностика и медленная реакция на сообщения о неисправностях.
Система должна была не просто работать в штатных условиях, а безопасно обрабатывать любые неправильные действия и неожиданные состояния.
Уроки, которые остаются актуальными
После расследований производителю пришлось исправлять программное обеспечение, усиливать аппаратные блокировки и менять подход к тестированию. Для критических систем стало очевидно: нельзя ограничиваться проверкой стандартных сценариев.
Необходимо моделировать быстрые действия операторов, конфликтующие команды, сбои оборудования и любые возможные комбинации ошибок. Therac-25 напоминает, что безопасность не возникает автоматически вместе с цифровизацией.
Чем больше ответственности передают программам, тем строже должны быть требования к их проектированию, проверке и контролю. Несколько строк неудачного кода могут остаться незаметными годами, но в неподходящий момент превратиться в угрозу для человеческой жизни.