Що потрібно розробникам для запуску власного сервера VM у корпоративному середовищі [закрито]

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

Ми намагаємось реалізувати середовище розробки, використовуючи віртуалізацію для невеликої команди з 4 розробників в межах організації підприємства. Це дозволило б нам створити окремі середовища розробки, тестування та постановки - а також дозволити доступ до нових операційних систем, які є вимогами до систем чи інструментів, які ми оцінюємо.

Ми переосмислили існуючу машину класу робочих станцій, ввели 24 ГБ оперативної пам’яті та RAID-10, і все робило добре, поки ми не намагалися додати машину до домену.

Зараз ми починаємо війну, з якою всі розробники підприємств з початку часу мали боротися - боротьба за місцевий контроль середовища розробки та тестування. Мережеві та ІТ-адміністратори викликали ряд проблем, починаючи від "ESX Server - це стандарт підприємства" до "сервери заборонені на клієнтських локальних мережах" до "[заповнити-порожнє] - це не набір навичок, якими зараз володіє місцева або корпоративна ІТ-організація ".

Ми, мабуть, могли б виправдати апаратну та формальну технічну підтримку на рівні виробництва (читай: ми могли б виправдати необхідність, якби нам довелося, але це зайняло б час і призвело до великої кількості головного болю) - але це, ймовірно, потребує місяців, щоб офіційно отримати ІТ-ресурси призначається, трактуючи це як виробничу систему - і навіть якби ми це зробили, ми, швидше за все, втратимо місцевий контроль, який хочемо.

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

1. Які аргументи висловили ваші розробники, які перемогли вас дозволити існуванню таких типів силосів на підприємствах, які мають стандартну політику щодо мереж та безпеки, яка, як правило, (і зрозуміло), перешкоджає такому типу інфраструктури, що не управляється централізовано?
2. Це лише питання розробників зробити технічне чи ділове обґрунтування та забезпечити, що відбудеться управління патчем та AV - чи більше політична боротьба за контроль та власність?
3. Зважаючи на вибір, чи бажаєте ви взяти на себе право власності та підтримку апаратного забезпечення / ОС, надаючи правам локального адміністратора розробникам, або дозволити їм керувати ними повністю, гарантуючи, що вони встановлюють управління патчами / AV та стягують з них відповідальність у разі виникнення проблем?
4. Якщо ви успішно заблокували розробників від локального контролю над "шахрайськими серверами" на вашій інфраструктурі, чи розробники просто зробили належне чи вони (або ви) перенесли середовище розробки в відключену VLAN / повністю окрему мережу?

Кілька припущень для обмеження обсягу цього питання:

1. Для повторного повторення це стосується умов розвитку - не потрібно виробничих навантажень чи підтримки. Нічого зовні не доступне.
2. Це не священна війна Hyper-V проти ESX (у нас би все було добре - але Hyper-V був вибраний, оскільки він "безкоштовний" з MSDN для цих цілей [так, VMWare також має безкоштовні інструменти - але хороше управління інструменти, як правило, не є], і місцеві розробники будуть легше керувати в "Магазині Майкрософт") - тому аргументи "за" або "проти" виходять за рамки цього питання.
3. Команда розробників вже запевнила або керувати патчем та антивірусом, або інтегруватись із існуючими системами підприємств, якщо ІТ підтримуватимуть його, але це, безумовно, в межах сфери, чи ви готові це прийняти.

Перш за все, я бачу кілька причин, чому ваші адміністратори мають рацію відштовхуватися:

• ІТ також несе відповідальність за звітування про такі речі, як управління патчами, антивірусне програмне забезпечення, відповідність ПК, щорічні (або частіші) перевірки безпеки тощо. Це не лише питання впевненості в тому, що це вирішується, але і можливість щоб довести це сторонній.

  Як приклад, я запускаю мережу в невеликому коледжі, і у нас є лабораторія фізики з кількома машинами для збору даних для експериментів студентів. Єдине, що вони роблять, - це збирати дані з наукового інструменту та роздруковувати результати (на безпосередньо прикріплений принтер) для студента для аналізу та здачі інструктору. Вони ніколи не є в Інтернеті - навіть оновлення AV та Windows застосовуються через локальну мережу. Єдина причина, коли вони взагалі підключені до мережі та запускають програмне забезпечення AV - це явні цілі звітування моєму програмному забезпеченню для моніторингу, що вони все ще існують та є поточними. Це нерозумно, оскільки вони насправді бути більш безпечними , щоб видалити підключення до мережі, але вони були першими оплачено субсидією на освіту і так це мої вимоги до звітності.

• Вам подобається чи ні, ваш сервер розробників - це виробнича система з позицій розробників. Дайте це, можливо, через місяць, і розробникам буде важко працювати, якщо він знизиться через процеси, які ви налаштуєте, припускаючи, що сервер доступний. Уникнення / обмеження ситуацій, коли працівників не працює через технологічні збої, є основною причиною того, що підприємства все ще використовують централізовані відділи ІТ.
• Якщо "ESX Server є корпоративним стандартом", вам потрібно це дотримуватися. В цей час існують значні відмінності між тим, як гіпер-v, vmware, xen та інші роблять справи, і машину, побудовану для одного, не можна просто вважати, що він працює добре на іншому. Якщо ви збираєтеся це зробити, ІТ потрібно буде допомогти в управлінні ним в якийсь момент, і вони не хочуть перетворювати його на vmware після того, як на машині є маса суглобів, що може спричинити проблеми.
• Коли-небудь ця машина буде старіти, і або потрібно більш регулярне обслуговування або встановлення стандартного циклу заміни. Навіть нові сервери іноді мають запчастини. Така ситуація майже завжди опиняється в колі ІТ лише після того, як щось зламається, що заважає людям виконувати свою роботу. Рано беручи на себе відповідальність за сервер, ІТ може зробити набагато кращу роботу, уникнувши незапланованих відключень в дорозі.
• Це особисте, але я можу вам сказати, що саме останнє, що я хочу, щоб навколо моєї мережі було ще один робочий стіл, маскується під сервер. Я розібрався з достатньою кількістю цих останніх кількох років, щоб тривати мені все життя.

Зважаючи на це, ІТ потрібно підтримувати цю ініціативу. Їм недостатньо просто сказати: «Ні». Киньте їм виклик запропонувати альтернативу, яка відповідає вашим (дуже реальним) потребам. Єдиною політичною ситуацією тут має бути те, що їхня альтернатива, ймовірно, матиме більшу ціну наклейки (адже вони планують витрати, яких ви ще не можете побачити), і тому питання буде в тому, хто за це повинен платити. ІТ не захоче, тому що не заплатив на це бюджет, але ви будете балакати, тому що це в 6 разів більше, ніж ви витратили на рішення, яким ви були задоволені (на даний момент).

Крім того, це здається, що ви, можливо, намагаєтесь бігти, перш ніж піти пішки. Ви хочете оновити процес розробки. Як колишній розробник, я думаю, що це чудово. Але не просто викидайте купу віртуальних машин та "середовищ" (тобто: dev, stage, qa тощо). Сплануйте, як будуть виглядати нові процеси - як розробники будуть працювати. Чи будете ви використовувати безперервну інтеграцію? Автоматизовані побудови? Використовуючи яке програмне забезпечення для їх підтримки? Чи буде дозволено розробникам переміщувати код на виробництво чи постановку, чи буде лише QA мати таку можливість? Вам потрібна окрема постановка? А як щодо двох гілок розробників (одна для vNext, одна для помилок з vCurrent)?

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

1) Які аргументи висловили ваші розробники, які перемогли вас дозволити існуванню таких типів силосів на підприємствах, які мають стандартну мережеву політику та політику безпеки, яка, як правило, (і зрозуміло), виключає цей тип інфраструктури, що не управляється централізовано. ?

Ні - в основному тому, що я не граю управлінської ролі в своїй організації, тому жодна з цих "політичних речей" насправді не стосується мене. Єдиний аргумент, який насправді переконав би мене - дозволити щось, що явно суперечить мережевій політиці і звільнене від контролю та видимості командних системних операцій, - це пробіл та лист CYA від боса мого начальника.

Справа не в тому, що я дуже хочу бути бізнесом, який каже "Ні", це просто те, що немає хорошого способу, щоб це добре закінчилося з позицій операційної групи.

1. Ми закінчуємо сервери, якими керують люди, яким основний набір навичок - це не керування серверами в мережі, які не бачать всю мережу та пов'язаний з цим проблемний простір. Це не просто політична проблема "захисту" дерну; в якості банального прикладу уявіть, що відбувається, коли розробник з якоїсь причини вмикає DHCP.
2. Ми в кінцевому підсумку управляємо серверами команди розробників для них. Це безладно з протилежної причини. Розробники постійно дратуються, що ми це виправляємо (ламаємо щось, про що вони знають, але ми цього не робимо) або боремося за те, щоб вони ввімкнули функції, які з різних поважних причин нам не потрібні. Це швидко перетворюється в глухий кут, коли операційна команда відчуває себе обтяженою та переслідуваною, а команда розробників відчуває розчарування та ігнорування.
3. Є політичні наслідки - адже тоді вам доведеться пояснити іншому відділу, чому розробники "особливі" і чому вони звільняються від мережевої політики.

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

Я не думаю, що розробникам не потрібно робити ділових справ - цілком зрозуміло, що розробники повинні розвиватися і для цього вони потребують певного середовища розвитку. Що стосується управління патчем та AV - це робота операційної команди, і ми забезпечимо її виконання. Ми не вважаємо, що розробники не можуть цього зробити. Ми просто не довіряємо вам, що ви це зробите правильно - системні адміністратори залишаються системними адміністраторами, оскільки вони не вірять нічого, щоб зробити що-небудь правильно, так що це нічого особистого. Звичайно, існує очевидна політична проблема відчуття, ніби хтось інший "робить свою роботу", але це насправді не є технічною проблемою, а значить, поза сферою СФ.

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

Ні з наведених вище причин.

4) Якщо ви успішно заблокували розробників від локального контролю над "шахрайськими серверами" на вашій інфраструктурі, чи розробники просто зробили належне чи вони (або ви) перенесли середовище розробки в відключену VLAN / повністю окрему мережу?

Повітряна щілина. Найкращий спосіб вирішити цю ситуацію - дати розробникам своє оточення (і контроль над ним), а потім повітряний проміжок або використовувати якийсь інший надійний метод, щоб відокремити його від мережі. Це, по суті, як ми обробляємо загальнодоступний wifi. Ви хочете послуги Wi-Fi? Звичайно. Ви платите за підключення до мережі, ми керуватимемо WAP, але він ніколи не торкнеться нашої мережі. Вибачте. Ваші потреби - це одна із сотень. Є й інші проблеми, які ми повинні враховувати.

Ви не хочете брати участь у справі, щоб сказати "ні", тому що розробники (які особливо технічно розумні) знайдуть способи отримати те, що хочуть у будь-якому випадку. Тож забезпечте їм середовище, яке відповідає їх потребам, зробіть їх щасливими, а потім знайдіть якийсь спосіб запобігти дотику до решти вашої ділової мережі все, що вони роблять у середовищі розвитку.

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

Якби ви прийшли до мене з машиною класу робочих станцій, завантаженою в рукоятку з оперативною пам’яттю споживача, жорстким жорстким диском споживчого рівня, споживчим модулем живлення та споживчим рівнем RAID, я б відмовився також ставити його на серверну мережу.

Потрібно багато зрозуміти, як розмістити щось подібне на сервері VLAN.

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

2. Компоненти в цій машині вийдуть з ладу. Я обіцяю. Протягом 6 або 12, 24 місяців це піде животом вгору. Тоді, де резервні копії? О, ти їх не налаштував? Але я думав, що це сервер? О, це сервер, який хтось інший надав? ... і звинувачувальна гра починається знову

3. Хто візьме на себе відповідальність, коли він врізається і лайно потрапляє у вентилятор? У більшості організацій "я дав це дияволу доглядати" не летить.

4. Куди вони збираються його поставити? Сьогодні сервери всі встановлені на стійці і розміщують вежу в просторі стійки, і їх стійки можуть не бути розроблені для цього.

Отже, ІТ-відділ дуже виправдано не розміщувати цей випадковий комп'ютер у своїй серверній мережі.

Однак робота ІТ-підрозділів - це гарантувати, що ВАС може виконувати свою роботу належним чином. Вони повинні переконатися, що у вас є те, що вам потрібно, коли вам це потрібно. Якщо у вас є програмне забезпечення, яке бізнес повинен тримати, він повинен забезпечити платформу для його роботи. Ось їхня посадова інструкція. Але вам потрібно переконатися, що вони мають інформацію, необхідну для виконання своєї роботи.

Якби ви прийшли до мене в моїй організації сказати мені, що ви починаєте новий проект, я дав би вам три ВМ: Dev, Live та Staging. Ви мали б повні права адміністратора на Dev, і ми обговоримо, що вам потрібно, щоб виконати свою роботу для двох інших. Якщо вам потрібні повні права адміністратора на них, і ви могли б це виправдати, тоді ви їх отримаєте. У нас розгортання VM вниз. VMWare робить це надзвичайно просто - для розгортання потрібно лише близько 5 хвилин на VM.

Здається, ваш ІТ-відділ страждає від того, на що страждає майже кожен ІТ-відділ великої компанії. Будуючи маленькі замки та захищаючи їх своїм життям, не пускаючи інших, бути боссом і т. Д. Як хтось, хто щодня займається ІТ-відділами інших людей, я це бачу весь час. І це засмучує.

Основним фактом є те, що зміни повинні відбуватися в ІТ-відділі, і їх слід спонукати зверху. І якщо ви можете змусити ІТ усвідомити, що вони не є силою для себе (оскільки більшість з них не приносить доходу для свого бізнесу, це може бути досить ляпкою) і що вони є там, щоб підтримати наявний персонал і розширювати бізнес, тоді ви виявите, що ваші запитання стають неактуальними, адже всі будуть грати в щасливі сім'ї.

Чому ви хочете додати його до домену? Якщо говорити про інший спосіб, який краще відповідає на питання: Ви можете налаштувати лабораторію, щоб вона робила все, що завгодно, доти, доки вона не підключена до корпоративної локальної мережі. (Якщо вам потрібен доступ до Інтернету, можливо, ви можете отримати VLAN з DMZ-редактором; це не повинно бути проблемою, особливо якщо ви використовуєте його лише для виходу , наприклад, для завантаження.)

Це одна, з багатьох безліч, різних відповідей на питання.

Тут ви отримаєте багато відповідей, за і проти розробників, які мають адміністраторський доступ до будь-якої частини середовища (можливо, переважно проти), але ось підсумок:

Група сисадмін відповідає за те, щоб підтримувати виробничі системи стабільними та безпечними, і вони відповідають за те, щоб ці системи надавали послуги, які компанія платить (тому що вони платять за них) на рівні, який вони очікують.

Так само команда розробників покладала завдання надавати послуги компанії (веб, додатки тощо), хоча і на іншій арені. Боротьба за контроль над середовищем розвитку є контрпродуктивною і не служить жодній корисній меті для обох сторін.

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

Розробники повинні бути господарями середовища розробки, а Сисадміни повинні бути господарями виробничого середовища, в розумних межах та з розумними перевірками, противагою та контролем. Коли будь-якій із сторін потрібно "перехреститися", це має бути у співпраці та співпраці з "правлячою" партією під їх компетенцією та керівництвом.

По-перше, мій досвід суворо в меншій організації, але це питання виникає в компаніях усіх розмірів, тому ...

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

За винятком того, що "просто" - це неймовірне заниження, так, якщо розробники можуть зробити технічне та бізнес-обгрунтування, не виникне проблем. Інші тут і на programer.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 або продажу в Північну Корею.