уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
Аргумент про то, что прерывания рвут поток и тяжело вспомнить разбиваются о эффект Зейгарник, который о том, что мозг лучше всего запоминает незавершённые задачи.
Лично мне метод Помодоро очень помогает фокусироваться на главном в текущий момент. У меня во время него включается системный режим "не беспокоить" и звук тикания часов и это мне инженеру очень помогает не утопить день в переписках и общении.
Вы не заметили главного: тот факт, что вероятность события мала не отменяет возможности события и поэтому потребность в пропуске снаружи внутрь по умолчанию только ответного трафика никуда не девается. Это как с ограблением: и одного раза и не нужно. Если этот фильтр сохраняется для CPE с ipv6, то всё хорошо, за исключением ненужности ipv6 внутри моей локалки за счёт его машиноориентированности при администрировании. Ваша ситуация может отличаться.
значит ли это, что устройства стали недоступны? Долго, но реально, если интересно. А интерес вполне может быть ради ботнетов с участием каждой умной зубочистки и хитрого ёршика для бутылок
и конечно же никто не догадается делать это в параллельные 100500 потоков, размазав источники по ботнету и во времени. Я 10/8 параллельным nmap за 25 минут проходил в поисках принтеров с snmp-портом
если там есть default gateway прописанный руками или полученный от DHCP, то ответ наружу на маршрутизируемый адрес будет успешным. Другое дело, что по-умолчанию CPE таки не пропустит неинициированный ранее изнутри трафик снаружи внутрь, если нет проброса портов вовнутрь
зависит от настройки производителем фаерволла. Если там снаружи внутрь можно только умолчательное established/related, то всё ок, иначе провайдер имеет шанс добраться до Вашей любимой коллекции с понями на Вашем домашнем NAS при большом желании.
Да, Вы правы, с легального адреса на внутренний rp_filter пропустит. И да, Вы правы, по-умолчанию CPE обычно не пускают трафик снаружи внутрь за исключением related,established
ох уж это ситхианство с его абсолютом: "если нельзя идеально и навсегда, то значит никак нельзя и ничего делать не надо!" :) NAT это достаточно хорошо со многих сторон, включая простоту и дешевизну CPE, именно поэтому IPV6 до сих пор не в массах, хотя вроде бы о кончине блоков IPv4 уже 2 десятилетия говорят
удачи вам в поиске отдельных злых людей, квалификация которых позволит работать в интернет-провайдере за их зарплату и безнаказанно корёжить его ядро с сетью дистрибьюции и доступа только ради доступа к вашей персональной коллекции торрентов. А если вдруг вами действительно заинтересуются спецслужбы, то вы сами им всё на блюдечке принесёте и ещё и будете настойчиво интересоваться устроило ли их то, что вы принесли. Будьте проще: NAT это общественное благо, говорю это как работавший в ISP, в том числе в поддержке в тот момент, когда внешний трафик был помегабайтным и пользователи регулярно влетали в "я этого не качал, за что счёт 100500!?!?"
уверен, что каждый, кто приходил к стоматологу с идеями как поставить себе титановые челюсти для разгрызания тросов знает, какие эти стоматологи негодяи и токсики
менеджеры обычно неплохо понимают язык денег, когда фичи оцениваются деньгами на выбор: тогда они сами бегают и выбивают бюджеты или смиряются. Поэтому умение аллоцировать стоимость ресурсов на проекты часто здорово облегчает коммуникации после прохождения менеджерами этапа принятия.
Резануло глаз, поэтому позволю себе заметить, что DevOps, тот самый, который не человек, а методология, это больше всего про общение и совместное непрерывное нанесение ценностей работодателю и его пользователям, а не цепочка "должен, должен, должен", обёрнутая в ITIL с согласованными сроками рассмотрения.
Узкое место в том, что коммунальная инфраструктура должна строиться с учётом интересов всех команд и быть максимально гомогенной, прозрачной и управляемой и нужно хорошо в ней разбираться, чтобы переделывать и развивать её адекватным способом. Если просто дать рули разработчикам отдельных продуктов, то обычно она очень быстро потеряет все эти 3 качества, в том числе разделившись на много слабосовместимых контуров с разными подходами и технологиями. И по моему скромному опыту проблема усугубляется тем, что среднее время жизни разработчика на проекте около 1,5 лет и участники изменений из команд достаточно быстро меняются, а весь техдолг остаётся, накапливаясь. Как в переписке правильно заметили, часть девопсовой ответственности должна включать релизы продуктов, чтобы они не окукливались в обеспечении стабильности инфры и прикладов, каковая проще всего достигается остановкой изменений.
Действительно здесь махровая проблема с процессами и зонами ответственности. Как по мне, это частично лечится переведом части девопсов в продуктивные команды, чтобы поменять их приоритеты на командоориентированные, оставив пару на платформе. Тогда они уже сами между собой договорятся в интересах продуктов и платформы. Но да, сверху должен быть тот, кто будет смазывать их общение и не даст перетянуть одеяло на себя ни одной из сторон
Аргумент про то, что прерывания рвут поток и тяжело вспомнить разбиваются о эффект Зейгарник, который о том, что мозг лучше всего запоминает незавершённые задачи.
Лично мне метод Помодоро очень помогает фокусироваться на главном в текущий момент. У меня во время него включается системный режим "не беспокоить" и звук тикания часов и это мне инженеру очень помогает не утопить день в переписках и общении.
чтобы свич с линуксом подключить в поездке к внешнему телевизору или монитору, с ним надо тащить его огромную докстанцию?
про что и речь
если таскать портативный монитор, то macbook air уделает такую мобильность по всем фронтам, включая полноценность софта и железа
NAT это именно защита, но от случаев, когда защита не от провайдера. Защиты обычно эшелонированные и это просто один из эшелонов.
Вы не заметили главного: тот факт, что вероятность события мала не отменяет возможности события и поэтому потребность в пропуске снаружи внутрь по умолчанию только ответного трафика никуда не девается. Это как с ограблением: и одного раза и не нужно. Если этот фильтр сохраняется для CPE с ipv6, то всё хорошо, за исключением ненужности ipv6 внутри моей локалки за счёт его машиноориентированности при администрировании. Ваша ситуация может отличаться.
значит ли это, что устройства стали недоступны? Долго, но реально, если интересно. А интерес вполне может быть ради ботнетов с участием каждой умной зубочистки и хитрого ёршика для бутылок
и конечно же никто не догадается делать это в параллельные 100500 потоков, размазав источники по ботнету и во времени. Я 10/8 параллельным nmap за 25 минут проходил в поисках принтеров с snmp-портом
если там есть default gateway прописанный руками или полученный от DHCP, то ответ наружу на маршрутизируемый адрес будет успешным. Другое дело, что по-умолчанию CPE таки не пропустит неинициированный ранее изнутри трафик снаружи внутрь, если нет проброса портов вовнутрь
зависит от настройки производителем фаерволла. Если там снаружи внутрь можно только умолчательное established/related, то всё ок, иначе провайдер имеет шанс добраться до Вашей любимой коллекции с понями на Вашем домашнем NAS при большом желании.
Да, Вы правы, с легального адреса на внутренний rp_filter пропустит.
И да, Вы правы, по-умолчанию CPE обычно не пускают трафик снаружи внутрь за исключением related,established
Linux kernel rp_filter, т.к. большинство клиентских CPE на линуксе
cat /proc/sys/net/ipv4/conf/default/rp_filter
ох уж это ситхианство с его абсолютом: "если нельзя идеально и навсегда, то значит никак нельзя и ничего делать не надо!" :) NAT это достаточно хорошо со многих сторон, включая простоту и дешевизну CPE, именно поэтому IPV6 до сих пор не в массах, хотя вроде бы о кончине блоков IPv4 уже 2 десятилетия говорят
это вы каждой бабушке и каждой инстамодели предлагаете знать и уметь настраивать?
удачи вам в поиске отдельных злых людей, квалификация которых позволит работать в интернет-провайдере за их зарплату и безнаказанно корёжить его ядро с сетью дистрибьюции и доступа только ради доступа к вашей персональной коллекции торрентов. А если вдруг вами действительно заинтересуются спецслужбы, то вы сами им всё на блюдечке принесёте и ещё и будете настойчиво интересоваться устроило ли их то, что вы принесли. Будьте проще: NAT это общественное благо, говорю это как работавший в ISP, в том числе в поддержке в тот момент, когда внешний трафик был помегабайтным и пользователи регулярно влетали в "я этого не качал, за что счёт 100500!?!?"