Неуязвимость. Отчего системы дают сбой и как с этим бороться - Андраш Тилчик

Чарльз Перроу написал однажды, что «системы безопасности – одни из главных источников катастрофических событий внутри сложных и жестко связанных систем»{132}. При этом он имел в виду атомные электростанции, химические предприятия и самолеты. Но с таким же успехом он мог бы сказать это и о церемонии вручения премии «Оскар». Если в ходе мероприятия не возникло бы такого количества «лишних» конвертов, этого досадного провала никогда бы не случилось.

Несмотря на предупреждения Перроу, сами по себе системы безопасности, безусловно, хорошее дело. Они предотвращают некоторые предсказуемые ошибки, поэтому возникает соблазн использовать как можно больше таких систем. Однако зачастую функции безопасности сами по себе становятся частями общей системы – и это добавляет ей сложности. А по мере возрастания сложности повышается и вероятность сбоев, возникающих с неожиданной стороны[11].

Излишества функций безопасности – не единственная причина, по которой случаются неприятные происшествия. Исследование систем экстренного вызова персонала в пяти реанимационных отделениях показало{133}, что только за месяц было зафиксировано 2,5 млн сигналов тревоги, 400 000 из которых сопровождались каким-то звуком. Это один сигнал тревоги каждую секунду и один звуковой сигнал каждые восемь минут. Около 90 % из них оказались ложными. Это как в старой сказке: кричите «Волк!» каждые восемь минут и скоро вас просто перестанут слушать. Что еще хуже: в тот момент, когда происходит что-то действительно серьезное, постоянные сигналы тревоги не дают отличить те, которые действительно важны, от тех, что имеют дежурный характер.

Это парадокс: дополнительные функции безопасности снижают общий ее уровень{134}. Мало кто так отчетливо это понимает, как Боб Уотчер, врач и автор книг из Калифорнийского университета в Сан-Франциско. В своей книге «Цифровой доктор» (The Digital Doctor){135} Уотчер вспоминает случай с Пабло Гарсия, подростком, который чуть не умер, когда медсестра случайно дала ему гигантскую дозу антибиотиков.

В 2012 году в университетском госпитале внедрили новую компьютерную систему. Она управляла в том числе и роботом-фармацевтом, который занимал целую комнату и при помощи манипуляторов комплектовал лекарства для больных, набирая их из специальных ящичков. Врачи и медсестры надеялись, что новые технологии устранят человеческие ошибки и повысят безопасность пациентов. «Компьютеризированный процесс заказа лекарств сделал рукописные назначения врачей таким же достоянием прошлого, как царапины на грампластинках, – писал Уотчер. – Робот-фармацевт мог гарантировать, что доставалось нужное лекарство, а его доза отмерялась с ювелирной точностью. Штрихкод на упаковке представлял собой еще один элемент безопасности, поскольку в том случае, если сестра взяла неправильное лекарство или ошибочно принесла его не тому больному, подавался сигнал»{136}.

Это замечательные функции безопасности, и они действительно устранили много обычных ошибок. Но они же добавили системе и сложности. А в случае с Пабло Гарсия проблема началась с того, что интерфейс системы заказа лекарств, который был разработан так, чтобы избежать канцелярских ошибок, ввел в заблуждение молодого врача-педиатра. Она была уверена, что заказала только одну таблетку 160 мг. Однако в заказе она указала 160 мг/кг, поэтому система автоматически помножила его на вес мальчика, который составлял 38,6 кг. Таким образом, врач заказала 38,5 таблетки.

Сразу же включилась система предупреждения, и на экране компьютера высветился сигнал тревоги о передозировке. Однако доктор отключила его, поскольку ненужные предупредительные сигналы появлялись на экране монитора постоянно. Фармацевт, который проверял заказ (разумеется, в электронном виде), тоже пропустил ошибку. Робот стоимостью в миллион долларов с радостью упаковал пилюли. И хотя медсестра, пришедшая к Гарсия, и сомневалась по поводу такой большой дозы, штрихкод – еще одна ступень безопасности системы – показал ей, что она находится в нужной палате у нужного пациента. Это развеяло ее сомнения, и она дала мальчику лекарство – все 38 с половиной таблетки.

Колокольчики, свистки и дополнительные функции безопасности устраняют некоторые ошибки. Но в то же время они повышают сложность систем и могут стать причиной серьезных происшествий и аварий. Однако, когда мы хотим оградить себя от них – даже от тех происшествий, виновницей которых была высокая сложность систем, – мы испытываем соблазн добавить в них еще больше функций безопасности. Во время обсуждения случая с передозировкой лекарств{137} один из коллег Уотчера задумчиво произнес: «Думаю, нам надо ввести здесь еще один тревожный сигнал». Уотчер почти закричал в ответ: «Проблема как раз и состоит в том, что у нас слишком много сигналов тревоги! Добавление еще одного только ухудшит дело!»

И он прав. Кажущееся очевидным решение – наслоение все большего количества функций безопасности – не работает. И что нам с этим делать? Как нам заставить наши системы работать лучше?

Первый разумный шаг – это их диагностирование. Матрица Перроу с указанием сложности и жесткости связей в системах позволяет нам оценить их уязвимость с точки зрения противодействия чрезвычайным происшествиям или непредвиденным противоправным деяниям. «Матрица демонстрирует, где в вашем проекте или бизнесе следует ожидать неприятных сюрпризов»{138}, – говорит Гэри Миллер, инженер-атомщик, переквалифицировавшийся в консультанта по менеджменту. Он стал кем-то наподобие проповедника концепции Перроу в своей компании.