Заголовок тогда неудачный, да. В нём прямо написано, что вы видите проблему не в сватьях и братьях, а в KPI. Я видел успешное внедрение KPI в продажи и участвовал даже в этом немного. Что конечно не говорит о том, что надо бездумно во все продажи и на всех этапах развития бизнеса KPI внедрять.
А зачем у вас сначала рушится общий пайплайн у всех, а потом чинится группой подозреваемых? Почему нельзя в общую ветку MR принимать только после зеленого пайплайна по этому MR?
Есть несколько вариантов структур управления, один из них — «матричная структура управления». Скорее всего у вас «QA Engineer» в команде должен иметь «двойное подчинение» — команде/тимлиду и «QA Tech Lead». Так вы сможете получить и максимальную интеграцию QA в разработку и единого ответственного за организацию QA в компании.
Думаю вы сами выдвинули утверждение, что канал доставки герметичных пакетиков (т.е. в исходной задаче — исходного объема соли в солонку) уязвим к чему-либо и сами пытаетесь эту проблему решить.
Это просто совсем другая задача, хотя наверное тоже интересная. Для эксплуатации этой уязвимости уже могут потребоваться какие-то «привилегии» (устроиться кладовщиком).
В том числе это может быть уязвимость уже не относящаяся к столовой. Как не относится к уязвимости ОС то, что в ней можно запустить трояна и дать ему все права.
Ну я отвечал на ту задачу и в той формулировке, которую указал ITurchenko, решение — одноразовые герметичные пакетики, выдаваемые на кассе. Очевидно обычному потребителю в пакетики подсунуть что-то — это надо чтобы кассир принял пакетик и вручил следующему потребителю. Хочется строгости — можно проинструктировать кассира не брать герметичные пакетики обратно и повесить объявление о том, что не надо брать со стола какие попало пакетики.
Видимо после слово «хакер» у вас включился контекст информационной безопасности со всеми накопленными аналогиями. Атака, вектор атаки, пользователи, вот это всё. А между тем в задаче этого ничего нет.
PS: Одноразовый пакетик на кассе безусловно не равен солонке на столе, как и запечатанный специальный конверт с пинкодом к банковской карте выдаваемый банковским сотрудником не равен открытому обычному конверту с пин-кодом валяющемуся на столике для посетителей. Хотя безусловно тот и другой «не закрывает все векторы атаки».
Почему ошибся? Я отвечал про «не закрывает все векторы атаки».
Задача была конкретная (без всяких «и так далее»), решение на неё названо. Если под этой задачей вами понимается не то, что там было выше написано, то мы с вами говорим про разные задачи.
Давайте еще на ходу теперь придумаем, что это теперь не хакер, а грабитель, или вообще метеорит, который летит к земле. Может всё-таки будем оставаться в рамках исходной постановки задачи?
С очень большой вероятностью либо программист уже тут не работает, либо никогда и не работал, а это какая-нибудь платформа/фреймворк, где в документации сказано, что за логами надо следить.
А надо было не оператора уволить, а премии лишить хотя-бы частично того, кто организовал процесс эксплуатации ИТ-системы без защиты от элементарных вообще-то вещей.
Тут вся соль ситуации в том, что заказчику нужен был не только бэкап БД, и они как эксперты предлагали по сути НЕ бэкап. И только Лёня как раз предлагал решение наиболее похожее на бэкап БД, но которое НЕ решало одну из важнейших проблем заказчика.
При этом автор пишет про «страшное недопонимания внутри их команды», а я из статьи вижу «страшное недопонимание» в треугольнике заказчик-Лёня-автор.
Спасибо, нашел это в статье, и правда автор сохранять хотел входящий поток.
Но вот только это не бэкап. Обычно это вроде логом или журналом называют.
Это не взаимозаменяющие вещи и бывает так, что нужно и то и другое. И если бы автор эти две темы развел с самого начала, то его предложению скорее всего никто бы не сопротивлялся.
Не удивлён, что автор получил негативный опыт, при таких коммуникациях с заказчиком.
2. Не факт. Среда не идеальна.
Это просто совсем другая задача, хотя наверное тоже интересная. Для эксплуатации этой уязвимости уже могут потребоваться какие-то «привилегии» (устроиться кладовщиком).
В том числе это может быть уязвимость уже не относящаяся к столовой. Как не относится к уязвимости ОС то, что в ней можно запустить трояна и дать ему все права.
Видимо после слово «хакер» у вас включился контекст информационной безопасности со всеми накопленными аналогиями. Атака, вектор атаки, пользователи, вот это всё. А между тем в задаче этого ничего нет.
PS: Одноразовый пакетик на кассе безусловно не равен солонке на столе, как и запечатанный специальный конверт с пинкодом к банковской карте выдаваемый банковским сотрудником не равен открытому обычному конверту с пин-кодом валяющемуся на столике для посетителей. Хотя безусловно тот и другой «не закрывает все векторы атаки».
Задача была конкретная (без всяких «и так далее»), решение на неё названо. Если под этой задачей вами понимается не то, что там было выше написано, то мы с вами говорим про разные задачи.
И за логами надо следить, чтобы они не переполнялись. Это прям азбука.
При этом автор пишет про «страшное недопонимания внутри их команды», а я из статьи вижу «страшное недопонимание» в треугольнике заказчик-Лёня-автор.
Но вот только это не бэкап. Обычно это вроде логом или журналом называют.
Это не взаимозаменяющие вещи и бывает так, что нужно и то и другое. И если бы автор эти две темы развел с самого начала, то его предложению скорее всего никто бы не сопротивлялся.
Не удивлён, что автор получил негативный опыт, при таких коммуникациях с заказчиком.
Бэкап вроде должен просто восстановить состояние БД на продакшене, то есть те же 67%