Bagaimana batas koneksi database hampir me-reboot Mac pelanggan saya

Kami menjalankan armada kecil Mac mini untuk pelanggan. Sebuah daemon di hub mem-poll setiap mesin lewat SSH, mengirim telemetri ke control plane, dan melakukan eskalasi saat mesin diam. Pertama ia menunggu. Lalu ia melakukan power cycle lewat smart plug. Lalu ia memanggil manusia.

Minggu lalu control plane mulai mengembalikan error 500. Tiga belas menit kemudian, daemon menyimpulkan keempat Mac sudah mati dan mencatat power cycle untuk masing-masing. Dua di antaranya milik pelanggan yang membayar. Yang ketiga baru terjual pagi itu.

Yang sebenarnya gagal

Sebuah connection pool database. Control plane berjalan di fungsi serverless yang terhubung ke pooler Postgres, dengan batas lima belas koneksi untuk seluruh proyek. Beberapa fungsi yang masih hangat memakai semuanya, dan setiap route API yang memakai database mulai gagal. Detailnya ada di tulisan terpisah.

Mac-nya baik-baik saja. SSH berjalan. Setiap sesi GUI aktif. Pelanggan yang sedang build di salah satunya tidak merasakan apa pun. Satu-satunya yang rusak adalah sistem yang tugasnya mengetahui apakah Mac-nya rusak.

Bagaimana armada yang sehat terlihat mati

Daemon menyimpan satu timestamp per mesin: terakhir kali poll berhasil. Logika eskalasi membandingkannya dengan waktu sekarang. Poll, cukup wajar, dimulai dengan mengambil daftar mesin dari control plane. Jika pengambilan itu gagal, poll berhenti lebih awal.

Jadi selama gangguan, tidak ada poll yang berjalan dan tidak ada timestamp yang maju. Semua selisih waktu bertambah bersamaan. Logika eskalasi tidak tahu bahwa daemon tidak pernah mencoba. Ia melihat tiga belas menit keheningan dari empat mesin, lalu melakukan tugas yang memang dirancang untuknya.

ladder: Unit 02 unreachable 12m51s → power cycle
ladder: Unit 03 unreachable 12m51s → power cycle
ladder: Unit 04 unreachable 12m51s → power cycle
ladder: Unit 05 unreachable 12m43s → power cycle

Kenapa tidak ada yang reboot

Tidak ada smart plug yang dikonfigurasi. Langkah power cycle mencari plug, tidak menemukannya, lalu lanjut. Setelahnya, keempat mesin menunjukkan uptime enam hari, enam hari, satu hari, dan sekitar satu jam. Tidak ada yang tersentuh.

Itu keberuntungan, bukan desain. Smart plug termasuk rencana untuk gelombang mesin berikutnya. Seandainya sudah terpasang, masalah koneksi database akan memutus listrik ke tiga Mac pelanggan. Salah satunya mungkin sedang build. Tidak ada satu pun yang berbuat salah.

Perbaikannya

Kini daemon mencatat kapan terakhir kali ia berhasil mengambil daftar unit dan benar-benar mencoba menjangkau mesinnya. Logika eskalasi menolak bertindak kecuali itu terjadi baru-baru ini. Ia juga mencatat alasannya: masalahnya di control plane, bukan di unit.

ladder: skipped, no successful unit poll in 14m02s (control plane, not the units)

Baris itu menyatakan persis apa yang ia tolak lakukan dan alasannya. Itulah yang seharusnya dikatakan versi lama sejak awal.

Aturan di baliknya sederhana. Remediasi harus mewajibkan bukti bahwa cek benar-benar berjalan. "Kami mencoba menjangkaunya dan gagal" adalah bukti. "Kami belum mendengar kabarnya" bukan bukti. Karena itu juga yang terlihat saat pendengarnya sendiri mati.

Yang perlu diuji di otomasi Anda

Kami sudah menguji apa yang terjadi saat Mac mati. Kami tidak pernah menguji apa yang terjadi saat sistem yang mengawasi Mac mati. Itu bukan tes yang sama. Dan tes yang kedua itulah yang meraih sakelar listrik.