Membangun Website Ops Autopilot: sistem yang menjaga website klien tanpa harus begadang

Website mati jam dua pagi, klien baru menelepon jam sembilan, dan pengunjung sudah keburu kabur sebelum kita tahu ada masalah. Skenario itu dialami hampir semua orang yang mengelola beberapa website sekaligus. Website Ops Autopilot lahir dari kelelahan menghadapi pola seperti itu: saya ingin sebuah sistem yang menjaga website klien secara terus-menerus, memberi tahu saya lebih dulu, dan kalau bisa memperbaiki sendiri hal-hal yang memang aman untuk diperbaiki otomatis.

Tulisan ini sekaligus catatan kerja dan materi web ops yang saya pakai sehari-hari: bagaimana menjaga website tetap hidup, bagaimana membedakan gangguan kecil dari yang serius, dan bagaimana memulihkan layanan tanpa harus menunggu keluhan pelanggan.

Apa itu web ops dan mengapa website perlu diawasi

Website ops adalah rutinitas menjaga sebuah website tetap sehat setelah selesai dibuat: pengawasan berkelanjutan, perawatan berkala, penanganan gangguan, dan pemulihan ketika ada yang gagal. Membuat website itu ibarat membeli mobil; website ops adalah servis rutin yang membuat mobil itu tetap layak dibawa pergi jauh. Mobil baru yang mengilap pun tetap mogok kalau oli dan remnya tak pernah dicek.

Dua hal yang paling sering diukur sederhana namun penting: uptime, yaitu persentase waktu website benar-benar bisa diakses, dan waktu respons, yaitu seberapa cepat website menjawab permintaan. Dari situ turun dua angka yang menentukan seberapa mahal sebuah gangguan: berapa lama sampai masalah terdeteksi, dan berapa lama sampai masalah benar-benar selesai. Seluruh alur di proyek ini dirancang untuk menekan angka-angka itu, karena perbaikan yang cepat tidak ada artinya kalau masalahnya baru diketahui berhari-hari kemudian.

Masalah yang ingin diselesaikan

Memantau satu website itu mudah, cukup dibuka sesekali. Masalah muncul ketika jumlahnya bertambah. Beberapa website berjalan sebagai aplikasi Next.js dengan proses tersendiri, beberapa lagi hanya file statis, dan sisanya memakai PHP. Tiap jenis punya cara gagal yang berbeda, jadi mengeceknya satu per satu secara manual jelas tidak masuk akal untuk jangka panjang.

Target saya sederhana. Sistem harus tahu kondisi tiap website setiap saat, mengenali gangguan sedini mungkin, lalu menempuh langkah yang aman untuk memulihkannya. Kalau langkah otomatis tidak memungkinkan, sistem cukup memberi peringatan yang jelas supaya saya bisa turun tangan.

Cara kerjanya secara garis besar

Inti dari Website Ops Autopilot adalah alur tertutup yang berputar terus, mengikuti siklus hidup sebuah insiden: deteksi, diagnosis, perbaikan, verifikasi, lalu catatan. Setiap satu menit sistem melakukan pemeriksaan (probe) ke tiap website dan mencatat hasilnya. Ketika sebuah website merespons dengan kode error, melambat di luar batas wajar, atau tidak merespons sama sekali, sistem membuat sinyal gangguan, mencoba menebak akar masalahnya, lalu mencocokkannya dengan daftar resep perbaikan yang sudah dikenal.

• Probe berkala mengecek status, waktu respons, dan masa berlaku sertifikat SSL tiap website.
• Sinyal gangguan dibuat begitu hasil probe menyimpang dari kondisi normal.
• Mesin diagnosis mengelompokkan gangguan berdasarkan jenis dan tingkat keparahannya.
• Resep perbaikan dijalankan aplikasi setelah diagnosis selesai, lengkap dengan uji coba kering sebelum eksekusi.
• Hasil perbaikan diverifikasi dengan probe ulang, lalu notifikasi dikirim dan catatan insiden disimpan sebagai bahan evaluasi berikutnya.

Bagian yang paling saya jaga adalah verifikasi. Sistem tidak menganggap sebuah perbaikan berhasil hanya karena perintahnya terkirim. Ia menunggu probe berikutnya menunjukkan website benar-benar pulih. Kalau tetap merah, statusnya ditandai gagal beserta alasannya, bukan dipaksa sukses.

Eksekusi oleh Hermes

Loop itu tidak berputar sendiri. Ada penjadwal yang memicunya, dan di proyek ini pemicunya Hermes. Setiap satu menit Hermes memeriksa jadwal yang jatuh tempo, menjalankan pemeriksaan kesehatan pada website yang waktunya tiba, lalu memicu diagnosis kalau hasilnya menyimpang dari kondisi normal. Satu siklus berjalan utuh: pemicu masuk, probe dijalankan, hasil dibandingkan, catatan disimpan, dan notifikasi keluar kalau memang perlu.

Dua hal kecil di bagian penjadwalan ternyata menentukan rasa percaya hasilnya. Pertama, jangan sampai dua siklus berjalan bersamaan, karena pemeriksaan yang tumpang tindih hanya membuat hasilnya berisik dan notifikasi berlipat. Kedua, setiap eksekusi harus meninggalkan jejak: apa yang dijadwalkan, jam berapa dijalankan, dan hasilnya apa. Kalau suatu hari ada data yang dipertanyakan, yang menjawab adalah catatan itu, bukan ingatan.

Supaya penjadwalan tidak bergantung pada satu jalur, aplikasi menyediakan endpoint terpisah yang menjalankan satu siklus pemeriksaan penuh ketika dipanggil. Endpoint itu bisa dipanggil penjadwal luar sebagai cadangan. Eksekusinya sama persis dengan yang dipicu Hermes, hanya pemicunya yang lain. Dengan begitu, kalau proses utama sempat mati dan hidup kembali, pemeriksaan yang jatuh tempo tetap punya jalan untuk dijalankan ulang.

Untuk tahap awal, pembagian tugas seperti ini sudah cukup kerja. Penjadwal menjaga supaya siklus jalan tepat waktu, sementara pemeriksaan, diagnosis, verifikasi, dan notifikasi tetap dipegang aplikasi di satu tempat yang mudah ditelusuri. Video demo di bawah menunjukkan bagian yang benar-benar berjalan: pemeriksaan dipicu tiap menit, probe jalan satu per satu, sinyal dan diagnosis tercatat, dan notifikasi keluar setelah hasilnya diverifikasi.

Pilihan teknologi

Antarmuka dan logika utama dibangun dengan Next.js 16 dan React. Datanya disimpan di SQLite melalui Drizzle ORM, jadi seluruh riwayat pemeriksaan, insiden, dan hasil perbaikan tercatat rapi tanpa perlu database besar di tahap awal. Penjadwalan dan pemicu pemeriksaan dijalankan Hermes, sementara notifikasi dikirim lewat WhatsApp karena di situlah orang yang bertanggung jawab biasanya membacanya.

Materi web ops yang paling berguna dari proyek ini

Hampir semua tantangan menarik di sini bukan soal algoritma, melainkan soal mendefinisikan kata sehat dengan tegas. Website yang menjawab kode 200 belum tentu sehat: isinya bisa berubah, halaman penting bisa error di bagian tertentu, dan sertifikat bisa kedaluwarsa perlahan. Karena itu aturan dianggap sehat harus bisa diuji satu per satu, bukan berdasarkan perasaan.

Pelajaran berikutnya datang dari alarm palsu. Website statis tidak punya proses yang berjalan, jadi tidak boleh dianggap mati hanya karena tidak ada port yang menyala. Salah menafsirkan hal ini membuat sistem sempat melapor gangguan palsu, dan alarm palsu itu justru lebih melelahkan daripada gangguan yang tertangani: orang jadi cuek pada peringatan. Setelah tiap website diberi keterangan jenis dan cara penyajiannya, alarm menjadi lebih sedikit dan jauh lebih dipercaya.

Hal terakhir adalah jejak. Setiap probe, sinyal, diagnosis, dan perbaikan disimpan bersama waktunya, supaya kejadian bisa ditelusuri ulang belakangan. Dari catatan itulah pola mulai kelihatan: gangguan mana yang sering kambuh, pertanyaan klien mana yang bisa dijawab mandiri, dan perbaikan otomatis mana yang ternyata jarang terpakai.

Otomasi yang baik bukan soal mengganti manusia, melainkan soal mengurangi jumlah keputusan kecil yang harus diambil manusia setiap hari.

Catatan pengembangan Website Ops Autopilot

Praktik web ops dasar yang bisa ditiru sekarang

• Pasang pengawasan uptime sederhana untuk seluruh website, ditambah pengingat masa berlaku sertifikat SSL.
• Tetapkan target waktu respons dan catat hasilnya, supaya pelambatan terbaca sebagai tren dan bukan kejutan.
• Siapkan saluran peringatan yang jelas dan sepakat siapa yang menerima ketika terjadi gangguan.
• Tulis catatan singkat setiap kali ada gangguan dan tindak lanjutnya, sekecil apa pun perbaikannya.
• Buat cadangan berkala dan pastikan pemulihannya pernah diuji, bukan hanya dijadwalkan.

Apa yang sudah jalan dan apa yang belum

Sampai tulisan ini dibuat, pemantauan berkala, deteksi gangguan, diagnosis, dan notifikasi sudah berjalan dengan data nyata, bukan tampilan tiruan. Siklusnya dipicu Hermes dan setiap eksekusinya meninggalkan jejak yang bisa ditelusuri. Yang masih dalam pengerjaan adalah menjalankan resep perbaikan secara penuh otomatis, dukungan banyak penyewa (multi-tenant) supaya tiap klien punya ruang datanya sendiri, penerapan paket berlangganan, dan halaman status publik agar klien bisa melihat riwayat uptime tanpa harus bertanya.

1. 1Buat isolasi data per penyewa sehingga satu klien tidak bisa melihat data klien lain.
2. 2Terapkan batas paket untuk jumlah website dan notifikasi sesuai langganan.
3. 3Sediakan halaman status publik dengan ringkasan uptime tiga puluh hari terakhir.
4. 4Tambahkan pencadangan basis data terjadwal beserta tombol pemulihannya.

Penutup

Website Ops Autopilot masih terus dikembangkan, tapi arahnya sudah jelas: membuat rutinitas web ops yang rapi, terbukti, dan tidak bergantung pada orang yang harus begadang. Kalau Anda mengelola beberapa website dan mulai kewalahan memantaunya, pendekatan seperti ini bisa jadi jalan keluar yang layak dicoba. Silakan hubungi saya kalau ingin berdiskusi soal kebutuhan serupa.