Industri teknologi sedang bergelut dengan kesedaran yang semakin berkembang bahawa DevOps, yang pernah dipuji sebagai pendekatan revolusioner kepada pembangunan perisian dan operasi, mungkin telah tersesat arah. Apa yang bermula sebagai pergerakan untuk memperkasakan pembangun untuk memiliki persekitaran pengeluaran mereka telah berkembang menjadi sesuatu yang dihujahkan oleh ramai sebagai mengalahkan tujuan asalnya.
Visi Asal berbanding Realiti Semasa
DevOps bermula dengan idea yang mudah: pembangun sepatutnya menggunakan kod mereka sendiri dan bertanggungjawab untuk memastikan ia terus berjalan. Ini bermaksud memantau sistem, bertindak balas terhadap isu, dan menggunakan kemahiran pengaturcaraan untuk mengautomasikan penggunaan dengan selamat. Pendekatan ini sangat masuk akal, terutamanya apabila perkhidmatan awan menjadikan pelancaran pelayan semudah memanggil API.
Walau bagaimanapun, sebaik sahaja amalan ini mendapat nama rasmi, semuanya berubah. Syarikat mula mencipta pasukan DevOps khusus dan mengupah jurutera DevOps, dengan berkesan menarik pembangun yang berfikiran pengeluaran daripada pasukan produk. Ini meninggalkan pasukan pembangunan tanpa sesiapa yang memberi tumpuan kepada kebimbangan pengeluaran, mencipta semula silo yang sama yang DevOps bertujuan untuk hapuskan.
Masalah Jurang Kemahiran
Salah satu isu paling ketara yang melanda pelaksanaan DevOps moden ialah ketidakpadanan kemahiran yang asas. Ramai profesional dalam peranan DevOps berasal dari latar belakang pentadbiran sistem tradisional tanpa keupayaan pengaturcaraan yang kuat. Ini mewujudkan kesesakan di mana pasukan bergelut dengan tugas nyahpepijat asas dan automasi yang memerlukan kemahiran pembangunan sebenar.
Jangkaan bahawa seseorang individu boleh mengendalikan pembangunan, operasi, kebolehperhatian, dan sokongan tidak berskala dalam amalan. Apa yang sering terhasil ialah sama ada kakitangan operasi dengan gelaran baru yang mewah atau pembangun yang dilemparkan ke dalam wilayah yang tidak dikenali, jarang mencapai gabungan kemahiran sebenar yang dituntut oleh peranan tersebut.
Masalah Biasa Pelaksanaan DevOps
- Ketidakpadanan Kemahiran: Ramai profesional DevOps kurang kemampuan pengaturcaraan yang kukuh, berasal dari latar belakang pentadbir sistem tradisional
- Silo Organisasi: Mewujudkan pasukan DevOps berasingan menarik kepakaran pengeluaran daripada pasukan pembangunan
- Isu Kepercayaan: Pelaksanaan moden sering mengehadkan daripada memperkasakan pembangun
- Beban Pematuhan: Keperluan keselamatan dilaksanakan melalui sekatan daripada ketelusan
- Kerumitan Alatan: Abstraksi dalaman yang ketinggalan berbanding keupayaan penyedia awan
Isu Kepercayaan dan Kawalan
Pasukan DevOps moden sering beroperasi di bawah andaian bahawa pembangun tidak boleh dipercayai dengan akses pengeluaran. Pemikiran ini membawa kepada lapisan sekatan dan proses kelulusan yang memperlahankan pembangunan daripada membolehkannya. Pasukan akhirnya membina alat dalaman yang direka lebih untuk menyekat daripada memperkasa, membungkus API awan dalam abstraksi buatan sendiri yang ketinggalan di belakang apa yang sudah ditawarkan oleh penyedia.
Jurutera pasukan produk pada masa kini berasa seperti kanak-kanak yang dimanjakan, mereka tidak tahu bagaimana pelayan berjalan, dan meminta perkara yang tidak munasabah.
Ini mewujudkan kitaran ganas di mana pembangun menjadi semakin terputus daripada realiti pengeluaran manakala pasukan DevOps menjadi penjaga pintu daripada pemboleh.
Perangkap Pematuhan
Keperluan pematuhan sering dipersalahkan atas amalan yang menyekat, tetapi isu sebenar terletak pada pelaksanaan. Keselamatan sepatutnya datang daripada keterlihatan dan ketelusan, bukan pintu yang berkunci. Apabila pasukan DevOps memiliki senarai semak pematuhan, mereka sering membakar ketidakpercayaan ke dalam peraturan, menganggap pembangun sebagai pelakon jahat yang berpotensi daripada rakan usaha sama.
Apa Yang Berfungsi Lebih Baik
Organisasi yang menemui kejayaan sedang beralih daripada pasukan DevOps yang berasingan ke arah model terbenam. Sesetengah syarikat mempunyai jurutera yang berfikiran pengeluaran bekerja secara langsung dengan pasukan pembangunan, menggunakan gelaran seperti jurutera sistem daripada jurutera DevOps. Pendekatan ini mengekalkan kepakaran operasi dekat dengan produk sambil mengekalkan semangat kolaboratif yang menjadikan DevOps berharga pada mulanya.
Pasukan yang paling berkesan menggabungkan pembangun yang berfokus ciri dengan ahli pasukan yang mahir ops yang boleh menggunakan kerja mereka sendiri, disokong oleh pasukan kejuruteraan platform khusus yang menyediakan alat dan infrastruktur tanpa menjadi kesesakan.
Pendekatan Alternatif yang Berjaya
- Model Terbenam: Jurutera yang berfikiran pengeluaran bekerja secara langsung dengan pasukan pembangunan
- Jurutera Sistem: Peranan teknikal yang memfokuskan kepada infrastruktur tanpa beban " DevOps "
- Kejuruteraan Platform: Pasukan khusus yang menyediakan alatan dan infrastruktur tanpa menjadi halangan
- Tanggungjawab Berkongsi: Menggabungkan pembangun yang memfokuskan ciri dengan ahli pasukan yang mahir dalam operasi
Memandang Ke Hadapan
Industri nampaknya sedang belajar daripada kesilapan ini, walaupun perlahan. Platform Engineering sedang muncul sebagai evolusi seterusnya, walaupun sesetengah pihak bimbang ia mungkin mengulangi corak yang sama. Kuncinya nampaknya mengekalkan semangat kolaboratif dan tanggungjawab bersama yang menjadikan DevOps berharga sambil mengelakkan silo organisasi yang melemahkannya.
Kejayaan memerlukan kepimpinan teknikal yang kuat yang memahami kedua-dua pembangunan dan operasi, objektif yang jelas, dan budaya yang menghargai kerjasama berbanding politik. Tanpa asas ini, mana-mana model organisasi akan bergelut tanpa mengira apa yang dipanggil.