Pada 24 September 2026, Jepang melakukan pembaruan besar-besaran pada sistem pajak nasionalnya. Tak lama setelah itu, loket kantor pajak jadi butuh "waktu cukup lama" untuk menerima pembayaran tunai dan menerbitkan surat keterangan pembayaran pajak, sementara layanan lapor pajak online e-Tax juga mengalami beberapa gangguan dan pemeliharaan darurat. Sistem raksasa yang terintegrasi jadi tidak stabil sesaat setelah peralihan itu hal yang mudah dimengerti, apalagi oleh orang yang pernah berurusan dengan sistem terdistribusi atau otomatisasi kerja. Tapi "paham kalau sistem bisa rusak" dan "jalan keluar saat rusak sudah memadai" adalah dua hal yang berbeda.
Bayangkan kamu sedang buru-buru mengurus sesuatu, lalu petugas loket bilang: "Sistem kami lagi bermasalah secara keseluruhan dan belum tahu kapan pulih. Kalau mendesak, silakan datang langsung, kami layani."
Reaksi biasanya: "Oh, berarti tinggal datang saja."
Tapi coba pikir sedikit lebih jauh, dan pemandangannya jadi tidak enak.
Orang yang urusannya tidak bisa beres lewat online atau jalur biasa akan mengalir ke loket. Di sisi petugas, sistem tidak stabil, jadi tiap berkas butuh waktu lebih lama. Yang datang bertambah, kemampuan melayani malah turun.
"Datang saja, kami layani" tidak sama dengan "datang, langsung beres dalam sekejap".
Jadi kalau tenggatmu masih longgar, memilih menunggu adalah keputusan yang cukup masuk akal.
Dan dalam hati, rasanya ingin teriak:
"Terima saja pakai kertas! Serius."
Tapi kertas bukan database cadangan ajaib.
1. Apa yang terjadi pada September 2026
Direktorat Jenderal Pajak Nasional Jepang (NTA) memperbarui sistem pajaknya pada 24 September 2026. Untuk sistem generasi baru bernama KSK2, NTA sudah lama menyampaikan tiga konsep pengembangan:
- Beralih dari pengurusan berbasis dokumen kertas ke pengurusan berbasis data
- Menyatukan database dan aplikasi yang tadinya terpisah per jenis pajak
- Mengganti komputer mainframe besar yang memakai OS khusus dengan sistem terbuka yang memakai OS umum
Jadi ini bukan sekadar ganti tampilan layar. Cara menyimpan data, batas antaraplikasi, sampai fondasi infrastrukturnya, semuanya diubah sekaligus dalam pembaruan skala besar.
Pada hari pembaruan itu, 24 September, NTA mengumumkan "keterlambatan berbagai proses di loket kantor pajak". Disebutkan bahwa penerimaan uang tunai, penerbitan surat keterangan pembayaran pajak, dan lainnya memerlukan waktu cukup lama, dan bahkan kalau diajukan lewat e-Tax pun surat keterangan tidak bisa langsung terbit. Pembaruan itu sendiri sudah selesai, tapi ada masalah pada pengoperasian sistem yang dibutuhkan untuk layanan loket.
Pada pekan peralihan yang sama, juga terjadi masalah login lewat Mynaportal (portal layanan publik Jepang yang terhubung dengan kartu nomor pribadi), kesalahan tampilan konfirmasi pembayaran lewat internet banking, penghentian sebagian fitur e-Tax, dan pemeliharaan darurat untuk menangani gangguan. Penghentian sebagian fitur e-Tax diumumkan sudah teratasi paling lambat 27 September.
Di sisi lain, pengumuman keterlambatan di loket masih terpasang pada 28 September sebagai informasi darurat di situs NTA. Penyebab utamanya secara rinci belum diumumkan saat itu.
Satu hal lagi yang lebih penting: jangan campuradukkan pemeliharaan terjadwal dengan gangguan. Dalam pembaruan kali ini, sejak awal sudah dijadwalkan penghentian panjang dari pukul 00.00 tanggal 19 September sampai pukul 08.30 tanggal 24 September, serta penghentian seharian penuh pada 26 September. Di atas itu, menumpuklah masalah pasca-peralihan dan pemeliharaan darurat.
Wajar kalau rasanya "ini kok kayak mati terus", tapi di dalamnya bercampur penghentian yang direncanakan dan penghentian akibat gangguan.
2. Sistem serius yang mengurus uang pun bisa rusak. Justru karena itu, kadang sengaja dihentikan
"Kalau sistem yang mengurus pajak dan uang, bukankah seharusnya dibuat supaya tidak boleh mati sama sekali?"
Secara naluri, memang begitu.
Tapi pada sistem penting, selain ketersediaan ada juga konsistensi.
Misalnya, hal paling menakutkan dalam proses pembayaran bukan sekadar layar yang tak terbuka selama lima menit.
- Sudah bayar tapi tercatat belum bayar
- Satu proses tercatat dua kali
- Surat keterangan diterbitkan dengan data lama
- Hanya satu sistem yang diperbarui, yang satunya tertinggal
- Setelah pemulihan, proses dijalankan ulang dan proses yang sama berjalan sekali lagi
Dalam kondisi seperti itu, "pokoknya tetap dijalankan" bisa lebih berbahaya daripada berhenti.
Materi SRE (rekayasa keandalan situs) dari Google juga menjelaskan bahwa saat terjadi gangguan besar, lebih baik menghentikan meluasnya kerusakan dulu sebelum menyelidiki akar masalah, dan kalau ada kemungkinan data rusak, membekukan sistem bisa lebih baik.
Bukan berhenti padahal urusannya uang.
Justru karena urusannya uang, kadang perlu keputusan berhenti daripada terus berjalan tanpa bisa menjamin keadaan yang benar.
Kalau "sudah coba restart belum?" bisa menyelesaikan semuanya, para operator sistem inti di seluruh negeri sudah lama pulang lebih awal.
3. Semua uji unit lolos pun, begitu diintegrasikan tetap bisa meledak
Yang menyebalkan dari sistem terintegrasi adalah tiap komponen bisa normal, tapi keseluruhannya tetap rusak.
Sistem A normal.
Sistem B juga normal.
Database normal.
Autentikasi juga normal.
Tapi kalau format yang dikirim dari A ke B berbeda satu karakter saja, semuanya berhenti.
Kalau data yang dipindahkan dari sistem lama ke sistem baru punya nilai yang tak lazim, berhenti.
Kalau saat percobaan ulang hanya responsnya yang hilang, jadi tidak jelas apakah prosesnya sudah dijalankan atau belum.
Cache lama, formulir lama, koneksi ke lembaga luar, hak akses, waktu, pemrosesan batch, pengodean karakter, aksara lama, pengiriman ulang saat gangguan. Makin banyak batas, makin banyak kombinasi yang tidak kelihatan kalau diuji sendiri-sendiri.
Bahkan otomatisasi kecil buatan pribadi pun mudah celaka karena keadaan lama, eksekusi ganda, data yang terlewat, perbedaan API eksternal, dan efek samping percobaan ulang.
Sekarang bayangkan semua itu terjadi pada sistem inti yang mencakup kantor pajak seluruh negeri, banyak jenis pajak, penerimaan, pengembalian, surat keterangan, e-Tax, hingga lembaga luar.
Orang yang tahu betapa susahnya integrasi justru akan berpikir, "ya, sesaat setelah peralihan pasti ada yang muncul".
Tapi itu bukan tameng.
Yang perlu dinilai bukan hanya apakah tidak ada satu pun gangguan, tetapi seberapa aman layanan bisa diturunkan secara bertahap saat gangguan terjadi.
4. Kenapa jadinya "belum ada perkiraan pemulihan"
Bagi pengguna, ini salah satu kalimat yang paling bikin kesal:
"Waktu pemulihan belum ditentukan."
Tapi menjanjikan jam sembarangan saat penyebabnya belum diketahui bisa lebih berbahaya.
Memulihkan sistem penting bukan sekadar menyalakan server lagi lalu selesai.
Pertama, ruang lingkup gangguan dipetakan.
Lalu dicek apakah ada data yang baru tertulis setengah jalan.
Dicek apakah menjalankan ulang tidak akan menimbulkan pemrosesan ganda.
Dicek apakah status tidak berselisih dengan pihak luar yang terhubung.
Kalau perlu, dipertimbangkan kembali ke keadaan sebelumnya atau memakai jalur alternatif.
Setelah pulih, proses yang menumpuk selama berhenti dijalankan berurutan lalu hasilnya dicocokkan.
Yang paling merepotkan kalau bercampur keadaan seperti "di sisi pengirim tampak berhasil, tapi di sisi penerima belum terkonfirmasi".
Dalam tulisan tentang desain sistem terdistribusi yang diterbitkan Amazon pun dijelaskan bahwa agar percobaan ulang aman, idempotensi itu penting, yakni rancangan yang membuat permintaan yang sama, kalau dikirim ulang, tidak menggandakan efeknya.
Tidak bisa menyebut waktu pemulihan bukan bukti bahwa petugasnya tidak mengerjakan apa-apa.
Kalau belum jelas sejauh mana yang rusak, sejauh mana bisa dikembalikan, dan dari mana harus melanjutkan agar tidak terjadi pemrosesan ganda, membuat perkiraan yang tepat memang sulit.
5. "Kalau mendesak, datang ke loket" itu cukup menakutkan kalau dilihat sebagai antrean
Di sinilah loket muncul.
Walau sistem sedang bermasalah, kadang tetap dikatakan "kalau datang langsung, kami layani".
Ini jalan keluar yang patut disyukuri.
Tapi dari sudut waktu tunggu, terkumpul kondisi yang cukup berbahaya.
Mari sederhanakan keadaan normal.
Sebut jumlah orang yang datang ke loket sebagai λ, dan jumlah yang bisa diselesaikan petugas sebagai μ.
Saat terjadi gangguan, dua hal bisa terjadi bersamaan.
Pertama, orang yang biasanya cukup lewat online atau proses internal ikut datang ke loket, sehingga λ naik.
Kedua, petugas jadi sulit memakai sistem, pengecekan dan input manual per berkas bertambah, sehingga μ turun.
Permintaan naik, kapasitas melayani turun.
Bagi antrean, ini kombinasi terburuk.
Dan petugas kantor pajak tidak otomatis bertambah banyak begitu gangguan terjadi.
Materi SRE Google juga menyebut bahwa sistem yang mendekati kelebihan beban tidak sekadar sedikit melambat, tetapi bisa memburuk secara nonlinier karena waktu tunggu yang bertambah dan gangguan beruntun. Karena itu kontrol beban dan respons layanan terbatas itu penting.
"Datang ke loket pasti dilayani" tidak berarti "loketnya sepi".
Kalau tenggatmu longgar, tidak menyerbu di hari puncak gangguan dan menunggu pemulihan adalah keputusan yang cukup masuk akal kalau menghitung biaya waktu.
Sebaliknya, kalau ada tenggat hukum atau keadaan mendesak, jangan dibiarkan berdasarkan penilaian sendiri. Cek pengumuman resmi NTA atau kantor pajak pada saat itu untuk mengetahui cara alternatifnya.
6. "Pakai kertas saja" separuh benar. Kertas bisa jadi jalan keluar untuk penerimaan, tapi bukan database cadangan
Melihat gangguan ini, lama-lama muncul pikiran:
"Terima saja pakai kertas, kan bisa."
Gagasan ini tidak sepenuhnya salah.
Panduan perencanaan kelangsungan sistem informasi dari NIST (lembaga standar Amerika Serikat) juga menyebut, sebagai cara alternatif saat gangguan, menjalankan sebagian atau seluruh proses kerja secara manual dalam jangka pendek.
Jadi pemrosesan manual memang salah satu langkah kelangsungan yang sah.
Namun tidak berarti "tulis di kertas, selesai semua".
Yang bisa dilakukan dengan kertas, misalnya:
- Mencatat fakta bahwa permohonan atau konsultasi sudah diterima
- Memastikan tanggal dan jam penerimaan
- Menyimpan dokumen yang diperlukan
- Menyusun urutan pemrosesan setelah pemulihan
- Memberikan nomor pertanyaan atau bukti terima
Sebaliknya, pencocokan data pusat, pengecekan status pembayaran, penelusuran catatan lama, penerbitan surat keterangan yang akurat, dan koneksi dengan lembaga luar bisa jadi tidak tuntas tanpa sistem inti.
Karena itu yang ideal bukan "kembalikan semuanya ke kertas".
Yang ideal adalah "walau sistem inti mati, penerimaan tidak ikut mati".
Kertas bukan database cadangan.
Tapi lembar bukti terima dari kertas bisa menjadi pintu darurat.
7. Yang benar-benar dibutuhkan adalah "operasi terbatas" yang tidak berhenti total
Sistem yang tahan gangguan belum tentu mempertahankan 100% fungsi normalnya.
Sebaliknya, ia mempertahankan fungsi yang penting saja dan turun ke mode sederhana.
Google SRE menyebut ini penurunan fungsi bertahap, yang dikenal sebagai graceful degradation. NIST juga menyebut fasilitas alternatif, lokasi alternatif, dan pemrosesan manual sebagai pilihan dalam rencana kelangsungan.
Kalau diterapkan pada urusan pajak, gambaran idealnya seperti ini:
- Jangan hentikan penerimaan. Informasi permohonan minimal tetap bisa diterima, secara offline atau lewat kertas.
- Terbitkan nomor penerimaan. Hilangkan kondisi "tidak tahu apakah sudah diterima".
- Masukkan ke antrean pemrosesan lanjutan. Bisa diproses ulang berurutan setelah pemulihan.
- Cegah pemrosesan ganda. Punya pengenal sehingga permohonan yang sama, walau dimasukkan lagi, dihitung satu kali.
- Bedakan tingkat urgensi. Dahulukan yang tenggatnya dekat atau berdampak besar pada kehidupan.
- Tunjukkan status kepada pengguna. Umumkan terpisah apa yang berhenti, apa yang bisa dipakai, dan apa yang sudah pulih.
- Cocokkan setelah pulih. Bandingkan penerimaan kertas dan offline dengan data produksi untuk menemukan yang terlewat dan yang ganda.
Yang penting bukan ilusi bahwa "meski ada gangguan, semuanya tetap jalan seperti biasa".
Yang penting adalah merancang cara rusaknya.
8. Lalu, seberapa sering e-Tax bermasalah?
Kalau melihat pengumuman resmi e-Tax tahun 2026, terlihat beberapa pemberitahuan gangguan sepanjang tahun: Januari, keterlambatan pemberitahuan pembayaran selesai; Februari, gangguan koneksi dengan Mynaportal dan sulit login; Maret, sulit login; Juli, gangguan lewat Mynaportal; Agustus, pembayaran langsung dan fitur lain tidak bisa dipakai; dan September, beberapa gangguan sesaat setelah pembaruan.
Tapi di sini tidak boleh asal menghitung.
Semua itu bukan gangguan yang sama.
Ada masalah di e-Tax sendiri, ada juga di koneksi Mynaportal, pembayaran, tampilan, dan layanan pihak luar. Selain itu, pemeliharaan terjadwal bukan gangguan.
Maka dari daftar resmi, yang bisa dikatakan hanyalah bahwa "gangguan sebagian dan gangguan koneksi pendukung diumumkan beberapa kali setahun", bukan bahwa "seluruh sistem pajak sering mati total di seluruh negeri".
Kasus September 2026 menonjol terutama karena di pekan peralihan pembaruan raksasa, penghentian terencana yang panjang dan beberapa gangguan pasca-peralihan menumpuk jadi satu.
9. Setelah tahu neraka integrasi, cara marah pun sedikit berubah
Orang yang pernah membuat sistem otomatisasi kecil akan melihat gangguan sistem raksasa dengan cara yang agak berbeda.
Dulu reaksinya:
"Kok bisa sih benda seperti ini mati?"
Lalu selesai.
Begitu pernah menghubungkan beberapa layanan, punya antrean, memasang percobaan ulang, menyimpan status, dan terhubung ke API eksternal, muncul juga kesan:
"Wah, peralihan sistem terintegrasi. Ini neraka."
Satu-satu jalan, tapi keseluruhannya rusak.
Diperbaiki, batas lain yang rusak.
Keadaan lama tertinggal.
Dicoba ulang, jadi ganda.
Dilihat lognya, ternyata informasi kemarin.
Dengan merasakan versi mininya saja, kita lebih mudah membayangkan sulitnya sistem inti yang raksasa.
Namun memahami dan menilai itu berbeda.
Jangan berhenti di "ini sulit, jadi wajar", tapi lihat hal-hal berikut:
- Sejauh mana uji beban dan uji migrasi dilakukan sebelum peralihan
- Sejauh mana operasi terbatas bisa dijalankan saat gangguan
- Sejauh mana penerimaan manual berfungsi
- Apakah pengumuman status cukup bagi pengguna
- Apakah penyebab dan langkah pencegahan akan diumumkan setelah pulih
- Apakah pada peralihan berikutnya jenis kecelakaan yang sama bisa dicegah
Karena rumit, kecelakaan bisa terjadi.
Justru karena rumit, rancangan dan pembelajaran setelah kecelakaan itu penting.
10. Kesimpulan: bukan "semua pakai kertas", melainkan "meski dengan kertas, jangan biarkan pintu masuknya mati"
Kalau sistem inti kantor pajak berhenti, dari sisi pengguna rasanya cukup tidak adil.
Tempat yang mengurus uang dan prosedur hukum, tapi berhenti.
Waktu pulihnya pun tak jelas.
Katanya bisa datang ke loket, tapi bagaimanapun dipikirkan pasti ramai.
Maka muncul keinginan untuk bilang, "pakai kertas saja sekalian".
Di dalam perasaan itu ada tuntutan desain yang cukup penting.
Menggantikan seluruh sistem pajak hanya dengan kertas tidak realistis.
Tapi tidak perlu juga penerimaan, pencatatan, penentuan prioritas, sampai antrean pemrosesan lanjutan ikut mati begitu sistem jatuh.
Yang dibutuhkan sistem raksasa bukan mitos "tidak akan pernah rusak".
Melainkan tetap menyisakan pekerjaan minimum walau rusak.
Bisa dikembalikan tanpa pemrosesan ganda.
Memberi tahu pengguna apa yang bisa dan tidak bisa dipakai.
Dan setelah pulih, bisa mengambil kembali pekerjaan yang tertahan dengan aman.
Jadi tuntutan akhirnya adalah ini:
Bukan "semuanya pakai kertas".
Tapi "setidaknya penerimaan harus bisa dihidupkan dengan kertas. Serius."
Referensi
- NTA, "Tentang keterlambatan berbagai proses di loket kantor pajak", 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, "Tentang pembaruan sistem pajak nasional"
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - Laporan NTA 2025, "Sistem generasi baru (KSK2)"
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, "Tentang waktu pemeliharaan terkait pembaruan sistem pajak nasional"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, "Daftar pengumuman"
https://www.e-tax.nta.go.jp/topics/ - e-Tax, "[Teratasi] Tentang kondisi e-Tax tidak dapat digunakan"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
