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

Отчеты хранятся в базе данных с открытым доступом, и NASA освещает события и тенденции в области авиабезопасности в ежемесячной новостной рассылке, которая носит название Callback («Отзыв»). Последний выпуск, например, содержал отчет команды авиалайнера, которому в последний момент поменяли взлетно-посадочную полосу, что потребовало крайне резкого снижения{218}. Экипаж не смог его выполнить в отведенное время, поэтому подал соответствующий доклад. В ответ Федеральное управление авиации поменяло процедуру захода на посадку.

В другом выпуске новостной рассылки рассказывалось об опасности халатности на основе историй пилота небольшого частного самолета, который вовремя не переключил подачу топлива из одного бака на другой (и был вынужден приземлиться на шоссе, поскольку топливо в первом баке закончилось), и механика, который погубил двигатель самолета, забыв в нем инструмент для ремонта{219}. Как вы, наверное, уже догадались, Чик Перроу очень любит систему ASRS. «Для конструкторов, – пишет он, – она является источником информации, в котором они обнаруживают парадоксальные вещи, касающиеся недостатков систем. Для организаций она служит напоминанием о том, что хоть кто-то в самом деле думает о вопросах безопасности»{220}.

Фундаментальным свойством сложных систем является то, что мы не можем обнаружить все существующие в них проблемы, просто размышляя о них. Сложность системы может вызывать возникновение таких непонятных и редких взаимодействий, что предсказать большинство цепочек ошибок, которые могут возникнуть, практически невозможно. Но перед разрушением сложные системы подают предупреждающие сигналы, которые раскрывают эти взаимодействия. Таким образом, сами системы подсказывают, как эти взаимодействия могут проявиться.

Однако мы часто не уделяем этим подсказкам должного внимания. До тех пор, пока все идет нормально, мы склонны полагать, что наши системы работают хорошо – даже если в основе успеха всего лишь слепая удача. Это называется искаженное понимание результатов. Возьмите, например, Стефана Фишера, воображаемого менеджера проекта, работающего над разработкой нового планшета в какой-то IT-компании. За несколько месяцев до запуска планшета в серийное производство инженер, отвечавший за его фотокамеру, перешел на работу в другую компанию. В результате команда проекта начала отставать от графика. Чтобы сэкономить время, Стефан решил отказаться от подбора и оценки альтернативных камер.

В нашем эксперименте{221} мы попросили 80 студентов высшей школы бизнеса после ознакомления с проектом оценить действия Стефана и рассмотреть три возможных сценария развития событий. В успешном сценарии планшет продавался хорошо, и проблемы отсутствовали. Сценарий «просто повезло» окончился успешно только благодаря случайному благоприятному стечению обстоятельств: конструкция камеры вызывала перегрев планшета, однако можно было модернизировать процессор и уменьшить нагрев устройства. А вот в сценарии неудачи камера также вызывала перегрев планшета, но модернизировать процессор не представилось возможным. Это стало большой проблемой, и планшет продавался плохо.

В случае со студентами, которые оценивали проект Стефана (как и в случае с инженерами NASA, участвовавшими в подобном же эксперименте с безымянным космическим кораблем), оценку участников определял результат. Когда продажи планшетов шли успешно, Стефан получал хорошие характеристики. Даже когда его проект ждал успех только в результате слепой удачи, участники оценивали его как высококвалифицированного, умного и заслуживающего продвижения по службе. Они выражали сомнения в качестве его решений только в случае неудачи проекта. Но пока проект не терпел фиаско, участники эксперимента не придавали особого значения тому обстоятельству, что Стефану просто везло. Они не усматривали особой разницы между хорошей работой и элементарным везением.

Помните потерю финансовой компанией Knight Capital 500 млн долларов на бирже? Эта потеря произошла из-за небольшой ошибки IT-специалиста компании, который забыл скопировать новый компьютерный код на все восемь серверов Knight Capital. Когда-то в прошлом компьютерщики компании наверняка совершали подобные ошибки, но им везло, и проблема разрешалась без каких-либо потрясений. Поэтому был сделан вывод, что система работает нормально. В конце концов, никаких неудач ведь не было. Однако на самом деле запуск каждого нового программного обеспечения превращался в игру в кости.

Многие из нас совершают нечто подобное и в повседневной жизни. Мы относимся к засорившемуся туалету как к небольшому неудобству, а не как к сигналу тревоги – пока не прорывает канализацию. Или мы игнорируем небольшие «тревожные звоночки» в автомобиле – например, туго переключающуюся коробку передач или шину, которая медленно спускает воздух, – вместо того чтобы отвезти машину в ремонт.

Чтобы совладать со сложностью систем, нам необходимо научиться воспринимать небольшие сбои – информацию, которой эти системы буквально забрасывают нас. Сюда же относятся ситуации, когда мы минуем неудачи буквально чудом, и другие предупреждающие знаки. Во Флинте городские власти не придали должного значения целому ряду сигналов тревоги и упорно настаивали на том, что воду из городского водопровода можно пить без опасений. Они даже не признали наличия проблемы. Инженеры вашингтонского метро сработали лучше. Они понимали, в чем состоит проблема, и создали процедуру тестирования и мониторинговую программу, которая должна была следить за системой. Эти охранительные меры, однако, оказались погребенными под повседневной суетой. Хотя решение проблемы было найдено, оно не применялось на практике. Наконец, менеджеры United Airlines осознавали наличие проблемы и предупредили о ней всех своих пилотов, но это предупреждение не вышло за пределы авиакомпании. Оно не достигло пилотов TWA, которые управляли злополучным рейсом № 514.

Каждая из этих историй приближает нас к решению, которое может сработать. Оказывается, в некоторых организациях нашли способы, благодаря которым можно учиться на небольших ошибках и предаварийных ситуациях. Исследователи называют эту методику аномализированием{222}, пример ее графического представления мы дали на следующей странице.