1760087498
2025-10-10 09:00:00
Ключевые выводы
- Автоматизация часто участвует в инцидентах с программным обеспечением нелогичным образом (например, затрудняет разрешение или усложняет реакцию человека).
- Полное разделение задач на те, которые решает автоматизация, и те, которые решают люди, влияет на проектирование систем таким образом, что усложняет разрешение инцидентов.
- Автоматизация может непредвиденным образом ухудшить приобретение/сохранение человеческих знаний и навыков из-за того, что у людей меньше опыта работы с системами, предназначенными для управления автоматизацией.
- Когнитивная наука может способствовать более эффективному проектированию систем и инструментов, которые включают автоматизацию или полагаются на нее, используя принципы совместных когнитивных систем.
- В идеале разработчики сложных программных систем должны внедрять автоматизацию как способ расширить и улучшить человеческий труд, а не стремиться заменить его.
Наше исследование пролило свет на эти предположения и ограничения, а также на то, как они продолжают сеять хаос в программных системах, которые все больше полагаются на автоматизацию (и все больше на искусственный интеллект). Ниже я излагаю некоторые распространенные предположения и заблуждения об автоматизации и ее роли в программном обеспечении (и инцидентах с программным обеспечением), результаты наших исследований относительно того, как автоматизация проявляется в инцидентах с программным обеспечением, а также некоторые идеи о том, как люди могут лучше разрабатывать автоматизированные инструменты, которые помогут людям лучше справляться с инцидентами с программным обеспечением.
Мифы и заблуждения об автоматизации
Хотя на данный момент автоматизация задействована почти во всем программном обеспечении, мне было любопытно, как инструменты/системы, предназначенные для работы независимо от людей, могут способствовать, помогать или иным образом участвовать в инцидентах, когда программное обеспечение не работает так, как задумано или ожидалось — такие вещи, как конвейеры развертывания CI/CD или автоматическое масштабирование модулей Kubernetes. Мой интерес к исследованию роли автоматизации в инцидентах с программным обеспечением возник как из множества историй и анекдотов, которые я знаю от людей из сферы SRE и реагирования на инциденты, так и из наблюдения за тем, как ИИ продолжает доминировать в технических обсуждениях, инструментах и продуктах.
Исследования в других областях, таких как авиация, продемонстрировали ряд мифов и неправильных представлений о том, как автоматизация способствует несчастным случаям в этих областях, и я решил проверить, справедливо ли это для инцидентов с программным обеспечением. Основное заблуждение при изучении автоматизированных кабин и пилотов заключается в предположении, что автоматизация должна заменить работу, которую выполняют люди.
Это заблуждение было описано в исследованиях человеческого фактора как «функциональное распределение путем замещения» или «миф о замещении», продвигая идею о том, что все, что нам нужно сделать, — это дать компьютерам и людям отдельные задачи в соответствии с их сильными сторонами. Миф о замещении относится к ошибочному предположению, что автоматизация может просто заменить человеческие функции в системе, не меняя фундаментально то, как работает система или человеческая работа.
Это заблуждение основано на таких предположениях, как HABA-MABA («Люди лучше / машины лучше»), которые предполагают, что сильные стороны человека и машины фиксированы, а проектирование системы – это просто вопрос соответствующего распределения задач (Деккер, Сидни и Вудс, Дэвид. (2002). MABA-MABA или Абракадабра? Прогресс в координации взаимодействия человека и автоматизации. Познание, технологии и работа. 4. 240-244)
Деккер и Вудс утверждают, что этот подход, основанный на замещении, терпит неудачу, потому что:
- Автоматизация не просто заменяет существующие задачи, она трансформирует человеческий труд, создание новых задач, ролей и задач.
- Эти изменения часто носят качественный и непредсказуемый, а не только количественный характер.
- Вера в простую замену приводит к плохим проектным предположениям, игнорирует потребности в координации и упускает из виду, как реальная человеческая работа адаптируется на практике.
Их исследование показало, что автоматизация, вопреки этим преобладающим убеждениям, часто способствует инцидентам и несчастным случаям непредвиденным образом, налагая неожиданную нагрузку на людей, ответственных за надзор или взаимодействие с ней.
Непредвиденные последствия автоматизации
То, что мы увидели в отчетах об инцидентах с программным обеспечением от VOID, отражает то, что Деккер и Вудс сформулировали выше. Мы обнаружили, что автоматизация способствует возникновению инцидентов по-разному, часто в одном инциденте по-разному! Автоматизация может быть фактором, способствующим возникновению инцидента, она может предупредить людей об инциденте, она может (очень редко) решить инцидент самостоятельно и, к сожалению, также может затруднить решение инцидента для людей, чем если бы автоматизация отсутствовала изначально.
Пожалуй, самым публичным примером этого была ситуация, когда сотрудники Facebook не смогли попасть в свои собственные центры обработки данных во время крупного сбоя в работе в 2021 году. Через их систему автоматически распространилась команда, которая непреднамеренно отключила все соединения в их магистральной сети, фактически отключив центры обработки данных Facebook по всему миру. Это привело к проблеме с DNS, из-за которой остальная часть Интернета не могла найти свои серверы, а также потребовалось дополнительное время для активации протоколов безопасного доступа, необходимых для того, чтобы сотрудники Facebook могли находиться на месте и иметь возможность работать на серверах.
В частности, мое исследование выявило множество закономерностей, которые исследовательница Лисанн Бейнбридж сформулировала в своей основополагающей статье. Ирония автоматизации. Вот некоторые из шаблонов:
- Проектирование только для желаемых результатов
Разработчики автоматизации склонны представлять себе желаемые результаты автоматизации (например, меньшую рабочую нагрузку, более высокую точность) и что только те желаемые результаты произойдет. В качестве примера возьмем всю арену «ошибок конфигурации»: конвейер CI/CD хорош до тех пор, пока он не выпустит изменение, которое приведет к сбою всей системы, без каких-либо признаков того, что может произойти что-то неладное.
- Непредвиденные негативные последствия
Автоматизация не имеет доступа ко всем реальным параметрам для точного решения проблем во всех контекстах и фактически может сделай это сложнее чтобы люди могли напрямую влиять на систему так, как они хотят, когда возникают непредвиденные негативные последствия автоматизации. Штормы повторных попыток — отличный пример этого в действии, когда автоматизация делает то, для чего она была предположительно предназначена, но в экстремальных обстоятельствах это может значительно усугубить проблему. Прервать этот процесс редко бывает тривиально.
- Деквалификация в сочетании с пассивным мониторингом
Людям по-прежнему приходится следить за тем, чтобы автоматизация работала правильно, но зачастую им не хватает знаний или контекста о том, как автоматизация должна функционировать, чтобы знать, работает ли она на самом деле правильно или нет. Это связано с тем, что правильное знание системы и того, как в ней работает автоматизация, требует частого использования и ознакомления с ее работой в различных сценариях. Этот тип знаний развивается только посредством практической, практической обратной связи с рассматриваемой системой, насколько она эффективна, а также где и когда возникают крайние случаи или неожиданные результаты. Если вы когда-либо смотрели на панель предупреждений, не понимая, что именно происходит с незнакомой вам системой, вы, вероятно, испытали это на собственном опыте.
- Новые, неожиданные формы человеческого труда
Когда автоматизированная система выходит из строя, объем знаний, необходимый для восстановления работоспособности, вероятно, больше, чем требуется при нормальной работе. Это создает немедленные, новые и многочисленные элементы работы. Поскольку разработчики систем автоматизации не могут полностью автоматизировать человеческие «части», человеку приходится справляться с тем, что остается после того, как автоматизированные части ведут себя не так, как ожидалось, оставляя после себя еще большую сложность.
- Отсутствие прозрачности активности автоматизированной системы.
Автоматизация создает системы, которые требуют от людей предоставления информации, выходящей за рамки известных инструкций (например, руководств). Чтобы отладить систему с автоматизацией, необходимо понимать не только систему в целом, но и автоматизацию, а также то, что она должна делать и почему она делает это неправильно. Это принципиально более сложная задача, чем без автоматизации! Это часто проявляется в отдельных источниках или хранилищах опыта, например, когда Эми, эксперт по Кафке, уходит в отпуск, никто другой не знает тонкостей вопросов ребалансировки потребителей так, как она.
Как совместные когнитивные системы лучше поддерживают людей, работающих с автоматизацией
Совместная когнитивная система (JCS) — это система, в которой люди и машины работают вместе, основываясь на принципах общие познавательные усилияа не просто разделять работу между людьми и машинами отдельно. Вместо замены человеческого труда JCS выступает за превращение автоматизированных компонентов в эффективных «командных игроков», которые могут дополнять и поддерживать человеческий труд.
В исследовании, проведенном Гэри Кляйном и его коллегами, они описывают 10 ключевых аспектов этой совместной деятельности коллективно как:
«… соглашение (часто молчаливое) об облегчении координации, работе над достижением общих целей и предотвращении сбоев в координации команды. Это… предполагает приверженность определенной степени согласования целей. Обычно это влечет за собой смягчение одним или несколькими участниками своих собственных краткосрочных целей, чтобы обеспечить возможность достижения более глобальных и долгосрочных командных целей».
Здесь слишком сложно рассмотреть все десять ключевых элементов, но стоит отметить, что для того, чтобы согласовать эту цель (и скорректировать ее с течением времени), те, кто работает вместе, должны:
- Будьте взаимно предсказуемы в своих действиях
В сильно взаимозависимых задачах, таких как операции с программным обеспечением, мы можем эффективно планировать свои действия только тогда, когда можем точно предвидеть действия других. Квалифицированные команды достигают такой предсказуемости благодаря общим знаниям и собственным механизмам координации, которые со временем развиваются в результате широкого сотрудничества. Несмотря на распространенный рефрен о «человеческой ошибке» в инцидентах, в целом люди вполне предсказуемы в своей работе, и мы наладили средства проверки, если что-то кажется непредсказуемым (звонок, чат, электронная почта и т. д.). Таким образом, в конечном итоге эта цель на самом деле больше связана с тем, чтобы автоматизация стала более предсказуемой (и чтобы у людей были лучшие способы «видеть», что с ней происходит).
- Будьте взаимно управляемыми
Быть управляемым — это способность сознательно оценивать и модифицировать действия других сторон в условиях сотрудничества по мере изменения ситуации и приоритетов (очень распространенная реальность для команд разработчиков программного обеспечения). Эффективная координация требует адекватного реагирования команды на действия друг друга по ходу работы.
- Поддерживайте общий язык
Это действительно ключевой атрибут хорошо отточенной JCS. Общая основа отражает соответствующие знания, убеждения и предположения что все вовлеченные стороны разделяют, что позволяет каждой стороне понимать общение, которое помогает координировать совместные действия. Разрушение взаимопонимания иногда может привести к потенциально катастрофическому нарушению функционирования команды.
Теперь, если вы думаете: «Ну, я не знаю ни одной автоматизированной системы, которая бы это делала!» тогда ты не одинок, потому что я тоже. Пока нет. мне очень интересно кое-что недавняя работа в этой области от Honeycomb. Кажется, они понимают многие принципы, которые я описал выше, и могут сформулировать, почему (а почему бы и нет) использовать LLM и ИИ:
«По мере того, как написание кода становится все проще и проще, понимание кода становится все сложнее и сложнее. Написание кода никогда не было самой сложной частью разработки программного обеспечения; его всегда приходилось эксплуатировать, поддерживать и повторять. Чтобы по-настоящему повысить производительность, ИИ должен будет лучше помогать нам в этих вещах».
Я, конечно, надеюсь, что все больше разработчиков автоматизированных (и основанных на искусственном интеллекте) инструментов и систем будут учитывать подобные принципы в своих проектах, чтобы сделать автоматизацию более эффективным командным игроком и помочь нам лучше работать самостоятельно. Меня часто спрашивают, решит ли «лучший ИИ» эту проблему за нас, и мой ответ всегда один и тот же: если люди, разрабатывающие инструменты ИИ, не принимают во внимание эти общие когнитивные факторы, то нет, не будут. Это только усугубит масштабы и скорость, с которой людям придется снова решать те же самые проблемы.
Если люди заинтересованы в получении дополнительной информации, я помог запустить Устойчивость в Software Foundationразнообразное междисциплинарное сообщество, занимающееся решением подобных проблем в нашей отрасли.
Многие из моих (и других) исследований показывают, насколько недооценена и неправильно понята роль, которую человеческий опыт играет в программном обеспечении. Меня всегда восхищал человеческий опыт: как мы его приобретаем, как он выглядит (и ощущается) в действии и насколько эфемерным он может иногда казаться. После того, как оно создано, его легко принять как должное, и его нельзя просто клонировать и систематически масштабировать. Поскольку машина искусственного интеллекта постоянно движется вперед, я искренне надеюсь, что мы продолжим инвестировать в человеческий опыт, который поддерживает работу наших систем.
#Исследование #непредвиденных #последствий #автоматизации #программном #обеспечении
По теме
