Pisahkan Pemeriksaan Kesehatan VPN dari Pemeriksaan Kesehatan Aplikasi

Proses tunnel Anda bisa berjalan sementara koneksi terlindungi tidak dapat digunakan, dan halaman web yang gagal bukan bukti bahwa tunnel rusak. Ketika satu probe mewakili semuanya, kebijakan mulai ulang memulai ulang komponen yang salah dan menyebutnya otomasi. Setiap pemeriksaan di bawah menyebutkan lapisan yang diamatinya, tindakan yang dipicu kegagalannya, dan bukti bahwa tindakan itu berhasil. Langkah terakhir mengubah seluruh rangkaian menjadi halaman yang bisa diikuti seseorang pada pukul tiga pagi.

Langkah 1: sebutkan lapisan yang diamati setiap pemeriksaan

Tanyakan apa yang benar-benar bisa dilihat setiap probe sebelum menulis salah satunya. Keaktifan membuktikan daemon berjalan, jabat tangan atau daftar peer membuktikan hubungan itu ada, permintaan yang dirutekan membuktikan pengiriman, dan pencarian membuktikan resolusi. Semuanya gagal dalam urutan itu, dan tidak satu pun menyiratkan yang berikutnya. Pemeriksaan proses hijau di samping tunnel yang mati adalah kasus normal, bukan kontradiksi.

Tuliskan keempat pemeriksaan dalam urutan itu, dengan perintah persis dan keluaran yang diharapkan untuk masing-masing. Probe yang keluarannya tidak dapat Anda nyatakan akan dibaca berbeda oleh setiap operator yang melihat peringatan. Letakkan daftar yang sama di teks peringatan, bukan hanya di runbook, agar orang yang dibangunkan malam hari bertemu lapisan sebelum gejala. Jaga setiap perintah siap disalin di host yang menjalankannya.

Lalu tambahkan pemeriksaan aplikasi sebagai butir kelima yang terpisah. Halaman yang layanan akunnya mati tidak membenarkan memulai ulang tunnel.

Langkah 2: ikat setiap kegagalan ke satu tindakan

Untuk setiap pemeriksaan, putuskan apa yang dimulai ulang, apa yang tetap diblokir, dan apa yang memanggil manusia. Kegagalan lapisan tunnel dapat membenarkan mulai ulang tunnel; kegagalan resolver menunjuk ke integrasi DNS di klien; kegagalan lapisan aplikasi hampir tidak boleh menyentuh tunnel.

Katakan apa yang tidak boleh dilakukan kegagalan, karena default yang berbahaya adalah yang bersifat mengizinkan. Status tidak sehat tidak boleh pernah menjadi izin untuk lalu lintas aplikasi langsung, karena jalur cadangan yang diam-diam melewati tunnel menghapus alasan tunnel itu ada. Persempit juga tindakannya: memulai ulang komponen bersama karena satu tujuan lambat mengubah masalah lokal menjadi masalah seluruh armada. Itu juga menghancurkan bukti yang Anda butuhkan untuk menemukan penyebabnya.

Langkah 3: jaga probe tidak berbahaya dan murah

Gunakan permintaan kecil yang hanya-baca: sumber daya statis, endpoint kesehatan yang melaporkan dependensinya sendiri, atau koneksi TCP ke port yang Anda kendalikan. Hindari kredensial, penjelajahan privat, dan apa pun yang mengubah keadaan pada setiap interval, karena probe yang menulis adalah uji beban sesuai jadwal.

Catat tujuan, ekspektasi rute, dan batas waktu untuk setiap probe. Ekspektasi rute adalah bidang yang orang lewatkan, dan itulah yang memisahkan kegagalan tunnel dari kesalahan perutean saat Anda membaca peringatan nanti. Turunkan interval dan ambang kegagalan dari waktu pemulihan yang Anda janjikan, dan jaga batas waktu lebih pendek daripada interval. Probe yang masih berjalan saat yang berikutnya mulai melaporkan satu kegagalan dua kali dan tampak seperti kedipan.

Langkah 4: rusak setiap lapisan dan lihat probe yang benar menjadi merah

Hentikan proses tunnel dan pastikan pemeriksaan proses gagal sementara DNS mungkin masih menjawab dari cache. Ubah rute dan pastikan permintaan yang dirutekan gagal sementara proses dan jabat tangan tetap sehat. Rusak DNS saja dan pastikan pemeriksaan aplikasi melaporkan resolusi alih-alih galat tunnel. Jika dua probe selalu bergerak bersama, Anda punya lebih sedikit pemeriksaan daripada yang Anda kira.

Uji arah pemulihan dengan disiplin yang sama. Setelah Anda memulihkan lapisan, probe seharusnya bersih tanpa mulai ulang manual, dan tindakan yang dipicu tidak boleh meninggalkan jalan pintas apa pun. Amati satu siklus penuh sebelum memercayai keadaan hijau, karena probe yang hanya bersih saat ditangani tangan menyembunyikan jalur pemulihan yang rusak.

Langkah 5: letakkan runbook di tempat peringatan menunjuk

Satu halaman dengan lima baris membawa seluruh desain: lapisan, perintah, hasil yang diharapkan, tindakan saat gagal, pemilik. Tambahkan satu baris per probe tentang apa yang sengaja tidak diujinya. Baris itulah yang mencegah orang berikutnya menambahkan pemeriksaan keenam yang mengukur segalanya dan tidak membedakan apa pun. Tautkan halaman itu dari teks peringatan, atau tidak ada yang akan membukanya saat insiden berlangsung.

Dalam penerapan kontainer, kondisi dependensi membentuk startup dan tidak lebih. Urutan startup dan kondisi kesehatan Compose dokumentasi menjelaskan bagaimana kesiapan menentukan urutan layanan dimulai; tidak ada yang menegakkan kebijakan keluar setelahnya, dan tidak ada yang gagal tertutup saat tunnel jatuh. Penegakan berkelanjutan memerlukan kebijakan sendiri dan probe sendiri, ditulis di halaman yang sama.

Runbook selesai ketika lapisan yang tepat pulih tanpa ada yang membaca situs yang tidak tersedia sebagai tunnel rusak. Itu menguji dokumennya, bukan tunnelnya.