Amaran Laman Web Mana yang Sebenarnya Penting

Setiap alat pemantauan disediakan dengan amaran dihidupkan secara lalai, dan kebanyakan perniagaan secara senyap akan mematikan separuh daripadanya dalam bulan pertama. Bukan kerana amaran itu salah — biasanya setiap satu memang tercetus kerana sesuatu yang benar-benar berlaku — tetapi kerana terlalu banyak, ia tiba pada waktu yang salah, dan selepas mesej kelima jam 3 pagi tentang lonjakan CPU yang reda dengan sendirinya, seluruh saluran itu terus disenyapkan. Itulah kegagalan sebenar dalam kebanyakan susunan pemantauan laman web: bukan kerana tiada apa-apa yang ditangkap, tetapi kerana semuanya ditangkap, pada kelantangan yang sama, sehingga tiada sesiapa membacanya lagi.

Reka bentuk amaran adalah kemahiran yang berbeza daripada pemantauan. Pemantauan ialah mengumpul data — masa tindak balas, kadar ralat, penggunaan ruang cakera, tarikh sijil, log tugasan. Reka bentuk amaran pula ialah memutuskan angka yang mana, melepasi garisan yang mana, wajar mengganggu hari seseorang. Jika ini tersilap, anda akan berakhir dengan salah satu daripada dua susunan yang tidak berguna: saluran yang terlalu bising sehingga diabaikan, atau saluran yang terlalu senyap sehingga terlepas satu-satunya perkara yang benar-benar memerlukan seseorang bertindak dalam masa sejam.

Dua Kategori, dan Hanya Satu Sepatutnya Mengganggu Sesiapa

Kebanyakan perkara yang dikesan oleh sistem pemantauan jatuh ke dalam salah satu daripada dua kategori: perkara yang memerlukan seseorang bertindak sekarang, dan perkara yang seseorang perlu tahu akhirnya. Menggabungkan kedua-duanya menjadi satu aliran sahaja — satu peti masuk, satu saluran sembang, satu set notifikasi push, semuanya membawa tahap kesegeraan yang sama — adalah kesilapan paling biasa dalam cara perniagaan menyediakan amaran. Ia biasanya bukan kegagalan alat; kebanyakan alat menyokong pengasingan amaran segera daripada amaran rutin. Ia keputusan yang tiada sesiapa buat secara sengaja.

Apa yang Benar-benar Wajar Mengejutkan Seseorang daripada Tidur

Senarai yang ringkas, dan ia memang sengaja dibuat ringkas:

Laman web down. Bukan perlahan, bukan merosot — tetapi langsung tidak dapat dicapai, atau mengembalikan ralat pada setiap permintaan. Ini jelas dan sensitif dari segi masa: setiap minit ia down adalah minit di mana tiada sesiapa boleh membeli daripada anda, membaca apa yang anda siarkan, atau menghubungi anda.

Checkout, atau borang kritikal lain, gagal berfungsi walaupun bahagian lain laman web dimuat turun dengan lancar. Ini boleh dikatakan lebih teruk daripada gangguan penuh, kerana laman web kelihatan sihat kepada anda dan enjin carian sedangkan ia secara senyap menolak setiap pelanggan yang cuba membayar atau bertanya. Semakan yang hanya mengesahkan halaman utama memberi respons normal akan langsung terlepas pandang isu ini — ia jenis semakan yang berbeza, disasarkan kepada jenis kegagalan yang berbeza.

Sijil TLS hampir luput. Ini sepenuhnya boleh dijangka dan sepenuhnya boleh dielakkan, dan sebab itulah ia salah satu cara paling memalukan untuk sesuatu laman web down. Sijil percuma daripada perkhidmatan seperti Let's Encrypt lazimnya dikeluarkan dengan tempoh sah 90 hari (Let's Encrypt FAQ), diperbaharui secara automatik oleh kebanyakan susunan hosting — tetapi perkataan "automatik" itu memikul banyak tanggungjawab dalam ayat tersebut, dan tugas pembaharuan automatik memang boleh gagal secara senyap. Amaran yang tercetus dengan tempoh masa sebenar sebelum tamat tempoh, berminggu-minggu dan bukan sekadar berjam-jam, memberi seseorang masa untuk membaiki pembaharuan yang rosak sebelum pelayar mula memberi amaran kepada setiap pelawat untuk menjauhinya.

Ruang cakera semakin habis. Bukan sekadar "cenderung meningkat" — tetapi sudah benar-benar hampir penuh. Cakera yang penuh bukan sahaja melambatkan laman web; bergantung kepada apa yang memenuhinya, ia boleh menghalang pangkalan data daripada menulis, menghalang backup daripada selesai, dan menghalang log daripada mencatat maklumat yang sebenarnya anda perlukan untuk mendiagnosis masalah itu. Ia cenderung menjatuhkan beberapa perkara berasingan serentak.

Tugas backup gagal. Perkara ini wajar mendapat penjelasan tersendiri, kerana ia item yang paling tidak intuitif dalam senarai ini dan, secara senyap, yang paling besar kesannya.

Mengapa Kegagalan Backup Lebih Penting daripada Lonjakan CPU

Lonjakan CPU, dengan sendirinya, biasanya bukan kecemasan. Pelayan dibina untuk menangani turun naik beban; lonjakan yang reda dalam masa beberapa minit selalunya cuma trafik biasa, tugasan berjadual, atau crawler enjin carian yang sedang sibuk pada sesuatu petang. Ia berbaloi dicatat. Ia jarang wajar mendapat perhatian segera sesiapa, dan menganggap setiap lonjakan sebagai segera adalah tepat jenis perkara yang melatih sesuatu pasukan untuk berhenti mempercayai saluran amaran itu sepenuhnya.

Kegagalan tugas backup membawa jenis risiko yang berbeza, dan perbezaannya terletak pada apa yang berlaku seterusnya, bukan apa yang baru sahaja berlaku. Tiada apa-apa pada laman web itu rosak sebaik sahaja backup gagal — itulah sebenarnya bahayanya. Kegagalan itu tidak kelihatan sehingga hari sesuatu yang lain tidak kena dan anda cuba mencapai backup yang, rupa-rupanya, secara senyap sudah lama tidak wujud dalam bentuk yang boleh digunakan selama tempoh tugas itu gagal secara senyap. Lonjakan CPU adalah simptom yang boleh anda lihat serta-merta. Backup yang gagal pula adalah jurang yang hanya anda temui pada saat yang paling teruk, kerana secara definisinya tiada sesiapa memantaunya sehingga ia diperlukan.

Ketidaksimetrian itu — kelihatan-sekarang-tetapi-berisiko-rendah berbanding tidak-kelihatan-sekarang-tetapi-mahal-kemudian — adalah ujian sebenar sama ada sesuatu itu layak berada dalam senarai segera. Ia bukan tentang seberapa mengejutkan sesuatu peristiwa kedengaran dalam fail log. Lonjakan ralat pelayan "500" kelihatan dramatik dan selalunya bukan apa-apa; tugas backup yang secara senyap melaporkan kejayaan tanpa benar-benar menghasilkan fail yang boleh dipulihkan kedengaran seperti perkara pentadbiran biasa, tetapi boleh menjadi pembeza antara sekadar kesulitan sepetang dengan kehilangan pesanan, kandungan, atau rekod pelanggan selama berminggu-minggu.

Apa yang Sepatutnya Berada dalam Ringkasan, Bukan Amaran Segera

Kebanyakan perkara yang dikesan oleh susunan pemantauan wajar kelihatan, tetapi tidak wajar segera: beberapa pautan rosak yang muncul sebagai 404, kemas kini plugin atau pakej yang tersedia, halaman yang dimuat sedikit lebih perlahan daripada biasa, amaran tidak kritikal yang tertimbus dalam fail log, gangguan ringkas masa tindak balas yang reda sebelum sesiapa pun sempat bertindak ke atasnya. Menggabungkan semua ini ke dalam ringkasan harian atau mingguan mengekalkannya kelihatan — seseorang masih perlu melihatnya — tanpa menganggap setiap satu daripadanya sebagai peristiwa yang wajar mengganggu hari seseorang.

Ujiannya mudah: jika tiada apa-apa yang boleh dilakukan seseorang secara berguna dalam sejam akan datang, ia tidak sepatutnya tiba seolah-olah ada.

Menetapkan Ambang Berdasarkan Kesan kepada Perniagaan, Bukan Keanehan Pelayan

Banyak konfigurasi pemantauan lalai memberi amaran ke atas sesuatu kerana ia mudah diukur, bukan kerana ia penting. Peratusan CPU, penggunaan memori, dan masa tindak balas mentah adalah angka yang mudah untuk ditetapkan ambangnya, dan itulah sebabnya ia yang disediakan secara lalai. Tetapi pelayan yang panas sedangkan ia melayan setiap permintaan dengan betul dan pantas bukanlah masalah. Pelayan yang beroperasi selesa tetapi gagal memproses pembayaran adalah masalah yang serius. Angka yang paling mudah digrafkan jarang menjadi angka yang mencerminkan apa yang sebenarnya hilang kepada perniagaan apabila ambang itu dilepasi.

Latihan yang lebih berguna ialah bekerja secara songsang daripada kesan sebenar: apa yang benar-benar akan merugikan perniagaan dari segi wang, kepercayaan, atau data jika ia terbiar tanpa disedari selama sejam? Kemudian tetapkan amaran terus ke atas hasil itu — kadar penyelesaian checkout jatuh kepada sifar, webhook pembayaran gagal berulang kali, tugas backup memulangkan status kegagalan — berbanding ke atas metrik proksi yang mungkin atau mungkin tidak berkait dengannya.

Had yang Jujur

Tiada satu pun daripada ini dapat mencegah setiap kegagalan. Amaran hanya memberitahu anda ada sesuatu yang tidak kena; ia tidak membaikinya, dan amaran yang direka dengan baik tetapi tiada sesiapa tersedia untuk bertindak ke atasnya masih sekadar bunyi bising dengan masa yang lebih baik. Nilai sebenar daripada mereka bentuk amaran dengan betul lebih kecil skopnya tetapi lebih boleh dicapai daripada itu: ia bermakna sesiapa yang tersedia menumpukan perhatian kepada segelintir perkara yang benar-benar memerlukannya, berbanding belajar untuk terus mengabaikan keseluruhan saluran itu.

Di Mana Ini Sesuai dalam Penjagaan Berterusan

Memutuskan apa yang perlu segera memaklumkan seseorang berbanding apa yang boleh menunggu ringkasan mingguan adalah kerja berterusan — ambang yang munasabah semasa sesuatu laman web dilancarkan boleh tidak lagi munasabah apabila ia berkembang, dan seseorang perlu benar-benar membaca ringkasan itu, bukan sekadar menerimanya. Jenis perhatian itulah sebahagian daripada apa yang sepatutnya dirangkumi oleh retainer seperti JagaWeb Care (RM450 sebulan); Care + Changes (RM1,500 sebulan) menambah kuota bulanan untuk perubahan yang selalunya diperlukan susulan sesuatu amaran — pembaharuan yang perlu dikonfigurasikan dengan betul, ambang yang perlu diselaraskan untuk laman web yang sudah berkembang. Kedua-duanya bukan janji bahawa tiada apa-apa akan pernah tidak kena; ia cara untuk memastikan ada seseorang memantau amaran yang benar-benar berlaku.