Kurumsal Ağlarda Sanallaştırılmış Geliştirme Ortamları

Kurumsal bir kuruluştaki 4 geliştiriciden oluşan küçük bir ekip için sanallaştırma kullanarak bir geliştirme ortamı uygulamaya çalışıyoruz. Bu, ayrı geliştirme, test ve hazırlama ortamları oluşturmamıza ve değerlendirdiğimiz sistemler veya araçlar için gereksinimler olan yeni işletim sistemlerine erişmemize olanak tanır. Mevcut bir iş istasyonu sınıfı makineyi yeniden tasarladık, 24 GB RAM ve RAID-10 ile attık ve makineyi etki alanına eklemeye çalışana kadar iyiydik.

Şimdi, zamanın başlangıcından bu yana tüm kurumsal geliştiricilerin savaşmak zorunda kaldığı savaşa başlıyoruz - bir geliştirme ve test ortamının yerel kontrolü için mücadele. Ağ ve BT yöneticileri, "ESX Sunucusu kurumsal standarttır" ile "sunucu VLAN'larında sunuculara izin verilmez" ile "[boş alanı doldurma] arasında şu anda yerel olarak sahip olunan bir yetenek kümesi değil veya kurumsal BT organizasyonu ".

Gerekirse üretim sınıfı donanım ve resmi BT desteğini haklı çıkarabiliriz, ancak zaman alacak ve çok fazla baş ağrısını içerecekti. O zaman bile, bunu bir üretim sistemi olarak ele alarak BT kaynaklarını resmen tahsis etmek aylar alabilir - ve yapsak bile, ihtiyacımız olan yerel kontrolü kaybedebiliriz.

Birçoğunuzun üretim dışı ortamların geliştirici kontrolü - ve özellikle sanallaştırma - üzerinde benzer mücadeleler yaşadığını hayal ediyorum, bu yüzden sorularım aşağıdaki gibi:

1. Hangi tür stratejiler ve argümanlar, bu tür siloların genel olarak (ve anlaşılır şekilde) bu tür olmayan ( merkezi) yönetilen altyapı?
2. Bunun teknik bir gerekçe mi, yoksa daha çok kontrol ve mülkiyet için politik bir mücadele mi olduğunu buldunuz mu?
3. BT tarafından yönetilen bir geliştirme ortamına ulaştıysanız, günlük geliştirme ve test için ne kadar birlikte gösterim yapıldı?
4. Bu ağ erişim mücadelelerinden kaçınmak için geliştirme ortamını bağlantısı kesilmiş bir VLAN'a veya tamamen ayrı bir ağa taşıyan biri oldu mu?

Ayrıca, bu bir Hyper-V ve ESX kutsal savaşı değil (her ikisiyle de iyi olacağız - ancak Hyper-V, bu amaçlar için MSDN ile "ücretsiz" olduğu için seçildi [evet, VMWare'in ücretsiz araçları da var - ancak iyi yönetim araçları genellikle değildir] ve yerel geliştiriciler tarafından bir "Microsoft Shop" da yönetilmesi daha kolay olacaktır) - bu nedenle, bunlardan herhangi biri için veya bunlara karşı olan argümanlar bu sorunun kapsamı dışındadır.

Bu aynı zamanda sanallaştırmaya karşı fiziksel donanıma göre daha azdır - denklemin sanallaştırma bileşeni olmadan aynı sorunun da sorulabileceğini düşünüyorum.

Ayrıca dev ekibinin yama yönetimi ve antivirüs yönetimi için zaten güvence verdiğini veya destekleyeceklerse mevcut kurumsal sistemlerle entegre olduğunu varsayalım. Farklı senaryolara sahip bu senaryo, umarım karşıt bakış açısını ortaya çıkarmak için SF'de de yayınlanmıştır .

"Rezervasyondan çıktınız" ve bunu haklı çıkarmaya çalışıyorsunuz.

Bu sanallaştırma ile ilgili değil; Bu, kontrol ve sorumluluk ile ilgilidir. BT departmanı, şirket sistemlerinin güvenliği ve güvenilirliğinden sorumludur. Çalıştıklarından emin olmak için BT onları kendi kontrolleri altında tutar. BT'nin kontrolü altında olmayan bir sistem oluşturdunuz ve şimdi bir sorun haline geliyor.

Programcıların deneyimlerime göre kendi sistemlerini istemelerinin genel nedenleri:

• BT duyarlı değil. Yeni bir ortam elde etmek haftalar sürüyor, ancak şimdi bir ortama ihtiyacınız var.
• Kontrole ihtiyacınız var; Size vermeyecekler. İzinleri ayarlayabilmeniz, bileşenleri yükleyebilmeniz gerekir. BT size izin vermeyecektir.

Nihayetinde, üretime gittiğinizde, tamamen kilitli olan BT tarafından yönetilen bir sistem isteyeceksiniz. Ancak gelişirken esnekliğe ihtiyacınız var. Bazı öneriler:

• Arkadaş edin. BT'deki bazı insanları tanımak; Onlarla yüz yüze konuşun. Durumunuzu açıklayın ve onlara neler yapılabileceğini sorun. Basitçe sorarak bir dev sunucusunda yönetici haklarına sahip olabilirsiniz.
• Yerel Çalıştır. Uygulamanın bazı bölümlerini yerel makinelerinizde çalıştırabilirseniz, bir sunucuya ihtiyacınız olmayabilir veya kilitli bir DB yönetim ortamıyla kurtulabilirsiniz.
• Sponsor Alın. Hiçbir şey BT'nin VP'ye gelip "Projemi neden engelliyorsunuz?" Proje sponsorunuzun gücünü kullanın.
• Buluta! Proje bütçeniz bunu karşılayacaksa, sadece EC2'ye ev sahipliği yapın - tüm BT departmanınızı atlayın. Riskler saldırıya uğramakta ve şirket bilgilerinin güvenlik duvarı dışına çıkması nedeniyle işten çıkarılmaktadır.
• Uzun Oyunu çalıştırın. Uygun şekilde yetkilendirilmiş ve yönetilen sunucular için talepleri erkenden bildirin. Homebrew'unuz hakkında şikayet aldığınızda, hala resmi sunucularda beklediğinizi söyleyin.
• Preallocate. İleride ihtiyaç duyabileceğinizi düşündüğünüz sunucular talep edin. Ardından, gerçek ihtiyaçlarınız olduğunda bunları yeniden hedefleyin.

Bunlar gibi bir amatör olduğum kadar, departman başkanlarına BT kaynaklarının ekstra masrafına (ve genişliğine) olan ihtiyacı haklı çıkarmak için uygun ve iyi yapılandırılmış bir argümanın gerekli olduğu görülmektedir. Muhtemelen konulara aracılık edebilen ve teklifin potansiyel değerini, bunun için ödeme yapan kullanıcılarla ilişkilendirebilen iyi bir konuşmacı istiyorsunuz.

Sorun aslında gerçek dikkate değer bir sorundur: Bir grup Dev ortamını istiyor, ancak diğer gruba, kendisini özellikle BT departmanlarının haklı olduğu bir şey olan, ağın genel sisteminin güvenliğinden sorumlu olan, gerçekten sorumlu olan diğer gruba biraz baskı uygular. kıymetli.

Potansiyel olarak kazançlı bir proje için belirli kaynakları, hatta geliştiriciler için sadece özgür bir ortamın dışında bırakabilme yeteneğinin, şimdi maliyet azaltma ve kaynak kontrol önlemi olarak Sanallaştırma için bir piyasa rasyonalizasyonu ile üstünleştiğine dikkat çekiyor.

Şimdi beni yanlış anlamayın, sanallaştırmaya karşı değil, ondan uzak değilim. Ama bana öyle geliyor ki, bir geliştirme grubunun, her şeyi sanallaştırmaktan daha verimli ve potansiyel olarak daha güvenli bir ortam olacak ayrı bir bölgeye hak kazanmasına izin vermek için genellikle çok iyi ve açıklanabilir rezonlar vardır.

Bir işletme, ofisler arası düzenli departmanlar için bulutu kullanarak paradan tasarruf edebileceğinden emin olun, orada çok yararlıdır. (bu bir çeşit sanallaştırma, ama farklı, biliyorum)

Ancak bir geliştiricinin, uygulama / programın bir sanallaştırma uygulaması nedeniyle (yani tek başına bir bilgisayarda gerçekleşmeyeceği) nedeniyle kırılıp kırılmadığı hakkında bir soru olduğu için hata ayıklanamayan tanımlanamayan bir hata oluşturduğunu varsayalım. aslında programlamada değil, VM uygulamasında hatayı izlemeye çalışırken zaman kaybetmeye karşı üretken hale gelir.

Umarım netleşirim. Özel durumunuz için cevabım yok, ancak bunların sorun açısından umarım faydalı düşünceler olduğunu düşünüyorum ve bu tür konuların ilgili her iki departmanla ve belki de temsilcinin bir temsilcisi ile açıkça ve tamamen tartışılmasını şiddetle tavsiye ediyorum. nihayetinde satın alma için dava açmak zorunda kalacak kurumsal yönetim. Bu yüzden iyi bir konuşmacı veya aracı önerim!

Muhtemelen daha fazla çalışan gerektiriyorsa, bu olumlu bir şey olabilir (orada çok sayıda işsiz insan var), ancak geliştirici bölümünde kendi grupları için sunucu yöneticisi gibi bir rol eklemek için yeterli BT zekası olabilir mi?

Aslında oldukça önemli olduğunu biliyorum, bu yüzden küstah olmak istemiyorum, ancak mevcut işçilere konsolidasyon ve rollerin eklenmesinin kişisel zamanlarında çok fazla yük bıraktığını düşündüğüm zamanlar var. özellikle de radikal olarak yeni ve başarılı bir yazılım mühendisliğinin bir parçası olabildiklerinde.

Sorununuzu kıskanmıyorum, ancak yeni tasarımlar, yeni yazılımlar ve yeni fikirler getirmekle tamamen meşgul olan işyerini kıskanıyorum. Size içtenlikle iyi şanslar diliyorum ve katkılarımın bir miktar yardımcı olacağını umuyorum.

Mihaly

BT departmanının aslında bir anlamı var.

Muhtemelen yüzlerce sistemdeki binlerce uygulamayı yönetiyorlar. Bunu etkili bir şekilde yapabilmelerinin tek yolu, daha az standart donanım yapılandırmasında çalışan birkaç seçili standart yazılım yığınına sahip olmaktır.

Bu rotayı takip ederseniz üretime yaklaştıkça daha fazla sorunla karşılaşırsınız - en kötü senaryoda, yayına başlamadan günler önce standart bir üretim ortamında çalışmak için tüm uygulamayı yeniden hesaba katmanız gerekir.

BT grubuyla çalışmak ve sizin için bazı standart test ortamlarını yapılandırmalarını istemek daha iyidir. - İronik olarak, muhtemelen her ortam için sanal makine kuracaklar.

Programcılar, BT altyapı elemanlarının altyapıyı sağlamasına ve ağ çalışanlarının ağları yapılandırmasına izin vermelidir - şirketler nasıl çalışır!

Ayrıca uygulamanız standart dışıysa, BT bir test ortamı oluşturmayı düşünmeyecekse, bunu üretime alma şansınız sıfır olacaktır. Kurumsal mimarlarla konuşun, hangi ortamların standart olduğunu öğrenin ve bunları kullanmaya çalışın. Uygulamanızı standart yazılım / donanım kullanarak gerçekten uygulayamıyorsanız, kurumsal mimariden altyapınızı istisnai bir durum olarak onaylaması için resmi bir talepte bulunmanız gerekir.

Aşağıdaki durumlarda yönetim ile davanızı açmanız gerekecektir:

1. Sanallaştırılmış ortamın , şirketin özel olarak belirtilen gereksinimlerinden birini veya daha fazlasını karşılaması (birden çok platformu destekleme esnekliği gibi) ve

2. BT'den daha az maliyetle daha zamanında uygulayabilirsiniz ve

3. Yerel kontrole sahip olmak maliyetleri düşürür ve pazara sunma gecikmelerini azaltır ve

4. BT'nin güvenlik ve bakım endişelerini karşılayabilir ve

5. Programcı verimliliği etkilenmeyecektir.

Sonuncusu ise büyük .   Bu konuyu bu tür sanallaştırma konusunda uzmanlaşmış birkaç kişiyle tartıştım. Bana, bunu yerel bir PC kadar duyarlı hale getirmek için yeterli donanım attığınızda, herhangi bir donanım maliyeti tasarrufu olmayacağını söylüyorlar.

Dolayısıyla, kanıtlanmış maliyet tasarruflarınızın yapılandırma esnekliği ve bu yapılandırmaları bir an önce değiştirebilme şeklinde olması gerekecektir.