Pelatihan Tertulis DevOps

Bagaimana Cara Membentuk Organisasi DevOps dan Merancang Arsitektur Perangkat Lunaknya?

Menurut hukum Conway, organisasi yang merancang sistem cenderung menghasilkan sistem yang mencerminkan struktur komunikasinya sendiri. Dengan kata lain, perangkat lunak tidak bisa lebih baik daripada efektivitas komunikasi dan interaksi tim. Struktur tim pasti memengaruhi arsitektur perangkat lunak, kinerja TI, dan pada akhirnya kinerja bisnis.

Struktur Organisasi Menentukan Perangkat Lunak yang Dihasilkan

Sebagian besar perusahaan, mungkin termasuk perusahaan Anda, membagi organisasi pengiriman perangkat lunak ke beberapa tim dan akhirnya menghasilkan perangkat lunak dengan jumlah lapisan arsitektur yang sama. Eksperimen terkontrol juga menunjukkan bahwa ketika sebuah organisasi dengan 6 tim diminta membuat perangkat lunak, hasilnya adalah arsitektur 6 lapis. Ketika organisasi dengan 3 tim diminta membuat perangkat lunak yang sama, hasilnya 3 lapis. Banyak contoh lain yang serupa.

Perusahaan asuransi ternama dengan 86.000 karyawan di seluruh dunia kebetulan membagi salah satu organisasi TI-nya menjadi 2 tim fungsional utama yang menyediakan backend untuk mengelola pelanggan, kontrak, tagihan, dan layanan. Satu tim berfokus pada bahasa Java dan tim lain pada stored procedure PL/SQL. Mereka juga bergantung pada operasi TI, administrator basis data, infrastruktur, jaringan, keamanan, dan layanan penjaminan mutu terpusat, sehingga pengiriman perangkat lunak secara aman menjadi lebih sulit.

Meski timnya terpisah, arsitektur mereka tidak dapat memisahkan dengan baik logika orkestrasi bisnis dalam Java dari logika akses data dalam PL/SQL. Mereka mengirimkan ratusan fitur, masing-masing berupa kode Java dan PL/SQL yang saling kusut. Setiap perubahan dan permintaan fitur baru membutuhkan puluhan serah terima, sehingga antrean panjang dan waktu tunggu terjadi bahkan untuk perubahan kecil. Karena dampak perubahan kecil pun sulit diperkirakan dalam lingkungan ini, mereka terus merusak fitur yang sudah berjalan dan menyebabkan waktu henti yang memerlukan banyak waktu, pengerjaan ulang, eskalasi, dan tekanan untuk diatasi.

Untuk mengubah cara kerja itu, dua tim fungsional bergabung menjadi satu tim produk. Mereka secara bertahap merancang ulang perangkat lunak dengan mengubah lapisan akses data menjadi sekumpulan fungsi API. Mereka juga membuat sistem bisnis baru yang sepenuhnya terlepas dari cara kerja internal API akses data. Sejak awal, inisiatif ini memperbaiki semangat tim karena pakar Java dan PL/SQL bekerja demi produk bersama dan bukan kepentingan unit masing-masing. Dengan arsitektur berketerkaitan longgar, dampak perubahan lebih mudah diketahui, perubahan lebih mudah dan cepat diterapkan, serta cacat lebih mudah ditemukan dan diperbaiki. Rata-rata waktu pengiriman fitur baru turun dari 4 bulan menjadi 3 minggu. Antrean insiden hampir kosong, dan tim menggunakan waktu yang tersedia untuk meninjau, merombak struktur, dan meningkatkan basis kode.

Organisasi Matriks, Tim Fungsional, dan Ilusi Optimalisasi Biaya

Perusahaan Anda memiliki tim fungsional di berbagai bidang seperti basis data, jaringan, operasi, keamanan informasi, penjaminan mutu, manajemen rilis, manajemen proyek, dan manajemen produk. Tim proyek dibentuk dari orang-orang di berbagai unit fungsional. Dalam organisasi matriks yang berusaha mengirimkan produk dan layanan, manajer proyek biasanya bertanggung jawab memastikan sesuatu terkirim, sedangkan manajer produk memastikan bahwa yang dikirim memang tepat.

Masalahnya, tim fungsional hanya sedikit atau sama sekali tidak memahami cakupan pekerjaan yang mereka dukung. Dalam kasus ekstrem tetapi umum, tim tidak memedulikan gambaran keseluruhan atau hasil TI dan bisnis dari produk dan layanan yang mereka dukung. Yang penting bagi mereka adalah melindungi diri ketika proyek bermasalah dan orang-orang mulai saling menyalahkan.

Tim fungsional biasanya menangani antrean tiket panjang dan membutuhkan waktu lama untuk membantu proyek Anda. Karena berbagai proyek berebut sumber daya fungsional, eskalasi menjadi satu-satunya cara mendapatkan perhatian dengan cepat. Eskalasi yang terus berulang merusak suasana kerja dan kepercayaan antartim.

Serah terima berulang, penundaan, masalah mutu, pengerjaan ulang, hambatan, dan stres menjadi bagian dari keseharian. Organisasi matriks sulit mencapai hasil lebih baik selama terus mengejar ilusi optimalisasi biaya yang tidak transparan. Bahkan karena masalah mutu, pengerjaan ulang, dan penundaan, struktur fungsional mungkin lebih mahal daripada berbagai alternatif penataan. Jika keterampilan fungsional yang penting seperti penjaminan mutu dan operasi TI telah dialihdayakan ke lokasi yang jauh, organisasi TI Anda mungkin kesulitan menjaga pengiriman tetap aman dan memenuhi kebutuhan penting bagi kelangsungan bisnis.

Bagaimana DevOps Mengatasi Masalah Ini? Dengan Tim yang Berfokus pada Produk dan Layanan

DevOps menyarankan Anda beralih dari ilusi penghematan biaya melalui tim fungsional ke peningkatan kecepatan yang telah terbukti. Jika diterapkan dengan benar, DevOps juga membantu menghemat biaya sementara tim Anda terus mengirimkan hasil dengan cepat.

DevOps menyarankan tim yang berfokus pada produk dan layanan. Tim ini independen, lintas fungsi, otonom, mandiri, dan biasanya kecil. Mereka mampu menangani seluruh siklus rekayasa produk dan layanan, bukan hanya proyek sementara. Pekerjaannya mencakup arsitektur, desain, penulisan kode, pengujian, eksperimen, penerapan, operasi, dan pemeliharaan. Ya, Anda tidak salah baca. Siapa yang bisa mengoperasikan dan memelihara perangkat lunak lebih baik daripada pembuatnya? Tentu saja tidak ada. Karena itu, tim DevOps paling sukses di Amazon dan Netflix tetap menangani produk dan layanan setelah dirilis, termasuk mengoperasikan dan memelihara perangkat lunak di sistem produksi mereka sendiri.

Organisasi Anda Beralih dari Mendanai Proyek Sementara ke Mendanai Produk dan Layanan

Untuk meningkatkan kinerja bisnis, organisasi Anda tidak lagi mendanai proyek sementara yang hasil bisnis nyatanya sulit dinilai dalam jangka panjang. Dengan DevOps, organisasi mendanai misi, tujuan, serta produk dan layanan yang mendukungnya. Keberhasilan tim dinilai dari kinerja TI dan bisnis, termasuk imbal hasil investasi di bidang tempat mereka melayani klien internal dan/atau eksternal dengan produk, layanan, dan layanan mikro. Tim bertanggung jawab atas produk dan layanan yang mereka buat, bukan sekadar menjadi bagian dari unit fungsional yang kurang memerhatikan hasil bisnis.

Bagaimana Cara Membangun Tim DevOps dan Arsitektur Perangkat Lunak Anda?

DevOps tidak menyarankan membubarkan dan menata ulang semua proyek sekaligus. Cara yang tidak mengganggu tetapi tetap berdampak adalah memasukkan pakar fungsional ke dalam tim proyek. Jika tim memiliki pakar penjaminan mutu, keamanan informasi, basis data, jaringan, server, operasi, dan bidang lain yang dibutuhkan, mereka dapat merancang, menerapkan, serta memelihara produk dan layanan secara mandiri.

Di tim DevOps yang berfokus pada produk dan layanan, ketersediaan, mutu, kinerja, keamanan informasi, dan kepatuhan menjadi tanggung jawab sehari-hari setiap orang. Bagaimana tim bisa membuat aplikasi yang aman, bermutu, sangat tersedia, dan mampu menanggung beban yang dibutuhkan klien jika persyaratan nonfungsional baru diperhatikan setelah desain dan pengembangan selesai? Bagaimana pakar eksternal dapat menilai dan memvalidasi keamanan serta mutu secara tepat tanpa terlibat dalam satu pun tahap rekayasa? Karena itu, tim berkinerja tinggi menggunakan pakar eksternal hanya untuk konsultasi dan tetap bertanggung jawab penuh atas persyaratan nonfungsional sepanjang siklus hidup.

Ada Pilihan Lain yang Dapat Anda Pertimbangkan

Google adalah organisasi DevOps yang sangat sukses dan masih banyak mengandalkan tim fungsional bersama tim DevOps produk dan layanan. Keduanya memandang misi organisasi beserta produk dan layanan sebagai tujuan bersama. Tim fungsional membuat cetak biru seperti templat, daftar periksa, dan kerangka aplikasi, serta sistem layanan mandiri, misalnya untuk menyediakan dan mengonfigurasi server serta jaringan. Dengan begitu, mereka tidak menghambat tim produk dan layanan. Mereka bekerja sama dan membantu sejak awal siklus rekayasa, memberikan tinjauan sejawat yang membangun atas desain, kode, dan pengujian, serta menyediakan konsultasi berkelanjutan.

Berapa Ukuran Tim DevOps yang Ideal?

Ukuran yang ideal adalah 5 hingga 10 orang. Ukuran ini menyederhanakan komunikasi dan koordinasi. Pemimpin dan anggota tidak menghabiskan banyak waktu untuk tugas kecil dan administrasi. Ukuran produk dan layanan yang dikelola juga tetap terbatas sehingga aplikasi tidak terlalu rumit untuk dioperasikan dan dipelihara. Setiap anggota memahami gambaran keseluruhan dan mendapat pengalaman memimpin melalui misi penting organisasi. Pemimpin tim bekerja dengan manajemen atas untuk memahami sasaran dan menyampaikannya kepada anggota.

Bagaimana Jika Produk dan Layanan Tidak Lagi Dapat Ditangani Tim Beranggotakan hingga 10 Orang?

Pisahkan produk dan layanan baru, lalu bentuk tim DevOps lain untuk menanganinya. Produk dan layanan tidak hanya untuk klien eksternal yang membayar. Anda juga dapat membangun produk, layanan, atau “API layanan mikro” internal beserta timnya untuk klien internal. Jika sistem penagihan terlalu besar untuk tim beranggotakan hingga 10 orang, misalnya, bentuk tim lain untuk menangani API akses basis data. Tim lain mungkin menangani API pembayaran daring, dan tim lain menangani proses batch. Semua tim sebaiknya menggunakan repositori kode dan pipeline penerapan bersama untuk memastikan integrasi berkelanjutan, pengiriman cepat, dan keberhasilan organisasi.

Dalam arsitektur yang sangat saling bergantung, perubahan kecil pada satu aplikasi dapat berdampak buruk pada banyak alur kerja. Karena itu, produk, layanan, dan API layanan mikro harus berketerkaitan longgar. Setiap tim DevOps hanya bertanggung jawab atas satu bagian dan dapat merancang, mengembangkan, dan menerapkan perangkat lunaknya secara mandiri. Mekanisme peringatan dini dalam pipeline sebaiknya memberi tahu tim dengan cepat dan otomatis tentang kemungkinan dampak buruk setiap perubahan kode.

Bagaimana Tim Kecil Beranggotakan hingga 10 Orang Dapat Menangani Sendiri Semua Tahap, dari Arsitektur hingga Operasi?

Dorong semua anggota tim menjadi generalis. Beri mereka kesempatan untuk terus mengembangkan keterampilan baru.

Rekrut hanya orang yang ingin belajar dan berkembang, apa pun tingkat pengetahuan dan pengalaman mereka saat ini. Hindari orang yang ingin dinilai berdasarkan peran dan tanggung jawab yang tetap. Organisasi, produk, dan layanan Anda akan terus berubah.

Permintaan akan berubah besok, kalau bukan hari ini.

KESIMPULAN

Dalam bab ini, kami menjelaskan hasil yang kurang optimal dari organisasi matriks, sekat antarunit fungsional, dan cara DevOps mengatasinya.

DevOps menyarankan Anda membentuk tim kecil beranggotakan hingga 10 orang yang berfokus pada produk, layanan, atau API layanan mikro.

Tim tersebut sebaiknya terdiri atas teknisi perangkat lunak generalis yang menguasai seluruh lapisan teknologi dan mampu menangani semua tahap secara mandiri, dari desain hingga pemeliharaan.

DevOps mengandalkan arsitektur berorientasi layanan (SOA) dengan keterkaitan longgar, sehingga setiap tim DevOps memiliki dan mengoperasikan satu bagian arsitektur.