Віртуалізовані середовища розвитку в корпоративних мережах

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

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

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

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

1. Які стратегії та аргументи допомогли вам здобути перемогу над інфраструктурними (ІТ та мережами) людьми, щоб дозволити існування цих типів силосів на підприємствах, які мають стандартну мережеву політику та політику безпеки, що, як правило (і зрозуміло), перешкоджає такому типу не ( централізовано) - керована інфраструктура?
2. Чи вважаєте ви, що це питання технічного обґрунтування - чи більше політичної боротьби за контроль та власність?
3. Якщо ви опинилися в середовищі розробки IT, керованої ІТ, скільки прокладених проектів для щоденної розробки та тестування?
4. Хто-небудь перейшов у середовище розробки до відключеної VLAN або до повністю окремої мережі, щоб уникнути цих проблем з доступом до мережі?

Крім того, це не священна війна Hyper-V проти ESX (у нас би все було добре - але Hyper-V був обраний, оскільки він "безкоштовний" з MSDN для цих цілей [так, VMWare також має безкоштовні інструменти - але хороших інструментів управління, як правило, немає], а місцевими розробниками в "Магазині Microsoft" було б легше керувати) - тому аргументи "за" або "проти" не виходять за рамки цього питання.

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

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

Ви пішли "з бронювання" і намагаєтесь це виправдати.

Йдеться не про віртуалізацію; Йдеться про контроль і відповідальність. ІТ-відділ несе відповідальність за безпеку та надійність систем компанії. Щоб переконатися, що вони працюють, ІТ тримає їх під власним контролем. Ви створили систему, яка не контролюється ІТ, і це зараз стає проблемою.

Як правило, програмісти хочуть, щоб їх власні системи, на мій досвід, були:

• ІТ не реагує. Щоб отримати нове середовище, потрібні тижні, але зараз вам це потрібно.
• Вам потрібен контроль; Вони не дадуть вам його. Потрібно мати можливість встановлювати дозволи, встановлювати компоненти тощо. ІТ вам не дозволить.

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

• Подружитися. познайомитися з деякими людьми в ІТ; Поговоріть з ними віч-на-віч. Поясніть свою ситуацію і запитайте їх, що можна зробити. Ви можете отримати права адміністратора на сервер розробників, просто запитавши.
• Запустити Local. Якщо ви можете запустити частини програми на своїх локальних машинах, вам може не знадобитися сервер або ви можете піти з заблокованим екземпляром БД.
• Отримайте спонсора. Нічого не рухає ІТ, як підходить віце-президент і каже: "Чому ти блокуєш мій проект?" Скористайтеся спонсором спонсора проекту.
• До хмари! Якщо ваш проектний проект покриє його, просто розмістіть на EC2 - ви обійдете весь ІТ-відділ. Ризики становлять зламані та звільнені за надання інформації про компанію за межами брандмауера.
• Проведіть довгу гру. Попередньо розміщуйте запити на належним чином авторизовані та адмініструвані сервери. Коли ви отримуєте скарги на свій домашній пиріг, скажіть, що ви все ще чекаєте на офіційних серверах.
• Попередньо виділіть. Запросіть сервери, які, на вашу думку, вам можуть знадобитися в майбутньому. Потім повторно призначте їх, коли у вас є реальні потреби.

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

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

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

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

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

Але припустимо, що розробник викликає невпізнанну помилку, яку неможливо налагодити, тому що виникає питання про те, чи не зламалася програма / програма через реалізацію віртуалізації (тобто, що вона не відбудеться в автономному комп'ютері), то це стає контрпродуктивним, щоб витрачати час на спроби відстежити помилку, яка насправді не в програмуванні, а в реалізації VM.

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

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

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

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

Михайло

ІТ-відділ насправді має крапку.

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

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

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

Програмісти повинні програмувати, нехай хлопці з ІТ-інфраструктури надають інфраструктуру, а мережеві хлопці налаштовують мережі - це як корпорації працюють!

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

Вам доведеться скласти свою справу з керівництвом, яке:

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

2. Ви можете реалізувати його більш своєчасно, з меншими витратами, ніж ІТ, і

3. Наявність місцевого контролю знизить витрати та зменшить затримку з часом на ринок та

4. Ви можете задовольнити проблеми ІТ щодо безпеки та обслуговування та

5. На продуктивність програміста це не вплине.

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

Таким чином, ваші продемонстровані економії витрат повинні мати гнучкість у конфігурації та можливість змінити ці конфігурації за мить.