Как наука о безопасности вписывается в разработку программного обеспечения?

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

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

Что должны знать программисты о безопасности? Нет лучшего введения, чем сложности и проблемы, связанные с искусственным интеллектом. Трудно обсуждать безопасность с командами, которые создают веб-приложения, которые могут показаться безобидными и безобидными, но с искусственным интеллектом угроза безопасности уже здесь.

Что такое безопасность системы?

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

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

Основы системной безопасности можно разбить на следующие элементы:

Скептицизм ошибок пользователя

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

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

Метрики как обоюдоострый меч

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

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

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

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

Расширьте возможности оператора

В сообществе специалистов по безопасности есть известная история о проблемном транспортном перекрестке в Нидерландах, где городским планировщикам удалось добиться резкого снижения травматизма и аварий, убрав все полосы движения, знаки, светофоры / сигналы, тротуары, велосипедные дорожки и т. Д. Часто упоминается как пример того, как большая безопасность может сделать вещи менее безопасными в действительности, но иногда замалчивается, почему перекресток был безопаснее.

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

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

Когда я работаю с инжиниринговыми организациями, мне нравится разрабатывать процесс, но я ненавижу процесс ради процесса. Я объясняю людям, что процесс - это показатель доверия, возникающего благодаря человеческим связям. Всегда предпочтительнее использовать социальные связи и сотрудничество для достижения цели, потому что люди адаптируются. Подобно велосипедистам и водителям, приближающимся к голому перекрестку в Нидерландах, они будут оценивать потребности друг друга и прокладывать путь вперед. Однако по мере роста организации некоторые аспекты сотрудничества становятся более сложными, поскольку они полагаются на социальные связи, которых нет. Срабатывает номер Данбара, и есть коллеги, которым вы не доверяете, потому что не знаете их. Они работают в другом отделе, в другом отделе, может быть, в другом месте.

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

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

Дрейф

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

В результате операции постепенно уходят от официального процесса в неформальную и потенциально небезопасную реальность.

Значение дрейфа состоит в том, что некоторые решения, к которым люди стремятся сделать вещи «более безопасными», увеличивают вероятность дрейфа и тем самым снижают безопасность. Чем больше правил и больше шагов, тем выше вероятность того, что шаг будет пропущен или правило будет случайно нарушено.

Сложный против Сложного

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

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

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

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

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

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

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

Применение безопасности к искусственному интеллекту

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

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

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

Не заменяйте людей

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

У нас возникают проблемы с использованием искусственного интеллекта, когда мы предполагаем, что люди глупы, а компьютеры умны. На самом деле люди и компьютеры глупы по-разному и дополняют друг друга.

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

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

Иногда сложную проблему можно переформулировать как сложную. Обработка естественного языка - хороший пример. Около сорока лет работа по обучению компьютеров человеческому языку была сосредоточена на правилах грамматики. Мы пытались преподавать компьютерную теорию хомского лингвистики. Хотя верно, что все языки имеют тот или иной тип базовой структуры правил, язык в повседневной жизни будет создавать вариации в зависимости от контекста. Другими словами, правила могут не меняться, но их исполнение динамично.

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

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

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

Быть скучным

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

[Фармацевты] обеспокоены тем, что медсестры часто прерывают выдачу лекарств и, таким образом, допускают ошибки, которые могут привести к травмам или смерти пациентов, выступали за вмешательство барьерного типа. В некоторых случаях медсестрам на приеме лекарств приходилось носить красный жилет с текстом, предупреждающим других, чтобы они не прерывали; в других было построено небольшое «безопасное пространство» (вроде телефонной будки), в которое могли уйти медсестры, выдающие лекарства. Ни один из них не работал должным образом. Медсестер в жилетах по-прежнему прерывали другие, причем на более долгое время. Оказалось, что те, кто их прерывает, действительно руководствовались жилетом, который гласил: «Не перебивай слишком часто». Это означало, что, когда они действительно прерывали медсестру, выдающую лекарства, им требовалось больше времени, чтобы убедиться, что все их (потенциальные) вопросы и проблемы могут быть решены за один раз. А медсестры в телефонной будке, вероятно, были похожи на рекламу, в которой говорилось: «Медсестра сейчас». Теперь другие могли видеть, где они; для разнообразия, они не двигались и были явно доступны.

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

Лучшие инструменты искусственного интеллекта - это те, которые учитывают, когда люди-операторы сами по себе нуждаются в помощи и сосредотачиваются на помощи, но эти решения скучны.

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

Первый вопрос, который мы должны задать: где динамические взаимодействия, а где статические? Самая простая модель системы может выглядеть как видеопоток для распознавания объектов, который создает аннотации:

Ни распознавание объектов с помощью человека, ни распознавание с помощью искусственного интеллекта не будет точным в 100% случаев, но факторы, вызывающие ошибки, различны для каждого из них.

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

В компьютерах неудача в распознавании объектов связана с качеством данных и тем, насколько репрезентативны данные, обучающие модели, для реальности. Если видеоматериал имеет существенно другое качество, или находится под другим углом, или содержит факторы, которые не контролируются (например, движение камеры, изменение цвета и т. Д.), То компьютер, скорее всего, совершит ошибку.

Следующее, что нужно учитывать, - это то, какие типы ошибок могут быть сделаны и каков их бюджет. Мы можем внести изменения, чтобы контролировать количество времени, которое человек тратит на аннотирование видео, или уровень шума в комнате, чтобы минимизировать ошибки. Или мы можем точно настроить наши модели и увеличить наши обучающие данные, но полезен ли какой-либо из этих подходов, зависит от того, какой уровень терпимости мы имеем к ошибкам в этом взаимодействии. Если мы предположим, что аннотация - это просто примечание каждый раз, когда в видеопотоке появляется резиновая уточка, у нас есть два типа ошибок, о которых следует подумать - ложные срабатывания и ложные отрицания - и три варианта этого взаимодействия: 1) лучшее распознавание (человеческое) делает только анализ, 2) ИИ выполняет первый проход, подтверждает человек, 3) ИИ выполняет второй проход, выделяя области, в которых человек мог допустить ошибку.

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

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

Разные цели проекта позволяют решить проблему аннотации по-разному. Но есть один вариант, который всегда является наихудшим: полностью удалить человека-оператора и попытаться создать ИИ компьютерного зрения, который может динамически подстраиваться не только под качество подачи, но и на непредсказуемые переменные, такие как угол камеры, освещение и движение, ЗАТЕМ компьютер также делает все необходимое. аннотации тоже работают.

И все же это почти всегда то решение, которое предлагают компании, занимающиеся ИИ.

Показать контекст

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

Например, в Алабаме запрещено приучать медведей к борьбе. Звучит безумно. Зачем нам такой глупый закон? За исключением того, что в 1870-х годах борьба с медведями была на самом деле популярным (хотя и жестоким) видом спорта, и она продолжалась и в 20 веке, когда на мероприятиях WWE время от времени проводились матчи по борьбе с медведями. Говорят, что в одном матче дрессировщик намазал медом хоботы соперника-человека, чтобы дать медведю преимущество ... это было в 1981 году! Так что, да, это печально, что законодателям штата понадобилось принять закон, чтобы люди перестали бороться с дикими животными, но это только кажется глупым, потому что большинство из нас полностью забыло, что борьба с медведями когда-либо существовала.

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

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

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

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

И все же Microsoft - особняк. Большой, мощный выброс с большим влиянием и ресурсами, но все же выброс. Если вы ищете UI для AI, большая часть разговоров идет об использовании AI для исключения дизайнеров и автоматической генерации UI. Или создание интерфейсов перетаскивания, которые позволяют людям, не умеющим писать код, создавать алгоритмы ИИ. Если это все еще кажется вам хорошей идеей, значит, вы не обращали внимания.

Узнать больше о безопасности системы

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

Системное мышление: вся теория безопасности предполагает системное мышление. Введение эколога Донеллы Медоуз в картографирование и рассуждения о системах является классическим не зря.

Сидни Деккер всегда будет моей рекомендацией. Его книги и научны, и удобочитаемы, и, имея опыт работы в качестве пилота авиалинии, он говорит с большим авторитетом, когда дело доходит до повышения безопасности. Я обычно рекомендую Drift Into Failure, но я только что закончил Анархист безопасности, и он тоже довольно хорош. Полевое руководство по пониманию человеческой ошибки и Культура справедливости - популярные названия в сообществе SRE.

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

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