Комментарии 77
Если интересны детали, то это история очень хороша описана во второй части автобиографии Фейнмана("Какое тебе дело до того, что думают другие?").
Кто нечитал - очень рекомендую, замечательные книги(первая-"Вы, конечно, шутите, мистер Фейнман!")
"Вы, конечно, шутите, мистер Фейнман!" это лучшее что я читал, в ней есть все: юмор, жизненные уроки, мотивация и биография одного из самых интересных и умных людей 20го века
Безусловно, прекрасная книга и, собственно, личность выдающегося ученого.
Но вот мне из трех жизнеописаний великих физиков (вторая - про Л.Д. Ландау) более всего мне импонирует личность и биография Роберта Вуда. Субъективно, Фейнман постоянно старается выглядеть простаком. Вуд более непритворный. Ну а Ландау - это Ландау.
Здесь вкратце, в Сети полнее: https://elementy.ru/nauchno-populyarnaya_biblioteka/435110/Robert_Uilyams_Vud
Да, книги тоже отличные. Мне из первой запомнилась история, как он преподавал в Бразилии, не зная португальского - очень похоже на мой опыт в Латине без испанского.
Фейнман - безусловно умный человек, один из умнейших своего времени. Однако, я помню с каким удовольствием сел читать "Вы, конечно, шутите...", и в каком шоке я был по окончании прочтения. Я не знаю, каким человеком он был на самом деле, но в книге он показан "многогранной неординарной личностью" без каких либо признаков эмпатии. Если это правда, то это просто страшно, находиться рядом стаким человеком. Хотя, возможно, гениям многое прощают.
Ну, быть мудаком социопатом - не преступно. С другой стороны, работать над штуками типа манхэттенского проекта, обладая развитой эмпатией, было бы, предполагаю, ужасно некомфортно, так что в таких отраслях есть некоторое давление среды, естественный отбор.
>по книжке "Вы, конечно, шутите..." трудно судить о человеке, насколько знаю он вполне адекватный был, конечно не без причуд, почитайте более-менее полную биографию к примеру, может измените мнение
ps
когда его попросили этой катастрофой заняться, он уже больной был, типа знал что немного осталось, на обезболивающих лекарствах находился, но таки сделал что мог, без него вероятно не нашли бы причину так быстро, просто к сведению о человеческих качествах
Не сказал бы, что ему за это были сильно благодарны: его выводы вовсе не хотели включать в отчет, и согласились на "особое мнение" (которое официально не обязательно принимать во внимание) только после того, как он пригрозил со скандалом выйти из комиссии.
>Не сказал бы, что ему за это были сильно благодарны
еще бы, типа один против большинства, не могли поверить пока не показал публично что делается с уплотнением при достаточном охлаждении, но не в этом дело, по большому счету именно он предложил наиболее реальную версию, это позволило быстро усилить уплотнение и продолжить полеты,
конечно и этим в том числе он в памяти остался, вообще его работы по физике очень сильные были, стоит взглянуть, если интересуетесь, ну а про его лекции по физике типа все знают, у меня до сих пор на полке
ps
вообще довольно интересный site, откуда оригинал пришел, там много чего стоит посмотреть
Шредингер в 40 лет вообще жил с 14 летней девочкой и ничего.
Я не знаю, каким человеком он был на самом деле, но в книге он показан «многогранной неординарной личностью» без каких либо признаков эмпатии.Неожиданный вывод, вообще не соответствующий тому, что я там прочел. А на чем такой вывод основан, не развернете? Честно, очень интересно.
В этой книге есть и "Особое мнение", так что перевод уже был ;)
>Факт, что некоторая неисправность не привела к катастрофе в прошлом, часто принимается в качестве аргумента в пользу “безопасности” полетов с этой неисправностью, и очевидные проблемы проявляются снова и снова, часто вовсе без попыток их исправить или отложить полет.
Именно - это аналог "я столько раз заходил в сарай с сеном с горящей сигаретой и пожара не было".
Это логика менеджеров. У них же нет инженерного образования - вот они и принимают решения на основе своей логики.
Сложный вопрос, как построить управление проектом так, что бы в ключевых точках (безопасность например) окончательное решение было за инженерами, а не за менеджерами.
Справедливости ради, инженеры тоже таким страдают частенько. Может, не очень хорошие инженеры, но все же. Работает - не трогай!
Работает - не трогай!
Это все таки другое. Оно работает в этом случаи это:
- ничего не поломано
- нет предпосылок к тому что что-то сломается
Да не понятно как это работает, но оно работает поэтому лучше не трогать
Но если мы не понимаем более-менее точно, как работает - откуда можем быть уверены, что работает не на пределе возможностей и завтра не сломается? Те же трещины, описанные Фейнманом - можно, как оказалось, рассматривать не как угрозу безопасности, а как просто дополнительный пункт в протоколах обслуживания. Если мы не изучили досконально свойства материала при сверхнизких температурах в атмосфере кислорода - мы не знаем точно, как там распространяются трещины. Проблема не в том, что "на самом деле" они опаснее или безопаснее, чем решило НАСА; проблема в том, что это решение было принято гораздо более "от балды", чем следовало бы.
думаю, что "не трогай" всё же следует понимать как "не вмешивайся бездумно".
Для примера возьмём те же лопатки. Допустим, есть другой сплав, который в среднем меньше трескается, чем текущий. Если бездумно начать изготавливать лопатки из нового сплава, то в голову приходят следующие проблемы:
1) именно эта причина возникновения трещин разрушает новый сплав быстрее, чем старый;
2) новый сплав быстрее корродирует от топлива.
Да вообще, любое воздействие, которое на старый сплав не влияло. "Ошибка выжившего".
И "ошибка выжившего", и прочие когнитивные искажения, да. Многие из них основаны на том, что человеку комфортнее работать с тем, что он видит и знает. У нас в команде как-то раз было "давайте возьмем тул Х, потому что его команда лучше знает" - вроде бы логично, но через несколько месяцев все инженеры, которые знают Х - по очереди ушли, а для остальных "внезапно" порог входа, про который никто не подумал при выборе, оказался высоковат. Bus factor практически в чистом виде.
Работает - не трогай!
Этот принцип вовсе не про то, что вы писали. Он именно про отсутствие необходимости бездумных изменений в то, что уже и так работает и его работа всех устраивает.
Допустим, у вас есть программа, которая выполняется за 10 000 тактов процессора. Эта скорость работы всех устраивает, стабильность работы выше всяких похвал и нареканий по существу вообще нет. Приходит человек с горящими глазами, говорит "я знаю как сделать так, чтобы она начала работать за 9 000 тактов!", его никто не останавливает и тут возможны два варианта:
1) Оно действительно начинает не менее стабильно работать за 9000 тактов.
2) Оно не работает/работает не всегда и вываливается/при определенных ситуациях работает за 90 000 тактов. В итоге проблемы с другими программами, всё встало и судорожно начинают чинить.
Принцип "работает - не трогай" как раз отсекает подобные ситуации рискОвых изменений в гарантировано работающие системы ради извлечения никому не нужной выгоды. То есть в конечном итоге предотвращают работу ради работы с риском уложить всё.
Это я вам как инженер говорю.
P.s. Наиболее вероятно вы возразите что "возможно существуют ситуации в которых сломается и старая программа" и действительно такие ситуации возможны. Проблема в том, что проводя ненужные изменения мы увеличиваем риски возникновения таких ситуаций, а не уменьшаем. Так как старая программа к этому моменту проверена во всех уже случавшихся сценариях использования, а новая это пока непаханое поле из граблей.
При этом в существующей программе есть known knowns (известные ограничения и архитектурные решения), known unknowns (техдолг и известные баги) и unknown unknowns (неизвестные баги), и сумма у них всегда 1.0. Т.е. если наш инженер подходит к этой легаси системе, и у него KK и KU около нуля ("бездумный подход"), то UU (ака поле из граблей) окажется очень большим. В реальности часто ситуация ухудшается тем, что человеку кажется, что он "в принципе" все понимает, но на самом деле нет.
Идеальная ситуация для рефакторинга же - когда KU довольно большое, но и KK тоже. Это позволяет трезво оценить и overhead (который рефакторинг помогает снизить), и риски. Другое дело, что неэффективное легаси редко когда бывает отлично задокументировано, включая процесс принятия решений и рассмотренные варианты.
Плюс недостаток полномочий, плюс субординация, плюс политика. Результат вполне можно обозвать той же фразой "работает - не трогай", только значение у неё гораздо менее позитивное выходит.
Программа в данном случае лишь аналогия.
Инженеры всё же обычно чуть другим занимаются и в их случае, даже если рассматривать крайне близкую к "гражданскому" программированию промышленную автоматику, KK и KU сами по себе не столь большие. Вернее в большинстве случаев KU ~ 0 так как установка функционирует, функционирует безостановочно (не считая выводы на ППР и прочее обслуживание) и никому не мешает, долгов не создаёт. KK тоже ~ 0 так как существенным ограничением может быть, разве что, невозможность интеграции установки. Или нехватка входов/выходов для модернизации.
Поэтому UU там всегда стремится к единице. Исходя из этой причины и не занимаются в промышленности обновлением ради обновлений (кроме некоторых ещё не наученных горьким опытом).
Плюс в данном случае есть огромная проблема с тестированием. Так как симуляторы хоть и есть, но без полноценного "виртуального двойника" они бессмысленны. Поэтому наладка ПО, в случае промышленной автоматики, всегда идёт на кошках. А это ещё и время простоя.
Поэтому применительно к инженерным системам "работает - не трогай" это скорее сродни "не трогай оголённые провода". То есть свод правил, соблюдая которые, ты не подвергаешь риску себя и окружающих.
KK это вообще все ограничения в работе установки, они всегда есть. Требования к питанию, к сырью, к управляющим сигналам.
С другой стороны - вот например, исследования уплотнительных колец во всяких интересных условиях не проводились, потому что ну вот система летает, все в порядке с ними там. А оказалось, что "работает" в этом случае означало "работает, но не всегда" - в реальности бывает нетривиально отличить одно от другого, и часто требует глубокого понимания работы системы.
Требования к питанию, к сырью, к управляющим сигналам
Новое питание не подвезут - ГОСТы, смена сырья ведёт или к смене установки, или к её глубокой модернизации (если она не рассчитана на новое сырьё), управляющие сигналы уже и так есть. Поэтому нет, это не считово.
С другой стороны - вот например, исследования уплотнительных колец во всяких интересных условиях не проводились, потому что ну вот система летает, все в порядке с ними там.
Мы говорим о несколько разных вещах. Для ракеты эти условия являлись нормальными условиями эксплуатации (или были ошибочно включены в них) поэтому нет, она всё же не была нормально проверена. У установки, которая работает вот уже десять лет при нормальных условиях эксплуатации баги уже не всплывают. А если ей подали другое напряжение/оно кончилось/запихали не то и не туда - условия перестают быть нормальными.
Так вся статья про то, что "нормально проверено" для разных людей с разным опытом может означать разные вещи. Для кого-то - работа на стенде двукратное время, для кого-то - год реальной эксплуатации экспериментальной установки, для кого-то вот "ну, мы уже 50 раз челноки запускаем, и пока ни разу не бабахнуло".
Так же и между "работает с большим запасом прочности", "работает на пределе возможностей" и "ведет себя странно, но почему-то до сих пор не сломалось" есть некоторая разница в разрезе "не трогай". Причем, в последнем случае "не трогай" даже чаще встречается, потому что любое вмешательство может вывести систему из этого хрупкого равновесия, да и ответ на вопрос "так, кто последний систему трогал?" инициатора изменений явно не обрадует, даже если проблема вызвана не ими.
Так вся статья про то, что "нормально проверено" для разных людей с разным опытом может означать разные вещи.
Мы с вами про промышленность. Установки работает в круглосуточном или окологрулосуточном режиме.
То есть время, сравнимое с полётами всей программы Шаттл (имеется ввиду активная фаза работы ускорителей) они пройдут меньше, чем за месяц.
"работает на пределе возможностей"
Для подавляющего большинства промышленных установок, особенно электрических, это диагностируется очень просто и с высокой степенью достоверности.
Для установки, которая работает круглосуточно, и требования к наработке на отказ несколько повыше, чем к SSME.
Похоже, вы имеете в виду "установки" в довольно узком смысле. Я же - всё, от розетки у меня дома и до пресловутых SSME.
Похоже, вы имеете в виду "установки" в довольно узком смысле.
Ну вообще я про промышленность, а "работает - не трогай" применяется обычно инженерами (обычно по эксплуатации) именно там. И даже несколько раз уточнил.
Если мы говорим про "вообще всё" то помимо всех возможных рисков уронить что-то в момент его трогания, надо оценивать и последствия от его потрогивания.
Инженерное образование, в большинстве, необходимое, но не достаточное условие для адекватности в принятии ключевых решений.
Ключевые окончательные решения от инженеров ничего не гарантируют.
Есть еще такая особенность, инженеры склонны преуменьшать важность не-функциональных требований: сроки, стоимость, вот это все. Поэтому в проекте нужен человек (один), который выслушает все заинтересованные стороны и примет решение. Как Королев, Фон Браун или вот сейчас Маск у себя - даже такой фрик, похоже, лучше, чем групповое принятие решений.
Групповое принятие решений никак не влияет на их качество. Наблюдал неоднократно лично, когда коллективное решение хуже индивидуального. Очень много зависит от состава группы и модератора.
Предыдущий комментатор это и имел ввиду. Недаром существует понятие design by committee.
"Успехи" Боинга, где такого центрального человека нет, и успехи SpaceX где такой человек, пускай и эксцентричный, есть - тому пример.
Это обычно так. А если еще группа - это представители разных коллективов, и каждый со своими интересами, то всё - туши свет... А в больших проектах это обычно так. В результате и получаются чудовищные компромиссные монстры.
Групповое принятие решений никак не влияет на их качество. Наблюдал неоднократно лично, когда коллективное решение хуже индивидуального. Очень много зависит от состава группы и модератора.
Групповое принятие решений, как показывает моя личная практика, всегда хуже индивидуального. По одной простой причине: ответственность.
В случае, если решение принимается индивидуально, сказать "так я тут не виноват, меня вообще подговорили и Федька так сказал" хоть и получится, но будет звучать максимально глупо. При принятии решения человек (если он, конечно, осознаёт важность своего решения и его последствия) будет более скрупулезно взвешивать все "за" и "против".
В случае группового принятия решений, ответственность за них размазывается по группе лиц. Персональная ответственность отсутствует как факт, а срабатывающие механизмы самоуспокоения твердят под нос "Да Федька там громче всех кричал и бил себя пяткой в грудь что все ОК будет". А при больших размерах группы какие бы то ни было мысли об ответсвенности за это решение отсутствуют: "Проголосую как большинство решит, а сам разбираться не буду".
Поэтому нет, ответственный должен быть только один. Что за выполнение задачи, что за принятие решений.
"Хуже-лучше" это одно измерение, в реальности же их несколько. Например, при принятии решений в одно лицо оказывается гораздо проще облажаться с документированием этого процесса - если не целиком забить, то уж пропустить "неважные" части внутреннего диалога вообще обычное дело. А в итоге бам! bus factor == 1
С другой стороны Н1 так и не полетела и виноват в этом тоже Королев. По хорошему принятие решений должно быть отделено от их выработки, но найти такого человека очень сложно - обычно у него или не будет компетенций и тогда решение будет базироваться на симпатиях и чуйке или же у него будет собственное мнение и тогда любые аргументы могут быть отвергнуты и снова в деле чутьё а не логика. Интересно как у Маска с этим обстоят дела.
Решение поставить кучу маломощных двигателей было принято Королёвым. И двигатели эти разрабатывались под конкретную ракету, он мог принять решение разрабатывать мощные движки, не делать 5 ступеней итд однако что вышло то вышло. Мой посыл был не в том, что Королёв виноват что Н1 не взлетела, а в том что даже визионеры с отличным послужным списком могут ошибаться по крупному.
Но если его виной считать неверно принятые решения (мне не очень тут нравится это слово, все же это ошибки, но не вина, потому что решения всегда принимаются в условиях неопределенности, и основаны на прогнозах, и не всегда вина человека, что прогнозы эти не точны). Ну да, в провале проекта всегда в большей степени виноват генеральный конструктор, просто потому, что он принимает самые важные решения, и если они неверные — исправить это уже зачастую нельзя.
Падала то Н1 не из-за маломолощности движков и не из-за наличия 5 ступеней.
Проблема в тестировании
Поскупились на стартовый стол поменьше чтоб отработать запуск например связки трёх ступеней из пяти. Наработали бы статистику и опыт и времени меньше б ушло чем на год останавливать полеты после взрыва
Профукали всё с тестированием движков. Очень ограниченные тесты были, ещё и методом случайной выборки. Военные традиции какие-то.
Система управления КОРД была сырая и корявая и как показали полёты себя не дискредитировала
Мне кажется, тут основной фактор - что у Королева был карт-бланш на средство доставки ядерной бомбы (ой, то есть, я хотел сказать, на Спутник и Гагарина), а когда дошло до Луны - сменился генсек и военные приоритеты, сам СП умер, начался "передел рынка" между ракетными и двигательными КБ, а пока вот это вот всё - Фон Браун со своим карт-бланшем добрался до Луны, и политическая ценность программы Н-1 резко упала.
Для принятия правильного решения нужно уметь задавать правильные вопросы, а тут нужны как собственный опыт, так и быстрый аналитический ум, чтобы моментально распознавать BS в презентациях.
Есть еще такая особенность, инженеры склонны преуменьшать важность не-функциональных требований: сроки, стоимость, вот это все.
Сроки и стоимость это как раз функциональные требования. Они вполне измеримы и понятны. Их появление и образование тоже может быть адекватно объяснено. Могут не обращать на них внимание или склонные к излишнему перфекционизму люди, или те, кому сказали "сделай идеально" без более детальных пояснений.
Вот некая сферическая эргономика, непонятный дизайн и позиционирование на рынке уже непонятны.
А цена и сроки реализации включены в требования любого ТЗ.
Включение требования в ТЗ не делает его функциональным. Функциональные требования - это описание взаимосвязей между входами и выходами системы, ответ на вопрос: "Что должна делать система?" Нефункциональные - описание самой системы (и, если надо, процесса разработки), ответ на вопрос: "Как она должна это делать?"
То есть, качество кода, производительность, отказоустойчивость, сроки разработки и цена - это все нефункциональные требования.
У Фейнмана отличная аналогия с "русской рулеткой". А самая наглядная из повседневной жизни - "я столько раз на "красный" переходил - и ничего, живой и здоровый".
Касательно программы "Space Shuttle" - ровно та же история повторилась потом с "Коламбией". Имеющаяся и хорошо известная проблема (отрыв части плиток) и уверенность, что раз ничего не случалось раньше - то не случится и дальше. Более того - в одной из миссий (STS-27) экипаж шаттла провёл полёт, как на иголках, так как знал, что теплозащита повреждена, причём, возможно, в критичном месте. Но с земли пришёл ответ, типа: "не загружайте себе голову, мы думаем, что ничего с вами не случится". После приземления были констатированы серьёзные повреждения от воздействия температуры, но на проблему забили ещё на 15 лет, вплоть до последнего полёта "Коламбии".
Режим зануды он
Русская рулетка - да, это ближе. При выполнении действия (явно разрешенного) всё нормально до определенного момента. Этот момент можно вычислить (в реальности - не всегда).
Красный светофор - это явное запрещение. Можно даже не знать почему именно. Но периодичность нарушения приводит к проблеме.
Режим зануды офф.
:)
ps
Про STS-27 не знал, спасибо.
На твердотопливных ускорителях стояли новые, более легкие, носовые обтекатели. И на 85 секунде полёта носовой обтекатель правого ТТУ стал разрушаться, и его осколки ударили по теплозащитному покрытию шаттла. Происходящее фиксировалось на наземные камеры и не осталось незамеченным. После выведения экипаж развернул манипулятор "Канадарм" с камерой и стал осматривать нижнюю поверхность "Атлантиса". Зрелище было неважным - плитки теплозащиты словно обстреляли из зенитного орудия (а командир Роберт Гибсон воевал во Вьетнаме и видел результат работы зениток). Но, странное дело, ЦУП Хьюстона не видел проблемы. Изображение с камеры передавалось по шифрованному каналу связи (напомним, это военная миссия), шифрование сильно снизило качество изображения, и инженеры на Земле решили, что повреждения являются всего лишь игрой света и тени. И, по совершенно непонятной причине, астронавтам, устно описывающим проблему, не поверили! Хуже того, ЦУП Хьюстона не предпринял никаких мер для получения дополнительной информации. За STS-27 не следили с Земли, не использовали спутники-шпионы, проблему посчитали незначительной. Посадка прошла нормально, но инженеров ждал неприятный сюрприз - при личном осмотре повреждения теплозащитного покрытия выглядели ещё хуже. "Атлантис" получил 707 ударов, пришлось менять от 125 до 175 плиток теплозащиты, а одна плитка с нижней поверхности вообще была сорвана, и алюминий под ней стал плавиться при торможении о плотные слои атмосферы. Астронавтам STS-27 повезло - именно на этом месте крепилась антенна, и корпус был толще обычного.
можно не играть в русскую рулетку, а можно заранее убедиться, что револьвер не заряжен
что именно имеют ввиду люди, которые говорят про переход на "красный"?
Угу. Хорошо говорить "мы думаем", когда сидишь в теплом ЦУПе, а не в консервной банке готовишься нырнуть в пекло.
С одной стороны менеджеры подгоняют, а технари делают "лижбыработало".
С другой, если бы не так, то никто никуда ещё очень долго не полетел..
Я удивлен, что не упомянут фильм "Челленджер" (2013 года), где как раз эта ситуация и описывается (Пост охватывает проблему несколько шире - но фильм не так уж далек от истины).
Буквально на днях читал это мнение в книге "Радость познания" (сборная солянка из лекций, статей и т.д. Фейнмана)
Надеюсь, Спейс Икс и Илон Маск в частности внимательно читали этот доклад.
Рекомендую к прочтению:
Верхом на ракете. Возмутительные истории астронавта шаттла | Майк Маллейн.
Подробно разобраны обе катастрофы шаттлов
НАСА обязано быть откровенным, честным и информативным перед гражданами, у которых оно просит поддержки, чтобы эти граждане могли принимать мудрые решения по использованию своих ограниченных ресурсов.
Золотые слова, но на российский чиновничий не переводятся :(
Компьютерная система "Шаттла" очень сложна, она содержит более 250 000 строк кода (ха-ха, прим перев).
Через 35 лет легко сказать "ха-ха". Глядя на совершенно другие языки программирования на двух тридцатидюймовых мониторах красиво расцвеченные редактором. Пайпалйн сборки, кучка тестов, система контроля версий, мощный компьютер для редактирования кода, stackoverflow.com и миллионные комьюнити. В таких условиях, конечно, "ха-ха". Хотя и сейчас 250 KSLOC интенсивной логики за месяц даже прочитать сложно.
Но вернёмся в 1970-1980-е годы. Странная дорогая железка (в данном случае вероятно речь о IBM AP-101), причём 99% времени у разработчика может и доступа к ней нет. Язык программирования, по сравнению с котором C - образец читабельности и структурирования (скорее всего HAL/S). Экран чёрно-зелёный 80х25 символов (а может и меньше). Памяти, конечно же не хватит чтоб просто загрузить в память все 250 KSLOC (хорошо, если 1 KSLOC влезет). Терминал компьютера, возможно, доступен по расписанию. Лучший способ читать код - распечатать и разложить закладки. Компиляция и сборка - целое событие. Тестирование в железке - эпохальное событие. Логи тестов, кстати, скорее всего не такие полные, как хотелось бы. Пошаговая отладка отсутствует. Нормальные дампы и инструменты анализа, возможно, тоже. Спеки на железку в печатном виде в коробке.
Уже и не "ха-ха"
Особое мнение Ричарда Фейнмана по гибели шаттла «Челленджер»