Aplikasi Laravel yang sehat di production bukan aplikasi yang tidak pernah error. Error tetap akan muncul: koneksi database putus, queue menumpuk, disk penuh, API pihak ketiga melambat, atau deploy kecil yang ternyata mengubah perilaku job lama. Bedanya, aplikasi yang dirawat dengan baik memberi sinyal lebih awal dan punya prosedur pemulihan yang jelas.
Maintenance bukan pekerjaan besar yang dilakukan saat server sudah kewalahan. Lebih aman kalau dijadikan pola rutin. Sedikit, konsisten, dan bisa dibuktikan hasilnya.
Mulai dari hal yang benar-benar dipakai pengguna
Jangan hanya melihat dashboard CPU lalu merasa semuanya aman. Aplikasi bisa memakai CPU rendah, tetapi pengguna tetap gagal checkout karena worker queue berhenti sejak pagi. Untuk Laravel, biasanya ada beberapa jalur yang layak dipantau setiap hari: request HTTP, database, queue, scheduler, cache, dan layanan eksternal.
Praktiknya, tentukan dulu transaksi penting aplikasi. Misalnya login, membuat pesanan, pembayaran, pengiriman email, dan sinkronisasi stok. Dari sana, pasang monitoring yang menjawab pertanyaan sederhana: apakah transaksi ini berhasil, berapa lama prosesnya, dan kapan mulai gagal?
Rawat log, jangan cuma mengumpulkannya
File laravel.log sering menjadi saksi paling jujur ketika masalah terjadi. Sayangnya, banyak server membiarkannya tumbuh sampai partisi penuh. Begitu disk habis, masalahnya merembet: session tidak tersimpan, upload gagal, queue tidak bisa menulis log, bahkan deploy ikut macet.
Atur channel logging dan rotasi log sejak awal. Untuk aplikasi yang cukup ramai, kirim log ke layanan terpusat agar pencarian error tidak bergantung pada SSH ke satu server. Yang perlu diperhatikan bukan hanya jumlah error, tetapi pola error yang berulang. Contohnya, timeout pada endpoint pembayaran yang hanya muncul jam 10 pagi. Itu biasanya petunjuk adanya lonjakan beban atau bottleneck di layanan lain.
Error yang sebaiknya segera diberi alert
- Lonjakan error 500 dan exception yang belum pernah muncul sebelumnya.
- Gagal konek ke database, Redis, storage, atau API pembayaran.
- Job gagal berulang pada queue yang sama.
- Request lambat pada endpoint transaksi utama.
- Ruang disk menipis dan penggunaan memori terus naik tanpa turun.
Alert yang terlalu ramai juga tidak membantu. Kalau setiap warning masuk ke grup chat, lama-lama semua orang terbiasa mengabaikannya. Alert sebaiknya diprioritaskan: mana yang perlu dibangunkan tengah malam, mana yang cukup dicek saat jam kerja.
Queue harus diperlakukan sebagai komponen utama
Pada banyak aplikasi Laravel, queue memegang pekerjaan penting: kirim email, buat invoice, proses gambar, sinkronisasi marketplace, sampai webhook. Karena berjalan di belakang layar, queue sering baru diperhatikan setelah pengguna bertanya, “Kenapa email saya belum masuk?”
Pastikan worker dikelola oleh process manager seperti Supervisor atau systemd dan otomatis hidup lagi jika proses mati. Jika memakai Redis dan Horizon, gunakan dashboard Horizon untuk melihat antrean, throughput, job gagal, dan worker yang aktif. Ini jauh lebih berguna daripada menebak dari log.
Job juga perlu dirancang agar aman dijalankan ulang. Network timeout bisa membuat aplikasi tidak yakin apakah request ke pihak ketiga sudah diterima atau belum. Di titik seperti ini, idempotency penting. Simpan reference ID, cek status sebelum membuat transaksi baru, dan jangan mengandalkan retry buta.
Scheduler perlu dicek, bukan diasumsikan hidup
php artisan schedule:run yang dipanggil cron tiap menit terlihat sepele, tetapi dampaknya besar. Banyak proses rutin bergantung di sana: hapus data sementara, kirim laporan, tutup periode, sinkronisasi data, atau dispatch job.
Masalah klasiknya sederhana: cron tidak berjalan setelah pindah server, path PHP berubah, atau command gagal diam-diam. Buat satu scheduled task ringan yang meninggalkan jejak, misalnya heartbeat ke log atau metric. Dengan begitu, kita tahu scheduler memang berjalan, bukan sekadar percaya konfigurasi lama masih benar.
Database: backup saja belum cukup
Backup database yang tidak pernah diuji restore sebenarnya hanya harapan. Jadwalkan backup, simpan di lokasi terpisah dari server utama, enkripsi bila isinya sensitif, lalu lakukan simulasi restore secara berkala. Tidak harus setiap hari, tetapi harus cukup rutin untuk membuktikan prosedurnya masih relevan.
Selain backup, cek query lambat dan pertumbuhan tabel. Tabel log aktivitas atau tabel audit bisa membengkak tanpa terasa. Saat tabel sudah puluhan juta baris, laporan yang dulu selesai dua detik bisa mulai timeout. Biasanya solusi bukan langsung menaikkan spesifikasi server. Lihat indeks, pola query, data yang bisa diarsipkan, dan batas retensi data.
Catatan kecil soal migration
Migration yang aman di lokal belum tentu aman di production. Menambah indeks pada tabel besar, mengubah kolom, atau menghapus field bisa mengunci tabel cukup lama. Untuk perubahan berisiko, lakukan bertahap: tambahkan kolom baru, deploy kode yang mendukung dua format, migrasikan data lewat job, baru hapus struktur lama setelah semuanya stabil.
Deploy harus bisa mundur dengan cepat
Maintenance sering terganggu bukan oleh bug besar, melainkan deploy yang setengah selesai. Cache konfigurasi lama, worker belum direstart, asset tidak cocok dengan backend baru, atau migration sudah berjalan tetapi kode baru gagal boot.
Pola yang lebih aman adalah membuat deploy repeatable dan singkat. Jalankan test sebelum rilis, gunakan environment production yang jelas, cache ulang konfigurasi dan route bila diperlukan, lalu restart queue worker setelah deploy. Simpan juga langkah rollback yang praktis. Kalau rollback membutuhkan improvisasi saat incident, itu berarti prosedurnya belum matang.
- Pastikan pipeline menjalankan test dan pemeriksaan dasar sebelum rilis.
- Backup atau siapkan titik pemulihan sebelum migration berisiko.
- Deploy kode, lalu refresh cache yang relevan.
- Restart worker queue agar memuat kode baru.
- Cek endpoint penting, queue, dan error rate setelah rilis.
- Jika metrik memburuk, rollback lebih cepat daripada berdebat terlalu lama.
Update dependency dengan ritme yang masuk akal
Menunda pembaruan Laravel dan dependency selama bertahun-tahun biasanya menghasilkan satu proyek upgrade yang mahal dan menegangkan. Sebaliknya, update setiap hari tanpa test juga bukan pola yang bijak.
Pilih ritme reguler, misalnya mingguan untuk patch keamanan dan bulanan untuk dependency non-kritis. Baca changelog yang berdampak, jalankan test, dan pastikan package yang dipakai memang masih dirawat. Package kecil yang tidak diperbarui bertahun-tahun sering menjadi sumber masalah saat versi PHP atau Laravel naik.
Buat runbook untuk masalah yang berulang
Runbook tidak perlu panjang. Dokumen satu halaman untuk “queue menumpuk”, “database penuh”, atau “webhook gagal masuk” sudah sangat membantu. Isinya cukup gejala, langkah pengecekan, perintah aman yang boleh dijalankan, eskalasi, dan cara verifikasi pulih.
Tujuannya bukan menggantikan kemampuan teknis tim. Tujuannya mengurangi waktu panik. Saat incident terjadi, orang tidak perlu mengingat semuanya dari kepala.
Jadwal maintenance yang realistis
Setiap hari, cek error kritis, kesehatan queue, scheduler, kapasitas disk, dan transaksi utama. Setiap minggu, tinjau job gagal, query lambat, backup terbaru, serta dependency keamanan. Setiap bulan, uji restore backup, review penggunaan storage dan database, perbarui runbook, lalu lihat incident bulan lalu: apa yang sebenarnya bisa dideteksi lebih awal?
Intinya sederhana: Laravel di production tetap sehat karena ada kebiasaan operasional yang konsisten. Bukan karena server besar, bukan karena dashboard mahal. Mulai dari memantau alur penting, membuktikan backup bisa dipulihkan, dan memastikan queue serta scheduler tidak bekerja dalam gelap. Tiga hal itu saja sudah mencegah banyak drama yang biasanya baru terlihat saat pengguna mulai komplain.
