Apa yang diperlukan bagi pengembang untuk menjalankan server VM mereka sendiri di lingkungan perusahaan [ditutup]

Ini skenario juga diposting di SO , dengan pertanyaan-pertanyaan yang berbeda untuk audiens yang berbeda - dan saya sangat senang saya lakukan karena saya telah menerima beberapa tanggapan yang sangat baik.

Kami berusaha menerapkan lingkungan pengembangan menggunakan virtualisasi untuk tim kecil yang terdiri dari 4 pengembang dalam organisasi perusahaan. Ini akan memungkinkan kami untuk mengatur pengembangan terpisah, pengujian, dan lingkungan pementasan - serta memungkinkan akses ke sistem operasi baru yang merupakan persyaratan untuk sistem atau alat yang kami evaluasi.

Kami bertujuan ulang mesin kelas workstation yang ada, melemparkan dalam RAM 24GB dan RAID-10, dan baik-baik saja sampai kami mencoba untuk mendapatkan mesin ditambahkan ke domain.

Sekarang kita memulai perang yang harus dilawan semua pengembang perusahaan sejak awal - perjuangan untuk kontrol lokal terhadap lingkungan pengembangan dan pengujian. Jaringan dan admin TI telah menimbulkan sejumlah kekhawatiran mulai dari "ESX Server adalah standar perusahaan" hingga "server tidak diizinkan pada VLAN klien" hingga "[isi-kosong] bukan keahlian yang saat ini dimiliki di organisasi TI lokal atau perusahaan ".

Kami mungkin dapat membenarkan perangkat keras tingkat produksi dan dukungan TI formal (baca: kami dapat membenarkan kebutuhan jika kami harus melakukannya, tetapi itu akan memakan waktu dan melibatkan banyak sakit kepala) - tetapi mungkin akan memakan waktu berbulan-bulan untuk secara resmi mendapatkan sumber daya TI ditugaskan dengan memperlakukan ini sebagai sistem produksi - dan bahkan jika kita melakukannya, kita mungkin akan kehilangan kontrol lokal yang kita inginkan.

Saya membayangkan bahwa banyak dari Anda memiliki perjuangan yang sama dengan pengembang dalam perusahaan Anda untuk kontrol pengembang dari lingkungan non-produksi, jadi pertanyaan saya adalah sebagai berikut:

1. Argumen apa yang telah dibuat oleh pengembang Anda yang membuat Anda lebih dari itu untuk memungkinkan jenis silo ini ada di dalam perusahaan yang memiliki jaringan standar dan kebijakan keamanan di tempat yang umumnya (dan dapat dimengerti) menghalangi jenis infrastruktur yang tidak dikelola (terpusat) yang dikelola?
2. Apakah ini hanya masalah pengembang membuat pembenaran teknis atau bisnis dan memastikan bahwa manajemen patch dan AV akan terjadi - atau lebih dari perjuangan politik untuk kontrol dan kepemilikan?
3. Diberi pilihan, apakah Anda lebih suka mengambil kepemilikan dan dukungan perangkat keras / OS sambil memberikan hak administrator lokal devs, atau membiarkan mereka mengelolanya sepenuhnya, sambil memastikan bahwa mereka melembagakan manajemen patch / AV dan menagih mereka dengan tanggung jawab jika mereka menyebabkan masalah?
4. Jika Anda berhasil memblokir pengembang dari memiliki kontrol lokal "server jahat" pada infrastruktur Anda, apakah pengembang hanya membuat jatuh tempo atau apakah mereka (atau Anda) memindahkan lingkungan pengembangan ke VLAN / jaringan yang sepenuhnya terpisah?

Beberapa asumsi untuk membatasi ruang lingkup pertanyaan ini:

1. Untuk mengulangi, ini untuk lingkungan pengembangan - tidak ada beban produksi atau dukungan yang diperlukan. Tidak ada yang dapat diakses secara eksternal.
2. Ini bukan perang suci Hyper-V vs ESX (kami akan baik-baik saja dengan baik - tetapi Hyper-V dipilih karena "bebas" dengan MSDN untuk tujuan ini [ya, VMWare memiliki alat gratis juga - tetapi manajemen yang baik alat umumnya tidak], dan akan lebih mudah dikelola oleh pengembang lokal di "Microsoft Shop") - jadi argumen untuk atau menentang keduanya berada di luar cakupan pertanyaan ini.
3. Tim pengembang telah membuat jaminan untuk mengelola manajemen tambalan dan antivirus, atau berintegrasi dengan sistem perusahaan yang ada jika TI akan mendukungnya - tetapi tentu dalam lingkup apakah Anda bersedia menerimanya atau tidak.

Pertama-tama, saya melihat beberapa alasan mengapa admin Anda benar untuk mendorong balik:

• TI juga bertanggung jawab untuk melaporkan hal-hal seperti manajemen tambalan, perangkat lunak antivirus, kepatuhan pci, audit keamanan tahunan (atau lebih sering), dll. Ini bukan hanya soal memastikan Anda bahwa ini sudah diatasi, tetapi juga mampu untuk membuktikannya kepada orang luar.

  Sebagai contoh, saya menjalankan jaringan di sebuah perguruan tinggi kecil, dan kami memiliki laboratorium fisika dengan beberapa mesin pengumpulan data untuk eksperimen siswa. Satu-satunya hal yang mereka lakukan adalah mengumpulkan data dari instrumen ilmiah dan mencetak hasilnya (ke printer yang terpasang langsung) untuk dianalisis dan diserahkan kepada instruktur. Mereka tidak pernah ada di internet - bahkan pembaruan AV dan Windows diterapkan melalui jaringan lokal. Satu-satunya alasan mereka terhubung ke jaringan dan menjalankan perangkat lunak AV sama sekali adalah tujuan eksplisit melaporkan ke perangkat lunak pemantauan saya bahwa mereka masih ada dan saat ini. Ini konyol, karena pada kenyataannya mereka akan lebih aman untuk menghapus koneksi jaringan, tetapi mereka pertama kali dibayar dengan hibah pendidikan dan itu adalah persyaratan pelaporan saya.

• Suka atau tidak, server dev Anda adalah sistem produksi dari sudut pandang pengembang. Berikan mungkin sebulan, dan pengembang akan mengalami kesulitan menyelesaikan pekerjaan jika itu turun karena proses Anda akan mengatur yang menganggap server tersedia. Menghindari / membatasi situasi di mana pekerja menganggur karena kegagalan teknologi adalah alasan utama bisnis masih menggunakan departemen TI yang terpusat.
• Jika "ESX Server adalah Standar Perusahaan", Anda harus mengikuti itu. Pada saat ini, ada perbedaan yang signifikan antara bagaimana hyper-v, vmware, xen, dan lainnya melakukan hal-hal, dan mesin yang dibangun untuk satu tidak bisa diasumsikan berjalan dengan baik di sisi yang lain. Jika Anda akan melakukan ini, IT akan perlu untuk membantu mengelolanya di beberapa titik, dan mereka tidak ingin harus mengubahnya ke vmware setelah ada banyak celah pada mesin yang mungkin menyebabkan masalah.
• Suatu hari mesin ini akan menjadi tua, dan membutuhkan perawatan yang lebih teratur atau menyiapkan siklus penggantian standar. Bahkan server baru terkadang memiliki bagian gelandangan. Situasi ini hampir selalu mendarat di pangkuan IT hanya setelah sesuatu yang rusak yang mencegah orang melakukan pekerjaan mereka. Dengan mengambil tanggung jawab untuk server lebih awal, TI dapat melakukan pekerjaan yang jauh lebih baik memastikan Anda menghindari pemadaman yang tidak direncanakan di jalan.
• Ini pribadi, tetapi saya dapat memberitahu Anda bahwa hal terakhir yang saya inginkan di jaringan saya adalah desktop lain yang menyamar sebagai server. Saya sudah berurusan dengan cukup banyak dari mereka beberapa tahun terakhir untuk bertahan seumur hidup saya.

Karena itu, TI harus dapat mendukung inisiatif ini. Tidak cukup bagi mereka untuk hanya mengatakan, "Tidak". Tantang mereka untuk datang dengan alternatif yang memenuhi kebutuhan Anda (sangat nyata). Satu-satunya situasi politik di sini adalah bahwa alternatif mereka cenderung memiliki harga stiker yang lebih besar (karena mereka sedang merencanakan biaya yang belum dapat Anda lihat), sehingga pertanyaannya adalah siapa yang harus membayar untuk itu. ITU tidak akan mau karena mereka tidak menganggarkan untuk itu, tetapi Anda akan menolak karena itu 6 kali dari apa yang Anda habiskan untuk solusi yang Anda senangi (untuk saat ini).

Juga, sepertinya Anda mungkin mencoba berlari sebelum Anda bisa berjalan. Anda ingin mengubah proses pengembangan Anda. Sebagai mantan pengembang, saya pikir itu hebat. Tapi jangan hanya membuang banyak VM dan "lingkungan" (yaitu: dev, stage, qa, dll). Rencanakan bagaimana proses baru akan terlihat - bagaimana pengembang akan menyelesaikan pekerjaan. Apakah Anda akan menggunakan integrasi berkelanjutan? Pembuatan otomatis? Menggunakan perangkat lunak apa untuk mendukung mereka? Akankah pengembang diizinkan untuk memindahkan kode ke produksi atau pementasan, atau apakah hanya QA yang memiliki kemampuan itu? Apakah Anda memerlukan pementasan terpisah? Bagaimana dengan dua cabang dev (satu untuk vNext, satu untuk bug dengan vCurrent)?

Anda mungkin memerlukan server agar pemimpin pengembangan atau manajer dapat menyelesaikan semua itu, tetapi jika demikian maka itu perlu menjadi langkah pertama, dan pengaturan dan desain proses awal perlu dilakukan sebelum pengembang mendapatkan tangan mereka di atasnya untuk aktual menggunakan.

1) Argumen apa yang telah dibuat oleh pengembang Anda yang memenangkan Anda untuk memungkinkan jenis silo ini ada di dalam perusahaan yang memiliki jaringan standar dan kebijakan keamanan di tempat yang umumnya (dan dapat dimengerti) menghalangi jenis infrastruktur yang tidak dikelola (secara terpusat) yang dikelola ini ?

Tidak ada - kebanyakan karena saya tidak memainkan peran manajemen dalam organisasi saya sehingga semua "hal politik" ini tidak benar-benar melibatkan saya. Satu-satunya argumen yang akan benar-benar meyakinkan saya adalah untuk membiarkan sesuatu yang secara eksplisit bertentangan dengan kebijakan jaringan dan dibebaskan dari kontrol dan visibilitas tim operasi sistem adalah celah udara dan surat CYA dari bos bos saya.

Bukannya saya benar-benar ingin menjadi bisnis untuk mengatakan "Tidak", hanya saja tidak ada cara yang baik untuk ini mengakhiri dengan baik dari sudut pandang tim operasi.

1. Kami berakhir dengan server yang dikelola oleh orang-orang yang keahlian utamanya tidak mengelola server di jaringan yang tidak memiliki visibilitas seluruh jaringan dan ruang masalahnya yang terkait. Ini bukan hanya masalah politik untuk "melindungi" wilayah; sebagai contoh basi bayangkan apa yang terjadi ketika pengembang menyalakan DHCP untuk beberapa alasan.
2. Kami akhirnya mengelola server tim pengembangan untuk mereka. Ini berantakan karena alasan yang berlawanan. Para pengembang terus-menerus merasa terganggu karena kami menambal ini (melanggar sesuatu yang mereka ketahui tetapi kami tidak), atau perjuangan mereka untuk mengaktifkan fitur yang karena berbagai alasan bagus kami tidak ingin diaktifkan. Ini dengan cepat berubah menjadi jalan buntu di mana tim operasi merasa terbebani dan dilecehkan dan tim pengembangan merasa frustrasi dan diabaikan.
3. Ada konsekuensi politik - karena dengan begitu Anda harus menjelaskan kepada departemen lain mengapa pengembangnya "istimewa" dan mengapa mereka dibebaskan dari kebijakan jaringan.

2) Apakah ini hanya masalah pengembang membuat pembenaran teknis atau bisnis dan memastikan bahwa manajemen patch dan AV akan terjadi - atau lebih dari perjuangan politik untuk kontrol dan kepemilikan?

Saya tidak berpikir pengembang perlu membuat kasus bisnis - cukup jelas bahwa pengembang harus mengembangkan dan untuk melakukan itu mereka memerlukan lingkungan pengembangan semacam. Adapun manajemen tambalan dan AV - itulah tugas tim operasi dan kami akan memastikan bahwa hal itu selesai. Bukannya kami pikir pengembang tidak bisa melakukannya. Hanya saja kami tidak percaya Anda melakukannya dengan benar - Administrator Sistem tetap menggunakan Administrator Sistem karena mereka tidak memercayai apa pun untuk melakukan sesuatu dengan benar sehingga itu bukan urusan pribadi. Tentu saja ada masalah politik yang jelas tentang perasaan seperti orang lain "melakukan pekerjaan Anda" tetapi itu bukan masalah teknis dan karenanya berada di luar ruang lingkup SF.

3) Diberi pilihan, apakah Anda lebih suka mengambil kepemilikan dan dukungan perangkat keras / OS sambil memberikan hak admin lokal, atau membiarkan mereka mengelolanya sepenuhnya, sambil memastikan bahwa mereka melembagakan manajemen patch / AV dan menagih mereka dengan tanggung jawab jika mereka menyebabkan masalah?

Baik untuk alasan yang diuraikan di atas.

4) Jika Anda berhasil memblokir pengembang dari memiliki kontrol lokal "server jahat" pada infrastruktur Anda, apakah pengembang hanya membuat jatuh tempo atau apakah mereka (atau Anda) memindahkan lingkungan pengembangan ke VLAN terputus / jaringan yang sepenuhnya terpisah?

Celah udara. Cara terbaik untuk menangani situasi ini adalah dengan memberikan pengembang lingkungan mereka (dan mengendalikannya) dan kemudian celah udara atau menggunakan beberapa metode kuat lainnya untuk memisahkannya dari jaringan. Ini pada dasarnya bagaimana kami menangani wifi publik. Anda ingin layanan wifi? Tentu. Anda membayar untuk koneksi jaringan, kami akan mengelola WAP, tetapi itu tidak akan pernah menyentuh jaringan kami. Maaf. Kebutuhan Anda hanyalah satu dari ratusan. Ada kekhawatiran lain yang harus kita pertimbangkan.

Anda tidak ingin berada dalam bisnis mengatakan tidak, karena pengembang (yang secara teknis sangat pandai) akan menemukan cara untuk mendapatkan apa yang mereka inginkan. Jadi berikan mereka lingkungan yang sesuai dengan kebutuhan mereka, buat mereka bahagia dan kemudian temukan beberapa cara untuk mencegah apa pun yang mereka lakukan di lingkungan pengembangan dari menyentuh sisa jaringan bisnis Anda.

TL; DR: Saya akan memberi Anda server dengan platform virtualisasi apa pun yang Anda inginkan pada jaringan fisik atau VLAN yang terpisah. Akses ke lingkungan pengembangan Anda akan melalui satu host benteng tunggal yang akan dikontrol dan dipantau oleh tim operasi. Apa yang Anda lakukan dengannya bisnis Anda - Ini tidak akan didukung tetapi kami akan memberikan saran dan bantuan jika waktu mengizinkan untuk sisi administrasi server.

Jika Anda datang kepada saya dengan mesin kelas workstation yang dimuat ke gagang dengan RAM kelas konsumen, kelas konsumen HDD, kelas konsumen PSU dan RAID tingkat konsumen, saya akan menolak untuk meletakkannya di jaringan server juga.

Ada banyak yang perlu Anda pahami tentang meletakkan sesuatu seperti itu di VLAN server.

1. Server VLAN mungkin merupakan DMZ. Dalam DMZ Anda tidak memasukkan apa pun yang tidak dikeraskan dan diamankan. Ini hanya mesin yang Anda berikan kepada mereka, mereka tidak tahu apa yang Anda lakukan dengannya. Ini juga berarti penambalan dan pembaruan rutin, yang berarti dikelola secara terpusat. Saya yakin tidak akan masuk ke setiap server yang tidak dikelola dan menerapkan tambalan dengan tangan.

2. Komponen dalam mesin itu akan gagal. Saya berjanji. Dalam 6 atau 12, 24 bulan, perutnya akan naik. Lalu, di mana cadangannya? Oh, kamu tidak mengaturnya? Tapi, saya pikir itu server? Oh, ini server yang disediakan orang lain? ... dan permainan menyalahkan mulai lagi

3. Siapa yang akan mengambil tanggung jawab ketika jatuh dan sial mengenai kipas? Di sebagian besar organisasi, "Aku memberikannya kepada dev untuk dijaga" tidak akan terbang.

4. Di mana mereka akan meletakkannya? Server semua rak dipasang hari ini dan menempatkan menara di rak membuang-buang ruang dan rak mereka mungkin tidak dirancang untuk itu.

Jadi, departemen TI sangat dibenarkan untuk tidak menempatkan komputer acak ini di jaringan server mereka.

Namun itu adalah tugas departemen TI untuk memastikan bahwa ANDA dapat melakukan pekerjaan ANDA dengan benar. Mereka perlu memastikan bahwa Anda memiliki apa yang Anda butuhkan, ketika Anda membutuhkannya. Jika Anda memiliki perangkat lunak yang harus dijalankan oleh bisnis, mereka harus menyediakan platform untuk menjalankannya. Itu deskripsi pekerjaan mereka. Tetapi Anda perlu memastikan bahwa mereka memiliki informasi yang mereka butuhkan untuk melakukan pekerjaan mereka.

Jika Anda datang kepada saya, di organisasi saya, memberi tahu saya bahwa Anda memulai proyek baru, saya akan memberi Anda tiga VM: Dev, Live, dan Staging. Anda akan memiliki hak admin penuh untuk Dev, dan kami akan membahas apa yang Anda butuhkan untuk melakukan pekerjaan Anda untuk dua lainnya. Jika Anda membutuhkan hak admin penuh untuk mereka, dan dapat membenarkannya, maka Anda akan mendapatkannya. Kami memiliki penyebaran VM kami tepuk tangan. VMWare membuat ini sangat sederhana - hanya butuh sekitar 5 menit per VM untuk menggunakannya.

Kedengarannya seperti departemen TI Anda menderita dari hampir semua departemen TI di sebuah perusahaan besar menderita. Membangun kastil-kastil kecil dan mempertahankannya dengan hidup Anda, tidak membiarkan orang lain masuk, menjadi suka memerintah, dll. Sebagai seseorang yang berurusan dengan departemen TI orang lain setiap hari, saya melihatnya sepanjang waktu. Dan itu membuat frustrasi.

Fakta dasarnya adalah bahwa perubahan perlu terjadi dari dalam departemen TI, dan harus dimulai dari atas mereka. Dan jika Anda bisa mendapatkan IT untuk menyadari bahwa mereka bukan kekuatan bagi diri mereka sendiri (karena kebanyakan dari mereka tidak menghasilkan pendapatan untuk bisnis mereka, ini bisa menjadi tamparan yang cukup), dan bahwa mereka ada di sana untuk mendukung staf yang ada dan meningkatkan bisnis, maka Anda akan menemukan bahwa pertanyaan Anda menjadi tidak relevan, karena semua orang akan bermain sebagai keluarga yang bahagia.

Mengapa Anda ingin menambahkannya ke domain? Dengan kata lain, yang menjawab pertanyaan dengan lebih baik: Anda dapat mengatur laboratorium untuk melakukan apa pun yang Anda inginkan, selama itu tidak terhubung ke LAN perusahaan. (Jika Anda membutuhkan akses internet, mungkin Anda bisa mendapatkan VLAN DMZ-ed; itu seharusnya tidak menjadi masalah, terutama jika Anda hanya menggunakannya untuk keluar , seperti untuk unduhan.)

Itu adalah satu, dari banyak banyak, jawaban berbeda untuk pertanyaan itu.

Anda akan mendapatkan BANYAK jawaban di sini, untuk dan terhadap pengembang yang memiliki akses admin ke bagian mana pun dari lingkungan (mungkin sebagian besar menentang), tetapi inilah intinya:

Grup sysadmin bertugas menjaga sistem produksi tetap berjalan, stabil, dan aman dan bertanggung jawab untuk memastikan sistem-sistem itu menyediakan layanan yang dibayar perusahaan (karena mereka membayarnya) pada tingkat yang mereka harapkan.

Demikian juga, tim pengembang telah ditugaskan untuk memberikan layanan kepada perusahaan (web, aplikasi, dll.), Meskipun di arena yang berbeda. Berjuang untuk mengendalikan lingkungan pengembangan adalah kontraproduktif dan tidak memiliki tujuan yang berguna bagi kedua belah pihak.

Saya bekerja di ISV / ASP kecil. Kami punya satu pengembang dan satu sysadmin (saya). Kami memiliki hubungan berdasarkan rasa saling menghormati dan kepercayaan. Kita perlu bekerja sebagai tim untuk membantu mencapai tujuan menyeluruh perusahaan. Saya memberi pengembang akses lengkap dan tidak terbatas ke lingkungan pengembangnya, yang mencakup workstation dan server. Saya mengelola sistem dev untuk keamanan, pembaruan, AV, dan perangkat keras dan dev mengerjakan sisanya. Ketika kodenya siap untuk diproduksi, dia menyerahkannya kepada saya, membantu saya dengan konfigurasi yang diperlukan, dan mundur. Kami saling membantu satu sama lain.

Pengembang harus menjadi penguasa lingkungan pengembangan dan Sysadmin harus menjadi penguasa lingkungan produksi, dalam batas-batas yang wajar dan dengan pemeriksaan, keseimbangan, dan kontrol yang wajar. Ketika kedua belah pihak perlu "menyeberang" itu harus dalam kerja sama dan konser dengan partai "memerintah" di bawah bidang dan bimbingan mereka.

Pertama-tama, pengalaman saya hanya di organisasi yang lebih kecil, tetapi masalah ini muncul di perusahaan dari semua ukuran, jadi ...

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

Dari sudut pandang saya, satu-satunya argumen yang perlu dibuat oleh pengembang adalah "kita membutuhkan ini." Jika mereka datang lebih dulu kepada saya, saya akan mencoba memahami kebutuhan mereka dan melihat apa yang bisa kami lakukan. Tetapi, pada akhirnya, jika mereka mengatakan "kita membutuhkan ini," saya akan memberi mereka keuntungan dari keraguan dan kepercayaan bahwa mereka tahu apa yang mereka lakukan.

Tapi itu baru permulaan - itulah sisi "Pro" dari persamaan. "Con" adalah tempat kita masuk ke perselisihan ...

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

Kecuali bahwa "hanya" adalah pernyataan yang luar biasa, ya, jika pengembang dapat membuat justifikasi teknis dan bisnis, tidak akan ada masalah. Yang lain di sini dan di programmer.SE (tempat pertanyaan SO Anda dimigrasikan) telah menunjukkan banyak jebakan untuk pengaturan Anda, jadi saya tidak akan mengulanginya. Jika Anda membuat rencana untuk menangani semua masalah itu dan masalah lain yang dipikirkan departemen TI Anda, dan membenarkan SEMUA biaya, maka masuk akal untuk melanjutkan.

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

Yang ini bukan pemula, Anda tidak dapat memiliki dua grup dengan tujuan dan tanggung jawab berbeda yang mencoba mengelola sistem yang sama. Itu tidak hanya berakhir dengan buruk, itu akan mulai dengan buruk dan berakhir dengan pertumpahan darah.

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

Saya pikir ini tercakup oleh jawaban saya untuk 2 .: ini adalah rincian teknis yang harus mereka berikan solusi.

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?

Saya setuju dengan kce: "Air-gap"

Jika mereka dapat membenarkan overhead tambahan yang mereka lakukan (dengan menjadi admin lingkungan mereka) pengembang dapat memiliki jaringan mini sendiri di mana mereka memiliki kebebasan, TETAPI itu benar-benar dikarantina: tidak ada yang menyentuh sisa jaringan. Jadi mereka harus datang dengan lebih banyak pembenaran teknis dan bisnis, misalnya untuk "bagaimana kita akan membuat cadangan data penting?"

Sekali lagi, saya harus setuju dengan kce: "Administrator Sistem tetap Administrator Sistem karena mereka tidak percaya apa pun untuk melakukan sesuatu dengan benar" Adalah tugas kami untuk membangun sistem yang paling dapat diandalkan yang kami dapat dari komponen yang tidak dapat diandalkan, sehingga setiap proposal yang mencakup setengah selusin hal yang seorang sysadmin berpengalaman tahu sangat serpihan akan mendapatkan reaksi negatif yang kuat.

Dari jawaban dan komentar di sini dan di programmer.se, saya pikir sudah jelas ada aspek yang belum Anda pertimbangkan. Meskipun akan memakan waktu lebih lama, saya pikir Anda benar-benar perlu pergi dan berbicara dengan orang-orang IT Anda dan menyajikan hal-hal berbeda: "inilah yang perlu kita lakukan, apakah ada cara untuk mengintegrasikan ini ke dalam infrastruktur dan operasi yang ada?"

Masalah umum, dalam kasus Anda, dan jutaan kasus serupa, adalah:

1) Tanggung jawab kabur - tidak ada hubungan langsung antara tindakan pekerja perusahaan dan keuntungannya. Dia dibayar berdasarkan bulan, dan bukan berdasarkan efek, yang mana semakin sulit untuk diukur, semakin besar organisasi itu. Ini berlaku untuk keamanan, manajer, dll. Jika mereka memaralisasi pekerjaan Anda, mereka tidak peduli.

2) Pembuat kebijakan dan keamanan biasanya memiliki sedikit atau tidak sama sekali pengetahuan tentang pemrograman. Mereka tidak dapat memahami bahwa mereka melumpuhkan pekerjaan Anda bahkan jika mereka peduli (yang biasanya tidak berlaku).

3) Profil psikologis yang disukai untuk bekerja dalam keamanan adalah kepribadian paranoid atau gangguan obsesif-kompulsif. Orang-orang ini melihat konspirasi di mana-mana. Jika pengembang menginginkan sesuatu, seperti server baru, mereka pasti ingin menggunakannya untuk mencuri data perusahaan dan menerbitkannya di WikiLeaks, atau menjual ke Korea Utara.