Halo, Habr! Dan lagi Alexey Pristavko berhubungan.

Tidak seperti artikel saya sebelumnya, hari ini kita akan berbicara tentang orang. Para pahlawan hari itu adalah layanan operasi, yang minatnya saya wakili, dan layanan pengembangan.

Pekerjaan terkoordinasi dari layanan ini adalah kunci untuk peluncuran yang sukses dan “penerbangan” mulus dari layanan yang dibuat. Tetapi, seperti yang ditunjukkan oleh pengalaman saya (dan bukan hanya), praktis tidak ada proyek yang dapat dilakukan tanpa konflik dan ketidaksepakatan, yang korbannya adalah layanan yang tidak bersalah.

Pada artikel ini saya akan mencoba menjawab pertanyaan-pertanyaan berikut:

• Bagaimana metode dan proses pengembangan memengaruhi operasi?
• Apa yang mendorong setiap sisi konflik?
• Apa akar penyebab perselisihan itu?

Selamat datang di kucing!

Apa saja tantangan yang dihadapi layanan

Kami akan mengenal departemen lebih baik dan mulai dengan layanan operasi (ini juga merupakan layanan dukungan). Mengapa binatang buas yang mengerikan ini dibutuhkan, tugas apa yang dikerjakannya, dan "untuk siapa" itu bekerja?

Tugas utama dari layanan operasi adalah untuk mengelola tingkat layanan, yaitu, mempertahankan operasi sistem TI dalam kerangka kerja SLA.
Operasi harus menyediakan akses konstan ke layanan dan fungsinya yang benar dalam kerangka perjanjian dengan pelanggan - biasanya dengan bisnis.

Inilah solusi untuk masalah ini:

• Manajemen insiden: memulihkan fungsi bisnis selama kecelakaan;
  
• Manajemen masalah: mengatasi kemungkinan penyebab kecelakaan dan insiden;
  
• Manajemen konfigurasi: mengumpulkan informasi dan menganalisis parameter operasi perangkat lunak dan infrastruktur;
  
• Manajemen perubahan: meminimalkan risiko masalah dan kecelakaan selama perubahan.
  

Peran layanan pengembangan juga dapat dipahami - penciptaan awal layanan TI dan pengenalan fungsionalitas baru ke dalamnya atas permintaan pelanggan.

Tentunya, Anda sudah memiliki kecurigaan tentang titik gesekan pengembang dan dukungan, karena di mana ada persimpangan tugas, ada konflik. Namun jangan buru-buru menarik kesimpulan. Perdebatan abadi antara pengembang dan admin jauh dari pusat "pertempuran".

Di mana pertentangan tumbuh

"Perang" programmer dan admin bukanlah konfrontasi kepentingan manusia, itu adalah konfrontasi layanan.



Masalahnya terletak pada prioritas dan motivasi dari layanan-layanan ini. Dalam bentuknya yang paling umum, ini dapat digambarkan sebagai berikut:

• Tim pengembangan ingin menggunakan teknologi kesegaran pertama (pengembangan profesional, minat) dan melakukan pekerjaan secepat mungkin (motivasi eksternal).
  

• Operasi tertarik pada teknologi yang paling stabil (masalah mereka diketahui dan secara umum menerima solusi) dan penjelasan terperinci tentang apa yang harus dilakukan jika terjadi masalah dalam perangkat lunak yang dikembangkan (motivasi eksternal untuk kecepatan pemecahan masalah).
  

Pada saat yang sama, penting untuk dipahami bahwa tidak hanya pengembang "melihat" fungsi baru dan tidak selalu secara eksklusif mengangkat admin yang jatuh.

• Admin secara aktif terlibat dalam proses pengembangan - dalam membangun infrastruktur, toleransi kesalahan dan skema skalabilitas, dalam menyiapkan konfigurasi awal, dan, idealnya, dalam proses mempersiapkan persyaratan perangkat lunak. Semua ini disebut proses pengembangan solusi (jangan bingung dengan penulisan kode langsung!).
  

• Programmer terlibat aktif dalam operasi. Mereka memperbaiki kesalahan perangkat lunak, melakukan optimasi sistem dan peningkatan teknis untuk mematuhi sistem SLA, yaitu, mereka memecahkan masalah aksesibilitas layanan IT final.
  

Konflik antara programmer dan administrator tumbuh dari substitusi konsep:

• pengembangan → coding;
  
• dukungan → administrasi layanan aplikasi.
  

Mencondongkan struktur subordinasi berdasarkan profesional (bukan berdasarkan fungsional) selalu mengarah pada konflik. Sebagai aturan, administrator dan programmer bekerja di tim yang sama sekali berbeda, dan kadang-kadang departemen, dan dimotivasi sebagai operasi dan pengembangan, masing-masing.

Akibatnya, programmer dari departemen pengembangan yang "dipaksa" untuk memperbaiki bug lama atau, Tuhan melarang, menulis dokumentasi, tidak bahagia. Admin dari operasi juga marah, yang diminta untuk dengan cepat melemparkan grand piano untuk meningkatkan server baru untuk pengembang atau membantu mereka dengan saran.

Masing-masing pihak memandang ini bukan sebagai solusi bersama untuk masalah, tetapi sebagai gangguan dari tugasnya sendiri, yang tidak terlihat bahkan tanpa tujuan itu.

Tetapi kita tidak boleh melupakan pelanggan, karena dia, meskipun secara tidak langsung, juga merupakan peserta dalam konflik. Sebagai aturan, ia perlu mendapatkan layanan yang mapan dan stabil. Kode telanjang, bahkan yang terbaik, sama sekali tidak berguna bagi pelanggan di luar sistem. Dia pada dasarnya memiliki gambaran dunia yang berbeda:



Pelanggan standar tidak memiliki tugas untuk membuat, menulis, atau, maaf, Tuhan, terapkan. Pelanggan ingin menyelesaikan masalah bisnis menggunakan tombol ajaib "Lakukan semuanya dengan baik", sementara IT memaksakan itu menawarkan solusi spesifik.

Mari kita lihat semua sisi konflik:



Tentu saja, ini hanya bagian paling umum dari persyaratan fungsional dan operasional.

Jadi, kami mengetahui bahwa masih ada tiga pihak dalam konflik : pengembangan, operasi, dan pelanggan. Selain itu, pelangganlah yang sebagian besar adalah "provokator", berbagi tanggung jawab antara tim. Ini sendiri tidak buruk, dan jika bukan karena pemisahan tim dan tanggung jawab yang diterima secara umum di antara mereka, itu akan menjadi konflik yang dapat dikelola.

Tetapi kita sudah tahu bahwa kedua layanan ini tidak swasembada. Mereka dipisahkan oleh barikade "layanan" dan pada saat yang sama mereka tidak boleh hanya berinteraksi di antara mereka sendiri di bidang pemindahan tanggung jawab sesuai dengan tahapan kehidupan produk, tetapi juga secara aktif berpartisipasi dalam memecahkan masalah masing-masing.

Aspek lain dari pengaruh pelanggan adalah strategi dan metodologi pengembangan bisnisnya. Dalam hal ini, saya berbicara tentang tidak memahami seperti apa proses pengembangan solusi IT tertentu. Tanpa pemahaman seperti itu, pelanggan sering menuntut untuk membuat seekor kucing paus, dan kemudian menempelkan sayap padanya. Dan selalu semuanya mendesak. Kadang-kadang ini dibenarkan oleh situasi dan inovasi ide, kadang-kadang itu adalah konsekuensi dari perlombaan untuk pemimpin pasar dan penyalinan yang tergesa-gesa. Alasannya mungkin sangat berbeda, tetapi hasilnya adalah satu.

Masalahnya adalah bahwa strategi semacam itu diterjemahkan ke dalam eksperimen konstan dan kebutuhan untuk mendapatkan hasil dalam waktu sesingkat mungkin. Pendekatan ini melemparkan kita ke dalam jurang perkembangan yang berkelanjutan, bukannya pekerjaan yang ditujukan untuk hasil tertentu. Pada prinsipnya, masalah terakhir diselesaikan oleh arsitek perusahaan, tetapi Anda tidak akan menemukan orang-orang ini di sore hari dengan api.

Proses pengembangan

Akhirnya, kami hampir sampai pada titik di mana semuanya berjalan. Apa kunci operasi layanan?

1. Transparansi perbaikan. Untuk mengelola perubahan, Anda perlu memahami apa, bagaimana, dan mengapa itu dilakukan.
   
2. Dokumentasi tentang logika kerja dan pemeliharaan. Idealnya, dalam bentuk instruksi. Kunci kepatuhan dengan SLA tidak hanya keandalan, tetapi juga pemahaman yang jelas tentang apa dan bagaimana melakukan, yang harus ada untuk semua pemain. "Pengetahuan lisan" tidak cocok di sini - sangat sering orang bekerja secara bergiliran dalam operasi, dan sangat tidak mungkin untuk mengumpulkan semua dan menjelaskan semuanya. Dan ingatan dalam situasi yang penuh tekanan (dan kecelakaan selalu membuat stres) bisa gagal.
   
3. Prosedur transfer yang jelas untuk mendukung versi baru dengan pengujian karakteristik operasionalnya dan operasi fungsional yang benar. Secara sederhana - regresi dan pengujian stres. Fungsionalitas sederhana dari fungsionalitas baru menggairahkan operasi sampai batas minimum: tim pengembangan itu sendiri akan memperbaiki rilis garansi yang gagal. Tetapi kesalahan yang diperkenalkan dalam fungsi lama, operasi harus, jika tidak menghilangkan sendiri, maka setidaknya proses, kadang-kadang membuktikan kesalahan pengembangan.
   
4. Kesempatan untuk mentransfer persyaratan Anda ke pekerjaan proyek baru. Ini adalah pengembangan yang meletakkan karakteristik operasional yang paling penting. Sebagai contoh, jika perangkat lunak tidak tahu cara bekerja dalam sebuah cluster, operasi tidak akan dapat membuatnya secara mandiri benar-benar andal.
   

Apa layanan operasi dan mengapa penting bagi seseorang bagaimana tim pengembangan bekerja, kami menemukannya. Mari kita beralih ke bagian yang paling menarik - kita akan menganalisis berbagai metodologi pengembangan dan dampaknya pada layanan operasi.

Mari kita mulai dengan klasik: Model air terjun.

Air terjun

Waterfall berfokus untuk memberikan fungsionalitas yang lengkap dan canggih. Model rilisnya adalah siklik. Siklusnya berlangsung dari beberapa minggu (sangat jarang) hingga kuartal dan enam bulan. Hampir selalu ada kumpulan persyaratan yang konsisten, analisisnya, pengembangan arsitektur solusi, penilaian durasinya, perencanaan, dan pengujian regresi penuh pada akhirnya.

Kepatuhan dengan kepentingan operasi tergantung pada implementasi spesifik. Karena tahapan-tahapan yang diperlukan biasanya disorot, prosesnya mencakup semua persyaratan dan prosedur formal untuk pemindahan ke operasi, termasuk dokumentasi.

Masalah utama Waterfall bagi pelanggan adalah durasi iterasi dan stabilisasi yang lama setelah rilis. Kadang-kadang pelanggan dipaksa untuk menunggu beberapa bulan sebelum suatu produk muncul dalam produk yang membutuhkan waktu seminggu untuk dibuat.

Jika hasilnya jauh dari yang diharapkan, pelanggan harus bertahan sampai akhir siklus baru, atau bahkan dua. Secara teratur di tempatnya adalah layanan operasi. Dan fungsi teknis paling sering adalah yang terakhir di baris.

Setiap rilis besar disertai dengan tumpukan kesalahan, yang dihilangkan selama periode stabilisasi. Biasanya itu berubah menjadi neraka bagi semua pihak - pengembangan dipaksa untuk terlibat dalam eksploitasi, operasi menerima insiden dan mendorong perkembangan mereka untuk menjamin penghapusan dengan segala cara, dan pelanggan, melihat semua kekacauan ini dan kehilangan uang, merobek rambutnya.

Terlepas dari semua ini, dari sudut pandang operasi, Waterfall adalah proses metodologis yang paling seragam dan dapat diprediksi di mana Anda dapat mengintegrasikan. Secara umum, baik lamanya siklus, maupun stabilisasi operasi tidak terlalu diperhatikan. Semakin banyak waktu berlalu di antara rilis, semakin lama Anda dapat bekerja dengan tenang - dan ini selalu merupakan nilai tambah. Selain itu, ketika ada keyakinan bahwa tidak ada yang akan berubah selama enam bulan ke depan, akan lebih mudah untuk memasukkan pekerjaan Anda ke dalam proses.

Sayangnya, sangat sering pelanggan menentang Waterfall dan permintaan untuk mempercepat pengembangan proyek. Demi keinginan ini, lahirlah metodologi yang lebih fleksibel.

Agile

Seperti yang Anda pahami, Waterfall adalah waktu yang sangat lama, secara formal dan memerlukan banyak dokumentasi, di mana setiap orang selalu berselingkuh . Dan pelanggan membutuhkan semuanya sekaligus. Sebagai jawaban untuk masalah ini, programmer datang dengan manifest Agile:

● Orang dan interaksi lebih penting daripada proses dan alat.
Sulit untuk berdebat dengan itu. Tentu saja, orang lebih penting. Tapi jangan lupa tentang prosesnya. Ini adalah proses yang menstandarkan dan mengatur interaksi. Selain itu, hanya di depan umum Anda tidak akan pergi jauh. Paling tidak, orang suka sakit, rileks, dan kadang berhenti.

● Produk yang berfungsi lebih penting daripada dokumentasi yang komprehensif.
Ini juga benar. Tetapi ada pertanyaan lain: seberapa baik dan berapa lama produk akan bekerja tanpa dokumentasi? Kemungkinan besar, tidak terlalu lama. Tapi itu bagus atau tidak - itu tidak akan berhasil karena kurangnya sumber. Dan kemudian Anda harus mengikuti taktik yang banyak orang jatuh cinta dengan "Saya tidak bisa mengetahuinya - menulis ulang dari awal." Tetapi selalu panjang, mahal, dan umumnya bukan fakta bahwa hasilnya akan menjadi lebih baik.

● Kolaborasi dengan pelanggan lebih penting daripada menegosiasikan ketentuan-ketentuan kontrak.
Dan lagi, ya, lebih penting. Tetapi bagaimana tanpa kesepakatan tentang ketentuan kontrak kita akan mengerti apa dan bagaimana melakukannya? Bagaimana lagi untuk mengatasi kesalahpahaman timbal balik, kecuali bagaimana berkomunikasi dan menyetujui melalui dokumen yang jelas? Tentu saja, kontrak juga bukan obat mujarab, tetapi jauh lebih dapat diandalkan daripada metode dari tahun sembilan puluhan:

- Vasya, apakah kamu mengerti saya?
- Ya seperti saudara, saudara.

● Kesiapan untuk perubahan lebih penting daripada mengikuti rencana awal.
Tapi ini hanya berlaku dalam satu kasus: jika rencana awal adalah log lengkap, dan apa yang mereka rencanakan untuk dibangun, ternyata tidak diperlukan siapa pun. Anda memberikan arsitek perusahaan di setiap tangan!

Hasil dari mengikuti manifesto ini secara membabi buta adalah bahwa pelanggan bisnis itu sendiri harus berubah menjadi arsitek perusahaan (tetapi lebih sering daripada tidak, ia berubah menjadi labu). Tidak hanya ini bukan "fungsional" yang melekat padanya, itu juga perlu untuk memahami IT.

Scrum

Scrum adalah salah satu upaya pertama untuk menyesuaikan Air Terjun dengan ideologi manifest Agile.
Fitur utama scrum:

• Bekerja dalam sprint pendek. Komposisi sprint setelah permulaannya tidak diedit;
  
• Merencanakan dengan memasukkan masing-masing Cerita Pengguna di sprint wish log. Pada pemilik proyek - pilihan dari "log proyek";
  
• Kepentingan pelanggan diwakili oleh pemilik proyek (Pemilik Produk);
  
• Tim pengembangan terdiri dari spesialis berbagai profil: pemrogram, pengembang, arsitek, analis. Tim bertanggung jawab atas hasilnya secara keseluruhan;
  
• Kami mengganti dokumentasi dan korespondensi dengan diskusi harian proyek oleh seluruh tim.
  

Secara teori, ini adalah pendekatan yang cukup kuat, dan dalam banyak hal ini menyerupai versi miniatur Waterfall. Masalah mulai muncul pada tahap implementasi. Sayangnya, SCRUM, karena siklus yang lebih pendek, memprovokasi memecah seluruh fungsi menjadi bagian-bagian terpisah dan memberikan fungsi di bagian-bagian bahkan pada tahap perencanaan sprint. Saya diam tentang fakta bahwa untuk alasan ini semuanya bisa serba salah selama "balapan". Sprint pendek tidak menyisakan waktu untuk stok manajerial dan menjadi sangat sulit untuk keluar.

Sebagai hasil dari prioritas ulang yang konstan dari suatu fitur dalam bentuknya yang telah selesai, ia dapat segera masuk ke produktif. Selain itu, pada tahap penulisan UserStory, sangat sulit untuk mengevaluasi dampak fungsionalitas yang direncanakan pada sistem akhir, karena statusnya tidak diketahui sebelumnya pada saat ketika fungsi ini muncul.

Bagaimana ini mengancam eksploitasi? Tidak selalu jelas apa yang harus bekerja, apa yang tidak boleh, dan jika itu berhasil, lalu kapan. Dengan demikian, ada substitusi pengujian sistem untuk pengujian fungsi, karena regresi normal akan memakan banyak waktu. Ini menambah bug ke produk dan menunda solusinya.

Untuk operasi normal, operasi harus:

• Berpartisipasi dalam pertemuan SCRUM;
  
• Selalu sadar akan situasi kerja pembangunan;
  
• Ketahui rencana pengembangan dan status rilis.
  

Kalau tidak, tidak mungkin untuk menangkap waktu dengan penerimaan atau membuat komentar. Tentu saja, eksploitasi sangat jarang untuk mengikuti semua poin ini, dan jika itu terjadi, itu mengarah pada eskalasi konflik. Bahkan pemilik produk selama pertemuan SCRUM dapat mengabaikan kepentingan dukungan.

Kanban

Langkah selanjutnya dalam evolusi metodologi pengembangan adalah Kanban. Siklus SCRUM yang sudah pendek juga tampak terlalu lama untuk bisnis. Anda dapat memahami pelanggan: Anda selalu ingin menjadi yang pertama mendapatkan chip paling keren. Ya, dan mengubah rencana tidak efisien, ternyata terlalu banyak "overhead".
Jadi, seperti kata para pembangun, lebih mudah untuk "mengukir di tempat."

Kanban adalah implementasi TI dari metodologi lean manufacturing Jepang. Tetapi ada nuansa: di Toyota, menggunakan Kanban, mobil dirakit dari bagian-bagian pra-rekayasa, sementara pengembangan terutama desain. Dalam pemrograman, bagian-fungsi hanya disalin, mereka tidak perlu terus-menerus "diproduksi".

Kanban biasanya berjalan seiring dengan proses CI / CD. Tidak ada sprint di sini, tugas-tugas disampaikan secara terus-menerus karena mereka sudah siap, ada batasan ketat pada ukuran tugas-tugas tersebut. Karena itu, fungsi yang kompleks dalam bentuk integral hampir tidak pernah disampaikan, karena tidak sesuai dengan ukuran tugas.

Dalam kondisi seperti itu, dokumentasi untuk sistem benar-benar menjadi usang sebelum ditulis, dan kehilangan akal, karena tidak mungkin untuk memperbaiki beberapa keadaan dari sistem yang diproduksi (yaitu diproduksi, tetapi tidak dikembangkan) di mana itu akan benar.

Untuk operasi, ini berarti ketidakmampuan untuk menyediakan SLA: tidak ada dokumentasi, dan tidak ada yang tahu bagaimana sistem bekerja dan bagaimana seharusnya bekerja.

Prediktabilitas dan jaminan operasi yang berkelanjutan adalah dasar dari implementasi SLA.

Namun, dengan pendekatan ini, biasanya tidak ada layanan operasi, hanya tim pengembangan yang secara berkala terganggu oleh perbaikan dan (kadang-kadang) oleh "hutang teknis". Tetapi tidak ada yang khawatir karena ini, karena rencana tidak rusak. Sulit untuk mengacaukan apa yang tidak.

Sebagaimana ditetapkan oleh penulis dari proses asli, Kanban sangat ideal untuk operasi di mana perencanaan digantikan oleh respons terhadap rangsangan. Misalnya, beginilah tampaknya kerja dengan insiden - jika rusak, kami akan memperbaikinya. Dalam kebanyakan kasus, dengan prosedur yang diketahui. Namun, Kanban benar-benar tidak cocok untuk pengembangan, karena itu tidak berarti hasil akhir. Pilihan metodologi ini akan membawa Anda ke proses tanpa akhir - "kami membangun, membangun, dan masih membangun." Jangan lakukan itu!

Devops

Tentu saja, DevOps bukan metodologi pengembangan sendiri, tetapi saya tidak bisa tidak memasukkan 5 kopecks saya dan tidak berbicara tentang upaya paling umum untuk menyelesaikan konflik operasi dan pengembangan.

Secara teori, DevOps adalah seperangkat praktik yang ditujukan untuk interaksi aktif spesialis pengembangan dengan spesialis teknologi informasi dan integrasi timbal balik dari proses kerja mereka satu sama lain.

DevOps didasarkan pada gagasan saling ketergantungan yang erat antara pengembangan dan operasi perangkat lunak dan ditujukan untuk membantu organisasi dengan cepat membuat dan memperbarui produk dan layanan perangkat lunak. Lagi tentang pembuatan dan pembaruan cepat. Tetapi untuk mengeksploitasi masalah ini tidak ada sama sekali.

Sebagai hasilnya, DevOps menjadi sarana untuk membuat tim pengembangan independen dari layanan operasi dengan menyelesaikan tautan pengembangan yang diperlukan. Jelas, solusi ini sendiri adalah satu sisi dan menyelesaikan masalah hanya untuk satu pihak - pengembangan. Seringkali ini hanya memperburuk konflik, memungkinkan pengembangan untuk sepenuhnya mengabaikan operasi layanan.

Dalam praktiknya, saya paling sering menemukan dua implementasi:

• Tim admin operasi dipelihara dan terlibat dalam produktif.
  

Admin otomatisasi muncul di tim pengembangan untuk menyelesaikan masalah pengembang alih-alih tim operasi. Saya pikir sudah jelas bahwa sebagai hasil dari solusi mereka, muncul di lingkungan pengujian, saya tidak ingin membiarkan yang produktif, dan konflik hanya tumbuh.

• Hal yang sama, tetapi tim operasi dihapuskan dalam semangat prinsip "tidak ada manusia - tidak ada masalah."
  

Tugas mengelola ketersediaan layanan berjalan di pinggir jalan. Orang yang termotivasi oleh keputusan mereka tidak tetap sama sekali. Secara berkala, tim insinyur DevOps muncul, tetapi ini tidak mengubah apa pun, karena prioritas kepemimpinan mereka adalah tanggal rilis untuk rilis. Semua tugas lain dapat didorong selama tidak ada yang melihat.

Bahkan jika kita kembali ke ide awal bahwa DevOps, lebih tepatnya, tentang pengujian, dan harus menjamin transfer cepat dari perubahan kualitatif yang dijamin, sekali lagi ternyata tidak mungkin untuk dikecualikan dari proses atau mengganti operasi. Fokus dari ide itu sendiri adalah untuk memastikan kualitas dari proses perubahan dan menjamin kualitas dari perubahan-perubahan ini. Perhatikan bahwa kepatuhan SLA dan kontrol akses tidak disebutkan di mana pun. Dan kualitas tinggi dari perubahan (komponen) tidak menjamin kinerja keseluruhan sistem yang tinggi secara keseluruhan.

Tidak mungkin untuk meramalkan semuanya dan memverifikasi semuanya - pengujian tidak menjamin tidak adanya kecelakaan. Peralatan mungkin aus, sistem mungkin gagal selama operasi dalam kondisi yang tidak terduga. Akhirnya, ada faktor manusia.
Oleh karena itu, bahkan dengan tim DevOps, proses operasi sangat diperlukan, dan, bagaimanapun, dokumentasi akan diperlukan. Ketika sesuatu rusak, Anda harus mencari tahu cara kerjanya.

Alih-alih output

Jadi apa yang harus dilakukan dan bagaimana menjadi?

Bisnis: kembangkan strategi pengembangan yang koheren untuk produk Anda dan kelola kondisi pasar, daripada buru-buru merespons perubahan.
Pengembangan: Jangan mengubah pelanggan menjadi arsitek perusahaan. Bangunan teknik atau sistem TI bukan profilnya, ia adalah seorang ahli dalam beberapa bidang bisnis lokal.
Semua bersama-sama: upaya untuk menyingkirkan layanan operasi mungkin berhasil, tetapi Anda tidak mungkin dapat mengabaikan proses operasi itu sendiri, aksesibilitas harus tetap terkendali. Profesional yang berdedikasi akan mengelola ini, atau itu akan menjadi beban tambahan bagi pengembang, Anda memutuskan.

DevOps adalah hal yang sangat baik dan berguna untuk meningkatkan kualitas, tetapi karena alasan yang dijelaskan di atas, itu juga tidak akan memungkinkan penjaminan apa pun dan tidak akan menggantikan layanan operasional penuh. Pendekatan ini tidak akan menyelesaikan konflik pengembangan, operasi dan bisnis, tetapi akan membantu memastikan proses penerimaan yang berkelanjutan dan mengurangi stres secara keseluruhan.

Tentunya Anda semua dengan satu atau lain cara berpartisipasi dalam situasi dan proses yang dijelaskan di atas. Bagikan pengalaman Anda di komentar!