Yang ingin kami lakukan sebenarnya sangat sederhana.
Menulis artikel baru, lalu menerbitkannya secepat mungkin.
Hanya itu.
Tetapi tanpa terasa, sebelum artikel terbit, rapat sudah dimulai.
Siapa yang menangani kali ini? Workers atau Actions? Anggarannya masih ada? Apakah kunci yang lama masih berlaku? Tanda ini milik siapa? Sudah berapa kali dicoba ulang?
Artikelnya menunggu.
Sistemnya juga menunggu.
Semua bagian merasa, "Ini bukan tugas saya."
Di kantor, kita bisa memanggil semua orang ke ruang rapat. Sistem terdistribusi hanya berhenti diam-diam.
Inilah neraka Live Schedule.
1. Kami ingin langsung terbit, malah jadi mengadakan pemilihan penanggung jawab
Saat kita ingin membuat proses penerbitan lebih kuat, wajar kalau kita menambah pengaman.
Kalau Workers berhenti, pindah ke Actions. Kalau anggaran Actions menipis, pindah ke Workers. Pasang kunci supaya pekerjaan yang sama tidak dikerjakan dua kali. Pasang tanda supaya dua proses tidak menyentuh pekerjaan yang sama. Hitung berapa kali dicoba ulang. Tambahkan pengawas.
Kalau dilihat satu per satu, semuanya masuk akal.
Masalah muncul saat semuanya dirangkai berurutan.
Sebelum menjawab "Apakah artikel ini bisa terbit?", kita harus menjawab pertanyaan yang jauh lebih besar: "Siapa yang boleh menerbitkannya?"
Yang paling berbahaya adalah saat hanya label penanggung jawab yang tersisa.
Proses di sisi Workers sudah berhenti. Tetapi catatannya masih bertuliskan "ditangani Workers". Saat Actions bangun, ia membaca "ditangani Workers" lalu melewati tugas itu.
Tidak ada yang rusak. Tidak ada yang bekerja.
Ini versi sistem terdistribusi dari "orang yang bertanggung jawab sedang tidak di tempat".
2. Masalahnya koordinasi, bukan kemampuan menjalankan
Pada satu kali jalan, Actions masih punya kapasitas dan anggaran.
Tetapi pekerjaan utamanya tidak berjalan.
Alasannya sederhana: pengecekan memutuskan bahwa "tugas itu milik Workers".
Di sinilah poin pentingnya.
Bukan CPU yang kurang. Bukan semua API yang mati. Bukan Actions yang tidak bisa mulai.
Masalahnya ada di koordinasi, bukan di pelaksanaan.
Yang menghalangi adalah urusan menentukan siapa yang mengerjakan, bukan tenaga untuk mengerjakannya.
Kalau begini, memperbaiki bug satu per satu tidak akan selesai.
Perbaiki jumlah data yang diambil. Perbaiki kegagalan menyimpan ke main. Perbaiki percobaan ulang. Perbaiki pergantian penanggung jawab. Lalu tanda lama tertinggal. Lalu kunci lama tertinggal. Pengawas menyadari masalahnya, tetapi tidak punya hak untuk menerbitkan.
Kelihatannya seperti main pukul tikus, tetapi semua tikus keluar dari lubang yang sama.
Lapisan pengatur ini terlalu pintar.
3. Schedule itu jam, bukan daftar tugas
Schedule di GitHub Actions memang praktis. Namun dokumentasi resminya menyebut bahwa jalannya bisa terlambat saat beban tinggi, dan bila beban cukup tinggi, sebagian pekerjaan dalam antrean bisa hilang.
Jadi schedule cocok untuk "tolong bangunkan sekitar jam segini".
Tetapi tidak cocok untuk "naskah ini harus selalu ada yang mengambil dan menyimpannya sampai berhasil".
Jam berbunyi.
Jam tidak memegang naskahmu.
Antrean pesan, sebaliknya, menyimpan pekerjaannya sendiri. Ia juga bisa menangani kegagalan: coba ulang, tunda, dan "antrean pesan gagal" (dead-letter queue), yaitu tempat terpisah untuk pekerjaan yang terus gagal.
Ini bukan berarti kita harus menambah layanan baru.
Maksudnya, bagi tugasnya dengan jelas:
- schedule = alarm yang berbunyi secara berkala
- daftar tertunda = catatan resmi pekerjaan yang belum selesai
- pelaksana = yang benar-benar mengerjakan
- kunci singkat = kunci supaya dua pihak tidak bekerja bersamaan
- coba ulang dan antrean gagal = tujuan pekerjaan yang gagal
Kalau jam juga merangkap bagian SDM, gudang, dan tempat barang hilang, jam itu akan kewalahan.
4. Catat "apa yang belum selesai", bukan "siapa pemiliknya"
Dalam pembagian tugas yang rumit, pusat catatan mudah bergeser ke "penanggung jawab".
Padahal yang benar-benar perlu diketahui dalam proses penerbitan adalah:
Artikel ini sudah terbit atau belum.
Hampir hanya itu.
Karena itu catatan resminya cukup daftar tertunda.
Naskah baru masuk: masuk daftar tertunda. Saat mulai terbit: pasang kunci singkat. Kalau berhasil: tandai terbit. Kalau gagal: kembalikan ke daftar tertunda. Kalau gagal sebanyak batas yang ditentukan: pindahkan ke antrean gagal dan kirim peringatan.
"Tugas Workers" atau "tugas Actions" hanyalah informasi tambahan. Jangan sampai jadi hak veto permanen.
Walau tertulis "tugas Workers", kalau tidak ada kemajuan selama waktu tertentu, pelaksana lain boleh mengambil alih.
Dengan begitu, label penanggung jawab yang sudah mati tidak bisa menyandera pekerjaan.
5. Jalur utama dimulai dari kejadian; schedule hanya memungut yang terlewat
Kalau ingin langsung terbit, menunggu jadwal berikutnya justru bertentangan dengan tujuan.
Bangunkan pelaksana begitu naskah baru tiba.
Jadikan itu jalur utama.
Lalu schedule memungut item tertunda lama yang masih ada setelah beberapa menit sampai puluhan menit.
Singkatnya:
Kejadian adalah jalur utama. Schedule adalah cadangan.
Dengan begitu, hari biasa berjalan cepat.
Kalau satu pemberitahuan terlewat, schedule memungutnya nanti.
Kalau schedule dijadikan jalur utama, setiap keterlambatan langsung menunda penerbitan. Ditambah pengecekan penanggung jawab, muncul kejadian "sudah bangun tapi tidak melakukan apa-apa".
Jamnya berbunyi.
Pemeriksaannya lolos.
Lalu bilang, "Hari ini bukan tugas saya," dan pulang.
Lalu untuk apa datang?
6. Cadangan bukan "ganti penanggung jawab", tetapi "ambil pekerjaan lama yang belum selesai"
Jebakan yang umum pada desain cadangan adalah memindahkan tugas dari A ke B secara resmi.
Pemindahan butuh pembaruan catatan.
Kalau pembaruan itu gagal, pemindahannya sendiri jadi masalah.
Bisa dibuat jauh lebih sederhana.
Biasanya Workers yang mengerjakan. Kalau berhasil, selesai. Kalau gagal, item tetap ada di daftar tertunda.
Pelaksana cadangan seperti Actions memeriksa secara berkala. Jika
- ada item tertunda
- usianya lebih tua dari batas waktu
- tidak ada kunci yang masih berlaku
- ia sendiri bisa menjalankannya
maka ia mengambilnya.
Tidak perlu "surat serah terima" dari Workers.
Yang perlu dilihat adalah fakta bahwa pekerjaan belum selesai.
Dengan cara ini, ada tidaknya hasil lebih penting daripada rapinya tabel penanggung jawab.
Untuk sistem penerbitan artikel, itulah yang paling wajar.
7. Live Schedule tidak perlu dibuang, tetapi jangan jadikan alat bantu hidup
Live Schedule sendiri tidak salah.
Ia sangat kuat saat ada orang yang mengawasi:
Mengubah urutan prioritas. Menyelidiki masalah. Menyusun usulan perbaikan. Mempercepat perbaikan. Memasukkan rencana baru.
Masalahnya, begitu ia berhenti, pabrik artikel ikut berhenti.
Live harus menjadi pemercepat, bukan titik tunggal yang jika rusak semuanya berhenti.
Walau tanpa Live,
naskah baru → daftar tertunda → pelaksana → pemeriksaan → terbit
harus tetap berjalan sendiri.
Kalau ada Live, jadi lebih cepat.
Kalau tidak ada, tidak mati.
Sama seperti kita tidak boleh menyambungkan jantung manusia ke "apakah ada yang membalas di Slack".
8. Kembalikan tujuan dari "sistem pintar selesai" ke "masuk satu, keluar satu"
Sistem seperti ini bisa terus diperbaiki tanpa akhir.
Pembagian tugas yang adil. Memaksimalkan paket gratis. Pencegahan duplikat. Perkiraan anggaran. Prioritas. Pemantauan. Pemulihan otomatis. Analisis.
Semuanya seru.
Dan kalau semuanya dikerjakan, artikel tidak terbit.
Karena itu tujuan awal boleh lebih kasar.
Masukkan satu naskah baru, dan satu artikel terbit tanpa tindakan khusus.
Kalau gagal, tetap di daftar tertunda. Pelaksana lain mengambilnya. Hanya yang gagal berkali-kali yang diserahkan ke manusia.
Setelah satu jalur sederhana ini stabil, optimalisasi bisa dikembalikan.
Kami hanya ingin menerbitkan artikel baru dengan cepat, tetapi tanpa terasa malah membuat sesuatu yang mirip sistem konsensus terdistribusi buatan sendiri.
Ada hari seperti itu.
Tetapi ada jalan keluarnya.
Potong kerumitan.
Nilai sistem penerbitan bukan pada indahnya pemilihan penanggung jawab.
Nilainya adalah artikel sampai ke publik.
Kesimpulan
Inti neraka Live Schedule bukan pada schedule itu sendiri.
Melainkan karena status "siapa penanggung jawabnya" dibuat lebih kuat daripada status "pekerjaan apa yang belum selesai".
Kalau desainnya dikembalikan, cukup seperti ini:
- Jadikan daftar tertunda sebagai catatan resmi pekerjaan yang belum selesai
- Mulai pekerjaan segera saat ada kejadian
- Buat kunci singkat
- Biarkan pelaksana cadangan mengambil item tertunda yang sudah lama
- Pakai schedule sebagai cadangan
- Pisahkan yang gagal sebanyak batas ke antrean gagal
- Perlakukan Live sebagai pemercepat opsional
Pabrik yang tidak berhenti lebih baik daripada pabrik yang pintar.
Mulailah dari situ.
- GitHub Docs: Events that trigger workflows — schedule https://docs.github.com/actions/reference/workflows-and-actions/events-that-trigger-workflows
- Cloudflare Workers Docs: Cron Triggers https://developers.cloudflare.com/workers/configuration/cron-triggers/
- Cloudflare Queues Docs: Overview https://developers.cloudflare.com/queues/
- Cloudflare Queues Docs: Dead Letter Queues https://developers.cloudflare.com/queues/configuration/dead-letter-queues/
