ผมสร้าง Gitae เพราะเจอคำถามเดิมซ้ำ ๆ ในงานจริง: เว็บไซต์ล่มจริง หรือปัญหาอยู่แค่ฝั่งผม?
การดูจาก browser tab เดียวไม่ใช่วิธีวิเคราะห์ที่ดี หน้าเว็บอาจโหลดไม่ได้เพราะ origin server ล่มจริง แต่ก็อาจเกิดจาก DNS, ปัญหา HTTPS certificate, routing, firewall rule, port ที่ปิดหรือถูก filter, ISP, เส้นทาง VPN, สถานะ browser หรือ local cache อาการที่เห็นเหมือนกัน แต่สิ่งที่ต้องแก้ต่างกันมาก
นี่คือสิ่งที่ผมอยากให้ Gitae ช่วย ไม่ใช่แค่แสดงไฟเขียวหรือไฟแดง แต่ช่วยลดขอบเขตปัญหาให้เหลือ layer ที่ควรตรวจต่อ
ปัญหาจริงที่อยู่หลังคำว่า “เว็บไซต์ล่ม”
Website checker แบบง่ายจำนวนมากตอบเพียงคำถามแคบ ๆ ว่า URL นี้ตอบกลับจากตำแหน่งหนึ่งในเวลาหนึ่งหรือไม่ ข้อมูลนั้นมีประโยชน์ แต่ยังไม่ใช่การหาสาเหตุของ outage
ถ้า DNS ผิด การ restart application ไม่ช่วย ถ้า HTTPS fail เพราะ certificate การแก้ content หน้าเว็บก็ไม่เกี่ยว ถ้า TCP port เข้าไม่ได้ server เองอาจยังทำงานอยู่ และถ้าเว็บเปิดจาก external server ได้แต่เปิดจาก connection ของผมไม่ได้ ปัญหาอาจอยู่บนเส้นทางระหว่าง network ของผมกับปลายทาง ไม่ใช่ application server
เพราะเหตุนี้ผมจึงวาง Gitae บนแนวคิดว่า เว็บไซต์คือ chain ของ dependency และแต่ละ check ให้หลักฐานได้เพียงบางส่วนของ chain นั้น
มุมมองจากภายนอกมีประโยชน์ แต่ไม่ใช่คำตอบสุดท้าย
Gitae รันการตรวจจาก VDS server ของผมใน Moscow และ Helsinki ทำให้มีจุดสังเกตที่อยู่นอกคอมพิวเตอร์และ network ที่ผมเห็นปัญหาครั้งแรก
ถ้าเว็บ fail ใน local แต่ตอบจาก VDS ทั้งสองจุด นั่นเป็นสัญญาณสำคัญว่า origin อย่างน้อยไม่ได้ unreachable สำหรับทุกคน ตอนนั้นผมจะดู local DNS, ISP routing, VPN, browser, firewall หรือปัญหาที่ขึ้นกับ network path มากขึ้น ถ้า remote probe ก็ fail ด้วย เหตุผลที่จะตรวจ server, DNS, certificate, routing หรือปัญหา network ที่กว้างขึ้นก็มีน้ำหนักมากขึ้น
แต่ remote check ไม่ได้ “แม่นกว่า” local check โดยอัตโนมัติ สอง VDS ไม่ได้แทน internet ทั้งหมด เว็บอาจใช้ได้จาก Moscow และ Helsinki แต่มีปัญหาในอีกประเทศ ISP อื่น CDN edge อื่น หรือ network อื่น ผมมองผล remote เป็นจุดสังเกตเพิ่ม ไม่ใช่คำตัดสินระดับโลก
ตอนนี้ Gitae ตรวจอะไรบ้าง
- Website check — ตรวจว่า URL ตอบจาก external server หรือไม่
- SSL check — ตรวจสถานะ HTTPS/TLS certificate และปัญหาที่เกี่ยวกับ certificate
- DNS check, nslookup และ dig — ช่วยดูว่า domain resolve อย่างไรและคืน DNS record อะไร
- Reverse DNS และ IP check — แสดงข้อมูล IP และ PTR/reverse-DNS
- Domain info และ domain age — ให้ข้อมูลพื้นฐานเกี่ยวกับ domain
- Port check — ทดสอบว่า target port เข้าถึงได้จากตำแหน่ง probe หรือไม่
- Find your IP — แสดง public IP ที่ service มองเห็น
- Ping และ traceroute — ให้ network signal เกี่ยวกับ latency, packet loss และเส้นทางไป host
- Hosting check และ CMS detection — แสดงสัญญาณของ infrastructure และ technology เพื่อช่วยระบุระบบ
ผมตั้งใจมองผลเหล่านี้เป็น “สัญญาณ” ไม่ใช่ข้อพิสูจน์ PTR record ไม่ได้พิสูจน์ว่าใครเป็นเจ้าของ server, CMS detection จาก public fingerprint ไม่ได้พิสูจน์ software stack ที่แน่นอน และ port ที่เข้าไม่ได้จาก probe หนึ่งอาจถูก filter ระหว่างทาง แทนที่จะปิดสำหรับทุกคน
ผมอ่านผลอย่างไร
คุณค่าจริงเกิดเมื่อเอาหลาย check มาดูร่วมกัน
ถ้า DNS คืน address ตามที่คาด, HTTPS certificate valid และเว็บตอบจาก VDS ทั้งสองจุด แต่ local ยังเปิดไม่ได้ ผมจะตรวจ local path ให้ลึกก่อนเปลี่ยน server ในทางกลับกัน ถ้า DNS ไม่สม่ำเสมอหรือ remote website check ก็ fail ก็มีเหตุผลมากขึ้นที่จะตรวจฝั่ง infrastructure
Ping และ traceroute ก็ต้องระวัง ICMP อาจถูก filter หรือ rate-limit hop ที่ไม่ตอบใน traceroute ไม่ได้แปลว่า node นั้นเสีย และ host ที่ไม่ตอบ ping ก็อาจให้บริการ HTTPS ได้ตามปกติ เครื่องมือเหล่านี้เพิ่ม context แต่ไม่ได้ให้ diagnosis สุดท้าย
หลักที่ผมยึดคือ check ที่ผ่านเพียงหนึ่งอย่างไม่ได้พิสูจน์ว่าทั้ง system ปกติ และ check ที่ fail เพียงหนึ่งอย่างก็ไม่ได้อธิบาย root cause ด้วยตัวเอง
Availability กับ SEO ไม่ใช่เรื่องเดียวกัน
Availability สำคัญต่อ SEO เช่นกัน แต่ technical outage ไม่เท่ากับ ranking problem Crawling ไม่ใช่ indexing และ indexing ไม่ใช่ traffic
ถ้า crawler เข้าถึง site ไม่ได้เพราะ DNS, network หรือ server error ในเวลานั้น crawler ก็ไม่สามารถ fetch content ที่ได้รับผลกระทบได้สำเร็จ Google ระบุว่า network และ DNS error ระหว่าง crawling ถูกจัดการคล้าย server-side 5xx error และการ unavailable เป็นเวลานานอาจกระทบ crawl และ URL ที่ index แล้ว แต่ไม่ได้หมายความว่า outage สั้นทุกครั้งจะทำให้ SEO เสียโดยอัตโนมัติ และ diagnostic tool ก็พิสูจน์ไม่ได้ว่าการเปลี่ยน traffic ภายหลังเกิดจาก outage นั้นโดยตรง
สำหรับ user เหตุผลง่ายกว่า: ถ้าเข้า site ไม่ได้ ก็ใช้งานไม่ได้ ขึ้นอยู่กับโปรเจกต์ สิ่งนี้อาจหมายถึง session, lead, conversion หรือ revenue ที่หายไป แต่ผลตรวจทางเทคนิคไม่ได้คำนวณ business impact ให้
ลำดับที่ผมอยากใช้เมื่อเว็บ “ล่ม”
- ยืนยันอาการจาก network อื่น อย่าถือว่า local browser แทน internet ทั้งหมด
- ตรวจ DNS ดูว่า domain resolve และ record ถูกต้องตามที่คาดหรือไม่
- ตรวจ HTTPS/TLS ดู certificate validity และ connection error
- ตรวจ port ที่ต้องใช้ ทดสอบการเข้าถึงจากตำแหน่ง probe
- เปรียบเทียบ network signal ใช้ ping และ traceroute เป็นข้อมูลประกอบ
- ดู IP, reverse DNS, hosting และ CMS เพื่อช่วยยืนยันว่ากำลังไปถึง infrastructure ที่คาดไว้
- ค่อยลดขอบเขตการตรวจ ดูว่าหลักฐานชี้ไปที่ application, server, DNS, network path หรือ local environment มากกว่า
นี่ไม่ใช่ incident response protocol ที่ใช้ได้กับทุกกรณี สำหรับผมมันเป็นวิธีลดความผิดพลาดที่อยากกำจัดตั้งแต่แรก: ไปแก้ layer ผิดเพียงเพราะข้อมูลเดียวที่มีคือ “เว็บเปิดไม่ได้”
ใช้จริงก่อน monetization
ตอนนี้ Gitae ยังไม่มี monetization ผมสร้างมันเพื่อใช้เองก่อน เพราะต้องการวิธีเช็กเว็บจากนอกเครื่องของตัวเองอย่างรวดเร็ว แล้วต่อไปยัง DNS, certificate, port และ network diagnostics ได้ทันทีโดยไม่ต้องสลับหลาย tool
เป้าหมายตอนนี้คือทำ diagnostics ให้มีประโยชน์ขึ้น และดูว่าโปรเจกต์จะได้ organic traffic จาก SEO และ demand จริงหรือไม่ ถ้ามี traffic แม้ระดับปานกลาง ผมอยากเพิ่ม automated website monitoring พร้อม instant messenger alert นั่นคือการขยายแนวคิดเดิมจาก manual diagnosis ไปสู่ detection: รู้ว่า service unavailable แล้วให้ข้อมูลพอที่ owner จะเริ่มตรวจได้เร็ว
แก่นของแนวคิดยังคงเรียบง่าย
“Up” และ “down” เป็นอาการ ไม่ใช่คำอธิบาย
DNS, HTTPS/TLS, routing, port, hosting, application และ network ของ user เอง ล้วนทำให้เกิด availability problem ที่ดูเหมือนง่ายได้ Gitae ไม่ได้หา root cause ทุกอย่างแบบอัตโนมัติ และ external server สองจุดก็ไม่ได้บอกว่า internet ทั้งหมดเห็นอะไร แต่สามารถรวม signal อิสระหลายอย่างไว้ในที่เดียว
นี่คือ tool ที่ผมต้องการ: ช่วยเปลี่ยนจาก “เว็บไซต์เปิดไม่ได้” ไปสู่คำถามที่มีประโยชน์กว่าอย่างมากว่า “ต่อไปควรตรวจ layer ไหน?”