Setiap tahun, akhir pekan belanja besar selalu menghasilkan pemandangan yang sama: ada situs yang melewati jam-jam tersibuknya dengan mulus, dan ada yang justru down tepat saat pelanggan sedang berusaha memberikan uang mereka. Akhir pekan kemarin tidak berbeda. Pelajaran site reliability dari lonjakan trafik ini bukan hal yang eksotis, dan berlaku sama relevannya untuk UKM Indonesia yang menjalankan promo Harbolnas maupun untuk peritel global.
Polanya cukup konsisten sampai terasa membosankan. Situs-situs yang bertahan tidak selalu punya server yang lebih besar. Yang mereka punya adalah cara berpikir: asumsikan lonjakan akan lebih besar dari perkiraan, degradasi secara terkendali alih-alih crash total, dan perlakukan hasilnya sebagai bahan belajar, bukan ajang cari kambing hitam. Situs-situs yang gagal biasanya sudah mengambil keputusan bisnis tanpa sadar bahwa mereka sedang mengambilnya.
Berikut tiga pelajaran paling penting, yang disesuaikan untuk tim tanpa anggaran infrastruktur ala Silicon Valley.
Kapasitas Adalah Keputusan Bisnis, Bukan Keputusan Teknis
Saat situs crash karena beban tinggi, engineer yang biasanya disalahkan. Padahal keputusan sesungguhnya sering sudah diambil berbulan-bulan sebelumnya, oleh seseorang yang memilih untuk tidak menambah kapasitas demi menghemat biaya beberapa jam saat puncak trafik. Itu tradeoff bisnis yang sah, tapi harus diambil secara sengaja, dengan mempertimbangkan biaya downtime.
Pertanyaan jujurnya begini: berapa biaya satu jam downtime saat puncak trafik, dan bagaimana perbandingannya dengan biaya kapasitas yang bisa mencegahnya? Bagi peritel yang meraih porsi besar pendapatan bulanannya hanya dalam satu akhir pekan, downtime satu jam bisa jauh lebih mahal dibanding biaya server tambahan selama setahun penuh. Bagi bisnis bermargin tipis dengan trafik yang stabil, menambah kapasitas besar-besaran demi lonjakan setahun sekali mungkin memang tidak sepadan.
Kesalahannya bukan pada keputusan untuk tidak menambah kapasitas. Kesalahannya adalah kapasitas yang kurang tanpa disadari, karena tidak ada yang menghitung biaya lonjakan itu. Latihan yang berguna sebelum sale besar:
- Perkirakan puncak concurrent user sebesar 2x sampai 3x dari perkiraan terbaik Anda, karena forecast biasanya meleset ke bawah.
- Lakukan load test pada level tersebut, bukan pada level rata-rata.
- Hitung biaya kapasitas untuk menangani lonjakan itu, dan hitung juga biaya downtime satu jam.
- Ambil tradeoff itu secara eksplisit, dalam rapat, dengan angka yang tertulis.
Kebanyakan UKM langsung lompat ke berharap semua akan baik-baik saja. Berharap bukan rencana kapasitas.
Degradasi Terkendali Selalu Lebih Baik daripada Downtime
Ini pelajaran site reliability yang paling penting: situs yang melambat atau mematikan fitur non-esensial akan bertahan, situs yang crash kehilangan seluruh harinya. Pemenang akhir pekan ini adalah mereka yang mendegradasi sistemnya secara sengaja.
Degradasi terkendali berarti memutuskan sejak awal apa yang akan dikorbankan saat sistem sedang tertekan, agar transaksi inti tetap berjalan:
| Saat beban tinggi, matikan | Harus tetap berfungsi apa pun yang terjadi |
|---|---|
| Rekomendasi personalisasi | Tambah ke keranjang |
| Tampilan stok real-time di halaman listing | Checkout dan pembayaran |
| Dashboard analitik real-time | Konfirmasi pesanan |
| Animasi dan gambar berat | Jalur untuk menyerahkan uang ke Anda |
Langkah klasiknya adalah antrean. Saat terlalu banyak pengguna datang bersamaan, mereka dimasukkan ke ruang tunggu yang tertata rapi, alih-alih dibiarkan masuk semua dan membuat sistem crash untuk semua orang. Pelanggan yang menunggu sembilan puluh detik di antrean lalu berhasil membeli adalah kemenangan. Pelanggan yang menemui halaman error kosong akan pergi, kemungkinan besar ke kompetitor, dan mungkin selamanya.
Untuk operasi yang lebih kecil, degradasi bisa sesederhana halaman fallback statis untuk browsing sementara sistem dinamis hanya menangani checkout, atau mematikan bagian situs yang membebani database saat trafik melonjak. Sisi teknisnya tidak perlu rumit. Yang harus dilakukan sejak awal adalah keputusan untuk melindungi transaksi inti. Banyak dari kegagalan ini sebenarnya bug biasa yang hanya muncul di bawah beban tinggi, dan itulah kenapa pengujian di luar skenario demo sangat penting, tema yang saya bahas lebih dalam di kenapa bug tetap sampai ke pelanggan Anda.
Postmortem Lebih Berguna daripada Mencari Kambing Hitam
Saat situs akhirnya down, dan cepat atau lambat pasti akan terjadi, yang dilakukan tim setelahnya menentukan apakah itu akan terulang. Blameless postmortem adalah praktik yang membedakan tim yang terus membaik dari tim yang mengulangi kesalahan yang sama.
Blameless postmortem bertanya "apa dalam sistem kita yang memungkinkan ini terjadi", bukan "ini salah siapa." Perbedaannya penting karena budaya saling menyalahkan membuat orang menyembunyikan informasi, dan informasi yang disembunyikan berarti kegagalan yang sama akan kembali terjadi. Ketika orang tahu mereka tidak akan dihukum karena mengungkap apa yang salah, Anda mendapatkan kronologi jujur yang dibutuhkan untuk benar-benar memperbaiki akar masalahnya.
Postmortem yang praktis untuk tim kecil cukup satu halaman:
- Apa yang terjadi, lengkap dengan kronologi. Kapan mulai, kapan disadari, kapan diperbaiki.
- Dampak. Berapa banyak pelanggan terdampak, berapa kerugian pendapatan, selama berapa lama.
- Akar masalah. Bukan sekadar "server-nya crash," tapi kenapa server itu crash dan kenapa tidak ada yang menangkapnya lebih dulu.
- Apa yang akan diubah. Konkret, ada penanggung jawabnya, dengan tenggat waktu. Bukan "akan lebih hati-hati."
Godaan setelah lonjakan trafik yang berat adalah langsung move on tanpa menoleh ke belakang, apalagi di tim kecil yang sudah kelelahan. Itulah cara termudah membeli kegagalan yang sama persis tahun depan. Satu jam untuk postmortem yang jujur adalah investasi reliabilitas termurah yang pernah bisa Anda lakukan.
Reliabilitas Adalah Kebiasaan, Bukan Barang yang Dibeli
Tidak satu pun dari pelajaran ini membutuhkan anggaran level enterprise. Perencanaan kapasitas hanyalah hitung-hitungan. Degradasi terkendali adalah sekumpulan keputusan tentang apa yang harus dilindungi. Postmortem adalah rapat yang dijalankan tanpa saling menyalahkan. Kesamaan dari ketiganya: semua terjadi sebelum dan sesudah lonjakan trafik, bukan pada saat itu terjadi, ketika sudah terlambat untuk melakukan apa pun selain menonton.
Bisnis yang melewati akhir pekan tersibuknya dengan lancar jarang sekali yang punya infrastruktur paling mewah. Mereka adalah yang memperlakukan reliabilitas sebagai disiplin yang terus-menerus: merencanakan kapasitas sebagai keputusan bisnis, membangun degradasi terkendali, dan belajar dari setiap kegagalan alih-alih menyembunyikannya. Reliabilitas adalah praktik yang Anda tanamkan dalam cara Anda bekerja, terkait erat dengan argumen yang lebih luas bahwa bisnis Anda butuh strategi teknologi yang sesungguhnya, bukan sekadar website yang terlihat baik-baik saja di hari Selasa yang sepi.
Yang Bisa Langsung Dipraktikkan
Sebelum sale besar berikutnya, lakukan tiga hal. Hitung biaya lonjakan trafik Anda dan tentukan kapasitas secara sengaja, bukan berdasarkan harapan. Tentukan sejak awal apa yang akan dikorbankan situs Anda saat beban tinggi, agar jalur checkout tetap selamat. Dan komitmenlah pada postmortem satu halaman yang blameless jika ada yang gagal. Downtime saat puncak trafik adalah keputusan bisnis, baik Anda mengambilnya secara sadar maupun tidak. Ambil secara sadar.