Mengapa pengembangan menentang operasi?

Saya masih seorang mahasiswa, tetapi saya tidak memiliki pengetahuan tentang operasi, dan bahasa Inggris saya masih buruk.

Pertanyaan saya adalah: Mengapa pembangunan menentang operasi ? Kapan pengembangan menentang operasi?

Inti dari DevOps, adalah bahwa pengembangan seharusnya tidak menentang operasi, sebaliknya mereka harus saling mendukung.

Secara tradisional, karena penyebaran air terjun dan pembaruan berskala besar, pengembangan akan menyebabkan berbagai masalah operasi saat penggelaran karena pengujian yang tidak memadai, perubahan lingkungan server, daftar ini terus berlanjut. Pada dasarnya, pembaruan itu terlalu besar untuk tim operasi untuk dapat secara efektif menyebarkan mereka tanpa beberapa masalah yang timbul dalam proses. Masalah-masalah ini mungkin mengapa Anda percaya bahwa pengembangan menentang operasi .

Di sisi lain, DevOps bekerja untuk mengurangi ukuran pembaruan, mengurangi lingkungan yang kaku, dan umumnya meningkatkan handoff aplikasi antara pengembangan dan operasi dengan meningkatkan jumlah kali handoff terjadi setiap tahun. Dengan semakin banyaknya penyebaran, semakin sedikit sakit kepala untuk operasi, karena mereka telah mengotomatisasi sejumlah besar pekerjaan yang diperlukan untuk memperbarui produk, atau mereka lebih baik mengantisipasi dan mempersiapkan pembaruan.

Tldr: DevOps bertujuan untuk membatalkan teori bahwa pengembangan menentang operasi dengan menciptakan pola pikir di mana operasi dan pengembangan bekerja sama untuk sering menggunakan produk dengan cara yang tepat waktu dan mudah direproduksi.

Saya pikir Anda sudah mendapatkan beberapa tanggapan yang komprehensif, tetapi Anda mengatakan bahasa Inggris Anda tidak bagus, jadi saya akan mencoba memberikan jawaban yang sangat singkat dan dapat dimengerti:

• Tujuan utama pengembangan adalah membuat perubahan.
• Tujuan utama operasi adalah menjaga stabilitas lingkungan.

Dua hal ini saling bertentangan. Karena itu, pengembangan dan operasi tidak boleh saling bertentangan. Mereka harus bekerja bersama untuk memastikan kedua tujuan dapat tercapai. Ini adalah tujuan DevOps.

Ketegangan antara pengembangan dan operasi sering disebabkan oleh ketidakselarasan insentif dan upaya untuk mengoptimalkan dalam tim.

Pengembang sering dinilai oleh kecepatan dan jumlah masalah yang bisa mereka lalui dan digabungkan ke dalam repositori kode dan hadiah mereka sering tidak terikat dengan kode yang benar-benar berfungsi atau bekerja dengan benar. Apalagi penskalaan, kinerja, dan faktor lainnya.

Operasi sering dinilai berdasarkan stabilitas lingkungan dan seberapa baik kode bekerja dalam produksi, tetapi jarang pada kualitas proses untuk membawa perubahan dengan cepat.

Ini menciptakan masalah di mana pengembang diberi insentif untuk membuat banyak kode dan melemparkannya ke dinding ke tim operasi dan tim operasi memiliki insentif untuk menerima perubahan sesedikit mungkin untuk memastikan stabilitas lingkungan.

DevOps dengan cara serangkaian solusi untuk masalah ini:

• Beberapa dari mereka dapat bersifat organisasi, di mana proses dan insentif dari tim dapat berubah. Misalnya, jika pengembang bekerja hanya ditandai sebagai selesai ketika sudah berjalan dalam produksi selama beberapa waktu, tidak ada masalah dan tim operasi setuju untuk mengambil kepemilikan kode. Demikian pula operasi dapat dinilai lebih pada kecepatan penerimaan kode, sementara lingkungan masih dalam batas stabilitas.
• Bagian lain dari solusi bisa dalam komunikasi dan polinasi silang, di mana Anda menanamkan orang-orang operasi dalam tim pengembangan dan sebaliknya. Anda mematahkan dinding antara tim-tim itu dan para insinyur DevOps seringkali merupakan hasil dari jenis bridging ini.
• Alat yang mendukung proses seperti Continuous Integration dan Continuous Deployment adalah bagian lain dari solusi, yang dapat meningkatkan kecepatan perubahan, sambil mempertahankan kualitas tinggi dan pemulihan yang cepat dari lingkungan produksi jika terjadi masalah melalui rollback kode atau kemajuan cepat dari perbaikan dalam produksi.

Sebagian besar organisasi berurusan dengan kompleksitas dengan memecah organisasi mereka menjadi bagian-bagian fungsional dan menuntut agar setiap bagian mencari cara untuk meningkatkan diri. Ini sering disebut pendekatan "silo".

Penting untuk memahami mengapa pendekatan silo ini menghambat kesuksesan bisnis dan sering gagal meningkatkan organisasi secara keseluruhan. Dan itu tidak hanya mempengaruhi pengembangan dan operasi - itu mempengaruhi semua silo fungsional lainnya dalam organisasi besar seperti tim jaminan kualitas, keuangan, produk dan manajemen proyek.

Karena manajer dari masing-masing silo fungsional diperintahkan untuk meningkatkan dengan memotong biaya atau meningkatkan kecepatan, reaksi mereka sering:

• Saya benar-benar kewalahan memperbaiki masalah dari upaya peningkatan terakhir. Tinggalkan aku sendiri.
• Apa yang Anda ingin saya lakukan, memenuhi tanggung jawab saya atau bekerja pada proyek peningkatan? Saya tidak punya waktu untuk melakukan keduanya.
• Jangan lagi! Di sinilah program lain bulan ini.

Dengan reaksi khas ini, eksekutif mana pun yang meluncurkan upaya perbaikan kecil jarang disambut dengan antusias. Manajer menemukan diri mereka dalam persaingan ketat dengan bidang fungsional lainnya atas sumber daya yang dibutuhkan untuk melaksanakan perbaikan mereka. Jadi, tidak heran perintah untuk meningkatkan mengintensifkan pertempuran lintas fungsional!

Bahkan ketika seorang manajer menyelesaikan bagiannya dari proyek perbaikan, ia kemudian bertemu dengan bidang fungsional lain dan organisasi lain (pemasok, kontraktor, dll ...) yang tidak melakukan pekerjaan mereka. Ini mengurangi atau sama sekali meniadakan hasil.

Ketegangan lintas fungsi ini tidak terbatas pada upaya peningkatan. Ini adalah inti dari pengambilan keputusan sehari-hari dan penilaian efektivitas manajemen di seluruh organisasi. Inilah satu contoh kehidupan nyata:

Seorang manajer keuangan diberi tahu, "tingkatkan." Dia memutuskan untuk memblokir mempekerjakan kontraktor yang harganya lebih dari harga nominal yang diterima di pasar. Dia menerapkan kebijakan baru dan mengklaim telah menghemat $ 1 juta dolar tahun ini. Dengan pengembang dan IT tidak dapat mempekerjakan kontraktor untuk membantu mereka menggunakan wadah dan orkestrasi wadah karena kontraktor ini mahal. Manajer operasi TI di perusahaan yang sama menghitung bahwa tidak meningkatkan infrastruktur mereka membebani perusahaan lebih dari $ 100.000 dalam biaya tambahan setiap bulan. Pada tingkat itu, penghematan tahunan dalam mempekerjakan kontraktor dimakan sebelum tahun berakhir.

Anda dapat membayangkan bahwa hubungan antara dua bidang fungsional ini tidak sepenuhnya mesra.

Konflik lintas fungsi ini didorong oleh pendekatan silo, di mana organisasi mengukur masing-masing silo dalam peningkatan secara independen. Jika Anda adalah pusat biaya, peningkatan secara alami berarti efisiensi yang lebih besar atau pengurangan biaya dalam silo Anda.

Dalam kerangka referensi ini, biaya dianggap mematuhi aturan "aditif". Biaya setiap silo ditambahkan bersama-sama, sama dengan total biaya organisasi. Oleh karena itu, manajer melihat pengurangan biaya di wilayah mereka sebagai "baik," karena mereka melihat terjemahan langsung ke penghematan biaya bagi perusahaan secara keseluruhan. Dalam kerangka referensi ini, upaya peningkatan tersebar di mana-mana untuk menyerang biaya dan pemborosan di seluruh organisasi.

Sebuah contoh yang bagus ketika tim pengembangan mulai bekerja Agile dan mendorong kode ke QA dan Operasi setiap dua minggu, bukan setiap kuartal seperti dulu. QA dan Operasi tidak siap untuk perubahan seperti itu dan disalahkan karena mengendur. Sekali lagi, ini tidak berkontribusi banyak pada cinta antara orang-orang dalam pengembangan dan operasi.