Что требуется разработчикам для запуска собственного виртуального сервера в корпоративной среде [закрыто]

Этот сценарий был также опубликован на SO , с различными вопросами для разных аудиторий - и я очень рад, что сделал, так как получил несколько очень хороших ответов.

Мы пытаемся внедрить среду разработки с использованием виртуализации для небольшой группы из 4 разработчиков в корпоративной организации. Это позволило бы нам настроить отдельные среды разработки, тестирования и промежуточной среды, а также предоставить доступ к новым операционным системам, которые являются требованиями к системам или инструментам, которые мы оцениваем.

Мы переделали существующую машину класса рабочей станции, добавили 24 ГБ ОЗУ и RAID-10 и работали нормально, пока не попытались добавить машину в домен.

Теперь мы начинаем войну, которую с самого начала должны были вести все корпоративные разработчики - борьба за локальное управление средой разработки и тестирования. Сетевые и ИТ-администраторы подняли ряд вопросов, начиная от «ESX Server является стандартом предприятия» до «серверы не допускаются в клиентских виртуальных локальных сетях» до «[заполнить пустые]» - это не набор навыков, которым в настоящее время обладают в местная или корпоративная ИТ-организация ".

Мы могли бы, вероятно, оправдать аппаратное оборудование и формальную ИТ-поддержку на уровне производства (читай: мы могли бы обосновать необходимость, если бы нам это понадобилось, но это заняло бы время и потребовало бы много головной боли) - но, вероятно, потребовались бы месяцы, чтобы формально получить ИТ-ресурсы назначенный, рассматривая это как производственную систему - и даже если бы мы сделали, мы вероятно потеряли бы местный контроль, который мы хотим.

Я полагаю, что у многих из вас была похожая борьба с разработчиками на вашем предприятии за контроль разработчиков над непроизводственными средами, поэтому у меня следующие вопросы:

1. Какие аргументы ваши разработчики привели к тому, что вы допустили существование таких типов хранилищ на предприятиях, которые имеют стандартные сетевые политики и политики безопасности, которые в целом (и по понятным причинам) исключают этот тип не (централизованно) управляемой инфраструктуры?
2. Это просто вопрос разработчиков, которые делают техническое или бизнес-обоснование и гарантируют, что управление патчами и AV будут происходить - или больше политической борьбы за контроль и владение?
3. Если бы у вас был выбор, вы бы предпочли взять на себя владение и поддержку оборудования / ОС, одновременно предоставляя разработчикам права локального администратора, или позволить им полностью управлять им, обеспечивая при этом создание управления исправлениями / AV и возлагая на них ответственность, если они вызовут проблемы?
4. Если вы успешно заблокировали разработчикам локальный контроль над «мошенническими серверами» в вашей инфраструктуре, разработчики просто сделали это должным образом или они (или вы) переместили среду разработки в отключенную VLAN / полностью отдельную сеть?

Пара предположений, чтобы ограничить объем этого вопроса:

1. Повторим, это для среды разработки - никаких производственных нагрузок или поддержки не требуется. Ничего внешне доступного.
2. Это не священная война Hyper-V против ESX (нам было бы неплохо - но Hyper-V был выбран, поскольку он «бесплатный» с MSDN для этих целей [да, у VMWare тоже есть бесплатные инструменты - но хорошее управление инструменты, как правило, не являются], и ими будет легче управлять местными разработчиками в «магазине Microsoft»), поэтому аргументы за или против любого из них выходят за рамки этого вопроса.
3. Команда разработчиков уже заверила, что будет управлять управлением исправлениями и антивирусами или интегрироваться с существующими корпоративными системами, если ИТ-отдел будет их поддерживать, но, безусловно, в пределах вашей компетенции, готовы ли вы принять это или нет.

Прежде всего, я вижу несколько причин, по которым ваши администраторы правы:

• ИТ-отдел также отвечает за составление отчетов о таких вещах, как управление исправлениями, антивирусное программное обеспечение, соответствие требованиям pci, ежегодные (или более частые) аудиты безопасности и т. Д. Это не только вопрос уверенности в том, что об этом позаботятся, но и возможность чтобы доказать это посторонним.

  Например, я управляю сетью в небольшом колледже, и у нас есть физическая лаборатория с несколькими машинами для сбора данных для студенческих экспериментов. Единственное, что они делают, это собирают данные с научного инструмента и распечатывают результаты (на непосредственно подключенный принтер), чтобы ученик мог их проанализировать и передать инструктору. Они никогда не находятся в Интернете - даже обновления AV и Windows применяются через локальную сеть. Единственная причина, по которой они подключены к сети и вообще используют программное обеспечение AV, - это явные цели сообщить моему программному обеспечению для мониторинга, что они все еще существуют и являются актуальными. Это глупо, поскольку они на самом деле быть более безопасными , чтобы удалить подключение к сети, но они были первыми оплачено субсидией на образование и так это мои требования к отчетности.

• Нравится вам это или нет, но с точки зрения разработчиков ваш dev-сервер - это производственная система. Дайте ему, может быть, месяц, и разработчикам будет трудно выполнить работу, если она выйдет из строя из-за процессов, которые вы настроите, предполагая, что сервер доступен. Избегание / ограничение ситуаций, когда работники бездействуют из-за технологических сбоев, является основной причиной, по которой предприятия все еще используют централизованные ИТ-отделы.
• Если «ESX Server является корпоративным стандартом», вам необходимо следовать этому. В настоящее время существуют значительные различия между тем, как Hyper-V, VMware, XEN и другие делают что-то, и машина, созданная для одного, не может считаться хорошо работающей на другом. Если вы собираетесь это сделать, ИТ-отделу в какой-то момент потребуется помощь в управлении им, и они не хотят преобразовывать его в vmware после того, как на машине возникнет куча ошибок, которые могут вызвать проблему.
• Когда-нибудь эта машина устареет, и ей потребуется либо более регулярное техническое обслуживание, либо настройка стандартного цикла замены. Даже на новых серверах иногда есть задницы. Эта ситуация почти всегда попадает на колени IT только после того, как что-то сломалось, что мешает людям выполнять свою работу. Принимая ответственность за сервер на раннем этапе, ИТ-отделы могут выполнять работу намного лучше, избегая незапланированных отключений в будущем.
• Это личное, но я могу сказать вам, что последнее, что я хочу в своей сети, - это другой рабочий стол, маскирующийся под сервер. Я имел дело с достаточным количеством тех за последние пару лет, чтобы продержаться мне всю жизнь.

Тем не менее, ИТ должны быть в состоянии поддержать эту инициативу. Им недостаточно просто сказать «Нет». Попросите их найти альтернативу, которая отвечает вашим (очень реальным) потребностям. Единственная политическая ситуация здесь должна состоять в том, что у их альтернативы, вероятно, будет более высокая цена стикера (потому что они планируют расходы, которые вы еще не видите), и поэтому вопрос будет в том, кто должен за это платить. ИТ не захочет, потому что они не планировали этого, но вы будете отказываться, потому что это в 6 раз больше того, что вы потратили на решение, которым вы были довольны (на данный момент).

Кроме того, похоже, что вы пытаетесь бежать, прежде чем вы можете ходить. Вы хотите обновить свой процесс разработки. Как бывший разработчик, я думаю, что это здорово. Но не просто выбрасывайте кучу виртуальных машин и «сред» (то есть: dev, stage, qa и т. Д.). Спланируйте, как будут выглядеть новые процессы - как разработчики выполнят работу. Будете ли вы использовать непрерывную интеграцию? Автоматизированные сборки? Используя какое программное обеспечение для их поддержки? Разрешат ли разработчикам переносить код в производственную или промежуточную версию, или только QA будет иметь такую ​​возможность? Вам нужна отдельная постановка? Как насчет двух веток разработчика (одна для vNext, другая для ошибок с vCurrent)?

Вам может понадобиться сервер только для того, чтобы руководитель разработки или менеджер мог все это решить, но если это так, то это должен быть первый шаг, и необходимо выполнить настройку и начальный дизайн процесса, прежде чем разработчики получат его в руки для фактического использовать.

1) Какие аргументы выдвинули ваши разработчики, которые покорили вас тем, что такие типы хранилищ существуют на предприятиях, которые имеют стандартные сетевые политики и политики безопасности, которые, как правило (и понятно), исключают этот тип не (централизованно) управляемой инфраструктуры ?

Нет - в основном потому, что я не играю управленческую роль в моей организации, поэтому любая из этих «политических вещей» на самом деле не затрагивает меня. Единственный аргумент, который действительно убедил бы меня, - это разрешить что-то, что явно противоречит сетевой политике и освобождено как от контроля, так и от контроля над операциями системы, - это пробел и письмо CYA от босса моего босса.

Не то, чтобы я действительно хотел сказать «Нет», просто нет хорошего способа, чтобы это хорошо закончилось с точки зрения операционной команды.

1. В итоге мы получаем серверы, управляемые людьми, у которых основной набор навыков не заключается в управлении серверами в сети, у которых нет видимости всей сети и связанного с ней проблемного пространства. Это не просто политическая проблема "защиты" газона; в качестве банального примера представьте, что происходит, когда разработчик по какой-то причине включает DHCP.
2. В итоге мы управляем серверами команды разработчиков для них. Это грязно по противоположной причине. Разработчики постоянно раздражаются, что мы исправляем это (ломаем то, о чем они знают, но мы не знаем), или они борются за нас, чтобы включить функции, которые по ряду веских причин мы не хотим включать. Это быстро превращается в тупик, когда рабочая группа чувствует себя обремененной и преследуемой, а команда разработчиков чувствует себя разочарованной и игнорируемой.
3. Есть политические последствия - потому что тогда вы должны объяснить другому отделу, почему разработчики «особенные» и почему они освобождаются от сетевой политики.

2) Это просто вопрос разработчиков, делающих техническое или бизнес-обоснование и гарантирующих, что управление патчами и AV будут происходить - или больше политической борьбы за контроль и владение?

Я не думаю, что разработчики должны делать бизнес-обоснование - довольно ясно, что разработчики должны разрабатывать и для этого им нужна какая-то среда разработки. Что касается управления патчами и AV - это работа операционной команды, и мы позаботимся о том, чтобы это было сделано. Мы не думаем, что разработчики не могут этого сделать. Просто мы не верим, что вы делаете это правильно - системные администраторы остаются системными администраторами, потому что они не доверяют ничему, чтобы что-то делать правильно, и это ничего личного. Конечно, существует очевидная политическая проблема, заключающаяся в том, что кто-то другой «выполняет свою работу», но на самом деле это не техническая проблема и, следовательно, выходит за рамки SF.

3) Если бы у вас был выбор, вы бы предпочли взять на себя ответственность и поддержать аппаратное обеспечение / ОС, предоставляя разработчикам права локального администратора, или позволить им полностью управлять им, обеспечивая при этом, чтобы они установили управление исправлениями / AV и возложили на них ответственность, если они вызовут проблемы?

Ни по причинам, изложенным выше.

4) Если вы успешно заблокировали разработчикам локальный контроль над «мошенническими серверами» в вашей инфраструктуре, разработчики просто сделали это должным образом или они (или вы) переместили среду разработки в отключенную VLAN / полностью отдельную сеть?

Воздушный зазор. Лучший способ справиться с этой ситуацией - дать разработчикам их среду (и контроль над ней), а затем воздушный зазор или использовать какой-либо другой надежный метод для отделения его от сети. Это по сути, как мы обращаемся с общественным Wi-Fi. Вы хотите услуги Wi-Fi? Конечно. Вы платите за сетевое соединение, мы будем управлять WAP, но оно никогда не коснется нашей сети. Сожалею. Ваши нужды только одна из сотен. Есть и другие проблемы, которые мы должны рассмотреть.

Вы не хотите говорить «нет», потому что разработчики (которые особенно технически умны) все равно найдут способы получить то, что они хотят. Поэтому предоставьте им среду, которая соответствует их потребностям, сделайте их счастливыми, а затем найдите способ предотвратить то, что они делают в среде разработки, не затрагивая остальную часть вашей деловой сети.

TL; DR: Я бы дал вам сервер с любой платформой виртуализации, которую вы хотите, в отдельной физической сети или VLAN. Доступ к вашей среде разработки будет осуществляться через один хост-бастион, который операционная группа будет контролировать и контролировать. Что вы делаете с этим своим бизнесом - он не будет поддерживаться, но мы предоставим вам совет и помощь, если позволит время для администрирования сервера.

Если бы вы пришли ко мне с машиной класса рабочей станции, загруженной в рукоять с ОЗУ потребительского уровня, жесткими дисками потребительского уровня, БП потребительского уровня и RAID-массивом потребительского уровня, я бы отказался поставить его и в сеть сервера.

Есть много вещей, которые вы должны понимать, чтобы разместить что-то подобное на VLAN-сервере.

1. Сервер VLAN вполне может быть DMZ. В DMZ вы не кладете ничего, что не закалено и не защищено. Это просто машина, которую вы им передали, они не представляют, что вы с ней сделали. Это также означает регулярные исправления и обновления, что означает централизованное управление. Я чертовски уверен, что не буду входить на каждый неуправляемый сервер и устанавливать патчи вручную.

2. Компоненты в этой машине выйдут из строя. Я обещаю. В течение 6 или 12, 24 месяцев, это пойдет на спад. Тогда где находятся резервные копии? О, ты их не настраивал? Но я думал, что это сервер? О, это сервер, который кто-то другой предоставил? ... и игра обвинений начинается снова

3. Кто возьмет на себя ответственность, когда он рухнет и дерьмо ударит в фаната? В большинстве организаций «я отдал его девочкам на попечение» не собирается летать.

4. Где они собираются это поставить? В наши дни все серверы монтируются в стойку, и установка башни в стойку приводит к потере пространства, и их стойки могут быть не предназначены для этого.

Итак, ИТ-отдел очень оправдан, что не помещает этот случайный компьютер в свою серверную сеть.

Однако задача ИТ-отделов заключается в том, чтобы ВЫ могли выполнять СВОЮ работу должным образом. Они должны убедиться, что у вас есть то, что вам нужно, когда вам это нужно. Если у вас есть часть программного обеспечения, которую бизнес должен поддерживать, они должны предоставить платформу для его работы. Это их описание работы. Но вы должны убедиться, что у них есть информация, необходимая для их работы.

Если бы вы пришли ко мне, в моей организации, сказали, что вы начинаете новый проект, я бы дал вам три виртуальные машины: Dev, Live и Staging. У вас будут полные права администратора для Dev, и мы обсудим, что вам нужно, чтобы выполнить свою работу для двух других. Если вам нужны были полные права администратора для них, и вы могли бы это оправдать, вы бы это получили. У нас есть проблемы с развертыванием виртуальных машин. VMWare делает это невероятно простым - для развертывания требуется всего около 5 минут на каждую виртуальную машину.

Похоже, ваш ИТ-отдел страдает от того, от чего страдает практически каждый ИТ-отдел крупной компании. Строить маленькие замки и защищать их своей жизнью, не впускать других, быть властными и т. Д. Как человек, который ежедневно занимается ИТ-отделами других людей, я вижу это все время. И это расстраивает.

Основной факт заключается в том, что изменение должно произойти изнутри ИТ-отдела, и оно должно быть инициировано сверху их. И если вы сможете заставить ИТ-специалистов осознать, что они сами по себе не являются силой (так как большинство из них не приносят доход для своего бизнеса, это может быть пощечиной), и что они там, чтобы поддержать существующий персонал и улучшить бизнес, тогда вы обнаружите, что ваши вопросы становятся неактуальными, потому что все будут играть в счастливые семьи.

Почему вы хотите добавить его в домен? Иными словами, это лучше отвечает на вопрос: вы можете настроить лабораторию, чтобы делать все, что вы, черт возьми, хотите, если она не подключена к корпоративной локальной сети. (Если вам нужен доступ в Интернет, возможно, вы можете получить DMZ-ed VLAN; это не должно быть проблемой, особенно если вы используете его только для выхода , например, для загрузки.)

Это один из многих, многих, разных ответов на вопрос.

Вы получите много ответов здесь, за и против разработчиков, имеющих доступ администратора к любой части среды (вероятно, в основном против), но вот суть:

Задача группы sysadmin - поддерживать работоспособность, стабильность и безопасность производственных систем и отвечать за то, чтобы эти системы предоставляли услуги, за которые компания платит (потому что они за них платят) на ожидаемых уровнях.

Кроме того, перед командой разработчиков была поставлена ​​задача предоставлять услуги компании (веб, приложения и т. Д.), Хотя и в другой области. Борьба за контроль над средой разработки контрпродуктивна и не приносит никакой пользы ни одной из сторон.

Я работаю на небольшом ISV / ASP. У нас есть один разработчик и один системный администратор (я). У нас есть отношения, основанные на взаимном уважении и доверии. Нам нужно работать как команда, чтобы помочь в достижении общих целей компании. Я предоставляю разработчику полный беспрепятственный доступ к его среде разработки, которая включает рабочие станции и серверы. Я управляю системами dev для обеспечения безопасности, обновлениями, AV и оборудованием, а dev делает все остальное. Когда его код готов к производству, он передает его мне, помогает мне с любой необходимой конфигурацией и отступает. Мы оказываем взаимопомощь друг другу.

Разработчики должны быть хозяевами среды разработки, а системные администраторы должны быть хозяевами производственной среды в разумных пределах и с разумными проверками, противовесами и средствами контроля. Когда любая из сторон должна «перейти», она должна сотрудничать и согласовывать свою деятельность с «правящей» партией под их контролем и руководством.

Прежде всего, мой опыт строго в небольшой организации, но эта проблема возникает в компаниях всех размеров, так что ...

1.  What arguments have your developers made that won you over to
allow these types of silos to exist within enterprises which have
standard network and security policies in

С моей точки зрения, единственный аргумент, который нужно сделать разработчикам, это «нам это нужно». Если бы они пришли ко мне первыми, я бы попытался понять их потребности и посмотреть, что мы могли бы решить. Но, в конечном счете, если они скажут «нам это нужно», я бы дал им преимущество сомнения и верю, что они знают, что делают.

Но это только начало - это "Pro" сторона уравнения. «Кон» - это то место, где мы вступаем в спор ...

2. Is this just a matter of the developers making a technical or
business justification

За исключением того, что «просто» - невероятное преуменьшение, да, если разработчики смогут сделать техническое и бизнес-обоснование, проблем не будет. Другие здесь и на программистов. SE (где ваш вопрос SO был перенесен) указали на кучу ошибок в вашей настройке, поэтому я не буду их повторять. Если вы придумали план для решения всех этих проблем и любых других, о которых думает ваш ИТ-отдел, и обосновали ВСЕ затраты, тогда имеет смысл идти вперед.

3.  Given the choice, would you prefer to take ownership and support
of the hardware/OS while giving devs local admin rights,

Это не стартер, вы не можете иметь две группы с разными целями и обязанностями, которые пытаются управлять одними и теми же системами. Это не просто плохо кончится, но плохо и закончится кровопролитием.

(more of 3.) ... or let them manage it entirely, while ensuring that
they institute patch management/AV and charging them with
responsibility should they cause problems?

Я думаю, что это покрыто моим ответом на 2: это технические детали, для которых они должны были бы найти решения.

4.  If you successfully blocked developers from having local control
of "rogue servers" on your infrastructure, did the developers just
make due or did they (or you) move the development environment to a
disconnected VLAN/entirely separate network?

Я согласен с kce: «Воздушный зазор»

Если они могут оправдать дополнительные накладные расходы, которые они берут на себя (став администраторами своей среды), разработчики могут иметь собственную мини-сеть, в которой у них есть свобода действий, НО она полностью изолирована: ничто не затрагивает остальную сеть. Поэтому им приходится придумывать больше технических и бизнес-обоснований, например, «как мы собираемся делать резервные копии критически важных данных?».

Опять же, я должен согласиться с kce: «Системные администраторы остаются системными администраторами, потому что они не доверяют ничему, чтобы что-то делать правильно». Наша задача - создавать самые надежные системы из ненадежных компонентов, поэтому любое предложение, включающее половину дюжина вещей, которые опытный сисадмин знает, являются невероятно ненормальными, получит сильную негативную реакцию.

Из ответов и комментариев здесь и на сайте programmers.se, я думаю, ясно, что есть аспекты, которые вы не рассмотрели. Хотя это займет больше времени, я думаю, вам действительно нужно пойти и поговорить со своими ИТ-специалистами и представить вещи по-другому: «Вот что нам нужно сделать, есть ли способ интегрировать это в существующую инфраструктуру и операции?»

Общая проблема в вашем и миллионах подобных случаев:

1) Нечеткая ответственность - нет прямой связи между действиями корпоративного работника и его прибылью. Ему платят по месяцам, а не по эффектам, которые сложнее измерить, чем больше организация. Это относится к безопасности, менеджерам и т. Д. Если они парализуют вашу работу, им все равно.

2) Политики и безопасность обычно мало или совсем не знают о программировании. Они не могли понять, что они парализуют вашу работу, даже если им было бы все равно (что обычно не применяется).

3) Предпочтительным психологическим профилем для работы в условиях безопасности является параноидальная личность или обсессивно-компульсивное расстройство. Эти люди видят заговор повсюду. Если разработчики хотят что-то, например, новый сервер, они наверняка захотят использовать его для кражи корпоративных данных и публикации их в WikiLeaks или для продажи Северной Корее.