Rapat Akibat Deployment yang Lambat (2015)
(tidyfirst.substack.com)- Dalam situasi ketika engineer merasa “tidak bisa merilis kode karena rapat”, penyebab sebenarnya bisa jadi adalah overhead organisasi yang muncul akibat kapabilitas deployment yang lambat
- Chuck Rossi dari Facebook melihat bahwa jumlah perubahan yang dapat ditangani oleh satu kali deployment tampaknya hampir tetap, dan untuk meningkatkan volume perubahan, jumlah deployment harus ditambah
- Facebook meningkatkan deployment kode PHP dari mingguan menjadi harian, lalu 3 kali sehari; siklus rilis aplikasi mobile juga dipersingkat dari 6 minggu menjadi 4 minggu, lalu 2 minggu, dan ini terutama dipimpin oleh tim release engineering
- Ketika produksi perubahan melampaui batas deployment, jumlah perubahan per deployment tidak mudah meningkat; sebaliknya overhead seperti rapat, review, dan handoff bertambah, sehingga organisasi beradaptasi ke arah menurunkan total volume perubahan
- Untuk meloloskan lebih banyak perubahan, bukan hanya rapat yang perlu dikurangi; kapasitas deployment harus ditingkatkan dengan memperbaiki siklus deployment, testing, monitoring, isolasi, dan hubungan sosial di dalam tim
Rapat Bisa Jadi Bukan Penyebab, Melainkan Akibat
- Keluhan umum bahwa “terlalu banyak rapat sehingga tidak bisa men-deploy kode” mungkin memiliki hubungan sebab-akibat yang terbalik
- Menambah atau mengurangi overhead organisasi relatif mudah, tetapi meningkatkan kapabilitas organisasi untuk men-deploy kode lebih sulit
- Rapat dan review bisa jadi merupakan hasil adaptasi organisasi agar sistem deployment tidak kelebihan beban
- Chuck Rossi mengamati bahwa di Facebook, jumlah perubahan yang dapat diproses oleh satu kali deployment tampak seperti sudah ditentukan
- Jika ingin lebih banyak perubahan, diperlukan lebih banyak deployment
- Deployment kode PHP meningkat dari mingguan menjadi harian, lalu 3 kali sehari
- Siklus rilis aplikasi mobile dipersingkat dari 6 minggu menjadi 4 minggu, lalu 2 minggu
- Perbaikan ini terutama didorong oleh tim release engineering
Jika Kapasitas Deployment Tidak Ditingkatkan, Overhead Membesar
- “Jumlah perubahan per deployment” tampak seperti metrik yang tidak elastis dan tidak mudah meningkat; diperlukan upaya besar untuk memperbaikinya
- Jika jumlah perubahan yang dibuat melampaui batas saat ini, tekanan yang muncul bukan untuk menaikkan jumlah perubahan per deployment, melainkan menurunkan total volume perubahan
- Rapat, review, handoff, dan overhead lainnya meningkat
- Seiring waktu, antusiasme dan inisiatif juga bisa menurun
- Peningkatan overhead dapat menciptakan positive feedback loop
- Pekerjaan yang diproses berkurang
- Tekanan meningkat
- Kesalahan bertambah
- Jumlah perubahan per deployment makin berkurang
- Overhead kembali meningkat
- Upaya terisolasi yang hanya mencoba mengurangi overhead dapat menaikkan tekanan dan akhirnya kembali memperbesar overhead
- Untuk meloloskan lebih banyak perubahan, kapasitas deployment di “ujung jauh selang” harus diperlebar
- Cara yang sulit: memperpendek siklus deployment dan menangani kekacauan yang menyertainya
- Cara yang lebih sulit: meningkatkan jumlah perubahan per deployment melalui testing, monitoring, isolasi antar-elemen, dan hubungan sosial yang lebih baik di dalam tim
- Upaya yang hanya berfokus mengurangi rapat bisa berujung pada “rapat untuk membahas cara mengurangi rapat”
- Ini dapat dilihat sebagai contoh Thinkie kausalitas terbalik, yaitu menempatkan ide yang pada awalnya tampak keliru
2 komentar
Saya suka pendapat ini.
Komentar Hacker News
Sayang sekali, tetapi kesimpulan tulisan ini tampaknya agak terbalik. Mengurangi risiko deployment dengan memperbaiki pengujian dan atribut organisasi memang penting, tetapi itu bukan satu-satunya pendekatan yang bekerja.
Penulis mengatakan jumlah perubahan per deployment itu tetap dan sulit ditambah, tetapi menurut saya “Reversie Thinkie” yang dimaksud di sini justru adalah mengurangi jumlah perubahan per deployment. Alasan adanya rapat deployment adalah risiko, dan makin banyak perubahan dalam satu deployment, makin besar kemungkinan bug atau isu operasional ikut masuk. Jika perubahan kecil di-deploy lebih sering, nilai bisa disampaikan lebih cepat dan kegagalan pun menjadi lebih kecil.
Jika ini digabungkan dengan canary deployment dan peluncuran bertahap, deployment tidak lagi menjadi persoalan menyalakan sakelar lalu rusak atau tidak, melainkan dunia tempat gangguan diubah menjadi penurunan kinerja atau dampak yang terbatas. Pendekatan ini juga dibahas dengan baik dalam riset DORA[0], Accelerate[1], The Phoenix Project[2], serta leluhur spiritualnya, The Goal[3].
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
Intinya adalah seberapa banyak waktu dan sumber daya yang diinvestasikan organisasi pada automated testing. Rapat rilis muncul karena tidak ada infrastruktur untuk memverifikasi sebelum dan sesudah deployment, serta tidak ada infrastruktur untuk me-rollback perubahan yang gagal; akibatnya, kurangnya verifikasi otomatis ditambal dengan pemeriksaan manual sementara. Jika organisasi QA kekurangan kemampuan teknis, demi mempertahankan diri mereka akan mendorong prosedur manual.
Lebih buruk lagi, mengikuti rapat semacam ini kadang dikemas sebagai tanda keunggulan dan praktik terbaik. Sebab orang yang dipekerjakan untuk meredakan masalah itu tidak punya insentif untuk menghilangkan masalah tersebut secara mendasar. Jika bug bocor ke operasi, itu menjadi “masalah yang dibuat developer tetapi gagal ditangkap QA karena berbagai alasan”; namun jika ada automated testing, bahkan melewatkannya di tahap PR pun sulit.
Rapat ada bukan karena risiko, melainkan karena di dalam organisasi ada peran-peran yang membutuhkan risiko agar punya alasan keberadaan, tetapi kekurangan teknologi untuk menguranginya. Jika pemeriksaan minimal bahwa perubahan setelah deployment sudah berjalan dan berfungsi bisa diotomatisasi, dan rollback otomatis saat gagal juga tersedia, rapat tidak lagi diperlukan.
Menurut saya, banyak proses seperti ini adalah respons yang masuk akal tetapi non-teknis untuk bertahan sebaik mungkin dalam situasi buruk ketika solusi mendasar belum ada. Namun itu tidak berarti sepenuhnya tidak berbahaya. Di beberapa organisasi, bahkan untuk proyek baru atau proyek menghapus inefisiensi lama, pengambil keputusan terus mendorong proses yang berpusat pada manusia sebagai solusi.
Ini karena kurangnya imajinasi teknis atau terjebak dalam kerangka masalah yang sudah ada, sehingga orang-orang yang memiliki imajinasi semacam itu perlu maju dan mengatakan bahwa, jika memungkinkan, proses manusia harus diminimalkan melalui perubahan teknis. Tidak semua proses manusia bisa dihilangkan dengan teknologi, tetapi kita juga tidak ingin tenaga kita tersebar tipis pada hal-hal yang tidak perlu.
Kita bisa memperkirakan bahwa mengubah lebih dari 2% dari keseluruhan proses dalam suatu periode adalah “terlalu banyak”, dan nilai ini bisa disesuaikan. Ini juga akan berbeda per area, jadi tim kode pemrosesan pembayaran dan tim kode HR seharusnya punya standar berbeda, dan masuk akal untuk merotasi rilis atau tim.
Misalnya, dalam periode ini tim tersebut mengerjakan hal sulit, lalu setelah live kembali diputar ke hal yang lebih mudah. Prinsip yang sama berlaku untuk serangan parit, gerak maju batalion, dan operasi gabungan antar-kecabangan.
Tentu saja ini masalah manajemen, tetapi sebagian besar bisa diotomatisasi, dan input berupa intuisi seperti tim mana yang baru-baru ini melakukan commit ke modul sensitif juga berguna. Terakhir, sudut pandang ini membuat sprint dalam Agile/Scrum terasa aneh. Kita tahu tidak bisa berlari secepat mungkin sepanjang maraton, jadi bagaimana seharusnya sprint dipersiapkan secara bergiliran?
Feature flag bisa digunakan, tetapi itu menciptakan “backlog fitur yang belum diaktifkan”. Pada akhirnya fitur biasanya dikonsumsi manusia, dan manusia membutuhkan pelatihan untuk perubahan.
Jauh sebelum ada yang menulis The Phoenix Project, ia sudah membahas flow, menerjemahkan prinsip Toyota Production System, dan menerapkan fisika pada proses bisnis. Saya juga menyukai The Phoenix Project, tetapi dibandingkan The Goal, buku itu lebih mirip adaptasi murah yang membuat orang-orang IT membaca cerita lini produksi tanpa kabur sambil berkata, “aku PrOgrAmmEr, jadi kerja kreatif tidak bisa dioptimalkan seperti pabrik.”
Jadi The Phoenix Project adalah penerus spiritual The Goal, bukan sebaliknya.
Mencoba menjelaskan konsep “literasi perangkat lunak”. Maksudnya, sebagaimana perusahaan masa kini bisa dijalankan lewat kalimat-kalimat berbahasa Inggris seperti dokumen kebijakan dan email, bisnis juga bisa dijalankan lewat kode.
Dari sini muncul kesimpulan seperti “jika GPU yang bekerja, maka coder adalah manajer baru”, atau bahwa diperlukan perangkat pengujian lintas perusahaan agar dampak perubahan menjadi jelas. Ini juga tampak berkaitan langsung dengan tulisan bagus ini. Jika semua pengambil keputusan tidak melihat kode, bukan Jira atau rencana proyek, sebagai objek kelas satu dalam proses perubahan, berarti para pengambil keputusan itu tidak memiliki literasi perangkat lunak.
Masalah “bagaimana mendiskusikannya dengan eksekutif non-teknis” sering muncul, dan jawabannya adalah: tidak bisa. Eksekutif itu yang harus berubah. Ini adalah tembok generasi besar yang sudah saya anggap sebagai masalah 30 tahun lalu, tetapi dulu saya naif mengira akan hilang begitu para coder bertumbuh. Namun karena coding tidak diperlukan untuk “menjalankan” perusahaan, hambatan ini sulit dilampaui sebelum ketidakmampuan coding menjadi sesuatu yang memalukan, seperti editor surat kabar yang tidak bisa menulis.
Intinya bukan SOP, pengujian, atau rapat, melainkan perlunya perusahaan yang bisa beroperasi dengan sekumpulan konsep baru yang saling memperkuat, seperti sistem sebagai komunikasi.
Namun saya tidak tahu mengapa itu disebut “literasi”. Istilah autopoiesis dari Maturana & Varela terasa lebih dekat ke inti persoalan, dan Autopoietic Systems dari Stafford Beer juga tampaknya bisa memberi landasan intelektual yang baik.
Namun pada titik tertentu, bukankah “bisnis” perangkat lunak murni pada akhirnya tampak seperti SaaS saja?
Organisasi akan secara aktif menghalangi upaya memperbaiki deployment. Mereka mengatakan hal-hal seperti “Jenkins tidak boleh diletakkan dekat lingkungan produksi”, “kita tidak bisa live tanpa QA”, atau “kami butuh waktu ini untuk menjamin kualitas perangkat lunak secara memadai” dengan wajah serius.
Sementara itu bug operasional ada jutaan, dan produk hampir tidak memenuhi kebutuhan pengguna. Pada akhirnya, melawan birokrasi di sebagian besar organisasi pada dasarnya mustahil. Apalagi jika Anda bukan bagian dari 200 lapis manajemen yang menghasilkan rapat-rapat semacam ini.
Rasanya ingin menyisakan hanya sekitar dua orang programmer dan designer, mengeluarkan semua yang lain, lalu membiarkan mereka bertarung sendiri tanpa agile coach, product owner, scrum master, atau product expert. Deployment yang lambat memang masalah, tetapi bukan masalah itu sendiri.
Jika Anda terus saja masuk ke tempat yang tampaknya tidak bisa diubah, berarti saat wawancara Anda perlu menanyakan hal ini lebih dalam. Di perusahaan-perusahaan kecil, banyak juga tempat yang tidak punya birokrasi gila sesuai preferensi saya, dan sekarang saya di perusahaan besar, tetapi jika bergerak secara konsisten dan meyakinkan, banyak hal perlahan bisa bergerak ke arah yang benar.
Kita perlu tahu bahwa pekerjaan butuh waktu, memahami mengapa orang membuatnya seperti itu, lalu menemukan argumen meyakinkan untuk membuatnya lebih baik. Memang ada tempat yang benar-benar buruk, jadi sebaiknya jangan bertahan di tempat seperti itu, tetapi putus asa tidak banyak membantu.
Pasti ada banyak hal yang harus diurai, tetapi bias saya condong ke argumen ini.
Jenkins adalah Wordpress-nya dunia pengembangan perangkat lunak. Ia adalah loop state besar yang menjalankan plugin tanpa pemisahan hak akses. Memberi kredensial admin produksi kepada instance Jenkins bisa sama saja dengan memberi kunci root kepada seseorang di Rumania yang membuat plugin yang belum pernah diaudit. Sangat bisa dipahami jika semua orang tidak menginginkan itu.
“Kita tidak bisa live tanpa QA” juga sama. Jika Anda men-deploy sesuatu yang belum pernah lolos QA ke produksi, lalu untuk apa QA ada? Untuk diperbaiki nanti? Jika tidak diberi kewenangan, QA tidak punya kesempatan untuk bekerja dengan baik maupun merasa bangga atas pekerjaannya.
Sejak hari pertama inisiatif apa pun, Jenkins terhubung ke produksi, sering kali langsung dengan trunk-based development, dan kualitas menjadi tanggung jawab semua developer. Di level individual contributor tidak ada “melawan birokrasi”, tetapi jika partner eksternal dan stakeholder terlibat mendalam, mungkin sesama leadership kadang berdiskusi sengit.
Pendekatan yang hanya menyisakan programmer dan designer terdengar bagus bagi saya, tetapi tidak bisa diskalakan. Setidaknya harus ada satu “owner”, “expert”, atau “manager” produk untuk mengantrekan prioritas stakeholder. Peran ini bisa dijadikan “topi” yang bergantian dipakai developer dan designer, tetapi ada orang tertentu yang luar biasa mahir dalam keterampilan ini.
Saya juga paham bahwa banyak organisasi tidak beroperasi seperti ini. Saat mengubah perusahaan ke arah ini, yang membantu adalah membuat satu tim eksperimen berbasis sukarelawan yang berkomitmen pada praktik-praktik ini, dan melindunginya dengan mandat dari atas tanpa mengarahkannya. Tentu saja, ini di California.
Sedikit terkait, saya pernah bekerja di tempat yang pipeline CI-nya memakan waktu sekitar 25 menit, dan lebih dari 3.000 unit/integration test menghabiskan 18 menit di antaranya.
Setiap kali terjadi masalah di produksi, kami menambahkan lebih banyak test, dan tentu saja saat ada yang berantakan, pemulihan butuh minimal 50 menit. Setelah banyak berpikir, kami memutuskan fokus pada pemulihan, melonggarkan dan menyederhanakan sebagian test sehingga keseluruhannya menjadi di bawah 5 menit, dan memakai canary deployment alih-alih rolling update.
Bagi kami itu benar-benar pengalaman yang menyegarkan, tetapi dalam beberapa hal juga terasa seperti sesuatu yang keliru.
Tentu saja, di dalam kecepatan deployment itu ada berbagai macam faktor yang ikut terseret, tetapi hampir semuanya adalah faktor yang baik.
Sedikit menyimpang, tetapi mengapa CloudFormation selambat ini?
Pernah ada kasus menghapus Lambda di dalam VPC yang terhubung ke EFS; deployment-nya sendiri cukup cepat, tetapi CloudFormation membutuhkan sekitar 20 menit untuk membersihkan dan menyelesaikannya
Setiap kali perubahan state di-deploy sebagai transaksi, prasyarat dan pascakondisi harus diperiksa di setiap langkah. Untuk merilis sekumpulan perubahan yang saling bergantung meski sedikit saja, tiap perubahan mau tidak mau harus di-deploy sebagai langkah berurutan. Setiap langkah melakukan beberapa panggilan jaringan untuk menerapkan perubahan, autentikasi, dan polling status; masing-masing memakan sekitar 50–200 ms dan cepat terakumulasi
Jika men-deploy aplikasi yang sama ke penyedia cloud lain dengan Terraform atau Ansible, hasilnya juga mirip. Jika perubahan yang sama di-deploy secara manual, pekerjaan yang hanya beberapa menit menjadi penderitaan seharian
Masalah terbesar IaC adalah ia terlalu high-level dan melakukan terlalu banyak hal di dalamnya, sehingga ada orang yang tidak tahu perubahan apa yang sebenarnya diterapkan atau apa yang sedang dilakukan. Lalu mereka mengeluh karena memakan waktu lama
Saya pernah mengalaminya sendiri di tempat kerja. Sebelum libur Natal ada perubahan besar dan rasa takutnya tinggi. Organisasi merespons dengan menambah pengujian, yakni memperbanyak regression test dan meningkatkan overhead
Akibatnya, risiko perubahan di dev merusak perubahan di branch saya menjadi lebih besar. Ini bukan risiko konflik merge kode, melainkan risiko dari perspektif sistem adaptif kompleks. Untuk menangani risiko ini, saya membuat rapat, dan saat memaparkan jadwal proyek saya menjelaskan ekspektasi kepada rekan kerja bahwa jika mereka meninggalkan komentar code style di PR, komentar itu akan ditunda ke PR berikutnya dan pada akhirnya diabaikan
Yang dibutuhkan adalah pengujian yang lebih granular dengan isolasi antarkomponen yang lebih baik. Masalahnya, manajemen hanya melihat dari level yang terlalu tinggi, dan memandang rapat bukan sebagai sarana, melainkan sebagai tujuan yang bernilai untuk dicapai dengan sendirinya. Logikanya: makin banyak rapat berarti makin banyak kolaborasi, dan itu bagus. Saya ingin melihat saran tentang memimpin perubahan teknis bersama manajemen nonteknis
Tulisan terkait: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - November 2015, 26 komentar
Dengan microservices, frekuensi deployment juga bisa diskalakan secara horizontal
Dengan aplikasi monolitik yang tersusun dari modul-modul independen, kita juga bisa melakukan deployment sebanyak itu tanpa microservices, sambil menghindari kelemahan besar seperti kompleksitas infrastruktur/CI·CD atau mengubah pemanggilan fungsi dalam aplikasi menjadi masalah komunikasi sistem terdistribusi yang tidak stabil. Kompleksitas insidental yang tidak perlu harus dilawan
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
Lalu muncul masalah baru yang menyenangkan: perencanaan deployment dan sinkronisasi peluncuran fitur
Jika tidak, Anda akan mendapatkan masalah data terdistribusi sekaligus lebih banyak lapisan kompleksitas—dengan kata lain, lebih banyak rapat daripada monolit
Dalam monolit, ada risiko orang tidak berani mengubah apa pun karena takut merusak sesuatu, di tengah kekacauan besar SOLID, DRY, dan omong kosong “clean code” lainnya. Bukan berarti prinsip berorientasi objek itu sendiri secara lahiriah salah, tetapi sering kali terlalu kabur secara ekstrem sehingga tidak ada yang benar-benar menerapkannya dengan tepat
Saya selalu tertawa melihat Uncle Bob setiap kali ada kritik, ia menepisnya dengan “mereka salah memahami prinsipnya”. Kalau begitu banyak orang salah, mungkinkah prinsipnya memang buruk? Microservices juga tidak melindungi dari tata kelola yang buruk; masalahnya hanya muncul dalam bentuk lain. Menurut saya sangat mudah dan umum terjadi ketika banyak microservice dibuat, tetapi tidak ada yang tahu perubahan tertentu berdampak apa pada layanan lain
Pada akhirnya ini masalah manajemen tim, dan berdasarkan pengalaman, itulah bidang yang paling buruk dikuasai industri kita. Mungkin akan membaik ketika generasi baru seperti “Team Topologies” masuk, tetapi bahkan jika benar-benar selesai, itu akan memakan waktu puluhan tahun. Jika organisasi hanya memandang “IT” sebagai pusat biaya dan tidak menyampaikan kebutuhan dengan cara yang bisa dimasukkan ke dalam proses praktik terbaik rekayasa perangkat lunak, sering kali hal itu juga berada di luar kendali departemen digitalisasi
Salah satu alasan saya menyukai Go sebagai bahasa serbaguna adalah karena secara desain ia sederhana, sehingga sering menghasilkan codebase yang mudah diubah. Saya melihat beberapa bank online dan platform manajemen sewa/aset beralih ke Go lalu tumbuh karena akhirnya bisa benar-benar menyampaikan apa yang dibutuhkan bisnis. Sebaliknya, pesaing mereka terjebak dalam codebase Java atau C# yang sulit ditangani; kalau beruntung, mereka merilis fitur penuh bug sekali tiap setengah tahun
Ini bukan masalah Go, Java, atau C# itu sendiri, melainkan karena arsitektur dan desain berorientasi objek gaya lama terlalu mudah dikacaukan. Di tempat kerja saya dulu, ada lebih dari seribu interface C#, tetapi tidak ada interface yang dipakai oleh lebih dari satu kelas. Puluhan ribu interface semuanya berada di folder dan namespace yang sama, dan untuk menemukan yang diperlukan harus berharap pada keberuntungan. Hal seperti itu bisa saja dilakukan di Go atau bahasa apa pun, tetapi kemungkinannya lebih kecil jika Anda tidak berada dalam budaya bahasa OOP clean code lama. Terutama di C#, abstraksi default sudah begitu mengakar dalam budaya sehingga justru lebih sulit untuk tidak melakukannya
Secara pribadi saya punya kasih sayang rahasia terhadap organisasi Python. Mereka selalu mengirimkan dengan cepat dan kodenya mengerikan. Menggemaskan
Secara umum benar, tetapi juga sama tidak relevannya
Singkatnya, yang penting hanyalah kinerja perangkat lunak, dan karenanya kinerja manusia. Manajemen risiko dan penerimaan risiko bisa diukur dengan angka. Dalam perangkat lunak, ini jauh lebih sederhana dibanding profesi lain, karena insinyur perangkat lunak hanya bisa menerima risiko dalam batasan operasional yang diketahui, sementara sisanya semuanya ditunda
Jika ingin menjadi lebih cepat, yang terutama harus dilakukan adalah memaksimalkan frekuensi iterasi manusia. Jika tidak bisa beriterasi karena menunggu izin, berarti terhambat; jika menunggu build atau refresh layar, berarti melambat. Ini juga bisa diukur dengan angka
Jika A bisa beriterasi 100 kali lebih cepat daripada B, akurasi menjadi hal sekunder. Karena B lambat, B harus memaksimalkan akurasi. A memiliki fleksibilitas ekstrem untuk belajar, gagal, dan memperbaiki diri agar menjadi lebih cepat dan lebih akurat
Salah satu cara mengurangi risiko sambil beriterasi lebih cepat adalah otomatisasi pengujian yang cepat. Jika A bisa menjalankan coverage pengujian 90% atau lebih dalam waktu 4 iterasi manusia, otomatisasi pengujian itu masih 25 kali lebih cepat daripada satu iterasi B, dan risiko regresinya 90% atau lebih rendah
Deployment cepat menciptakan war room untuk respons insiden
Yang jauh lebih penting daripada penurunan itu adalah, ketika ada masalah, kecepatan menemukan penyebabnya menjadi jauh lebih tinggi. Perubahan yang di-rollback sangat sedikit, sehingga mengembalikannya juga jauh lebih aman dan mudah. Tidak ada yang ingin membatalkan pekerjaan selama 3 minggu. Itu kacau