Jika The First Way menjelaskan tentang prinsip yang memungkinkan alur kerja yang lancar dan cepat dari kiri ke kanan (Development ke Operations), The Second Way ini mendeskripsikan prinsip yang memungkinkan feedback (umpan balik) yang cepat nan konstan dari kanan ke kiri (Operations ke Development).
Pada prinsip ini, fokus utamanya adalah untuk meningkatkan jumlah feedback dan mempercepat proses penyampaian feedback dari Operations ke Development (atau bisa juga dari pengguna ke tim terkait) guna mencegah agar masalah tak terulang kembali, memungkinkan deteksi masalah lebih dini, serta pemulihan infrastruktur lebih cepat.
Sebagai contoh, tim Developer telah menulis kode aplikasi dan kemudian menyerahkannya ke tim IT Operations untuk di-deploy. Akan tetapi, saat dilakukan pengujian pada lingkungan Test, performa dari kode aplikasi tersebut kurang begitu bagus sehingga menyebabkan aplikasi tidak optimal. Setelah itu, tim IT Operations memberikan feedback kepada Developer agar kodenya diperbaiki supaya ke depannya bisa berjalan lebih baik. Dengan begitu, tim Developer bisa melakukan perbaikan sesegera mungkin dan akhirnya kualitas aplikasi makin meningkat.
Prinsip ini sangat penting untuk kita pahami agar tercipta sistem kerja yang lebih aman sebab masalah dapat ditemukan sedini mungkin dan diperbaiki lebih cepat sehingga kita terhindar dari kegagalan saat aplikasi sudah di-deploy ke production a.k.a dirilis ke publik.
Menciptakan sistem kerja yang aman menjadi hal yang sangat penting dalam proses pengembangan aplikasi, terutama bila kita bekerja dengan sistem aplikasi yang kompleks. Pasalnya, kita harus bisa dan mampu mendeteksi masalah (atau potensi masalah) sedini mungkin dan segera menyampaikan feedback agar dapat langsung diperbaiki. Jika tidak, maka masalah akan semakin melebar dan akhirnya melumpuhkan seluruh sistem.
Apabila sistem aplikasi yang kompleks ini ternyata down (lumpuh) sepenuhnya, niscaya kita akan kesulitan dalam menghidupkannya kembali karena diperlukan sejibun prosedur, menghabiskan waktu, dan memakan biaya. Untuk itulah mengapa prinsip terkait umpan balik ini krusial untuk diterapkan.
Namun, pertanyaannya adalah bagaimana cara agar prinsip terkait umpan balik ini dapat diterapkan dengan baik? Tentu saja ada beberapa aspek penting yang wajib kita pahami. Mari kita telaah satu per satu.
Swarming dalam Menyelesaikan Masalah
Ketika kita mengembangkan atau memelihara aplikasi, feedback (umpan balik) akan datang kapan saja, entah itu berupa laporan masalah dari pengguna ataupun hasil temuan oleh tim internal. Namun, kali ini mari kita fokuskan terhadap feedback dari pengguna.
Sebelum DevOps hadir, banyak perusahaan IT yang mengelola insiden atau masalah melalui mekanisme “three-tier support hierarchy”, di mana suatu insiden haruslah diproses melalui 3 tingkatan, antara lain:
Level 1: Frontline Service Desk, yang bertugas untuk menangani komunikasi yang masuk dari pengguna secara langsung, biasanya dengan menjawab panggilan telepon, chat, dll.
Umumnya, Frontline Service Desk dipersiapkan untuk memberikan dukungan teknis umum pada tingkat menengah saja, dengan tujuan menghadirkan dukungan yang konsisten kepada pengguna, seraya menyelesaikan sejumlah besar masalah yang masuk di lini pertama.
Level 2: Dukungan tingkat kedua, biasanya berkaitan dengan Service Desk, tetapi dengan keterampilan atau spesialisasi yang lebih dalam.
Agen dukungan pada Level 2 ini umumnya memiliki pelatihan tambahan untuk mendukung sistem operasi (seperti Microsoft Windows) atau perangkat keras secara umum. Karenanya, mereka dapat menyelesaikan masalah yang lebih kompleks.
Level 3: Tim dukungan spesialis yang berfokus pada teknologi dan aplikasi tertentu.
Untuk perusahaan yang mengembangkan perangkat lunak secara internal, biasanya terdapat tim dukungan Level 3 khusus yang ditugaskan untuk setiap aplikasi atau layanan.
Melalui mekanisme seperti ini, pengguna hanya akan berhadapan dengan dukungan Level 1 (Level 1 Support). Semua masalah pengguna akan berawal dan mungkin berakhir di level ini. Akan tetapi, bila ada masalah yang terlalu kompleks untuk diselesaikan pada Level 1 Support, maka masalah tersebut akan dieskalasi ke Level 2 Support dan/atau Level 3 Specialist.
Ketahuilah bahwa sistem seperti ini memiliki banyak kekurangan, terutama dari sisi DevOps. Salah satunya masalah utamanya adalah ia dapat membuat banyak antrean.
Seperti yang kita bahas sebelumnya, semua masalah yang tak bisa ditangani oleh Level 1 Support akan dieskalasi ke Level 2 Support dan/atau Level 3 Specialist. Tak ayal mekanisme seperti ini sering kali menyebabkan banyak antrean. Sebab masalah yang ditangani oleh Level 2 dan Level 3 lebih kompleks ketimbang di Level 1, maka proses penyelesaian masalahnya pun membutuhkan waktu yang lama dan berujung antrean yang kian menumpuk untuk diselesaikan.
Parahnya lagi, terkadang ditemukan suatu insiden/masalah yang “bouncing” alias memantul antarlevel. Maksudnya begini. Dalam sistem “three-tier support hierarchy”, cara melakukan eskalasi ke tim lain adalah dengan mengubah tim yang ditugaskan padanya. Langkah ini biasanya dilakukan secara sepihak oleh tim pemberi tugas kepada tim penerima tugas.
Sayangnya, sangat umum untuk melihat suatu insiden/masalah memantul kembali, misal dari Level 2 dikembalikan ke Level 1. Ini bisa disebabkan oleh berbagai faktor, entah itu karena Level 2 memerlukan informasi yang lebih detail atau karena mereka merasa itu bukan tugas mereka.
Perlu Anda pahami bahwa DevOps pada dasarnya dibangun berdasarkan kolaborasi antara Developer dan IT Operations. Itu berarti, sudah jelas bahwa mekanisme “three-tier support hierarchy” merupakan antitesis dari prinsip DevOps.
Oleh karena itu, muncul sebuah terobosan baru dalam dunia pengelolaan insiden/masalah bernama “swarming”. Model ini secara eksplisit menolak mekanisme “three-tier support hierarchy” yang berbasis eskalasi dan lebih mendukung proses berbasis kolaborasi.
Beberapa prinsip intinya antara lain:
- Tidak boleh ada tim dukungan yang bertingkat.
- Tidak boleh ada eskalasi dari satu tim ke tim lain.
- Suatu insiden atau masalah harus diserahkan langsung ke orang yang paling mungkin dapat menyelesaikannya.
- Orang yang menangani masalah harus mengawasinya sampai masalah tersebut selesai.
Swarming menawarkan mekanisme yang lebih baik, yaitu dengan mengeliminasi antrean dan handoff yang ada untuk setiap insiden/masalah dengan membawa responden ahli (misal, dari Developer atau IT Operations) langsung ke inti masalah. Model swarming ini berfokus untuk mengurangi waktu yang dibutuhkan untuk penyelesaian masalah sekaligus berbagi pengetahuan di antara tim terkait mengenai insiden yang terjadi dengan cepat.
Model ini didasarkan pada kolaborasi berjejaring di seluruh tim teknis (misal, perpaduan dari Developer dan IT Operations) daripada pendekatan eskalasi bertingkat pada model “three-tier support hierarchy”. Sebagian besar perusahaan membentuk tim “swarm” dengan jumlah anggota yang sedikit berdasarkan bidang keahlian dan reputasi individu yang berfokus pada penyelesaian insiden/masalah yang masuk dari pengguna secara cepat. Umumnya terdapat beberapa kategori berikut:
Severity 1 Swarm: Terdiri dari 3 orang yang ahli pada bidang atau topik tertentu pada aplikasi perusahaan (SME atau Subject Matter Expert) dari berbagai tim (umumnya dari Developer dan IT Operations) dan akan dirotasi setiap minggunya. Tujuan dari tim ini adalah untuk menangani masalah dengan tingkat keparahan tertinggi secepat mungkin. Sehingga, biasanya dari 100% jumlah insiden/masalah yang masuk, tim ini hanya mengerjakan 1% yang memang benar-benar masuk dalam kategori kritis. Sisanya, akan dikerjakan oleh Local Dispatch
Local Dispatch Swarm: Tim ini didedikasikan untuk menerima sebagian besar insiden/masalah yang masuk dari pengguna (sekitar 99% masalah akan masuk ke tim ini). Mereka bertemu tiap hari setiap 60–90 menit untuk memilih insiden/masalah yang dapat mereka selesaikan dengan cepat (biasanya sekitar 30% akan selesai di sini) dan meneruskan insiden/masalah yang tidak dapat mereka pecahkan (sekitar 70% sisanya) ke Product Line support team.
Backlog Swarm: Tim ini akan bertemu setiap hari untuk menyelesaikan insiden/masalah yang diberikan oleh Product Line support team. Tim ini berisi orang-orang teknis yang terampil dan berpengalaman dari berbagai departemen (baik dari Developer maupun IT Operations), dengan fokus pada kasus-kasus sulit yang tak bisa diselesaikan oleh Product Line support team.
Nah, dengan cara ini, feedback (misal, berupa laporan masalah) dari pengguna bisa langsung diterima oleh tim yang tepat dan segera diatasi dalam waktu singkat.
Bagaimana, kini sudah paham kan dengan model swarming? Model ini dibangun di atas banyak prinsip yang sama yang mendukung keberhasilan DevOps, seperti:
- Kolaborasi lintas fungsi yang dinamis dengan menyatukan berbagai keterampilan ke dalam suatu tim gabungan.
- Organisasi tim yang fleksibel, bukan struktur hierarkis yang kaku.
- Otonomi individu, bukan proses dogmatis.
- Fokus pada penghindaran penumpukan WIP.
- Antarinvididu dapat saling berbagi pengetahuan ke tim lain pada saat proses penyelesaian masalah
Dengan begitu, model ini sangat cocok untuk diterapkan apabila Anda ingin menerapkan DevOps. Selain poin-poin di atas, model swarming juga mampu mendukung alur feedback yang lebih baik dari sisi internal. Karena absennya model hierarki dan digantikan dengan tim gabungan dari berbagai departemen (umumnya dari Developer dan IT Operations), mereka bisa secara langsung saling berkomunikasi, berbagi pengetahuan, dan silih memberi feedback seraya menyelesaikan masalah bersama.
Mendorong Tanggung Jawab ke Tempat Asalnya
Saat sedang mengembangkan aplikasi, mungkin saja secara tidak sengaja kita melanggengkan sistem kerja yang tidak efektif karena cara kita dalam menanggapi suatu insiden/masalah, apalagi jika aplikasi yang dikembangkan memiliki sistem yang kompleks. Sebagai contoh, dengan menambahkan lebih banyak proses approval (persetujuan), sebenarnya malah akan meningkatkan kemungkinan kegagalan di masa depan.
Percaya atau tidak, efektivitas dari proses approval akan menurun saat kita menempatkan tindakan pengambilan keputusan jauh dari tempat di mana pekerjaan dilakukan. Bahkan, tak hanya menurunkan kualitas dari keputusan yang diambil, melainkan juga dapat memperlama waktu dalam merilis aplikasi karena kita harus menyusuri birokrasi yang berbelit. Sehingga, ini dapat mengurangi kemampuan kita untuk belajar dari keberhasilan dan kegagalan. Pada akhirnya, takut berbuat salah.
Masih bingung? Oke, coba simak beberapa contoh proses yang tidak efektif berikut ini.
Tim A memerlukan bantuan tim lain untuk menyelesaikan tugas-tugas yang membosankan, rawan kesalahan, dan manual. Padahal, sebenarnya tugas-tugas tersebut dapat dengan mudah diotomatisasi dan dijalankan sesuai kebutuhan oleh tim A.
Tim A memerlukan approval dari orang-orang yang sebenarnya tak memiliki pengetahuan yang memadai tentang pekerjaan yang dilakukan oleh tim A sehingga orang-orang tersebut akhirnya hanya sekadar memberi stempel “approve/setuju”.
Menyerahkan sejumlah besar pekerjaan ke tim atau komite khusus untuk meminta persetujuan dari mereka dan kemudian menunggu respons dari mereka dalam waktu yang lama.
Sungguh, contoh-contoh di atas sangatlah tidak efektif dan memakan waktu. Oleh karena itu, sebagai gantinya, kita seharusnya mengefektifkan berbagai proses dengan melimpahkan wewenang hanya kepada orang-orang yang terlibat dalam proses pengembangan aplikasi untuk menemukan dan memperbaiki masalah sesuai dengan area keahlian mereka sebagai bagian dari pekerjaan sehari-hari.
Dengan melakukan ini, kita mendorong tanggung jawab dan pengambilan keputusan ke tempat asalnya (di mana pekerjaan tersebut dilakukan, yakni lingkungan di mana aplikasi dikembangkan), alih-alih mengandalkan persetujuan dan pengecekan dari tim lain atau eksekutif yang jauh keberadaannya.
Ada beberapa inisiatif yang bisa kita lakukan, di antaranya:
Kita bisa terapkan peer review (aktivitas memeriksa, meninjau, dan mengevaluasi kode oleh sesama Developer) terhadap perubahan kode yang dilakukan untuk menjamin bahwa kode dapat beroperasi di lingkungan production sesuai yang diharapkan.
Kita dapat mengotomatiskan sebanyak mungkin proses pemeriksaan kualitas kode yang biasanya dilakukan oleh departemen QA (Quality Assurance).
Alih-alih Developer harus meminta ke tim lain agar pengujian bisa dijadwalkan atau dijalankan segera, kita bisa mengeliminasi birokrasi tersebut agar pengujian tersebut dapat dilakukan kapan saja. Sehingga, ini memungkinkan Developer untuk menguji kode mereka sendiri sesegera mungkin dan bahkan men-deploy perubahan kode ke dalam lingkungan production secara mandiri.
Nah, dengan mengimplementasikan poin-poin di atas, kita menjadikan kualitas kode, keamanan apikasi, dan keandalan infrastruktur sebagai tanggung jawab semua orang, bukan hanya tim atau departemen tertentu.
Memiliki Developer yang saling berbagi tanggung jawab terhadap kualitas sistem yang mereka bangun sendiri tak hanya mampu meningkatkan hasil, tetapi juga dapat memperbaiki alur feedback. Apa yang Developer lakukan terhadap sistem akan langsung mereka rasakan sendiri dampaknya. Tak perlu lagi menunggu tim lain yang memberi tahu mereka. Sebelum masalah makin menyebar, Developer bisa langsung memperbaikinya sedini mungkin.
Mengoptimalkan Kualitas Operasional
Dalam dunia IT, ada dua tipe pelanggan yang harus kita pertimbangkan saat mengembangkan aplikasi:
Pelanggan eksternal, yang kemungkinan besar membayar untuk layanan yang perusahaan berikan.
Pelanggan internal, yang menerima dan memproses pekerjaan kita selanjutnya.
Lantas, siapakah di antara dua ini yang harus diprioritaskan? Sebenarnya, keduanya sama-sama penting untuk diutamakan. Dalam kasus bisnis, maka pelanggan eksternal alias pengguna aplikasilah yang perlu diprioritaskan karena mereka yang membuat perusahaan bisa bertahan di tengah gempuran persaingan pasar. Kita wajib memiliki empati kepada pengguna aplikasi dengan cara lebih tanggap dalam mengidentifikasi dan menyelesaikan setiap masalah yang mereka hadapi.
Namun, itu bukan berarti menafikan keberadaan pelanggan internal. Bagi Developer, pelanggan internalnya adalah tim IT Operations yang menerima kode dan memprosesnya ke lingkungan production. Oleh karena itu, dalam proses pengembangan aplikasi, Developer juga wajib mengoptimalkan kualitas operasional dengan mempertimbangkan hal-hal seperti arsitektur, kinerja, stabilitas, pengujian, konfigurasi, dan keamanan. Semua aspek-aspek tersebut harus diprioritaskan, sama seperti fitur pengguna.
Semoga dengan pembahasan di atas Anda paham ya dengan The Second Way. Intinya, menciptakan alur feedback (umpan balik) yang cepat merupakan hal yang sangat penting untuk mencapai kualitas kode, keamanan aplikasi, dan keandalan infrastruktur dalam proses pengembangan aplikasi.
Nah, salah satu cara terbaik untuk mencapainya adalah dengan memiliki praktik seperti continuous integration atau continuous deployment (akan kita pelajari nanti) yang dipadukan bersama dengan rangkaian automated test (pengujian otomatis) yang cepat. Dengan mempraktikkan hal-hal ini, feedback (umpan balik) bisa segera tersampaikan dengan cepat ke Developer (atau tim terkait) dan segera diperbaiki.