Server Saya Turun dan Saya Baru Tahu Lima Jam Kemudian Secara Kebetulan

Pemberitahuan itu tidak datang daripada perkhidmatan pemantauan. Ia tidak datang daripada amaran automatik atau webhook yang melepas masuk ke Slack. Ia datang daripada sistem pemantauan yang paling primitif yang boleh dibayangkan: membuka penyemak imbas, menaip URL, dan menatap halaman kosong. Ia adalah hari Selasa petang. Tapak itu telah turun sejak kira-kira jam sembilan pagi, dan sekarang sudah melampaui jam dua petang. Lima jam kesunyian total daripada aplikasi web yang biasanya melayani ribuan permintaan setiap hari. Lima jam di mana setiap pengunjung melihat halaman ralat, setiap panggilan API mengembalikan tiada apa-apa, dan setiap tugas berjadual gagal dengan senyap di latar belakang. Pelayan itu tidak ranap secara dramatik. Tidak ada panik kernel, tiada kegagalan cakera, tiada vektor serangan yang meninggalkan bukti forensik. VPS Contabo hanya berhenti bertindak balas kepada permintaan HTTP, duduk di sana dengan alamat IP yang sah dan denyutan pada lapisan rangkaian, tetapi menolak untuk melayani sebarang lalu lintas web sama sekali.

Penemuan itu berlaku kerana tugas yang tidak berkaitan sama sekali. Ada keperluan untuk menyemak tata letak halaman tertentu untuk perubahan reka bentuk, jadi penyemak imbas pergi ke URL dan mengembalikan tiada apa-apa. Naluri pertama adalah untuk menyalahkan rangkaian tempatan. Segarkan halaman. Masih tiada apa-apa. Cuba penyemak imbas yang berbeza. Masih tiada apa-apa. Buka terminal dan ping pelayan. Paket kembali dengan normal. Sambungan SSH? Berfungsi dengan baik. Status Apache? Mati. Proses pelayan web telah ranap pada suatu ketika dalam jam-jam awal pagi dan tidak pernah dimulakan semula, kerana tidak ada penyelia proses yang dikonfigurasi untuk menangani mod kegagalan yang tepat itu. Pembaikan itu mengambil tiga puluh saat. Kesedaran bahawa ini boleh berlaku lagi, dan mungkin telah berlaku sebelum ini tanpa ada yang perasan, mengambil masa yang jauh lebih lama untuk dicerna.

Setiap pembangun yang telah menjalankan perkhidmatan pengeluaran pada VPS mempunyai versi cerita ini. Mungkin ia bukan lima jam. Mungkin ia dua, atau lapan, atau hujung minggu penuh. Butiran-butiran berbeza tetapi polanya adalah sama. Pelayan turun, tiada siapa yang perasan, dan penemuannya adalah kebetulan. Masalah akar itu bukan kebolehpercayaan pelayan. Pelayan gagal, proses ranap, cakera penuh, kebocoran memori terkumpul. Itu adalah sifat menjalankan perisian pada perkakasan fizikal. Masalah akar itu adalah ketiadaan pemantauan, dan lebih khususnya, jurang antara mengetahui pelayan berada dalam talian dan mengetahui aplikasi itu benar-benar berfungsi.

Perbezaan Antara Pemantauan Uptime dan Mengetahui Laman Web Anda Benar-benar Berfungsi

Pemantau uptime tradisional melakukan satu perkara dengan baik. Mereka menghantar permintaan HTTP ke URL pada selang waktu tetap dan menyemak sama ada kod respons adalah 200. Jika kod adalah apa-apa yang lain, atau jika permintaan tamat, amaran melepas. Ini menangkap kegagalan yang paling membawa bencana: pelayan tidak dapat dijangkau sepenuhnya, domain telah tamat tempoh, sijil SSL tidak sah. Tetapi ia melepaskan kategori masalah yang sangat besar yang boleh dikatakan lebih biasa dan lebih merosakan.

Pertimbangkan senario di mana pelayan mengembalikan kod status 200, tetapi halaman itu rosak. Sambungan pangkalan data gagal, jadi kawasan kandungan menunjukkan mesej ralat dan bukannya penyenaraian produk yang dijangkakan. Fail CSS gagal dimuatkan, jadi halaman itu memberikan HTML tanpa gaya. Ralat JavaScript menghalang aplikasi utama daripada memulakan, meninggalkan pengguna menatap pemintas muatan yang tidak pernah selesai. Widget pihak ketiga menyuntik overlay yang meliputi keseluruhan kandungan halaman. Dalam semua kes ini, pemantau uptime melaporkan semuanya sebagai sihat kerana ia menerima respons 200. Pelayan itu aktif. Laman web itu rosak. Tiada siapa yang tahu.

Jurang ini antara "pelayan bertindak balas" dan "laman web berfungsi" adalah tempat pemantauan tangkapan layar menjadi penting. Tangkapan layar yang dijadualkan menangkap rupa sebenar halaman pada selang waktu biasa. Jika halaman tiba-tiba menunjukkan mesej ralat, tata letak rosak, atau layar putih kosong, tangkapan layar menjadikannya terlihat serta-merta. Gabungkan tangkapan layar berjadual dengan perbandingan perbezaan piksel, dan sistem dapat secara automatik mengesan apabila halaman telah berubah dengan cara yang tidak dijangka. Beberapa piksel beralih kerana kemas kini kandungan adalah normal. Keseluruhan halaman menjadi putih atau memaparkan jejak timbunan ralat tidak, dan algoritma perbezaan boleh membezakan antara kedua-duanya dengan ambang sensitiviti yang boleh dikonfigurasi.

Selepas gangguan lima jam, perkara pertama yang disediakan adalah pemantau uptime untuk setiap perkhidmatan kritikal. Tetapi penambahan yang lebih menarik adalah pemantauan tangkapan layar berjadual yang menangkap keadaan visual sebenar halaman-halaman utama setiap lima belas minit. Pemantau uptime menangkap ranap yang jelas. Pemantau tangkapan layar menangkap segalanya: kegagalan halus yang mengembalikan kod status 200 sambil menunjukkan halaman rosak, skrip pihak ketiga yang menyuntik kandungan yang tidak dijangka, ralat pangkalan data yang muncul hanya dalam keadaan tertentu.

Pembinaan Saluran Amaran yang Sepatutnya Wujud Sejak Awal

Seni bina sistem pemantauan yang tepat tidak rumit dalam teori. Penjadual mencetuskan semakan pada selang yang ditentukan. Semakan itu menangkap keadaan semasa sasaran. Keadaan dibandingkan dengan garis dasar yang dijangka. Jika perbandingan melebihi ambang, amaran melepas. Cabaran bukan dalam seni bina tetapi dalam kebolehpercayaan setiap komponen. Sistem pemantauan yang sendiri turun adalah lebih buruk daripada tanpa pemantauan sama sekali, kerana ia menciptakan perasaan palsu keselamatan.

Saluran pemantauan tangkapan layar berfungsi dalam peringkat. Penjadual menghantar tugas tangkapan pada selang yang dikonfigurasi, biasanya setiap lima, sepuluh, atau lima belas minit bergantung pada kritikal halaman. Tugas tangkapan menjalankan contoh Chromium tanpa kepala yang memuat halaman, menunggu persembahan selesai, dan menyimpan tangkapan layar yang dihasilkan. Tangkapan layar baru kemudian dibandingkan dengan tangkapan sebelumnya menggunakan algoritma perbezaan piksel yang mengenal pasti kawasan yang berubah dan mengira jumlah peratusan perubahan. Jika perubahan melebihi ambang yang dikonfigurasi, pemberitahuan dihantar melalui saluran yang dikonfigurasi: e-mel, webhook, Slack, atau sebarang titik akhir tersuai.

Perbandingan perbezaan adalah tempat perkara menjadi sangat menarik dari perspektif teknikal. Perbandingan piksel yang naif akan menandakan setiap tangkapan layar sebagai berubah kerana kandungan dinamik seperti cap masa, iklan, atau unsur animasi. Enjin perbezaan mengambil kira ini dengan menyokong zon pengecualian, kawasan segi empat tepat halaman yang dimasker sebelum perbandingan. Cap masa dalam tajuk, iklan sepanduk berputar, widget sembang langsung di sudut: ini semua boleh dikecualikan supaya hanya perubahan bermakna yang mencetuskan amaran. Apa yang tinggal selepas pengecualian adalah kawasan kandungan yang stabil, dan sebarang perubahan di sana hampir pasti bernilai penyiasatan.

Gangguan lima jam akan tertangkap dalam beberapa minit di bawah sistem ini. Tangkapan layar berjadual pertama selepas pelayan turun akan mengembalikan sama ada imej kosong atau halaman ralat, kedua-duanya akan berbeza secara dramatik daripada garis dasar. Peratusan perbezaan akan berhampiran 100%, jauh melebihi sebarang ambang yang munasabah, dan amaran akan melepas serta-merta. Lima jam gangguan akan menjadi lima minit, dan lima minit itu akan menjadi selang pemantauan itu sendiri, bukan masa yang diperlukan untuk manusia secara kebetulan tersandung pada masalah itu.

Apa Lima Jam Gangguan Tidak Kelihatan Benar-benar Kos

Kos segera lima jam gangguan mudah dikira apabila nombor-nombor tersedia. Untuk laman web yang mengendalikan ribuan permintaan harian, lima jam mewakili hirisan penting lalu lintas harian. Setiap permintaan yang mengembalikan ralat adalah pengguna yang tidak mendapatkan apa yang mereka datang cari. Ada yang adalah pengunjung baru yang tidak akan pernah kembali. Ada yang adalah pengguna sedia ada yang akan kehilangan sejumlah kecil kepercayaan. Ada yang adalah pengguna API yang aplikasi mereka sendiri gagal kerana kebergantungan itu. Kesan hasil langsung bergantung pada sifat laman web, tetapi bahkan untuk aplikasi SaaS kecil, lima jam gangguan semasa waktu perniagaan boleh mudah mewakili ratusan dolar dalam penukaran yang hilang.

Kos tersembunyi lebih sukar untuk dikira tetapi boleh dikatakan lebih besar. Enjin pencarian yang merangkau laman web semasa lima jam itu menerima respons ralat, dan walaupun gangguan singkat umumnya ditoleransi oleh infrastruktur perayapan Google, gangguan lanjutan boleh mengakibatkan nyahindeksan sementara halaman yang terjejas. Kempen e-mel yang berjalan semasa gangguan lalu lintas didorong ke titik akhir mati, membuang keseluruhan belanja kempen. Tugas berjadual yang bergantung pada aplikasi web, perkara seperti penghantaran webhook, penjanaan laporan, dan pemprosesan kelompok, semuanya gagal dengan senyap dan perlu dikenal pasti dan dijalankan semula secara manual selepas pelayan dipulihkan.

Kos yang paling berbahaya adalah yang reputasi. Pengguna yang menemui laman web turun tidak biasanya menghantar e-mel mengatakan "laman web anda turun." Mereka hanya pergi dan mungkin atau mungkin tidak kembali. Tidak ada mekanisme maklum balas untuk gangguan kerana mekanisme maklum balas itu sendiri turun. Tetingkap lima jam cukup panjang untuk beberapa pengguna hampir pasti mencuba laman web, mendapatnya rosak, dan berpindah ke pesaing tanpa pernah menjana titik data tunggal yang akan menunjukkan apa yang berlaku. Mereka hanya hilang, dan tidak ada cara untuk mengetahui berapa ramai atau siapa mereka.

Daripada Reaktif kepada Proaktif dan Tidak Pernah Menemui Secara Kebetulan Lagi

Pelajaran daripada petang hari Selasa itu bukan bahawa pelayan ranap. Itu sudah diketahui. Pelajaran adalah bahawa setiap minit antara kegagalan dan penemuannya adalah minit kerosakan yang berkumpul, dan satu-satunya cara untuk meminimalkan tetingkap itu adalah untuk mengotomatikkan pengesanan. Pemantauan manusia tidak berskala. Memeriksa laman web secara manual sekali sehari bermakna masa pengesanan purata untuk gangguan itu adalah dua belas jam. Memeriksanya sekali sejam membawa itu kepada tiga puluh minit, tetapi tidak ada manusia yang boleh secara realistis memeriksa setiap halaman setiap aplikasi sekali sejam sepanjang masa.

Gabungan pemantauan uptime dan pemantauan tangkapan layar visual meliputi kedua-dua lapisan masalah itu. Pemantau uptime menangkap pelayan turun sepenuhnya. Pemantau tangkapan layar menangkap aplikasi itu rosak sementara pelayan tetap aktif. Bersama-sama, mereka mengurangkan tetingkap pengesanan daripada "apabila seseorang kebetulan perasan" kepada selang pemantauan itu sendiri, yang boleh sesingkat satu minit untuk perkhidmatan kritikal. Amaran melepas, pemberitahuan tiba, dan pembaikan dimulai dalam beberapa minit dan bukannya jam.

Pelayan telah turun dua kali lagi sejak insiden asal itu. Kedua-dua kali, amaran tiba dalam tiga minit. Kedua-dua kali, pembaikan telah digunakan sebelum sebarang lalu lintas yang signifikan hilang. Infrastruktur pemantauan membayar diri sendiri dengan insiden pertama yang ia tangkap, dan segala-galanya selepas itu telah menjadi kepada sebelah yang positif. Era menemui gangguan secara kebetulan telah tamat, dan melihat ke belakang, satu-satunya soalan sebenar adalah mengapa ia mengambil gangguan lima jam untuk membuat pelaburan itu jelas.