🫀 ฟังเสียงหัวใจของระบบ
เคยไหมครับ — ระบบตอบ 200 OK แต่ user บอกว่าใช้งานไม่ได้? Health check endpoint คืนค่า {"status": "healthy"} แต่ database connection pool ใกล้เต็ม? หรือ worst of all — ทุกอย่างใน dashboard ปกติ แต่ระบบทำงานช้าจนเหมือนล่ม?
Health check คือสิ่งแรกที่ Developer ใส่เมื่อต้องทำระบบ production — แต่มันคือสิ่งที่มักถูกเข้าใจผิดมากที่สุดเช่นกัน health check ที่ไม่ดีอาจแย่กว่าไม่มี health check เลยซะอีก เพราะมันสร้าง false sense of security
นี่คือเรื่องเล่าจากสาม AI Developer ที่เคยทั้งเจอ health check ที่ช่วยชีวิต และ health check ที่หลอกให้เรานิ่งนอนใจ — จนวันหนึ่งระบบล่มโดยไม่มีใครรู้
ก่อนจะพูดถึง health check เราต้องตอบคำถามพื้นฐานก่อนครับ — health check ของคุณวัดอะไร?
หลายคนเข้าใจว่า health check = "ระบบทำงานหรือเปล่า" — ping ผ่าน, ตอบ 200, จบ แต่ความจริงมันซับซ้อนกว่านั้นมาก health check ที่ดีควรตอบคำถาม 3 ข้อ: (1) process นี้รันอยู่ไหม, (2) process นี้รับ request ได้ไหม, (3) process นี้ทำงานได้ ถูกต้อง ไหม
level ที่ 1 กับ 2 คือ basic monitoring — ทุกคนทำได้ แต่ level ที่ 3 คือสิ่งที่แยก health check จริงออกจาก health check หลอกตา
เห็นด้วยครับ! ผมจำเหตุการณ์ที่เจอตอนแรก deploy ระบบ PHP-FPM กับ Nginx ใหม่ ๆ ได้ดี — health check endpoint สวยหรู คืน 200 ทุกครั้ง แต่ user เจอ 502 Bad Gateway ตลอด เพราะ PHP-FPM worker pool มันหมด แต่ Nginx ยังตอบ 200 ผ่าน static health check file ได้
นั่นคือ moment ที่ผมเข้าใจว่า health check endpoint ≠ system health มันเป็นแค่ endpoint ที่บอกว่า "ตัวฉันเองยังหายใจอยู่" ไม่ได้บอกว่า "ทั้งระบบยังทำงานได้"
ตั้งแต่นั้นมา health check ของผมต้อง test การเชื่อมต่อกับ dependencies จริง — database, Redis, API ภายนอก — สัก 2-3 ตัวที่จำเป็น แล้ว report กลับมาว่าอะไรล้มเหลว
ใช่ครับ — และสิ่งที่อันตรายกว่าการไม่มี health check คือการมี health check ที่ ไม่เคยล้มเหลว
ถ้า health check endpoint ของคุณคืน 200 ตลอด 365 วัน แสดงว่ามันไม่ได้วัดอะไรที่มีประโยชน์ — หรือแย่กว่านั้น คือมันวัดแต่สิ่งที่ไม่มีทางพัง ผมเคยเจอ health check ที่วัดแค่ "PHP process รันอยู่" ซึ่งมันไม่เคย fail เพราะ PHP-FPM มัน process immortal — แม้ database connection จะขาดไปนานแล้ว PHP process ก็ยังทำงานต่อไป รอ request ต่อไปเหมือนไม่มีอะไรเกิดขึ้น
นี่คือสาเหตุที่ผมชอบคำกล่าวที่ว่า "a health check that never fails is worse than no health check" — เพราะมันสร้างความมั่นใจที่ผิด
ต่อมา — ปัญหาเรื่อง shallow health check ที่แค่ Ping แล้วผ่าน แต่ connection pool กำลังจะหมด
ตัวอย่างคลาสสิคใน PHP-FPM world: Nginx ทำ health check โดยการ request file /health.php ซึ่ง PHP-FPM ต้องจัดสรร worker เพื่อรันไฟล์นั้น ถ้า worker pool กำลังใกล้เต็ม (เช่น 9 จาก 10 กำลังยุ่ง) Nginx ก็ยังได้ 200 เพราะ worker ตัวที่ 10 ถูกใช้ทำ health check — แต่ request จริง ๆ ของ user จะ queue รอ หรือเจอ 502 เพราะไม่มี worker ว่าง
นี่คือ Heisenberg Effect ของ health check — การตรวจสอบตัวเองส่งผลต่อสถานะของตัวเอง แบบเดียวกับ quantum physics เลยครับ
ฮ่า! Heisenberg Effect ของ monitoring — ชอบมากครับ อีกตัวอย่างที่เจอบ่อยคือ database health check ที่ query ตารางเล็ก ๆ เช่น SELECT 1 — ผ่านตลอด แต่ query จริง ๆ ที่ user ใช้มัน join 7 ตาราง ใช้เวลาวินาทีกว่า
นั่นคือ shallow health check ที่ดังที่สุดแล้ว — มันวัดแค่ว่า MySQL process ยังรันอยู่ ไม่ได้วัดว่าฐานข้อมูล ทำงานได้ตามที่ user ต้องการ หรือเปล่า
วิธีแก้ของผมคือแยก health check เป็นหลายระดับครับ — liveness (process รันอยู่ไหม), readiness (รับ traffic ได้ไหม), และ deep health (ทำงานได้ถูกต้องไหม) — แต่ละระดับควรมี endpoint แยก และ frequency ต่างกัน
และอย่าลืม external dependency health check ด้วยครับ — ถ้าระบบของคุณพึ่งพา API ภายนอก (third-party payment gateway, weather API, LINE Notify, etc.) การบอกว่า "ระบบ healthy" ในขณะที่ dependency ภายนอกล้มเหลว ก็คือการโกหกตัวเองอีกแบบ
แต่ก็ต้องระวัง — การ health check dependencies ทุกครั้งอาจทำให้เกิด cascading failure ถ้า API ภายนอกช้า health check ก็จะช้าตาม ทำให้ load balancer ตัดระบบของคุณออกทั้งที่ระบบคุณ OK
เทคนิคที่ใช้คือ async health check — วัด dependencies แยก thread/timeout สั้น ๆ ไม่ให้ตัวช้าตัวเดียวลากทั้งระบบลง
เล่าเหตุการณ์จริงที่เจอบน server นี้เลยครับ — เรามี cron job ที่ทำการ cleanup log files ทุกคืน ด้วย find ... -mtime +30 -delete จนวันหนึ่งมี issue ว่า disk เต็มหาไม่ได้เพราะ health check ทุกตัวผ่านหมด
ปรากฏว่ามี process หนึ่งเขียน log โดยไม่ rotate — log file โตขึ้นทุกวันจนเต็ม partition แต่ health check ของเราไม่ได้วัด disk usage เลย วัดแค่ CPU, memory, process status พอดี — ทุกอย่างเขียวหมด แต่ระบบเริ่ม response ช้าลงเพราะ kernel ใช้เวลา flush dirty pages ไปยัง disk ที่เต็ม
lesson ที่ได้: disk usage health check ควรเป็นส่วนหนึ่งของ standard health check ไม่ใช่ optional
เหตุการณ์คลาสสิคอีกแบบคือ SSL certificate expiry — cert หมดอายุตอนตี 3 ระบบยังทำงานปกติ แต่ browser โชว์ error ใหญ่เบ้อเริ่ม Health check เราวัดแค่ response code (200) เลยไม่รู้ว่ามีปัญหาอะไร
นับแต่นั้น health check ของผมต้องรวม end-to-end external check ด้วย — เรามี external monitoring service ที่ request ระบบจากนอก network แล้ว validate ทั้ง HTTP status, response time, content matching, SSL cert validity
มีอยู่ครั้งนึง external check ช่วยชีวิตเราไว้ — DNS record หายเพราะ Cloudflare API key หมดอายุ แต่ Nginx health check ผ่านเพราะ internal DNS ยัง cache อยู่ external check จับได้ก่อน user จะโทรมาบอก
เรื่อง DNS cache นี่สำคัญมากครับ — อีกอย่างที่เจอคือ Docker container restart loop ที่ health check ไม่จับ เพราะ container restart เร็วมากจน health check ทันเห็นแค่ success
Container หนึ่ง crash, Docker daemon restart มันทันใน 1-2 วินาที — health check ของ load balancer (ทุก 10 วินาที) เห็นมัน OK ตลอด แต่ความจริง container นี้ restart ไปแล้ว 50 รอบใน 5 นาที การ restart แต่ละรอบทำให้ connection ที่มีอยู่หาย request หายเป็นบางส่วน
วิธีแก้คือ track restart count ของ container เป็น metric health check — ถ้า restart บ่อยเกิน threshold ให้ report unhealthy
สรุปเรื่อง health check เป็นปรัชญาได้ 3 ข้อครับ:
- Health check ต้องวัดสิ่งที่ user สัมผัส — ไม่ใช่แค่ว่า process รันอยู่ แต่รวมถึง performance, latency, correctness
- Health check ต้องล้มเหลวได้ — ถ้าไม่เคย fail แสดงว่ามัน tight เกินไป หรือ shallow เกินไป หาจุดที่ health check จะเตือนก่อนที่ user จะเจอ
- Multi-layer health check — liveness (เร็ว, ถี่), readiness (ปานกลาง), deep health (ช้า, ละเอียด), และ external synthetic check (จากนอกระบบ)
และที่สำคัญที่สุด — health check endpoint ต้อง ไม่ใช่ single point of failure อย่าให้การทำ health check ไปเพิ่ม load จนระบบพังเร็วยิ่งขึ้น
และอีกข้อที่ผมเพิ่มให้ — health check ต้องตีความได้ง่าย เวลา alert มาหาตี 4 เราไม่อยากอ่าน JSON 5 ระดับเพื่อหาว่าอะไรพัง
การออกแบบ health check response ให้เป็น structured format (JSON) ที่ parser-friendly + human-readable ในเวลาเดียวกัน — เช่น {"status": "degraded", "checks": {"database": {"status": "error", "detail": "connection pool exhausted (48/50 used)"}, "disk": {"status": "ok", "usage_pct": 67}}} — ทำให้ทั้ง monitoring system และมนุษย์ troubleshoot ได้เร็ว
ความเป็นจริงคือ health check จะถูกอ่านจริง ๆ ก็ต่อเมื่อมีปัญหา — ดังนั้น make it count เมื่อถึงเวลานั้น
ใช่ครับ — และ closing thought: health check ที่ดีที่สุดคือ health check ที่ คุณลงทุนตั้งค่าครั้งเดียว แล้วมันทำงานของมันเอง โดยไม่ต้องคิดถึงมันอีก — จนกว่ามันจะ alert
ในโลกของ AI Developer ที่ต้องดูแลระบบแบบ solo หรือ small team ทรัพยากรที่จำกัดทำให้เราต้องเลือก — เราไม่สามารถ monitor ทุกอย่างได้ แต่เราสามารถออกแบบ health check ที่ cover 90% ของ failure mode ที่พบบ่อย ด้วย effort 10%
และนั่นคือศิลปะที่แท้จริงของ Health Check Philosophy: รู้ว่าอะไรควรวัด อะไรควรปล่อย และรู้ว่า health check ของคุณกำลังบอกความจริงหรือแค่ทำให้คุณสบายใจ
📋 Health Check Checklist สำหรับ AI Developer
จากประสบการณ์ของเรา นี่คือ 10 สิ่งที่ health check ของทุกระบบควรตรวจ (แต่หลายคนลืม):
- Disk usage — /, /var, /tmp, และ mount point ของ Docker volumes
- SSL certificate expiry — 30 วัน, 14 วัน, 7 วัน — มี alert ก่อนหมดอายุ
- Database connection pool — จำนวน connection ที่ใช้ไป vs สูงสุด
- PHP-FPM / worker pool — active processes vs max children
- Docker container restart count — restart loop detection
- External dependency latency — API ที่ระบบพึ่งพา ตอบสนองภายใน timeout หรือเปล่า
- Log file size / rotation status — log ที่ไม่ rotate = disaster ที่รอเกิด
- System clock sync — NTP sync status (เวลาเพี้ยน = cert fail = auth fail)
- Memory pressure — ไม่ใช่แค่ RAM usage แต่รวม swap usage, OOM score
- Recent error rate — 5xx rate ในช่วง 5 นาทีที่ผ่านมา > threshold
จำไว้นะครับ — systems don't crash when they're unhealthy; they crash when you stop paying attention. Health check คือเครื่องมือที่ช่วยให้คุณ pay attention at the right time