Ironies of automation

В 1983 году когнитивный психолог Лизанна Бэйнбридж опубликовала статью "Ironies of automation"¹, о человеческом факторе в автоматизации. Статья – одна из наиболее цитируемых в области human-machine systems, о ней даже есть отдельная страница на википедии ².

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

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

Примеры зачастую полезнее объяснений

Я тут осознал, что сильно недооценивал роль примеров (examples) для технической документации. Документация очень сильно выигрывает от хороших примеров. Продуманные примеры могут быстро сориентировать читателя – ввести в курс дела, и облегчить понимание более детального описания. Более того, хорошо подобранные примеры способны сходу предоставить читателю (= пользователю) решение конкретной проблемы, без необходимости вообще вникать в детали. Вообще, кажется, есть много сценариев, где наиболее практичная документация == правильно подобранный набор примеров с краткой аннотацией.

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

Никто не читает документацию

В комментариях к передыдущему посту я спорил с этим утверждением, но потом порефлексировал над своим собственным опытом, и передумал: нет, и правда, почти никто.

Если аккуратнее: никто не любит читать документацию, никто не любит искать ответы на свои вопросы в документации.

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

Умение понятно писать – один из самых недооцененных инженерных навыков

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

Я сейчас не говорю о техническом писательстве как профессиональном навыке. Я говорю о более поверхностном – но и более универсальном – умении излагать свои мысли письменно, связно и понятно для читателя.

Конечно, есть миллион других навыков, которые не помешали бы инженеру, но я выделяю этот, потому что это low hanging fruit: большинство инженеров уже умеют думать, и уже хорошо разбираются в предмете. Не хватает, по-моему, малого – немного научиться думать о читателе.

What makes a rule complex (for brain): mechanical sympathy applied to humans

Интересная статья 2020 года: "What makes a rule complex?". Что делает правило (алгоритм) сложным для выполнения человеческим мозгом?¹

Мы часто оцениваем стоимость выполнения алгоритма: на какой-то абстрактной машине, или на реальном железе (конечном автомате, машине Тьюринга, Intel Core i7…). А что насчет человеческого мозга? Если смотреть на мозг как вычислительную машину, и скармливать ему разные "программы" – описания алгоритмов на человеческом языке – то насколько "дорого" для мозга будет выполнить действия соответственно описанию? Как цена выполнения алгоритма мозгом будет зависеть от устройства алгоритма?

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

Cores that don't count: "тихие" производственные дефекты процессоров

TL;DR: Инженеры гугла утверждают, что примерно 0.1% современных процессоров содержат дефекты, ускользнувшие от техконтроля производителя, из-за чего некоторые инструкции на таких процессорах втихую дают неправильный результат. Вероятно, доля таких производственных дефектов будет расти. Вероятно, пора отвыкать думать о процессоре как об идеальном вычислителе, и искать способы создавать такие программные системы, которые обнаруживают и компенсируют ошибки CPU.

В твиттере проскочил очень интересный доклад Питера Хошчилда (Peter H. Hochschild) из гугл на конференции HotOS 2021¹

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

Когда имеет смысл передавать IO в отдельный поток?

Допустим, у нас есть простая система, которая принимает запросы из сети, как-то их обрабатывает ("бизнес-логика"), и отправляет результат назад, в сеть. Мы заинтересованы в быстром отклике (=latency), а отправка – это IO, так что возникает идея ее снести в отдельный поток.

Но тогда придется передавать данные из основного потока в поток отправки – а межпоточная коммуникация это какие-то накладные расходы (копирование, инструкции синхронизации, т.п.)

Стоит ли вообще игра свеч, и если стоит – то когда?

Рабочие заметки в помощь мозгу

Давно уже хотел написать об этом, но только сейчас дошли руки:

Комрады! Пишите рабочие заметки – о чем вы думаете, над чем работаете – особенно если думаете о чем-то достаточно сложном. Это очень, очень, очень помогает думать! (И не только думать)

Вот уже несколько лет я практически все рабочие и личные задачи обсуждаю с большим файлом notes.txt (notes.org). Этот файл решает сразу несколько задач:

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

Queueing theory for fun and practice #3: системы с потерями

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

Какова должна быть посадочная вместимость приемной, чтобы не более 1 просителя в день ушло не солоно хлебавши, если пропускная способность Апполинария Матвеевича не более дюжины челобитных в день, а входящий поток около 10 челобитных в день?

TL;DR: реальные системы обрабатывают не все задачи – часть задач теряется или отбрасывается за счет ограниченности буферов и/или таймаутов. Потери делают систему устойчивой к перегрузке, и улучшают качество обслуживания тех задач, что дожидаются обработки – теряются более вероятно именно те задачи, которым пришлось бы ждать дольше всех. Системы с потерями – добро, делайте его больше.

(часть 3, предыдущая часть: нагрузка и время отклика)

Я уже упоминал, что система с бесконечной очередью, загруженная на 100%, будет давать неограниченное время ожидания. Однако на практике этого не происходит: есть немало систем, пропускная способность которых планировалась по максимуму, без запаса емкости – и которые, при этом, вполне приемлемо работают.

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

Два самых очевидных механизма потерь: либо очередь ограничена, и задачи теряются, когда она переполнена, либо задачи сами имеют какой-то внутренний TTL, и "уходят" из очереди, когда он превышен.

Queueing theory for fun and practice #2: нагрузка и время отклика

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

"Массовое окормление паствы: пособие для начинающих" (редакция 3-я, неизданная)

(Часть 2, начало: ТМО, square root staffing, Little)

Как зависит время отклика от нагрузки на систему (утилизации)? Для многих систем измерения дадут что-то вроде такой картинки:

Такую кривую зависимости среднего времени отклика от нагрузки за характерную форму часто называют J-curve. Конечно, не обязательно кривая в конкретной системе будет выглядеть точно так – например, могут присутствовать ступеньки, соответствующие разным механизмам, которые ответственны за время отклика – но в среднем такая кривая свойственна многим системам, и приводит к ней как раз наличие внутренних очередей/буферов.