Инновации с жизненно важными системами

Каждое предприятие имеет «критическую» инфраструктуру. Как правило, это означает, что если система отключится, часть (или весь) бизнес остановится до тех пор, пока технические специалисты не смогут снова запустить ее. Это часто происходит, когда требуется масштабное обновление программного обеспечения, оборудования или сети: недавно развернутые системы содержат неожиданные ошибки, вызывающие системный сбой, или пользователи допускают ошибки при работе с новой системой, потому что они незнакомы с ней, и производительность останавливается до тех пор, пока технические специалисты не смогут работать с ошибками развертывания или обучать пользователей. По большей части период простоя или снижения производительности является приемлемым риском в обмен на обещание повышения производительности и эффективности новых технологий, но это не является универсальным. Большинство предприятий могут позволить себе определенное время простоя, не рискуя большим доходом и не вызывая недовольства своих клиентов.

Но что происходит, когда системы, которые вам необходимо модифицировать, являются жизненно важными системами , где безопасность жизни зависит от возможности надежного использования системы?

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

Прежде чем мы начнем, я хотел бы объяснить, почему это может быть важно для вас. Хотя может быть неочевидно, что ваш проект на самом деле включает жизненно важную систему, это гораздо более вероятно, чем вы думаете. Квалифицируются все следующие, а также бесчисленное множество других тем:

• Автомобильный. Работаете над проектом с производителем транспортных средств или любым из их поставщиков? Вас завербовал из университета стартап по производству беспилотных автомобилей? Автоматическое торможение, круиз-контроль, контроль полосы движения, компьютерное зрение, распознавание препятствий, электронные модули управления двигателем и т. д. Каждая из них является жизненно важной системой, где отказ может быть фатальным.
• Авиация. Когда вы находитесь в воздухе на высоте 30 000 футов, почти любой системный сбой может иметь жизненно важное значение. Учитывая недавние события с Boeing 737 MAX, очевидны жизненно важные системы автопилота и компьютеризированного управления полетом, но есть и множество вещей, о которых вы можете не задумываться. Дома, если вентилятор в вашей системе HVAC выходит из строя и производит немного дыма, вы открываете окно или выходите на улицу, чтобы подышать свежим воздухом. Вы когда-нибудь пробовали открыть окно и выйти наружу во время трансатлантического перелета? Даже самые простые системы, от электрических розеток на кухне до тормозов на колесах тележки для напитков, могут быть жизненно важными в самолете.
• Коммуникации. Большинство разработчиков или инженеров в какой-то момент своей карьеры будут работать над проектом системы связи в том или ином качестве. Многим телекоммуникации изначально не кажутся жизненно важными; в конце концов, цивилизация прекрасно жила до телефонов и Интернета. Как человек, побывавший в зонах стихийных бедствий, где телекоммуникационная инфраструктура была разрушена, позвольте мне рассказать вам, что происходит на самом деле: люди сильно заболевают или получают травмы и не могут позвонить в 911; пожилые жители не могут позвонить своим детям, чтобы попросить их забрать рецепты из аптеки; аварийно-спасательные службы не могут общаться со своими диспетчерами или друг с другом; и люди, которые не могут связаться с членами своей семьи, становятся обеспокоенными и ставят себя в чрезвычайно опасные ситуации, пытаясь найти их. Системы связи абсолютно жизненно важны.

В современном мире, где технологии сильно зависят от технологий, проекты, которые вы никогда не считали даже полуважными, могут в конечном итоге стать жизненно важным компонентом жизненно важной системы.

Но если он не сломан, не чините его

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

Есть веская причина такой привязанности к программному и аппаратному обеспечению наследия. Известно, что он работает, маловероятно, что возникнут неизвестные ошибки, а его стоимость стабильна и предсказуема. Отличным примером является космическая отрасль: российский космический корабль «Союз» запускает космонавтов в космос уже более 50 лет с небольшими доработками за это время, и он продолжает использоваться, потому что он надежен и безопасен. К сожалению, это означает, что он также крайне неэффективен по сравнению с современными конструкциями: в то время как «Союз» стоит НАСА 81 миллион долларов США за место для доставки астронавтов на космическую станцию ​​с использованием своего наследия, SpaceX и Boeing, как ожидается, предложат места по 58 миллионов долларов США каждое. используя свои современные конструкции ракет.

Понятно, что мало кто хочет модернизировать старые системы, которые все еще работают; руководители не хотят рисковать, технические специалисты не хотят иметь дело с таинственным сервером в шкафу со сроком безотказной работы 12 лет, а клиенты не хотят изучать новые конструкции. К сожалению, между минимизацией рисков и экономией средств есть переломный момент: со временем традиционные конструкции необходимо будет модернизировать, даже в средах с высоким риском .

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

Убедить начальство

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

Независимо от того, работаете ли вы с корпорацией из списка Fortune 500 или с местной добровольной пожарной службой, все сводится к одному и тому же: к деньгам. Корпорации не хотят его терять, а некоммерческим организациям вообще не с чем работать. Единственный найденный мной надежный способ убедить руководство организации пойти на риск изменения жизненно важной системы — это продемонстрировать, что с вероятностной точки зрения они либо с большей вероятностью заработают/сэкономят деньги, чем потеряют их, либо что они могут снизить свою ответственность за счет модернизации своих технологий и повышения безопасности.

Это означает, что вам нужно сделать математику. Какова вероятность длительного простоя или будущих сбоев из-за ошибок (на основе предыдущих развертываний в вашей организации или данных из других организаций)? Каковы ожидаемые последствия в случае отказа и во что это обойдется? И наоборот, каковы ожидаемые приросты производительности или надежности и сколько они будут стоить? Если вы можете показать, что существует высокая вероятность того, что вы выйдете вперед, есть хорошие шансы, что вы получите зеленый свет.

Дело не в тебе

Возможно, вам знакома фраза «инженерами для инженеров», идиома, предполагающая, что инженеры создали что-то для использования людьми с квалификацией, аналогичной их собственной. Это чрезвычайно распространенное явление, и оно стало одним из основных факторов, ускоривших рост исследований удобства использования компьютеров в начале 1990-х годов. Как инженеры, мы часто имеем разные ментальные модели того, как работают технологические системы, чем у среднего конечного пользователя, что приводит к тенденции проектировать системы, предполагая, что конечный пользователь уже знает, как они работают. В обычных системах это приводит к ошибкам и недовольству клиентов; в жизненно важных системах это может привести к смерти.

Рассмотрим случай с рейсом 447 Air France. 1 июня 2009 года Airbus A330 пролетел над Атлантическим океаном по пути из Рио-де-Жанейро в Париж. Кристаллы льда блокировали трубки Пито, вызывая несоответствия в измерениях скорости воздуха. Бортовой компьютер отключил автопилот, признав, что он не может надежно управлять самим самолетом с неверными данными о воздушной скорости. Затем он перешел в режим «расширенного режима полета» , что позволило пилотам выполнять маневры, которые компьютер обычно не позволял. Вы можете представить себе инженеров, создавших систему, которые думали : «Если автопилот отключается, это, вероятно, происходит из-за ситуации, когда пилотам может потребоваться дополнительный контроль! ”

Это естественный ход мыслей инженеров, которые понимают, какие вещи могут привести к отключению автопилота. Для пилотов это было не так. Они заставили самолет резко набирать высоту, игнорируя предупреждения «STALL», пока он не потерял скорость и не рухнул в океан. Все 228 пассажиров и членов экипажа погибли. Хотя существует множество идей относительно точных мотивов их действий, преобладающая теория состоит в том, что пилоты предполагали, что бортовой компьютер предотвратит управляющие воздействия, которые могут привести к остановке самолета (что верно для нормального режима полета), и не осознавали, что он переключился в режим расширенного конверта, потому что они не разделяли ментальную модель инженеров логики, которая управляла решениями компьютера.

Это немного окольный путь, но он подводит нас к моей основной мысли: действия, которые вы хотите, чтобы пользователи выполняли в определенных условиях, должны быть действиями, которые кажутся им естественными .

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

Это означает, что абсолютно необходимо, чтобы конечные пользователи участвовали в каждом этапе процесса проектирования и разработки. Не может быть никаких предположений о том, что, вероятно, будут делать пользователи; все должно быть основано на доказательствах. При разработке интерфейсов вы должны проводить исследования, чтобы определить модели мышления, которые они вызывают у пользователей, и при необходимости корректировать их. Когда вы тестируете свои новые системы, вы должны тестировать их с реальными пользователями в реальных условиях в реальных условиях. И, к сожалению, когда вы изменяете свой дизайн, вам приходится повторять эти шаги снова и снова.

Хотя каждая сложная система уникальна, я хотел бы упомянуть, в частности, три конструктивных соображения, которые следует применять повсеместно:

• Элементы управления должны представлять действия, которые они вызывают. К счастью, это довольно распространено, обычно его можно увидеть в виде выбора соответствующих значков для кнопок графического интерфейса или соответствующих фигур для физических элементов управления. Кнопки «Новый файл» используют значок чистого листа бумаги, а рычаги шасси в самолетах имеют ручку в форме колеса. Однако легко стать самодовольным. Почему мы все еще видим значки 3,5-дюймовых дискет для кнопок «Сохранить»? Кто-нибудь моложе 25 лет вообще знает, что такое дискета? Мы продолжаем использовать его, потому что считаем его репрезентативным, но на самом деле это уже не так. Требуются постоянные усилия, чтобы гарантировать, что представления элементов управления значимы для пользователей, но также необходимо и сложно сбалансировать это с непрерывностью.
• Если система предупреждения выходит из строя, это должно быть обнаружено. Мы часто используем сигнальные лампы, которые включаются при возникновении проблемы, например мигающий красный индикатор. Это здорово для привлечения внимания пользователя, но что произойдет, если свет перегорит? Космический корабль, использовавшийся в лунных миссиях «Аполлон», имел десятки сигнальных ламп для всех видов систем, но они не работали обычным образом. Вместо того, чтобы загораться, когда была проблема, они продолжали гореть, когда все было в порядке, и выключались, когда возникала проблема. Это гарантировало, что перегоревшая сигнальная лампа не заставит астронавтов пропустить потенциально фатальную системную ошибку. Я не говорю, что вы должны использовать этот дизайн, поскольку лампочки прошли долгий путь в плане надежности с 1960-х годов, но он дает представление о том, насколько глубоким должно быть ваше планирование. Сколько раз система давала сбой, но вы не знали об этом, потому что ведение журнала или уведомления не работали должным образом?
• Переходы между режимами должны быть очевидны для пользователя. Что произойдет, если Airbus A330 перейдет из обычного режима управления в расширенный режим управления без ведома пользователя, и вдруг самолет сделает то, на что пользователь не рассчитывал? Что произойдет, если самоуправляемый автомобиль отключит автопилот, неожиданно оставив пользователю полный контроль? Что происходит, когда происходит какое-либо серьезное изменение режима или функциональности, которое требует немедленного изменения действий пользователя, но пользователю требуется минута или две, чтобы понять, что только что произошло? Хотя в сложной системе могут потребоваться различные режимы работы, режимы не могут меняться без надлежащего уведомления, объяснения и взаимодействия с пользователем при этом.

Отказ от производства жизненно важных систем

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

Еще одна тема, которая часто возникает в обсуждениях архитектуры с моими клиентами, — это поэтапное развертывание. Это выбор между постепенной заменой элементов уже существующей системы элементами новой до тех пор, пока в конце концов не будет заменено все, и изменением всего сразу. У каждого есть свои плюсы и минусы: поэтапное развертывание позволяет постепенно адаптировать пользователей к новому дизайну, гарантируя, что изменения вносятся в управляемых количествах, а пользователи не перегружены; с другой стороны, это может затянуть процесс на длительное время и привести к постоянному переходному состоянию. Немедленные развертывания выгодны тем, что они «срывают пластырь» и ускоряют процесс, но внезапные радикальные изменения могут ошеломить пользователей.

Я обнаружил, что для жизненно важных систем поэтапное развертывание, как правило, безопаснее, так как оно позволяет выполнять поэтапную оценку отдельных компонентов в производственной среде и позволяет выполнять меньшие реверсии, если что-то необходимо откатить. Однако это необходимо оценивать в каждом конкретном случае.

Нормализация отклонения

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

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

Классический пример — космический шаттл «Челленджер»: регулярно наблюдалась эрозия компонента твердотопливного ускорителя во время запуска, и хотя все знали, что эрозия компонентов ракеты — это плохо, это случалось так часто, что регулярно выдавались отказы, и это считалось обычный. 28 января 1986 года проблема, о которой все изначально знали, что нельзя допускать, но которую они нормализовали, привела к взрыву «Челленджера» и гибели семи астронавтов.

Как администратор жизненно важной системы, вы должны предотвратить подобные случаи. Изучите, как ваши пользователи взаимодействуют с системой. Понаблюдайте за ними пару дней и посмотрите, используют ли они неожиданные обходные пути. Периодически рассылайте опросы, чтобы узнать о предлагаемых изменениях и улучшениях. Посвятите время и усилия улучшению вашей системы, прежде чем ваши пользователи найдут способы обойти проблемы без вас.

Обучение производительности под давлением

Часто сбои в жизненно важных системах происходят, когда пользователи страдают от стресса, всплесков адреналина и туннельного зрения. Это случалось с пилотами Air France 447, это случалось с парамедиками, которые не могли вспомнить, как управлять своим кардиомонитором у первого пациента с остановкой сердца, и это случалось с солдатами, которые не могли правильно управлять своими рациями, находясь под обстрелом.

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

Заключение

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

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

В заключение я хотел бы отметить, что в сложных системах, критически важных для безопасности, в какой-то момент что-то пойдет не так, независимо от того, насколько тщательно вы планируете, тестируете и обслуживаете. Когда эти системы жизненно важны, вполне возможно, что отказ может привести к гибели людей или увечьям.

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

Работайте усердно, не будьте дерзкими, и вы сделаете мир лучше.