Аналогично. Вообще, методика PERT , насколько я знаю, подразумевает формирование сетевого графика работ. И, соответственно, этапы работ привязываются к ресурсам (хотя бы к их классам). А вот что дальше делать, было бы здорово узнать.
А разве космическое излучение не по одной штуке прилетает (т.е. одна сработка детектора)? Или всплеск сработок означает, что где-то рядом с датчиком происходит каскад ядерных реакций и от многих из них ионизирующие частицы прилетают в детектор?..
Замечали ли вы сигналы без очевидных причин (к примеру, всплеск сработок, когда прибор лежит дома)? От чего такие сигналы могут быть? В авто по дороге провезли источник? Сосед собирает рентгеновскую установку?
В итоге, как звонили без маркировки со спамом, так и звонят. Особенно с пулов Билайна (969). Полез смотреть, как с этим бороться - а никак, т.к. штрафов или каких-то санкций за отсутствие маркировки нет. Получается возня с ней была имитацией бурной деятельности...
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Ушел единственный DevOps-инженер, который знал конфигурацию отказоустойчивости кластера. Кластер упал при обновлении, подняли только через 36 часов.
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Специалист по Oracle уволился, не передав доступы к мониторингу.
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
Новая команда поддержки не могла найти документацию по старому сервису.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Инженер заболел, но только у него был договор с подрядчиком на оборудование.
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как". Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя" быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
«какую проблему пользователя мы решили» и «какой бизнес-метрике это помогло»
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
Аналогично. Вообще, методика PERT , насколько я знаю, подразумевает формирование сетевого графика работ. И, соответственно, этапы работ привязываются к ресурсам (хотя бы к их классам). А вот что дальше делать, было бы здорово узнать.
Не надо уточнять "в главной ветке, а в какой ? В develop?"
Основная причина - это ситуация, описанная в армянской сказке про кучу шапок из одной шкурки. И предотвратить её малореально...
Там, если что, такое выводится только при открытии со смартфона. С десктопа обещают доступ через браузер.
Либо пассивный залог для форт-подобных языков:
5 6 складывается вСтроку выводится
А разве космическое излучение не по одной штуке прилетает (т.е. одна сработка детектора)? Или всплеск сработок означает, что где-то рядом с датчиком происходит каскад ядерных реакций и от многих из них ионизирующие частицы прилетают в детектор?..
Замечали ли вы сигналы без очевидных причин (к примеру, всплеск сработок, когда прибор лежит дома)? От чего такие сигналы могут быть? В авто по дороге провезли источник? Сосед собирает рентгеновскую установку?
В итоге, как звонили без маркировки со спамом, так и звонят. Особенно с пулов Билайна (969). Полез смотреть, как с этим бороться - а никак, т.к. штрафов или каких-то санкций за отсутствие маркировки нет. Получается возня с ней была имитацией бурной деятельности...
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как".
Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя"
быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
В смысле, задачу можно было решить только сверхурочно? Почему бы время на неё не учитывать в рамках задачи?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Да, но не только.
Спасибо за ответ - интересный путь!
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Если автор по должности инженер, то техдир будет валить на него - типа, не предусмотрел.
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...