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


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

Kami mencoba menerapkan lingkungan pengembangan menggunakan virtualisasi untuk tim kecil 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 merancang ulang mesin kelas workstation yang sudah ada, membuang RAM 24GB dan RAID-10, dan baik-baik saja sampai kami mencoba untuk menambahkan mesin ke domain.

Sekarang kami memulai perang yang semua pengembang perusahaan sejak awal waktu harus berjuang - perjuangan untuk kontrol lokal dari lingkungan pengembangan dan pengujian. Jaringan dan admin TI telah menimbulkan sejumlah kekhawatiran mulai dari "ESX Server adalah standar perusahaan" untuk "server tidak diizinkan pada klien VLAN" hingga "[isi-in-the-blank] bukan merupakan keahlian yang saat ini dimiliki oleh organisasi TI lokal atau perusahaan ".

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

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

  1. Argumen apa yang telah dibuat oleh pengembang Anda yang memenangkan Anda untuk memungkinkan jenis-jenis silo ini ada di dalam perusahaan yang memiliki standar jaringan dan kebijakan keamanan di tempat yang secara umum (dan dapat dimengerti) menghalangi jenis infrastruktur yang tidak terpusat (terpusat) ini?
  2. Apakah ini hanya masalah para pengembang membuat justifikasi teknis atau bisnis dan memastikan bahwa manajemen patch dan AV akan terjadi - atau lebih dari perjuangan politik untuk kontrol dan kepemilikan?
  3. Dengan pilihan ini, apakah Anda lebih suka mengambil kepemilikan dan dukungan perangkat keras / OS saat memberikan hak admin lokal devs, atau membiarkan mereka mengelola 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 terhadap "server jahat" di infrastruktur Anda, apakah para pengembang hanya membuat atau apakah mereka (atau Anda) memindahkan lingkungan pengembangan ke jaringan VLAN / sepenuhnya terpisah yang terputus?

Beberapa asumsi untuk membatasi ruang lingkup pertanyaan ini:

  1. Untuk me-re-iterate, ini adalah untuk a pengembangan lingkungan - tidak diperlukan beban produksi atau dukungan. Tidak ada yang dapat diakses secara eksternal.
  2. Ini bukan Hyper-V vs ESX perang suci (kami akan baik-baik saja dengan baik - tetapi Hyper-V dipilih karena "gratis" 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 terhadap keduanya berada di luar lingkup pertanyaan ini.
  3. Tim pengembang telah membuat jaminan untuk mengelola manajemen tambalan dan antivirus, atau mengintegrasikan dengan sistem perusahaan yang ada jika TI akan mendukungnya - tetapi tentu saja dalam lingkup apakah Anda bersedia menerima itu atau tidak.

10
2017-09-28 03:01




Tidak benar-benar pertanyaan topik di sini, saya tidak berpikir. Namun demikian, ini adalah masalah bisnis - Anda memerlukan lingkungan pengembangan yang sesuai dengan kebutuhan Anda tanpa membuang banyak waktu dengan menggunakan penghalang jalan, dan orang-orang TI bertanggung jawab untuk memastikan keamanan dan integritas infrastruktur. Kompromi! Anda memiliki niat terbaik, tetapi membangun sistem tanpa memberi tahu orang yang bertanggung jawab atas infrastruktur tidak akan membuat Anda menjadi teman. - Shane Madden♦
@ShaneMadden - Jika hal-hal yang bersifat politis jelas diedit, saya pikir itu cocok. Pertanyaan teknis pada dasarnya adalah tentang bagaimana menangani perangkat atau lingkungan yang untuk alasan apa pun yang tidak dapat Anda kendalikan tetapi Anda harus memilikinya. - kce
Jika tidak ada kepentingan produksi ke server, mengapa Anda harus menambahkan domain sama sekali? - Chris Thorpe
Saya tidak benar-benar memiliki jawaban untuk ini, tetapi memalukan bahwa Anda tidak bisa mendapatkan kontrol lokal. (Saya seorang dev sendiri) kami memiliki beberapa jaringan yang berbeda dan pada salah satu dari mereka kami diizinkan untuk menyambungkan router kami sendiri untuk membuat jaringan uji dari sana. - HTDutchy
Menurut saya, yang terbesar adalah bahwa IT dimaksudkan untuk mendukung dan memberikan kepada seluruh organisasi - mencoba untuk menghindari proses mereka dengan mengambil kendali server dan manajemen sendiri hanya berarti mereka tidak melakukan pekerjaan mereka dengan benar :( sebagai seseorang di ruang infrastruktur di perusahaan pengembangan kami juga memiliki persepsi ini, tetapi hanya karena kami kekurangan sumber daya. Sekarang kami memiliki lebih banyak orang dan manajemen yang baik, tim kami lebih bahagia dengan kami dan kami lebih responsif . - Ashley Steel


Jawaban:


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

  • TI juga bertanggung jawab atas pelaporan pada hal-hal seperti manajemen tambalan, perangkat lunak antivirus, kepatuhan pci, audit keamanan tahunan (atau lebih sering), dll. Ini bukan hanya masalah memiliki jaminan bahwa ini sudah diurus, tetapi juga dapat buktikan itu untuk 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 langsung terpasang) agar siswa dapat menganalisis dan menyerahkannya kepada instruktur. Mereka tak pernah 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 pelaporan ke perangkat lunak pemantauan saya bahwa mereka masih ada dan masih berlaku. Ini konyol, seperti yang akan terjadi pada kenyataannya lebih aman untuk menghapus koneksi jaringan, tetapi mereka pertama kali dibayar dengan hibah pendidikan dan jadi itu adalah persyaratan pelaporan saya.

  • Suka atau tidak, server dev Anda adalah sistem produksi dari sudut pandang pengembang. Berikan mungkin sebulan, dan pengembang akan kesulitan menyelesaikan pekerjaan jika itu turun karena proses yang akan Anda atur yang mengasumsikan server tersedia. Menghindari / membatasi situasi di mana para pekerja ditetapkan menganggur karena kegagalan teknologi adalah alasan besar bisnis masih menggunakan departemen TI 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 lain-lain melakukan sesuatu, dan mesin yang dibangun untuk satu tidak bisa dianggap dijalankan dengan baik di sisi lain. Jika Anda akan melakukan ini, IT akan perlu untuk membantu mengelolanya di beberapa titik, dan mereka tidak ingin harus mengkonversinya ke vmware setelah ada sekelompok cruft pada mesin yang mungkin menyebabkan masalah.
  • Suatu hari mesin ini akan menjadi tua, dan membutuhkan perawatan yang lebih teratur atau pengaturan siklus penggantian standar. Bahkan server baru terkadang memiliki bum parts. Situasi ini hampir selalu mendarat di pangkuan IT saja setelah sesuatu telah rusak yang mencegah orang melakukan pekerjaannya. Dengan mengambil tanggung jawab untuk server lebih awal, IT dapat melakukan pekerjaan yang jauh lebih baik untuk memastikan Anda menghindari gangguan yang tidak direncanakan di jalan.
  • Pribadi yang satu ini, tetapi saya dapat memberitahu Anda bahwa itu sangat terakhir hal yang saya inginkan di sekitar jaringan saya adalah desktop lain yang menyamar sebagai server. Saya telah berurusan dengan cukup banyak dari beberapa tahun terakhir untuk bertahan hidup saya seumur hidup.

Yang mengatakan, IT perlu dapat mendukung inisiatif ini. Tidak cukup 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 merencanakan biaya yang belum dapat Anda lihat), dan jadi pertanyaannya adalah siapa yang harus membayarnya. TI tidak akan mau karena mereka tidak menganggarkannya, tetapi Anda akan menolak karena sudah 6 kali lipat dari apa yang Anda habiskan untuk solusi yang Anda senangi (untuk saat ini).

Juga, sepertinya Anda mungkin mencoba berlari sebelum Anda dapat berjalan. Anda ingin mengubah proses pengembangan Anda. Sebagai mantan pengembang, saya pikir itu hebat. Tetapi jangan hanya membuang sekelompok VM dan "lingkungan" (mis: 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? Apakah pengembang diizinkan untuk memindahkan kode ke produksi atau pementasan, atau hanya QA yang memiliki kemampuan itu? Apakah Anda membutuhkan pementasan yang terpisah? Bagaimana dengan dua cabang dev (satu untuk vNext, satu untuk bug dengan vCurrent)?

Anda mungkin memerlukan server agar pemimpin atau pengelola pengembangan dapat menyelesaikan semua itu, tetapi jika demikian maka itu perlu menjadi langkah pertama, dan penyiapan dan desain proses awal perlu dilakukan sebelum pengembang mendapatkan tangan mereka untuk penggunaan yang sebenarnya.


15
2017-09-28 03:51



Aneh. Saya mengedit posting dan mendapatkan dupe dibuat :( - Joel Coel
Hal yang sama terjadi pada saya dengan dupe == edit, tetapi tidak dalam waktu looooong - Mark Henderson♦
Ini adalah jawaban yang bagus - bukan jawaban yang ingin saya dengar, tetapi tepatnya alasan saya datang ke sini untuk sudut pandang yang berlawanan. Saya sekarang menyadari ini adalah reaksi terhadap persepsi bahwa IT tidak responsif dan pada gilirannya tidak bekerja dengan mereka untuk memenuhi kebutuhan kita. Anda memukul paku di kepala dengan "TI harus mampu mendukung inisiatif ini. Tidak cukup bagi mereka untuk hanya mengatakan," Tidak ". Tantang mereka untuk datang dengan alternatif yang memenuhi kebutuhan Anda (sangat nyata)." - ScottBai


1) Argumen apa yang telah dibuat oleh pengembang Anda yang memenangkan Anda untuk mengizinkan jenis-jenis silo ini ada di dalam perusahaan yang memiliki standar jaringan dan kebijakan keamanan di tempat yang secara umum (dan dapat dimengerti) menghalangi jenis infrastruktur yang tidak terpusat (terpusat) 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 benar-benar akan meyakinkan saya adalah untuk mengizinkan sesuatu yang secara eksplisit bertentangan dengan kebijakan jaringan dan dibebaskan dari kedua kontrol tim operasi sistem dan visibilitas adalah celah udara dan surat CYA dari bos bos saya.

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

  1. Kami berakhir dengan server yang dikelola oleh orang-orang yang memiliki keahlian utama tidak mengelola server di jaringan yang tidak memiliki visibilitas seluruh jaringan dan ruang masalah terkait. Ini bukan hanya masalah politik dari "melindungi" rumput; sebagai contoh basi bayangkan apa yang terjadi ketika seorang 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 kesal karena kami menambal ini (melanggar sesuatu yang mereka ketahui tetapi kami tidak melakukannya), atau perjuangan mereka bagi kami untuk mengaktifkan fitur-fitur yang untuk berbagai alasan baik yang tidak ingin kami aktifkan. Ini dengan cepat berubah menjadi kebuntuan di mana tim operasi merasa terbebani dan dilecehkan dan tim pengembangan merasa frustrasi dan diabaikan.
  3. Ada konsekuensi politik - karena Anda harus menjelaskan kepada departemen lain mengapa para pengembang "spesial" dan mengapa mereka dibebaskan dari kebijakan jaringan.

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

Saya tidak berpikir para pengembang perlu membuat kasus bisnis - cukup jelas bahwa pengembang harus mengembangkan dan untuk melakukan itu mereka membutuhkan lingkungan pengembangan semacam itu. Adapun manajemen patch dan AV - itulah pekerjaan tim operasi dan kami akan memastikan bahwa itu dilakukan. Bukannya kami berpikir pengembang tidak bisa melakukannya. Hanya saja kami tidak percaya Anda melakukannya dengan benar - Administrator Sistem tetap menggunakan Administrator Sistem karena mereka jangan percaya apa pun untuk melakukan sesuatu dengan benar jadi itu bukan masalah pribadi. Tentu saja ada masalah politik yang jelas dari perasaan seperti orang lain adalah "melakukan pekerjaan Anda" tetapi itu tidak benar-benar masalah teknis dan karenanya berada di luar ruang lingkup SF.

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

Bukan karena alasan yang diuraikan di atas.

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

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

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

TL; DR: Saya akan memberi Anda server dengan platform virtualisasi apa pun yang Anda inginkan baik di jaringan fisik terpisah atau VLAN. Akses ke lingkungan pengembangan Anda akan melalui host bastion tunggal yang akan dikendalikan dan diawasi oleh tim operasi. Apa yang Anda lakukan dengan bisnis Anda - Ini tidak akan didukung tetapi kami akan memberikan saran dan bantuan seiring waktu memungkinkan untuk sisi administrasi server.


9
2017-09-28 03:46



Ini adalah jawaban yang fantastis - saya berharap saya dapat menerima dua! - ScottBai


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

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

  1. Server VLAN mungkin sangat baik menjadi DMZ. Dalam DMZ Anda tidak menempatkan apa pun yang tidak mengeras dan aman. Ini hanyalah mesin yang Anda berikan kepada mereka, mereka tidak tahu apa yang Anda lakukan dengan itu. Ini juga berarti penambalan dan pembaruan rutin, yang berarti dikelola secara terpusat. Saya yakin sekali tidak akan masuk ke setiap server yang tidak dikelola dan menerapkan tambalan dengan tangan.

  2. Komponen-komponen dalam mesin itu akan gagal. Saya berjanji. Dalam 6 atau 12, 24 bulan, itu akan naik perut. Lalu, di mana cadangannya? Oh, kamu tidak mengaturnya? Tapi, saya pikir itu server? Oh, itu server yang disediakan orang lain? ... dan game blame dimulai lagi

  3. Siapa yang akan bertanggung jawab ketika crash dan kotoran memukul kipas? Di sebagian besar organisasi, "Saya memberikannya kepada dev untuk dijaga" tidak akan terbang.

  4. Di mana mereka akan meletakkannya? Semua server saat ini sudah terpasang dan menempatkan menara di rak membuang-buang ruang dan rak mereka mungkin tidak dirancang untuk itu.

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

Namun 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 bisnis kebutuhan untuk tetap berlari, mereka memiliki untuk menyediakan platform agar berjalan terus. Itulah 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, mengatakan kepada saya bahwa Anda memulai proyek baru, saya akan memberi Anda tiga VM: Dev, Live, dan Staging. Anda akan memiliki hak admin lengkap untuk Dev, dan kami akan mendiskusikan apa yang Anda perlukan untuk melakukan pekerjaan Anda untuk dua lainnya. Jika Anda membutuhkan hak admin lengkap untuk mereka, dan dapat membenarkannya, maka Anda akan mendapatkannya. Kami memiliki penyebaran VM ke bawah. VMWare membuat ini sangat sederhana - hanya membutuhkan waktu sekitar 5 menit per VM untuk membuatnya disebarkan.

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

Kenyataan dasarnya adalah bahwa perubahan perlu terjadi dari dalam departemen TI, dan harus diantisipasi dari atas mereka. Dan jika Anda bisa mendapatkan TI 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 besar), dan bahwa mereka ada di sana untuk mendukung staf yang ada dan menambah bisnis, maka Anda akan menemukan bahwa pertanyaan Anda menjadi tidak relevan, karena semua orang akan bermain keluarga bahagia.


6
2017-09-28 04:09



kedengarannya seperti di vlan klien dan para pengembang sudah memiliki ruang untuk itu, tapi saya setuju dengan sentimen. - Joel Coel
Benar - kami tidak akan pernah menyarankan sesuatu seperti ini masuk ke server VLAN atau bahkan di pusat data sama sekali. - ScottBai
Yang sedang berkata, jawaban Anda adalah sebaliknya pada target. Saya menyadari sekarang ini lebih merupakan masalah setidaknya persepsi bahwa IT tidak responsif atau mampu mengisi peran yang seharusnya. Pada akhirnya, jika TI menyediakan lingkungan yang dikelola dengan Dev (hak penuh), uji (hak penyebaran saja), pementasan (tidak ada hak), dan hidup / produksi (tidak ada hak) semuanya akan baik-baik saja dengan dunia dan kita tidak akan t harus mengambil beban tambahan mengelola lingkungan. Kedengarannya seperti pendekatan yang lebih baik untuk saya - sekarang untuk melihat apakah itu bisa terjadi dalam 6 bulan ke depan ... - ScottBai
Ah, saya pasti salah paham bagian pertama dari pertanyaan itu; Maaf! - Mark Henderson♦


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

Itu adalah salah satu dari sekian banyak jawaban yang berbeda untuk pertanyaan itu.


3
2017-09-28 03:26



Umumnya, dalam sebuah perusahaan besar, Anda tidak dapat "mengatur lab untuk melakukan apa pun yang Anda inginkan", bahkan jika itu tidak ada di LAN. - ceejayoz
@ceejayoz - Jika tim dev sedang menyiapkan lab VM pada workstation yang ada di kubus mereka, itu dihitung sebagai "apa pun sih", di pikiran saya, untuk keperluan pertanyaan ini. Jika mereka menginginkan kotak Sun besar, tape loader, SAN saluran serat, mereka harus melewati beberapa lingkaran lagi. - mfinni
DMZed VLAN awalnya direncanakan B - tetapi suka atau tidak ada satu ton perangkat lunak & infrastruktur yang memerlukan domain untuk diinstal atau bahkan berguna. Saya kira kita dapat membuat dan memelihara domain kita sendiri - tetapi itu jelas jatuh ke dalam wilayah Plan C atau D - dan tentu saja bukan sesuatu yang akan saya pertimbangkan dengan kabel jaringan bahkan dekat dengan jaringan nyata! - ScottBai


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

Kelompok sysadmin bertugas menjaga sistem produksi tetap berjalan, stabil, dan aman serta bertanggung jawab untuk memastikan sistem tersebut menyediakan layanan yang dibayar oleh perusahaan (karena mereka membayarnya) pada level yang mereka harapkan.

Demikian juga, tim dev telah ditugaskan untuk memberikan layanan kepada perusahaan (web, aplikasi, dll), meskipun dalam arena yang berbeda. Berjuang untuk mengendalikan lingkungan pengembangan adalah kontraproduktif dan tidak melayani tujuan yang berguna untuk 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 lengkap, akses tak terbatas ke lingkungan dev-nya, yang meliputi workstation dan server. Saya mengelola sistem dev untuk keamanan, pembaruan, AV, dan perangkat keras dan dev melakukan sisanya. Ketika kode siap untuk diproduksi, dia menyerahkannya kepada saya, membantu saya dengan konfigurasi apa pun yang diperlukan, dan melangkah mundur. Kami saling membantu satu sama lain.

Pengembang harus menjadi tuan dari lingkungan pengembangan dan Sysadmin harus menjadi tuan lingkungan produksi, dalam batas-batas yang wajar dan dengan pemeriksaan, saldo, dan kontrol yang wajar. Ketika salah satu pihak perlu "menyeberang", mereka harus bekerja sama dan berdamai dengan partai "berkuasa" di bawah lingkup dan panduan mereka.


3
2017-09-28 03:37





Pertama-tama, pengalaman saya benar-benar dalam organisasi yang lebih kecil, tetapi masalah ini muncul di perusahaan dengan berbagai 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 para pengembang adalah "kita membutuhkan ini." Jika mereka datang kepada saya terlebih dahulu, saya akan mencoba memahami kebutuhan mereka dan melihat apa yang bisa kami kerjakan. Tetapi, akhirnya, jika mereka mengatakan "kita membutuhkan ini," saya akan memberi mereka manfaat dari keraguan dan percaya bahwa mereka tahu apa yang mereka lakukan.

Tapi itu baru permulaan - itulah sisi "Pro" dari persamaan. The "Con" adalah di mana 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. Orang lain di sini dan di programmers.SE (di mana pertanyaan SO Anda bermigrasi) telah menunjukkan satu ton perangkap ke setup Anda, jadi saya tidak akan mengulanginya. Jika Anda datang dengan rencana untuk menangani semua masalah itu dan orang lain yang dipikirkan departemen TI Anda, dan membenarkannya SEMUA biaya, maka masuk akal untuk terus maju.

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 kelompok dengan tujuan dan tanggung jawab yang berbeda mencoba untuk mengelola sistem yang sama. Itu tidak akan 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 datang dengan solusi untuk.

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 KDE: "Air-gap"

Jika mereka dapat membenarkan biaya tambahan tambahan yang mereka ambil (dengan menjadi admin lingkungan mereka) pengembang dapat memiliki jaringan mini mereka sendiri di mana mereka memiliki kebebasan, TAPI itu benar-benar dikarantina: tidak ada yang menyentuh sisa jaringan. Jadi mereka harus datang dengan pembenaran lebih teknis dan bisnis, mis. untuk "bagaimana kita akan mencadangkan data penting?"

Sekali lagi, saya harus setuju dengan KDE: "Administrator Sistem tinggal Administrator Sistem karena mereka tidak mempercayai apa pun untuk melakukan sesuatu dengan benar" Ini tugas kita untuk membangun sistem yang paling dapat diandalkan yang kita dapat keluar dari komponen yang tidak dapat diandalkan, sehingga setiap proposal yang menyertakan setengah selusin hal yang diketahui oleh sysadmin yang berpengalaman sangat tidak stabil akan mendapatkan reaksi negatif yang kuat.

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


1
2017-09-28 05:29





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

1) Tanggung jawab Fuzzy - tidak ada hubungan langsung antara tindakan pekerja perusahaan dan keuntungannya. Dia dibayar per bulan, dan bukan karena efek, yang lebih sulit diukur, semakin besar organisasinya. Ini berlaku untuk keamanan, manajer, dll. Jika mereka menyamaratakan pekerjaan Anda, mereka tidak peduli.

2) Pembuat kebijakan dan keamanan biasanya memiliki sedikit atau tanpa pengetahuan tentang pemrograman. Mereka tidak dapat mengerti 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 mempublikasikannya di WikiLeaks, atau menjualnya ke Korea Utara.


0
2017-09-28 07:11



+1 untuk kebutuhan kepribadian paranoid, LOL itu adalah kehidupan murni dalam corp - Stepan Vihor