Geliştiricilerin kendi VM sunucularını bir kuruluş ortamında çalıştırmaları için gerekenler [kapalı]

Bu senaryo, farklı izleyiciler için farklı sorularla SO'ya da gönderildi - ve çok iyi yanıtlar aldığım için çok memnunum.

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 "istemci VLAN'larında sunuculara izin verilmez" ile "[boş alanı doldurun] 'a şu anda sahip olunan bir beceri kümesi değil yerel veya kurumsal BT kuruluşu ".

Muhtemelen üretim seviyesi donanım ve resmi BT desteğini haklı çıkarabiliriz (okuyun: eğer ihtiyacımız varsa ihtiyacı haklı çıkarabiliriz, ancak zaman alacak ve çok fazla baş ağrısını içerecekti) - ancak BT kaynaklarını resmi olarak almak aylar alacaktı bunu bir üretim sistemi olarak ele alarak - ve bunu yapsak bile, istediğimiz yerel kontrolü kaybederdik.

Çoğunuzun, üretim dışı ortamların geliştirici kontrolü için kuruluşunuzdaki geliştiricilerle benzer mücadeleler yaşadığını hayal ediyorum, bu yüzden sorularım aşağıdaki gibidir:

1. Geliştiricileriniz, bu tür siloların, bu tür (merkezi olarak) yönetilmeyen altyapıyı genellikle (ve anlaşılır bir şekilde) engelleyecek standart ağ ve güvenlik politikaları olan işletmelerde var olmasına izin vermek için hangi argümanları yaptı?
2. Bu sadece geliştiricilerin teknik veya ticari bir gerekçe oluşturma ve yama yönetimi ve AV'nin - ya da daha fazla kontrol ve sahiplik için siyasi bir mücadelenin - gerçekleşmesini sağlama meselesi midir?
3. Seçim göz önüne alındığında, geliştiricilere yerel yönetici hakları verirken donanım / işletim sisteminin sahipliğini ve desteğini almayı mı yoksa tamamen yönetmelerine izin verirken, yama yönetimi / AV oluşturmalarını ve sorunlara neden olmaları halinde sorumluluk almalarını mı tercih edersiniz?
4. Geliştiricilerin altyapınızda "haydut sunucuların" yerel denetimine sahip olmasını başarılı bir şekilde engellediyseniz, geliştiriciler sadece gerekli zamanı yaptı mı veya geliştirme ortamını bağlantısı kesilmiş bir VLAN / tamamen ayrı ağa mı taşıdılar?

Bu sorunun kapsamını sınırlamak için birkaç varsayım:

1. Tekrarlamak gerekirse, bu bir geliştirme ortamı içindir - üretim yükleri veya desteklenebilirlik gerekmez. Dışarıdan erişilebilecek bir şey yok.
2. 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 - ama 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.
3. Geliştirici ekibi, yama yönetimini ve antivirüsünü yönetmek için zaten güvence verdi veya BT destekleyecekse mevcut kurumsal sistemlerle entegre oldu - ancak bunu kabul etmek isteyip istemediğiniz kesinlikle kapsam dahilindedir.

Her şeyden önce, yöneticilerinizin geri itme haklarının birkaç nedenini görüyorum:

• BT ayrıca yama yönetimi, antivirüs yazılımı, pci uyumluluğu, yıllık (veya daha sık) güvenlik denetimleri, vb. Gibi şeyleri bildirmekten de sorumludur . Sadece bunun halledildiğinden emin olmanız değil, aynı zamanda için bunu kanıtlamak yabancılara.

  Örnek olarak, ağı küçük bir üniversitede çalıştırıyorum ve öğrenci deneyleri için birkaç veri toplama makinesine sahip bir fizik laboratuvarımız var. Yaptıkları tek şey bilimsel bir araçtan veri toplamak ve öğrencinin analiz etmesi ve eğitmene teslim etmesi için sonuçları (doğrudan bağlı bir yazıcıya) yazdırmaktır. Bunlar asla internette - hatta AV ve Windows güncellemeleri yerel ağ üzerinden uygulanır. Ağa bağlı olmalarının ve AV yazılımını çalıştırmanın tek nedeni, izleme yazılımıma hala var olduklarını ve güncel olduklarını açık bir şekilde bildirmektir. Gerçekte ağ bağlantısını kaldırmak için daha güvenli olacakları için aptalca, ancak ilk önce bir eğitim hibesi ile ödendi ve bunlar benim raporlama gereksinimlerim.

• İster beğenin ister beğenmeyin, dev sunucunuz geliştiriciler açısından bir üretim sistemidir. Belki bir ay verin ve geliştiriciler sunucunun kullanılabilir olduğunu varsayarak ayarlayacağınız işlemler nedeniyle çökerse işini yapmakta zorlanacaktır. İşçilerin teknoloji arızaları nedeniyle boşta kaldığı durumlardan kaçınmak / sınırlamak, işletmelerin hala merkezi BT departmanlarını kullanmasının önemli bir nedenidir.
• "ESX Sunucusu Kurumsal Standarttır" ise, bunu izlemeniz gerekir. Şu anda, hyper-v, vmware, xen ve diğerlerinin bir şeyleri nasıl yaptığı arasında önemli farklılıklar vardır ve biri için üretilen bir makinenin diğerinde iyi çalıştığı varsayılamaz. Bunu yapacaksanız, BT'nin bir noktada yönetilmesine yardımcı olması gerekecek ve makinede bir soruna neden olabilecek bir sürü hamleden sonra vmware'e dönüştürmek istemiyorlar.
• Bir gün bu makine eskimiş olacak ve daha düzenli bakıma ihtiyaç duyacak veya standart bir değiştirme döngüsü ayarlayacaktır. Yeni sunucular bile bazen serseri parçalara sahiptir. Bu durum neredeyse her zaman IT'nin kucağına ancak insanların işlerini yapmasını engelleyen bir şey kırıldıktan sonra iner . Sunucunun sorumluluğunu erkenden alarak BT, yolda beklenmeyen kesintilerden kaçınmanızı sağlayarak çok daha iyi bir iş yapabilir.
• Bu kişisel, ama size ağımda istediğim en son şeyin sunucu gibi görünen başka bir masaüstü olduğunu söyleyebilirim . Bana ömür boyu dayanacak son birkaç yılla yeteri kadar uğraştım.

Bununla birlikte, BT'nin bu girişimi desteklemesi gerekiyor. Sadece "Hayır" demeleri yeterli değil. (Çok gerçek) ihtiyaçlarınızı karşılayan bir alternatif bulmalarına meydan okuyun. Buradaki tek politik durum, alternatiflerinin daha büyük bir çıkartma fiyatına sahip olmaları olmalıdır (çünkü henüz göremediğiniz maliyetleri planlıyorlar) ve bu yüzden soru bunun için kimin ödeme yapması gerektiği olacaktır. Bunu yapmak istemiyorlar çünkü bunun için bütçe oluşturmadılar, ama balkacaksınız çünkü mutlu olduğunuz bir çözüm için (şu an için) harcadığınız 6 kat.

Ayrıca, yürümeden önce koşmaya çalışıyormuşsunuz gibi geliyor. Geliştirme sürecinizi yenilemek istiyorsunuz. Eski bir geliştirici olarak, bence bu harika. Ancak sadece bir grup sanal makine ve "ortam" atmayın (ör: dev, sahne, qa, vb.). Yeni süreçlerin nasıl görüneceğini planlayın - geliştiriciler nasıl iş yapacak? Sürekli entegrasyon kullanacak mısınız? Otomatik yapılar? Onları desteklemek için hangi yazılımı kullanıyorsunuz? Geliştiricilerin kodu üretime veya evrelemeye taşımasına izin verilecek mi, yoksa yalnızca KG bu yeteneğe sahip olacak mı? Ayrı bir aşamaya mı ihtiyacınız var? İki geliştirme dalına ne dersiniz (biri vNext için, biri vCurrent olan hatalar için)?

Bir geliştirme sunucusunun veya yöneticinin tüm bunları çözebilmesi için bir sunucuya ihtiyacınız olabilir, ancak eğer öyleyse bunun ilk adım olması gerekir ve kurulum ve ilk süreç tasarımının geliştiriciler gerçekte eline geçmeden önce yapılması gerekir. kullanın.

1) Geliştiricileriniz, bu tür siloların, bu tür (merkezi olarak) yönetilmeyen altyapıyı genellikle (ve anlaşılır şekilde) engelleyecek standart ağ ve güvenlik politikaları olan işletmelerde var olmasına izin vermek için kazandıran argümanları yaptı. ?

Hiçbiri - çoğunlukla kuruluşumda bir yönetim rolü oynamadığım için, bu "siyasi şeylerden" hiçbiri beni gerçekten etkilemiyor. Beni gerçekten ikna edecek tek argüman, ağ politikasına açıkça aykırı olan ve hem sistem operasyonları ekibi kontrolünden hem de görünürlükten muaf tutulan bir şeye izin vermektir.

Gerçekten "Hayır" diyen bir iş olmak istemiyorum, bunun sadece operasyon ekibinin bakış açısından iyi bir şekilde bitmesinin bir yolu yok.

1. Birincil beceri kümesinin ağdaki tüm ağı ve ilişkili sorun alanını göremeyen sunucuları yönetmediği kişilerle yönetiyoruz. Bu sadece çimin "korunması" için politik bir mesele değildir; bir örnek olarak, bir geliştirici bir nedenle DHCP'yi açtığında ne olacağını hayal edin.
2. Sonunda onlar için geliştirme ekibinin sunucularını yönetiyoruz. Bu tam tersi sebepten dolayı dağınık. Geliştiriciler sürekli olarak bu yamayı (bildikleri ama bilmediğimiz bir şeyi kırarak) ya da çeşitli iyi nedenlerle etkinleştirilmesini istemediğimiz özellikleri etkinleştirmek için mücadele ettiğimizden rahatsız oluyorlar. Bu, hızlı bir şekilde operasyon ekibinin yüklendiğini ve taciz edildiğini ve geliştirme ekibinin hayal kırıklığına uğradığını ve göz ardı edildiğini hissettiği bir kilitlenmeye dönüşür.
3. Siyasi sonuçlar var - çünkü o zaman başka bir departmana geliştiricilerin neden "özel" olduğunu ve neden ağ politikasından muaf olduklarını açıklamanız gerekiyor.

2) Bu sadece geliştiricilerin teknik veya ticari bir gerekçelendirme yapmalarını ve yama yönetimi ve AV'nin - ya da daha fazla kontrol ve mülkiyet için politik bir mücadelenin - gerçekleşmesini sağlama meselesi mi?

Geliştiricilerin bir iş vakası oluşturması gerektiğini düşünmüyorum - geliştiricilerin geliştirmesi gerektiği ve bunu yapmak için bir tür geliştirme ortamına ihtiyaç duydukları oldukça açık. Yama yönetimi ve AV için - bu operasyon ekibi işi ve bunun yapılmasını sağlayacağız. Geliştiricilerin bunu yapamayacağını düşünmüyoruz. Sadece doğru yaptığınıza güvenmiyoruz - Sistem Yöneticileri Sistem Yöneticileri olarak kalıyor çünkü hiçbir şey yapmak için hiçbir şeye güvenmiyorlar, bu yüzden kişisel bir şey değil . Elbette, başkasının "işinizi yapıyor" gibi hissettirdiği bariz bir politik sorun var ama bu gerçekten teknik bir sorun değil ve bu nedenle SF'nin kapsamı dışında.

3) Seçim göz önüne alındığında, geliştiriciye yerel yönetici hakları verirken donanım / işletim sisteminin sahipliğini ve desteğini almayı mı yoksa tamamen yönetmelerine izin verirken, yama yönetimi / AV oluşturmasını ve neden olurlarsa sorumluluk almalarını mı tercih edersiniz? sorunlar?

İkisi de yukarıda belirtilen nedenlerden dolayı.

4) Geliştiricilerin altyapınızda "haydut sunucuların" yerel denetimine sahip olmasını başarılı bir şekilde engellediyseniz, geliştiriciler sadece gerekli miydi yoksa geliştirme ortamını bağlantısız bir VLAN / tamamen ayrı bir ağa mı taşıdınız?

Hava boşluğu. Bu durumla başa çıkmanın en iyi yolu, geliştiricilere ortamlarını (ve kontrolünü) vermek ve daha sonra hava boşluğu bırakmak veya ağdan ayırmak için başka bir sağlam yöntem kullanmaktır. Bu aslında kamu wifi nasıl ele. Wifi hizmeti mi istiyorsunuz? Elbette. Ağ bağlantısı için ödeme yaparsınız, WAP'ları yönetiriz, ancak asla ağımıza dokunmaz. Afedersiniz. İhtiyaçlarınız yüzlerce kişiden biri. Dikkate almamız gereken başka endişeler de var.

Hayır demekle uğraşmak istemezsiniz, çünkü (özellikle teknik olarak zeki olan) geliştiriciler istediklerini elde etmenin yollarını bulacaktır. Bu yüzden onlara ihtiyaçlarına uygun bir ortam sağlayın, onları mutlu edin ve geliştirme ortamında yaptıkları her şeyin iş ağınızın geri kalanına dokunmasını önlemek için bir yol bulun .

TL; DR: Ayrı bir fiziksel ağda veya VLAN'da istediğiniz sanallaştırma platformuna sahip bir sunucu veririm. Geliştirme ortamınıza erişim, operasyon ekibinin kontrol edeceği ve izleyeceği tek bir bodrum ana bilgisayarı aracılığıyla olacaktır. İşinizle ne yaparsınız - Desteklenmeyecektir, ancak işlerin sunucu yönetimi tarafı için zaman izin verdiği için tavsiye ve yardım sağlayacağız.

Bana tüketici sınıfı RAM, tüketici sınıfı HDD'ler, tüketici sınıfı PSU ve tüketici sınıfı RAID ile kabzaya yüklenmiş bir iş istasyonu sınıfı makine ile geldiyseniz, onu sunucu ağına da koymayı reddederim.

Sunucu VLAN'ına böyle bir şey koymak hakkında bilmeniz gereken çok şey var.

1. Sunucu VLAN çok iyi bir DMZ olabilir. Bir DMZ'ye sertleştirilmemiş ve sabitlenmemiş hiçbir şey koymayın . Bu sadece onlara verdiğin bir makinedir, onunla ne yaptığını bilmiyorlar. Aynı zamanda düzenli yama ve güncellemeler, yani merkezi olarak yönetilmesi anlamına gelir. Eminim her yönetilmeyen sunucuda oturum açmayacaksınız ve yamaları elle uygulayamayacaksınız.

2. Bu makinedeki bileşenler arızalanacak. Söz veriyorum. 6 veya 12, 24 ay içinde göbek yukarı çıkacak. Peki, yedeklemeler nerede? Onları kurmadın mı? Ama bir sunucu olduğunu mu sanıyordum? Ah, başkasının sağladığı bir sunucu mu? ... ve suçlama oyunu yeniden başlıyor

3. Kazaya çarptığında ve boktan fanı vurduğunda kim sorumluluk alacak? En organizasyonlarda olduğu "Bakmam gereken dev en verdi" değil uçacak.

4. Nereye koyacaklar? Sunucuların hepsi bu günlerde rafa monte edilmiş ve bir rafa bir kule koymak alan israfı ve rafları bunun için tasarlanmamış olabilir.

Bu nedenle, BT departmanı bu rastgele bilgisayarı sunucu ağlarına koymamak konusunda haklı.

Ancak SİZİN işinizi düzgün yapabilmeniz BT departmanlarının işidir. İhtiyacınız olan her şeye sahip olduğunuzdan emin olmanız gerekir. Eğer iş o yazılım parçası varsa ihtiyaçlar çalışmasını sağlamak için, onlar var o çalıştırmak için bir platform sağlamaktır. Bu onların iş tanımı. Ancak işlerini yapmak için ihtiyaç duydukları bilgilere sahip olduklarından emin olmalısınız.

Bana organizasyonumda gelseydiniz, yeni bir projeye başladığınızı söylediyseniz, size üç sanal makine verirdim: Dev, Live ve Staging. Dev için tam yönetici haklarına sahip olacaksınız ve diğer ikisi için işinizi yapmak için neye ihtiyacınız olduğunu tartışacağız. Onlar için tam yönetici haklarına ihtiyacınız varsa ve bunu haklı çıkarırsanız, o zaman alırsınız. VM dağıtımımız düşük seviyededir. VMWare bunu inanılmaz derecede basitleştiriyor - her VM için dağıtılması sadece 5 dakika sürüyor.

BT departmanınız, büyük bir şirketteki her BT departmanından muzdarip olandan muzdarip gibi görünüyor. Küçük kaleler inşa etmek ve onları hayatınızla savunmak, başkalarına izin vermemek, otoriter olmak vb. Her gün başkalarının BT departmanlarıyla ilgilenen biri olarak bunu her zaman görüyorum. Ve bu sinir bozucu.

Temel gerçek şu ki, değişimin BT departmanından yapılması gerekiyor ve bunların üstünden başlatılması gerekiyor. Ve eğer BT'nin kendilerine bir güç olmadığını fark etmelerini sağlayabilirseniz (çoğu, işleri için gelir üretmediği için, bu karşısında bir tokat olabilir) ve mevcut personeli desteklemek için oradalar. ve işinizi geliştirirseniz , sorularınızın alakasız hale geldiğini görürsünüz, çünkü herkes mutlu aileler oynayacaktır.

Neden etki alanına eklenmesini istiyorsunuz? Başka bir deyişle, soruyu daha iyi yanıtlayan: Kurumsal LAN'a bağlı olmadığı sürece, istediğiniz her şeyi yapmak için bir laboratuvar kurabilirsiniz. (İnternet erişimine ihtiyacınız varsa, belki bir DMZ-ed VLAN alabilirsiniz; bu, özellikle indirme için olduğu gibi sadece dışarı çıkmak için kullanıyorsanız, bir sorun olmamalıdır .)

Bu, sorunun birçok, birçok, farklı cevabından biridir.

Burada, ortamın herhangi bir bölümüne yönetici erişimine sahip geliştiricilere (muhtemelen çoğunlukla karşı) çok sayıda cevap alacaksınız, ancak sonuçta:

Sysadmin grubu, üretim sistemlerini çalışır durumda, istikrarlı ve güvenli tutmakla görevlendirilmiştir ve bu sistemlerin şirketin ödediği hizmetleri (çünkü onlar için ödeme yapıyorlar) bekledikleri seviyelerde sağladığından emin olmaktan sorumludur.

Benzer şekilde, geliştirici ekibinin şirkete (web, uygulamalar vb.) Farklı bir alanda da olsa hizmet vermesi görevlendirilmiştir. Geliştirme ortamı üzerinde kontrol için mücadele etmek verimsizdir ve her iki taraf için de yararlı bir amaca hizmet etmez.

Küçük bir ISV / ASP'de çalışıyorum. Bir geliştiricimiz ve bir sistem yöneticimiz var (ben). Karşılıklı saygı ve güvene dayalı bir ilişkimiz var. Şirketin kapsayıcı hedeflerine ulaşmak için bir ekip olarak çalışmalıyız. Geliştiriciye, iş istasyonları ve sunucuları içeren geliştirici ortamına tam ve sınırsız erişim sağlıyorum. Güvenlik, güncellemeler, AV ve donanım için geliştirme sistemlerini yönetiyorum ve gerisini de geliştiriyor. Kodu üretime hazır olduğunda, bana uzatır, gereken herhangi bir konfigürasyonda bana yardım eder ve geri adım atar. Birbirimize karşılıklı yardım sağlıyoruz.

Geliştiriciler, geliştirme ortamının efendileri olmalı ve Sysadmins, makul sınırlar içinde ve makul kontroller, dengeler ve kontrollerle üretim ortamının efendileri olmalıdır. Her iki tarafın da “geçmesi” gerektiğinde, onların görüş ve rehberliği altında “hüküm süren” parti ile işbirliği içinde olmalı ve birlikte olmalıdır.

Her şeyden önce, deneyimim kesinlikle daha küçük bir organizasyonda, ancak bu sorun her boyutta şirkette ortaya çıkıyor, bu yüzden ...

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

Bana göre, geliştiricilerin yapması gereken tek argüman "buna ihtiyacımız var". Önce bana gelselerdi, onların ihtiyaçlarını anlamaya ve neler yapabileceğimizi görmeye çalışırdım. Ama sonuçta, "buna ihtiyacımız var" derse, onlara ne yaptıklarını bildikleri konusunda şüphe ve güvenden yararlanırdım.

Ama bu sadece başlangıç ​​- denklemin "Pro" tarafı. "Con" biz boğulmaya girdiği yerdir ...

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

"Sadece" inanılmaz bir eksiklik dışında, evet, eğer geliştiriciler teknik ve ticari bir gerekçe oluşturabilirlerse, bir sorun olmazdı. Diğerleri burada ve programcılar üzerinde.SE (SO sorunuzun taşındığı yer) kurulumunuza bir ton tuzağa işaret etti, bu yüzden onları tekrarlamayacağım. Tüm bu sorunlarla ve BT departmanınızın düşündüğü ve TÜM maliyetleri haklı çıkaracak bir planla karşılaşırsanız , devam etmek mantıklıdır.

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

Bu bir başlangıç ​​değil, aynı sistemleri yönetmeye çalışan farklı hedef ve sorumluluklara sahip iki grubunuz olamaz. Sadece kötü bitmeyecek, kötü başlayacak ve kan dökülecek.

(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?

Sanırım bu benim 2'ye cevabım tarafından kapsanıyor: bunlar için çözümler bulmaları gereken teknik detaylar.

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'ye katılıyorum: "Hava boşluğu"

Geliştirdikleri ek yükü haklı çıkarabilirlerse (çevrelerinin yöneticileri olarak) geliştiriciler, ücretsiz dizginlendikleri kendi mini ağlarına sahip olabilirler, ancak tamamen karantinaya alınır: hiçbir şey ağın geri kalanına dokunmaz. Bu nedenle, daha fazla teknik ve ticari gerekçe ortaya koymaları gerekiyor, örneğin "kritik verileri nasıl yedekleyeceğiz?"

Yine, kce ile aynı fikirdeyim: "Sistem Yöneticileri Sistem Yöneticilerini kalır, çünkü doğru bir şey yapmak için hiçbir şeye güvenmezler." Bizim işimiz, güvenilir olmayan bileşenlerden elde edebileceğimiz en güvenilir sistemleri oluşturmaktır. deneyimli bir sistem yöneticisinin bildikleri inanılmaz derecede lapa lapa şeyleri güçlü bir olumsuz tepki alacaktır.

Buradaki ve programcılar üzerindeki cevap ve yorumlardan. Bence, bunun dikkate almadığınız yönleri olduğu açık. Daha uzun sürmesine rağmen, BT adamlarınızla gerçekten konuşup konuşmanız ve farklı şeyler sunmanız gerektiğini düşünüyorum: "İşte yapmamız gereken şey, bunu mevcut altyapı ve operasyonlara entegre etmenin herhangi bir yolu var mı?"

Sizin ve milyonlarca benzer vakanızdaki genel sorun:

1) Bulanık sorumluluk - bir şirket çalışanının eylemleri ile kârları arasında doğrudan bir bağlantı yoktur. Ödemesi daha zor olan etkilerle değil, aylık olarak ödenir, organizasyon daha büyüktür. Güvenlik, yöneticiler, vb. İçin geçerlidir. Çalışmanızı paralize ederse, umursamazlar.

2) Politika yapıcılar ve güvenlik genellikle programlama hakkında çok az bilgiye sahiptir. Onlar umursasalar bile (genellikle geçerli değildir) çalışmanızı felç ettiklerini anlayamadılar.

3) Güvenlikte çalışmak için tercih edilen psikolojik profil paranoid kişilik veya obsesif kompulsif bozukluktur. Bu insanlar komployu her yerde görüyor. Geliştiriciler yeni sunucu gibi bir şey isterse, kesinlikle kurumsal verileri çalmak ve WikiLeaks'te yayınlamak veya Kuzey Kore'ye satmak için kullanmak isterler.