Bagaimana IT automation memungkinkan website untuk auto-recover

Seorang customer di Ohio sedang membandingkan dua produk di website e-commerce. Tetapi, kemudian websitenya menampilkan 500 error. Produk yang sudah dimasukkan ke keranjang hilang. Ia me-refresh halamannya tiga kali, tetapi tetap tidak ada perubahan. Website itu pun ditutup sepenuhnya.

Skenario ini tidak hanya terjadi di satu customer. Saat flash sale, bukan tidak mungkin ada ribuan customer yang mengalami hal sama.

Perusahaan retail menengah bisa kehilangan ribuan dolar ketika terjadi downtime mendadak. Setelah lima menit, revenue bisa menghilang sebesar tiga kali lipat. Setelah 30 menit, banyak customer tidak melanjutkan belanjanya dan beralih ke competitor.

Seberapa cepat recovery dilakukan adalah hal yang penting. Hal ini tidak ditentukan oleh seberapa bagus engineer di organisasi, melainkan apakah infrastruktur IT Anda bisa melakukan perbaikan sendiri atau harus menunggu campur tangan manusia.

Seperti apa recovery manual dilakukan?

Tanpa automasi, recovery manual berlangsung seperti ini:

• Tool monitoring mengirim alert
• On-call engineer melihatnya
• Mereka melacak penyebab masalahnya, yaitu Redis yang memblokir keranjang belanja
• Database restart, cache dihapus, sistem pembayaran dites
• Semuanya dikonfirmasi sudah stabil, secara bertahap dan manual

Ketika websitenya sudah kembali normal, revenue yang seharusnya didapat saat flash sale menghilang.

Namun, masalahnya bukan di engineer. Masalahnya adalah proses recovery yang dimulai dari manusia, yang mana mereka perlu waktu untuk siap mendiagnosis masalah. Di saat engineer sudah siap, revenue-nya sudah hilang.

Seperti apa recovery otomatis dilakukan?

Jika error serupa terjadi, IT Automation mengatasinya dengan berbeda.

Site24x7 dapat mendeteksi HTTP 5xx error rates yang melampaui 2% pada endpoint checkout. IT Automation kemudian memicu hal berikut: restart Redis pada server terdampak via agent-executed script, hapus session cache, dan transaksi sintesis memverifikasi homepage load dengan sukses. Customer pun bisa melihat loading spinner dan insidennya berakhir sebelum tim engineering melihat notifikasi alert.

IT Automation Site24x7 menjembatani deteksi dan resolusi dengan menjalankan tahapan recovery secara berurutan, dengan setiap tahap terkonfirmasi sebelum tahap selanjutnya dimulai. Manusia hanya dilibatkan ketika automasi tidak bisa menangani insiden secara mandiri.

Bagaimana Site24x7 memudahkan auto-recovery pada website

Site24x7 memantau uptime website, waktu respons, dan kesehatan transaksi secara berkelanjutan. Ketika ada ambang batas yang terlampaui atau waktu respons yang meningkat, profil IT Automation akan memicu worklow remediasi secara otomatis. Workflow ini kemudian melakukan restart web server, menghapus cache, mengatur skala load balancer, atau menjalankan script custom, sehingga memangkas MTTR secara langsung.

Apa yang bisa dilakukan IT Automation ketika website monitor mengirim alert

Ada satu perbedaan penting yang perlu dipahami. Website monitor di Site24x7 bersifat agentless, artinya monitor memeriksa URL dari lokasi eksternal tanpa perlu memasang agent di server. Karena itu, jenis automasi yang bisa dijalankan secara langsung berbeda dengan automasi pada server monitor.

Saat website monitor mendeteksi status Down atau Trouble, satu-satunya automasi bawaan yang dapat dijalankannya secara langsung adalah Invoke URL. Fitur ini berfungsi sebagai webhook yang mengirimkan request HTTP POST atau GET ke URL yang Anda tentukan. URL tersebut biasanya mengarah ke script yang berjalan di server standby, cloud function, atau endpoint API load balancer. Server standby kemudian menerima panggilan webhook dan menjalankan tindakan pemulihan yang sebenarnya, seperti me-restart Apache atau nginx, membersihkan session cache, beralih ke CDN cadangan, atau menambahkan instance baru.

Peran workflow automation

Workflow di Site24x7 merupakan lapisan di atas IT Automation. Jika IT Automation biasanya menjalankan satu tindakan sebagai respons terhadap alert, Workflow mengatur serangkaian tindakan di berbagai sistem, dengan titik pengambilan keputusan di antara setiap langkahnya.

Saat monitor mengirimkan alert kritis, Workflow akan memeriksa konteks terlebih dahulu sebelum mengambil tindakan. Workflow dapat memeriksa tool ITSM untuk memastikan apakah tiket terkait sudah tersedia sebelum membuat tiket baru. Workflow juga dapat mengambil detail resource yang terdampak melalui API monitoring sebelum memasukkannya ke mode maintenance. Notifikasi Slack yang terstruktur baru dikirim setelah langkah-langkah sebelumnya selesai, bukan langsung saat alert muncul.

Setiap langkah dalam Workflow disebut Workflow Function, yaitu unit logika kustom yang ditulis menggunakan Zoho Deluge atau JavaScript untuk menjalankan tugas tertentu dan meneruskan hasilnya ke langkah berikutnya. Satu fungsi melakukan validasi, fungsi berikutnya mengambil data, lalu fungsi selanjutnya menjalankan tindakan.

Perbedaan utama Workflow dengan IT Automation biasa terletak pada eksekusi bersyarat. IT Automation akan terpicu lalu menjalankan tindakannya. Sementara itu, Workflow akan memeriksa kondisi, menentukan langkah berikutnya berdasarkan hasil pemeriksaan, lalu mengambil tindakan sesuai konteks. Misalnya, memperbarui tiket yang sudah ada alih-alih membuat duplikat, atau melewati langkah maintenance jika resource sudah ditandai untuk maintenance.

Hasilnya, proses respons insiden dapat berjalan dari deteksi hingga penyelesaian tanpa intervensi manual. Pendekatan ini juga membantu mengurangi false positive dan tiket duplikat yang bisa muncul ketika automasi dijalankan tanpa mempertimbangkan konteks.

Suppression monitor dependen—fitur yang perlu dipahami

Sebagian besar platform automasi menjalankan setiap tindakan yang telah dikonfigurasi ketika suatu threshold terlampaui. Saat terjadi kegagalan berantai (cascading failure), misalnya satu server upstream mengalami gangguan dan menyebabkan 40 monitor yang bergantung padanya ikut terdampak, 40 script automasi dapat berjalan secara bersamaan pada infrastruktur yang sudah terbebani.

Site24x7 menangani kondisi ini dengan cara berbeda. Ketika resource yang menjadi dependensi sudah berstatus DOWN, IT Automation akan menekan eksekusi automasi pada semua monitor yang bergantung pada resource tersebut. Platform mengenali hubungan dependensi ini, menghentikan rangkaian automasi pada layanan yang terdampak, dan memungkinkan Anda menyelesaikan akar masalah satu kali—tanpa membebani infrastruktur dengan upaya recovery berulang pada setiap layanan yang terdampak secara bersamaan.

Untuk infrastruktur yang harus menangani lonjakan trafik, seperti saat flash sale, fitur ini sangat penting. Kegagalan database pada jam sibuk dapat memicu perubahan status monitor pada checkout API, layanan keranjang belanja, pengelola sesi, dan endpoint pembayaran secara bersamaan. Tanpa suppression, setiap monitor akan menjalankan automasinya sendiri. Dengan fitur ini, Site24x7 mengidentifikasi kegagalan pada upstream, menekan eksekusi automasi pada monitor yang bergantung padanya, dan memusatkan upaya recovery pada masalah yang sebenarnya.

Untuk mengonfigurasi suppression monitor, hubungkan setiap monitor dengan resource yang menjadi dependensinya melalui pengaturan monitor. Ketika resource tersebut berstatus DOWN, alert dan automasi pada monitor yang bergantung padanya akan otomatis ditekan. Pengaturan ini berlaku di tingkat monitor dan memiliki prioritas lebih tinggi daripada konfigurasi di tingkat grup.

Apa yang bisa dilakukan Invoke URL untuk recovery website?

• Restart web server (Apache, nginx, IIS) melalui script pada server standby.
• Memanggil load balancer API untuk mengalihkan traffic dari instance yang mengalami gangguan.
• Menjalankan fungsi AWS Lambda atau Azure Functions untuk menambah kapasitas infrastruktur.
• Memicu CDN purge untuk membersihkan cache yang sudah usang atau terkontaminasi.
• Mengirim data insiden ke PagerDuty, Slack, atau endpoint incident management custom.
• Memulai backup aplikasi sebelum proses pemulihan dijalankan.

Webhook ini mendukung metode GET, POST, PUT, PATCH, dan DELETE, URL dengan SSL, autentikasi Basic/NTLM, payload JSON, serta custom header. Site24x7 menyertakan parameter insiden—seperti nama monitor, status, penyebab gangguan, dan timestamp—dalam body POST. Dengan begitu, script penerima dapat mengetahui monitor mana yang memicu webhook dan penyebabnya.

Jika dipadukan dengan server monitor pada infrastruktur yang sama, Anda dapat memanfaatkan seluruh kapabilitas automasi, mulai dari me-restart site IIS dan application pool, menjalankan perintah di server (seperti membersihkan cache, melakukan rotasi log, dan me-restart proses), hingga menjalankan script server dengan logika kondisional menggunakan Ruby, Python, Shell, PowerShell, dan Bash. Anda juga dapat melakukan reboot server secara terkontrol dengan konfirmasi berdasarkan jumlah polling, serta menjalankan, menghentikan, dan me-restart Windows Services.

Semua tindakan ini dijalankan langsung melalui agent Site24x7 yang terpasang di server, tanpa memerlukan server standby sebagai perantara.

Konfigurasi yang praktis bagi sebagian besar tim e-commerce terdiri dari dua bagian: website monitor yang memantau URL checkout dan memicu webhook saat website mengalami gangguan, serta server monitor pada host yang sama untuk menjalankan automasi berbasis agent ketika metrik CPU, memori, atau proses melewati threshold yang ditentukan. Keduanya mencakup seluruh kebutuhan pemulihan: deteksi ketersediaan dari sisi eksternal dan tindakan perbaikan dari sisi internal. Anda dapat mengaitkan hingga lima automasi dengan setiap atribut yang dipantau. Setiap eksekusi tercatat dalam IT Automation Logs, termasuk nama tindakan, timestamp, host tujuan, dan hasil eksekusinya.

Real User Monitoring dan remediasi otomatis

Real User Monitoring (RUM) Site24x7 mengambil data session seperti page yang dikunjungi user dan bagaimana transaksi individual dilakukan. Ketika page tidak bisa loading atau ada flow checkout yang terputus, automasi akan masuk: recycle application pool, hapus session cache, restart web service, dan menjalankan health check webpage. Tujuannya untuk menjaga waktu load homepage tetap di bawah tiga detik dan menjaga agar user tidak menyadari adanya masalah.

Event-driven trigger

Profil automation berkaitan erat dengan kondisi alert tertentu:

• Homepage mengembalikan non-200 status
• Waktu respons checkout API melewati threshold
• Web server CPU melebihi 90%
• Jumlah customer yang meninggalkan keranjang melebihi baseline

Site24x7 menerapkan deteksi anomali berbasis AI yang membedakan lonjakan traffic karena Black Friday dan karena penurunan performa. Deteksi anomali seasonal mempelajari riwayat pola log, sehingga event yang traffic-nya tinggi tidak menghasilkan false escalation.

Ketika kehabisan koneksi database atau deployment yang bermasalah mulai memengaruhi 10% atau lebih trafik, automasi akan berjalan secara otomatis. Cache dibersihkan, layanan di-restart, dan kapasitas load balancer ditingkatkan sebelum bounce rate meningkat. Trigger automasi juga dapat dihubungkan langsung dengan threshold pelanggaran SLO. Ketika konsumsi error budget meningkat melampaui burn rate yang aman, tindakan korektif akan dijalankan secara otomatis sebelum periode pengukuran SLO terancam.

Root cause analysis berbasis AI

AI Engine Zia dari Site24x7 menganalisis berbagai sinyal performa, mulai dari skor RUM, kegagalan synthetic transaction, hingga metrik server, untuk mengidentifikasi akar masalah, seperti query database yang lambat, kehabisan koneksi dalam connection pool, atau timeout pada API pihak ketiga.

Ketika Zia mendeteksi lonjakan waktu respons checkout API, algoritma deteksi anomali akan membedakan penurunan performa yang sebenarnya dari lonjakan trafik. Zia kemudian menandainya sebagai insiden terkonfirmasi dan memicu automasi yang telah dipetakan sebelumnya untuk me-restart connection pool serta memverifikasi alur penjualan—tanpa perlu mengirim notifikasi ke tim on-call.

Hasilnya, tim dapat melakukan pemulihan otomatis, tidak lagi menangani insiden satu per satu ketika sudah terjadi. Engineer tidak lagi menghabiskan waktu on-call untuk mendiagnosis pola kegagalan yang sudah diketahui, sehingga dapat lebih fokus pada pekerjaan yang memberikan hasil jangka panjang dan tidak perlu terus diulang.

Tahapan workflow recovery

Insiden yang kompleks membutuhkan recovery berurutan yang terverifikasi, bukan satu script saja. Inilah apa yang dilakukan profil automasi Site24x7 saat terjadi kegagalan Redis di masa flash sale:

• Mendeteksi HTTP 5xx error rate yang melebihi 2% di checkout endpoint
• Me-restart layanan Redis pada server terdampak melalui agent-executed script
• Menghapus session cache dalam waktu 30 detik
• Menjalankan synthetic transaction untuk memverifikasi apakah homepage sudah berhasil dimuat
• Jika checkout masih gagal: Scale out replikasi database
• Jika performa masih belum pulih: Kembalikan deployment ke versi sebelumnya (rollback) atau alihkan ke CDN backup.

Setiap langkah akan diverifikasi sebelum langkah berikutnya dijalankan. Tindakan yang berdampak lebih besar, seperti menambah kapasitas (scaling) atau melakukan rollback, hanya akan dijalankan jika langkah sebelumnya belum berhasil mengatasi masalah. Pendekatan ini mencegah tindakan korektif yang berlebihan sekaligus menjaga catatan audit proses pemulihan tetap rapi. Perlu diperhatikan bahwa Site24x7 mendukung hingga lima tindakan automasi untuk setiap atribut yang dipantau. Karena itu, workflow yang terdiri dari beberapa langkah kompleks sebaiknya disusun pada tingkat profil threshold.

Integrasi komunikasi tim

Automasi menangani resolusi insiden, sementara integrasi menangani komunikasi.

ServiceDesk Plus membuat tiket secara otomatis ketika status monitor berubah dan menambahkan log eksekusi IT Automation sebagai notes. Dengan begitu, tim support memiliki audit trail yang lengkap tanpa perlu mencatatnya secara manual. Notifikasi melalui Slack dan Jira dikirim untuk kasus-kasus tertentu yang memang membutuhkan penanganan manusia, sedangkan eskalasi melalui PagerDuty hanya dilakukan untuk insiden yang tidak berhasil diselesaikan oleh automasi.

Hierarki ini penting karena jika setiap insiden memicu notifikasi kepada on-call engineer, lama-kelamaan mereka akan kehilangan kepercayaan terhadap notifikasi tersebut. Alert fatigue merupakan kegagalan sistem monitoring, sama seperti insiden yang tidak terdeteksi.

Proactive maintenance

Self-healing infrastructure bukan hanya reaktif. Site24x7 menjalankan maintenance secara otomatis sesuai jadwal, mulai dari rotasi log untuk mencegah error disk, renewal SSL certificate agar proses checkout tidak terganggu, cleanup cache CDN, hingga optimasi Core Web Vitals untuk mempertahankan skor Google Page Experience.

Insiden terbaik adalah insiden yang tidak pernah terjadi. Sebagian besar gangguan akibat sertifikat kedaluwarsa, disk penuh, dan cache CDN yang terkontaminasi sebenarnya dapat dicegah jika masalah terdeteksi sebelum menimbulkan dampak. Namun, di banyak organisasi, masalah-masalah ini bisa luput dari perhatian jika tidak ada pemantauan otomatis.

Business case

Salah satu perusahaan layanan keuangan global yang menggunakan kapabilitas AIOps Site24x7 melaporkan bahwa mereka berhasil memfilter hampir 90% alert noise setelah implementasi Site24x7. Tim engineering mereka tidak lagi merespons alert yang banyak, melainkan hanya fokus pada insiden yang membutuhkan penilaian manusia.

Perubahan ini membawa manfaat besar seiring waktu. Tim tidak lagi menghabiskan waktu on-call untuk insiden yang bisa ditangani automasi, sehingga mereka dapat lebih fokus membangun solusi baru, mengurangi technical debt, dan melakukan post-mortem yang benar-benar menghasilkan perbaikan.

Khusus untuk e-commerce, kemampuan recovery layanan dalam waktu kurang dari dua menit saat terjadi kegagalan Redis atau lonjakan koneksi database—tanpa intervensi manusia—dapat mengubah risiko operasional saat event penjualan menjadi revenue. Flash sale yang berisiko menyebabkan kerugian besar karena insiden bisa berjalan lancar karena infrastruktur mampu menangani gangguan secara otomatis, bahkan saat tim IT sedang beristirahat.

Mulai free trial Site24x7

Rancang profil IT Automation Anda sebelum flash sale selanjutnya. Kami menghadirkan free trial 30 hari yang termasuk IT Automation, RUM, synthetic monitoring, dan AIOps alerting engine. Coba gratis Site24x7 sekarang. website monitoring.

FAQ