это сценарий также был размещен на SO, с разными вопросами для разной аудитории - и я очень рад, что сделал это, поскольку получил несколько очень хороших ответов.
Мы пытаемся реализовать среду разработки с использованием виртуализации для небольшой команды из 4 разработчиков в рамках корпоративной организации. Это позволит нам создать отдельные среды разработки, тестирования и подготовки, а также предоставить доступ к новым операционным системам, которые являются требованиями к системам или инструментам, которые мы оцениваем.
Мы переназначили существующую машину класса рабочей станции, добавили 24 ГБ ОЗУ и RAID-10, и у нас все было хорошо, пока мы не попытались добавить машину в домен.
Теперь мы начинаем войну, с которой с незапамятных времен приходилось вести всем корпоративным разработчикам - борьбу за локальный контроль над средой разработки и тестирования. Сетевые и ИТ-администраторы высказали ряд опасений, начиная от «ESX Server является корпоративным стандартом» до «серверы не разрешены в клиентских VLAN» до «[заполните поле] не является набором навыков, которыми в настоящее время обладают местная или корпоративная ИТ-организация ".
Мы, вероятно, могли бы оправдать оборудование производственного уровня и формальную ИТ-поддержку (читай: мы могли бы оправдать необходимость, если бы нам пришлось, но это потребовало бы времени и большой головной боли), но, вероятно, потребуются месяцы, чтобы формально получить ИТ-ресурсы назначенный, рассматривая это как производственную систему - и даже если бы мы это сделали, мы, вероятно, потеряли бы местный контроль, который нам нужен.
Я полагаю, что у многих из вас были аналогичные проблемы с разработчиками на вашем предприятии за контроль разработчика над непроизводственной средой, поэтому мои вопросы следующие:
Пара предположений, чтобы ограничить объем этого вопроса:
Прежде всего, я действительно вижу несколько причин, по которым ваши администраторы правы, чтобы дать отпор:
ИТ также отвечает за составление отчетов о таких вещах, как управление исправлениями, антивирусное программное обеспечение, соответствие pci, ежегодные (или более частые) аудиты безопасности и т. д. Дело не только в вашей уверенности, что об этом позаботятся, но и в том, Докажите это посторонним.
Например, я управляю сетью в небольшом колледже, и у нас есть физическая лаборатория с несколькими машинами для сбора данных для студенческих экспериментов. Единственное, что они делают, - это собирают данные с научного прибора и распечатывают результаты (на непосредственно подключенный принтер), чтобы студент проанализировал их и передал преподавателю. Они есть никогда в Интернете - даже обновления AV и Windows применяются через локальную сеть. Единственная причина, по которой они подключены к сети и вообще используют антивирусное программное обеспечение, - это явные цели сообщить моему программному обеспечению для мониторинга, что они все еще существуют и актуальны. Это глупо, как бы они были на самом деле Больше безопасны для удаления сетевого подключения, но сначала они были оплачены грантом на образование, и это мои требования к отчетности.
Тем не менее, ИТ-отделы должны иметь возможность поддержать эту инициативу. Для них недостаточно просто сказать «Нет». Предложите им придумать альтернативу, отвечающую вашим (вполне реальным) потребностям. Единственная политическая ситуация здесь должна заключаться в том, что их альтернатива, вероятно, будет иметь более высокую цену (потому что они планируют расходы, которые вы еще не видите), и поэтому вопрос будет в том, кто должен за нее платить. ИТ-специалисты не захотят, потому что они не предусмотрели для этого бюджет, но вы откажетесь, потому что это в 6 раз больше, чем вы потратили на решение, которым вы были довольны (на данный момент).
Кроме того, похоже, что вы пытаетесь бежать, прежде чем научитесь ходить. Вы хотите обновить процесс разработки. Как бывший разработчик, я считаю, что это здорово. Но не просто выбрасывайте кучу виртуальных машин и «сред» (например: dev, stage, qa и т. Д.). Спланируйте, как будут выглядеть новые процессы - как разработчики будут выполнять работу. Будете ли вы использовать непрерывную интеграцию? Автоматизированные сборки? Какое программное обеспечение их поддерживает? Будет ли разрешено разработчикам переносить код в производство или стадию, или только QA будет иметь такую возможность? Нужна отдельная постановка? А как насчет двух веток разработки (одна для vNext, другая для ошибок с vCurrent)?
Возможно, вам понадобится сервер, чтобы руководитель разработки или менеджер могли все это разрабатывать, но если да, то это должен быть первый шаг, и необходимо выполнить настройку и первоначальный дизайн процесса. перед разработчики получают его для реального использования.
1) Какие аргументы привели ваши разработчики, которые убедили вас в том, что эти типы разрозненных хранилищ могут существовать на предприятиях, которые имеют стандартные сетевые политики и политики безопасности, которые в целом (и по понятным причинам) исключают этот тип инфраструктуры, не управляемой (централизованно) ?
Нет - в основном потому, что я не играю руководящей роли в своей организации, поэтому все эти «политические вещи» меня не касаются. Единственный аргумент, который действительно убедил бы меня, - это разрешить что-то, что явно противоречит сетевой политике и освобождается от контроля и видимости как со стороны группы системных операций, так и с точки зрения видимости, - это воздушный зазор и письмо CYA от начальника моего начальника.
Дело не в том, что я действительно хочу сказать «Нет», просто нет хорошего способа, чтобы это закончилось хорошо с точки зрения операционной группы.
2) Является ли это просто вопросом того, что разработчики делают техническое или коммерческое обоснование и гарантируют, что управление исправлениями и антивирусные программы произойдут - или это скорее вопрос политической борьбы за контроль и владение?
Я не думаю, что разработчикам нужно делать бизнес-обоснование - совершенно очевидно, что разработчики должны заниматься разработкой, и для этого им нужна какая-то среда разработки. Что касается управления исправлениями и антивирусной защиты - это работа операционной группы, и мы позаботимся о ее выполнении. Не то чтобы мы думали, что разработчики не могут этого сделать. Просто мы не верим, что вы делаете это правильно - системные администраторы остаются системными администраторами, потому что они не верь ничему, чтобы делать что-либо правильно так что ничего личного. Конечно, существует очевидная политическая проблема ощущения того, что кто-то другой «делает вашу работу», но это не совсем техническая проблема и, следовательно, выходит за рамки научной фантастики.
3) Если у вас есть выбор, вы бы предпочли взять на себя ответственность и поддерживать оборудование / ОС, предоставляя разработчикам права локального администратора, или позволить им полностью управлять им, при этом гарантируя, что они установят управление исправлениями / AV и возложат на них ответственность, если они вызовут проблемы?
Ни то, ни другое по причинам, изложенным выше.
4) Если вы успешно заблокировали разработчикам возможность локального управления «мошенническими серверами» в вашей инфраструктуре, сделали ли разработчики должное или они (или вы) перенесли среду разработки в отключенную VLAN / полностью отдельную сеть?
Воздушный зазор. Лучший способ справиться с этой ситуацией - предоставить разработчикам свою среду (и контроль над ней), а затем создать воздушный зазор или использовать какой-либо другой надежный метод для ее отделения от сети. По сути, так мы работаем с общедоступным Wi-Fi. Вам нужны услуги Wi-Fi? Конечно. Вы платите за подключение к сети, мы будем управлять точками доступа, но это никогда не коснется нашей сети. Сожалею. Ваши потребности - лишь одна из сотен. Мы должны учитывать и другие проблемы.
Вы не хотите говорить «нет», потому что разработчики (которые особенно технически умны) найдут способы получить то, что они хотят в любом случае. Так что обеспечьте им среду, которая соответствует их потребностям, сделайте их счастливыми, а затем найдите способ предотвратить что-нибудь они действуют в среде разработки, не затрагивая остальную часть вашей бизнес-сети.
TL; DR: Я бы дал вам сервер с любой платформой виртуализации, которая вам нужна, либо в отдельной физической сети, либо в VLAN. Доступ к вашей среде разработки будет осуществляться через один бастионный хост, который будет контролировать и отслеживать операционная группа. Чем вы занимаетесь в своем бизнесе - он не будет поддерживаться, но мы дадим совет и поможем, если позволит время, по вопросам администрирования сервера.
Если бы вы пришли ко мне с машиной класса рабочей станции, полностью загруженной ОЗУ потребительского уровня, жесткими дисками потребительского уровня, БП потребительского уровня и RAID-массивом потребительского уровня, я бы тоже отказался размещать ее в серверной сети.
Вам нужно многое понять о размещении чего-то подобного в серверной VLAN.
Серверная VLAN вполне может быть DMZ. В DMZ вы не помещаете что-нибудь это не закалено и не закреплено. Это просто машина, которую вы им вручили, они понятия не имеют, что вы с ней сделали. Это также означает регулярное внесение исправлений и обновлений, что означает централизованное управление. Я чертовски уверен, что не буду заходить на каждый неуправляемый сервер и вручную накладывать патчи.
Компоненты в этой машине выйдут из строя. Обещаю. В течение 6 или 12, 24 месяцев он пойдет вверх. Тогда где же резервные копии? О, вы их не настраивали? Но я думал, что это сервер? О, это сервер, который предоставил кто-то другой? ... и снова начинается поиск виноватых.
Кто возьмет на себя ответственность, если он выйдет из строя и все дерьмо попадет в вентилятор? В большинстве организаций «Я отдал это разработчикам на присмотр» - это не собираюсь летать.
Куда они его собираются поставить? В наши дни все серверы монтируются в стойку, и установка башни в стойку тратит впустую пространство, а их стойки, возможно, не предназначены для этого.
Итак, ИТ-отдел вполне оправданно не помещает этот случайный компьютер в свою серверную сеть.
тем не мение Задача ИТ-отделов - гарантировать, что ВЫ сможете выполнять СВОЮ работу должным образом. Они должны убедиться, что у вас есть то, что вам нужно, и тогда, когда вам это нужно. Если у вас есть программное обеспечение, которое потребности продолжать бежать, они иметь чтобы предоставить ему платформу для работы. Это их должностные инструкции. Но вы должны убедиться, что у них есть информация, необходимая для выполнения их работы.
Если бы вы пришли ко мне из моей организации и сказали, что начинаете новый проект, я бы дал вам три виртуальные машины: Dev, Live и Staging. У вас будут полные права администратора для Dev, и мы обсудим, что вам нужно для работы с двумя другими. Если вам нужны были полные права администратора для них, и вы могли это оправдать, вы бы их получили. У нас есть проблемы с развертыванием виртуальных машин. VMWare делает это невероятно простым - развертывание каждой виртуальной машины занимает всего около 5 минут.
Похоже, ваш ИТ-отдел страдает от того, от чего страдает практически каждый ИТ-отдел в большой компании. Строить маленькие замки и защищать их своей жизнью, не впускать других, быть властным и т. Д. Как человек, который ежедневно работает с ИТ-отделами других людей, я постоянно это вижу. И это расстраивает.
Однако основной факт заключается в том, что изменение должно происходить изнутри ИТ-отдела, и оно должно инициироваться сверху. И если вы сможете заставить ИТ-специалистов понять, что они не являются силой сами по себе (поскольку большинство из них не приносят дохода для своего бизнеса, это может быть настоящей пощечиной), и что они здесь, чтобы служба поддержки существующий персонал и усилить бизнес, тогда вы обнаружите, что ваши вопросы становятся неуместными, потому что все будут играть в счастливые семьи.
Почему вы хотите, чтобы он был добавлен в домен? Иными словами, это лучше отвечает на вопрос: вы можете настроить лабораторию, чтобы делать все, что вы хотите, если она не подключена к корпоративной локальной сети. (Если вам нужен доступ в Интернет, возможно, вы можете получить виртуальную локальную сеть с DMZ-ED; это не должно быть проблемой, особенно если вы используете его только для вне, нравится для загрузок.)
Это один из многих, многих, разных ответов на вопрос.
Здесь вы получите МНОГО ответов за и против разработчиков, имеющих административный доступ к любой части среды (вероятно, в основном против), но вот суть:
Перед группой системных администраторов стоит задача поддерживать работоспособность, стабильность и безопасность производственных систем, а также следить за тем, чтобы эти системы предоставляли услуги, за которые компания платит (потому что они платят за них), на ожидаемом уровне.
Точно так же команде разработчиков было поручено предоставлять услуги компании (веб, приложения и т. Д.), Хотя и в другой сфере. Борьба за контроль над средой разработки контрпродуктивна и бесполезна ни для одной из сторон.
Я работаю в небольшом ISV / ASP. У нас есть один разработчик и один системный администратор (я). У нас отношения, основанные на взаимном уважении и доверии. Нам нужно работать как одна команда, чтобы помочь достичь всеобъемлющих целей компании. Я предоставляю разработчику полный, неограниченный доступ к его среде разработки, которая включает рабочие станции и серверы. Я управляю системами разработки для обеспечения безопасности, обновлений, антивирусной защиты и оборудования, а разработчик делает все остальное. Когда его код готов к производству, он передает его мне, помогает мне с любой необходимой конфигурацией и отступает. Мы оказываем взаимную помощь друг другу.
Разработчики должны быть хозяевами среды разработки, а системные администраторы должны быть хозяевами производственной среды в разумных пределах и с разумными системами сдержек, противовесов и контроля. Когда любой из сторон необходимо «перейти», это должно происходить в сотрудничестве и согласовании с «правящей» партией, находящейся под их контролем и руководством.
Во-первых, мой опыт работы строго в небольшой организации, но эта проблема возникает в компаниях любого размера, так что ...
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
С моей точки зрения, единственный аргумент разработчикам - это «нам это нужно». Если бы они сначала пришли ко мне, я бы попытался понять их потребности и посмотреть, что мы могли бы решить. Но, в конечном счете, если они скажут: «Нам это нужно», я дам им сомнения и верю, что они знают, что делают.
Но это только начало - это "профессиональная" сторона уравнения. "Con" - вот где мы вступаем в спор ...
2. Is this just a matter of the developers making a technical or
business justification
За исключением того, что «просто» - это невероятное преуменьшение, да, если бы разработчики могли дать техническое и коммерческое обоснование, не было бы проблем. Другие здесь и на сайте programmers.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 или для продажи Северной Корее.