А разве космическое излучение не по одной штуке прилетает (т.е. одна сработка детектора)? Или всплеск сработок означает, что где-то рядом с датчиком происходит каскад ядерных реакций и от многих из них ионизирующие частицы прилетают в детектор?..
Замечали ли вы сигналы без очевидных причин (к примеру, всплеск сработок, когда прибор лежит дома)? От чего такие сигналы могут быть? В авто по дороге провезли источник? Сосед собирает рентгеновскую установку?
В итоге, как звонили без маркировки со спамом, так и звонят. Особенно с пулов Билайна (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? Из разработки, аналитики, ПМ/ПрМ?
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.
Там, если что, такое выводится только при открытии со смартфона. С десктопа обещают доступ через браузер.
Либо пассивный залог для форт-подобных языков:
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? Из разработки, аналитики, ПМ/ПрМ?
Если автор по должности инженер, то техдир будет валить на него - типа, не предусмотрел.
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.