> Во первых, сначала надавать авансов а потом послать, это хуже чем сразу
> послать.Если не вдаваться в способы усаживания, штука как бы в том, что аванс уже есть: доказательство принципиальной работоспособности мы наблюдали вместе, его я добиться смог, делов-то на одну команду, пусть и размноженную по интерфейсам.
> Неправда, имеете.
> ТЗ формализирует требования. Которые бывают функциональные, /что/ решение должно делать,
> и нефункциональные, /как/ оно должно это делать. По функциональным решают заказчик
> и спонсор, а разработчик их одёргивает. По нефункциональным сложнее, потому что
> там решают больше разработчики и одёргивать их надо эксплоатационникам, а тех
> к участию на раннем этапе проекта привлекают нечасто. Поэтому бывает, что
> внедрение срывается по вине каких-нибудь инфраструктурных инженеров, которые не сумели
> достать слюны единорога, о потребности в которй узнали накануне сдачи.
> Так что по уму, вы как сетевой администратор имеете непосредственное отношение к
> составлению ТЗ
То-то и оно, что если "по уму". Бальзам для глаз/ушей такие рассуждения, но объективная реальность такая объективная. Опять же, если уйти от ненужных подробностей - это всё понятно, в данном случае вопрос не в том, как "жить не по лжи", а как решить конкретную задачу, если это возможно, в объективной реальности, данной нам в ощущениях^W железе.
> Я про мандатные метки знаю очень по наслышке, у меня сложилось впечатление
> что они:
> - Хорошо ходят по специализированным сетям, но плохо по общим, и надо
> специально заморачиваться.
> - Решают какую-то задачу специфичную для приложения, а не для инфраструктуры сети
> общего назначения.
> (может быть, это впечатление неверное)
Я до сих пор тоже сам не общался, но впечатление вполне верное. Однако в целом - чему там "ходить", это всего лишь лишние байты в заголовке пакета (причём, вполне соответствующие стандартам), из-за которых эти самые пакеты почему-то по дефолту дропаются. "Специализированность" сети упирается тупо в тот факт, что межсетевые экраны эти пакеты либо фильтруют по меткам, либо снимают/вешают метки, опционально упихивая всё в туннели. В продакшне, я надеюсь, с этим будет всё ок (насколько всё может быть ок с "Рубиконами", конечно...), проверим, это отдельная история, там цискам (или что там будет вместо них), кажется, ничего маршрутизировать между такими сетями не придётся.
> Из первого следует что придётся лезть что-то менять во всю сеть, и
> если не перестраивать вообще, то, по меньшей мере, достаточно инвазивно курочить.
> Второе означает что хозяева приложения норовят переложить свои неучтённые риски на инфраструктуру,
> у которой может не быть ресурсов чтобы их как следует переварить.
Собственно я думаю, что если решение существует, то скорее всего из всех заморочек на общей сети - конфиг L3 коммутаторов на пару строчек, просто не тех (или не только тех), что я сходу нашёл в гугле.
Странно валить всё на нехватку ресурсов, когда всего лишь требуется пустить немного нестандартный трафик. Перекладывание рисков на сетевую инфраструктуру я уже видел (интерфейс программы, отрисовывающийся только после сотни последовательных SQL запросов, когда между юзером и сервером не <1мc, а половина России, мммм...!), это не тот случай :)
Видимо (надеюсь) нужно или заставить железки пропускать этот трафик какой-то другой настройкой, или зафильтровать то, что их перегружает при ее включении.
