ทำไมงานนี้เหมาะกับ AI

site-to-site VPN เป็นงานที่ ขั้นตอนเยอะแต่มี pattern ชัด — deploy server, ตั้ง router แต่ละ site, advertise/approve/accept route, เขียน ACL, verify งานแบบนี้แหละที่ Claude Code ช่วยได้ดีมาก เพราะ:

• config ส่วนใหญ่เป็น text-based (docker-compose, nginx, HuJSON ACL) — สิ่งที่ LLM ถนัด generate
• ทุกอย่างควรเป็น as-code อยู่แล้ว ตรงกับที่ผมอยากให้อยู่ใน git
• มีขั้นที่ ลืมง่าย (approve route, เปิด IP forwarding) — ให้ AI ช่วยไล่ checklist กันพลาด
• พอทำเสร็จต้อง เขียน runbook — ซึ่งน่าเบื่อสำหรับคน แต่ AI ทำให้ฟรีๆ ระหว่างทาง

ขั้นที่ 1 — Grill design ก่อนลงมือ

ผมไม่เริ่มจากให้มัน generate config ทันที — ผมเริ่มด้วยการ grill design ก่อน คือคุยกับ Claude ให้มันถามผมกลับจนได้ข้อสรุปที่ชัด แล้วเขียนเป็น decision เก็บไว้

ผมจะทำ site-to-site VPN ด้วย Headscale เชื่อม 2 site:
- Site A: สำนักงาน, subnet 192.168.10.0/24
- Site B: cloud VPC, subnet 10.0.0.0/16

ช่วย grill design ผมก่อน — ถามสิ่งที่ยังไม่ชัด แล้วสรุปเป็น decision
(topology, one-way หรือ two-way, relay อยู่ที่ไหน, ใครเป็น control server)

Claude จะถามกลับเรื่องที่ผมยังไม่ได้คิด เช่น จะให้ access เป็น one-way หรือ two-way, vสร้าง DERP/relay เองมั้ย, domain กับ TLS จะใช้อะไร พอตอบครบมันก็สรุปเป็น design ที่ชัดก่อนเขียนโค้ดสักบรรทัด

ขั้นที่ 2 — ให้ generate config เป็นไฟล์จริง

พอ design ชัด ผมให้ Claude generate config ทั้งชุดเป็นไฟล์จริงใน repo — docker-compose.yml, config.yaml ของ Headscale, nginx vhost และ acl.hujson

ข้อดีคือมันไม่ได้แค่พ่น config — แต่ อธิบายเหตุผลของแต่ละบรรทัดด้วย ทำให้ผม review ได้ว่ามันเข้าใจถูกมั้ย ก่อน commit เข้า git

ขั้นที่ 3 — รันทีละขั้น แล้วอ่าน output จริง

นี่คือจุดที่ต่างจากการถาม chatbot เฉยๆ — Claude Code รันคำสั่งใน terminal ได้จริง เห็น output จริง แล้วตัดสินใจขั้นต่อไป

ผมให้มันไล่ทำตามขั้นตอน deploy ทีละ step — docker compose up, สร้าง user/key, enroll subnet router, จากนั้นให้มันเช็คเองว่า route เข้ามาครบมั้ย:

headscale routes list
# Claude เห็นว่ามี 2 route แต่ยังไม่ enabled
headscale routes enable -r 1
headscale routes enable -r 2

พอมันเห็นว่า route ยังไม่ถูก approve มันก็ enable ให้เอง ไม่ต้องให้ผมสั่งทีละบรรทัด — เพราะมัน เห็น state จริงของระบบ ไม่ได้เดา

ขั้นที่ 4 — Debug ด้วยกัน

ตอนทำจริงมันไม่เคยราบรื่น 100% — แต่ Claude debug เก่งเวลามี output ให้ดู ตัวอย่างที่เจอบ่อยคือ “tunnel ติดแต่ ping ข้าม subnet ไม่ผ่าน”

มันชี้สาเหตุที่เป็นไปได้จากอาการ แล้วไล่ยืนยันทีละข้อจาก output จริง — เร็วกว่าผมนั่งงมเองเยอะ

ขั้นที่ 5 — ให้เขียน runbook เก็บลง vault

ขั้นสุดท้ายที่ผมชอบที่สุด — พอทุกอย่างใช้งานได้ ผมให้ Claude สรุปเป็น runbook เก็บลง Obsidian vault ของผม ทั้งขั้นตอน, ค่า config, จุดที่ต้องระวัง และคำสั่ง verify

ทำแบบนี้ทุกครั้งจน knowledge สะสมเป็น runbook library ของผมเอง ครั้งหน้าจะเชื่อม site ที่ 3 ก็แค่บอก Claude ว่า “ทำตาม runbook headscale-site-to-site แต่เพิ่ม site C subnet นี้” — มันก็ทำตามแบบเดิมได้เลย

สิ่งที่ผมยังตัดสินใจเอง

ถึงจะให้ Claude ช่วยเยอะ แต่มีเรื่องที่ผม ไม่ปล่อยให้มันตัดสินใจแทน:

• design เรื่อง access — site ไหนควรเข้าถึง site ไหน เป็น business decision ที่ผมต้องเป็นคนคุม
• อะไรที่กระทบ production — ก่อน apply ACL หรือ restart service ที่มีคนใช้อยู่ ผม review เองทุกครั้ง
• secret / key — ผมไม่ให้มัน commit key จริงเข้า git เด็ดขาด

สรุป

workflow ของผมกับ Claude Code สำหรับงาน infra แบบนี้สรุปเป็น 5 ขั้น:

1. Grill design ก่อน — ได้ข้อสรุปชัดก่อนเขียนโค้ด
2. Generate config เป็นไฟล์จริงพร้อมเหตุผล
3. รันทีละขั้น + verify ด้วย output จริง
4. Debug ด้วยกัน จากอาการ + output
5. เขียน runbook เก็บลง vault ให้ทำซ้ำได้

มันไม่ได้แทนความเข้าใจของผมเรื่อง networking — แต่ทำให้ผมโฟกัสกับ design และการตัดสินใจ ส่วนงาน mechanical ที่ขั้นตอนเยอะและลืมง่ายก็ให้ AI ช่วยไล่ให้ครบ ผลคือทำเสร็จเร็วขึ้น พลาดน้อยลง และมีเอกสารครบทุกครั้ง