นี่คือชุดข้อสอบและประเด็นสัมภาษณ์เชิงลึกชุดที่ 2 อีก 20 ข้อ (ข้อ 21 – 40) สำหรับเตรียมตัวสัมภาษณ์ Data Center Operations (DCO) ในส่วนของ Role-Related Knowledge (RRK) โดยยังคงโครงสร้างที่เข้าใจง่าย ปูพื้นฐานศัพท์และหลักการทำงานเชิงลึก พร้อมขั้นตอนการตอบและคำสั่งจริงในระดับวิศวกรรม

หมวดที่ 1: Hardware & Operating Systems (ระบบฮาร์ดแวร์และระบบปฏิบัติการ)

ข้อที่ 21: PCIe AER (Advanced Error Reporting) และ PCIe Degraded Link Speed

• คำถามสัมภาษณ์: “หากการ์ด Network หรือ GPU ความเร็วสูงที่เสียบบนสล็อต PCIe ทำงานได้ช้ากว่าสเปกครึ่งหนึ่ง หรือระบบรายงานข้อผิดพลาด PCIe AER คุณมีวิธีตรวจสอบและแก้ปัญหาอย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • สล็อต PCIe สื่อสารข้อมูลเป็นช่องทางขนานเรียกว่า Lanes (เช่น x4, x8, x16) และมีมาตรฐานความเร็วต่างกันตามรุ่น (Gen 3, Gen 4, Gen 5)
  • Link Training: เมื่อเปิดเครื่อง ซีพียูและการ์ดจะเจรจาตกลงความเร็วและจำนวนเลนที่ดีที่สุด หากหน้าสัมผัสของขาทองแดงสกปรก มีฝุ่น หรือสัญญาณรบกวน ระบบจะลดสเปกลงอัตโนมัติ (เช่น จาก Gen 4 x16 เหลือเพียง Gen 4 x8 หรือ Gen 1 x16) เพื่อให้ยังสื่อสารได้โดยไม่ล่ม
  • PCIe AER: เป็นฟีเจอร์ระดับฮาร์ดแวร์ที่ตรวจจับว่ามีข้อมูลบนบัส PCIe เสียหายหรือไม่ โดยแบ่งเป็น Correctable (ซ่อมได้) และ Uncorrectable (ทำให้ระบบค้างหรือการ์ดหลุด)
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจการทำงานของบัส PCIe และการใช้คำสั่งระดับระบบปฏิบัติการเพื่อวิเคราะห์สัญญาณทางกายภาพ
• แนวทางการตอบแบบมืออาชีพ:
  1. ตรวจสอบความกว้างของบัสและความเร็ว: ใช้คำสั่ง lspci -vvv -s <pci_address> แล้วดูหัวข้อ LnkCap (ความสามารถสูงสุดของการ์ด) เทียบกับ LnkSta (สถานะจริงที่วิ่งอยู่) เช่น:
     • หาก LnkCap: Speed 16GT/s, Width x16 แต่ LnkSta: Speed 2.5GT/s, Width x4 แสดงว่าเกิดปัญหา Hardware Link Degradation
  2. ตรวจสอบประวัติ AER: ค้นหา Error Log ในระดับเคอร์เนลด้วย dmesg -T | grep -i aer มองหารายการ Bad TLP, Bad DLLP, หรือ Replay Timer Timeout
  3. ขั้นตอนการแก้ไข:
     • สั่ง Cordon/Drain เครื่อง
     • ปิดเครื่อง ถอดการ์ดออกมาตรวจดูคราบออกไซด์หรือฝุ่นที่ช่องขาทองแดง (Gold Fingers) และทำความสะอาดด้วยน้ำยาทำความสะอาดหน้าสัมผัส (Contact Cleaner)
     • ตรวจสอบว่าขันยึดการ์ดลงใน Riser Card แน่นสนิทและไม่มีอาการเอียง (Sagging) ก่อนเสียบกลับ

ข้อที่ 22: ข้อมูล DMI/SMBIOS และการระบุพิกัดชิ้นส่วนฮาร์ดแวร์ผ่าน dmidecode

• คำถามสัมภาษณ์: “หากต้องการทราบยี่ห้อ โมเดล ซีเรียลนัมเบอร์ และสล็อตที่ติดตั้งของแรมทุกแถวในเซิร์ฟเวอร์โดยไม่ต้องเปิดฝาเครื่อง คุณจะใช้คำสั่งใด และมีข้อจำกัดอะไรบ้าง?”
• ปูพื้นฐานและหลักการทำงาน:
  • SMBIOS (System Management BIOS) / DMI (Desktop Management Interface): เป็นมาตรฐานที่เมนบอร์ดและ BIOS/UEFI บันทึกตารางผังรายละเอียดของอุปกรณ์ฮาร์ดแวร์ทั้งหมดในเครื่องเอาไว้ในหน่วยความจำตอนบูต
  • ข้อมูลชุดนี้ทำหน้าที่เป็นเหมือน “บัตรประชาชน” ของชิ้นส่วนภายในเครื่อง
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเชี่ยวชาญในการสำรวจฮาร์ดแวร์ (Inventory Audit) จากระยะไกลผ่านระบบปฏิบัติการ
• แนวทางการตอบแบบมืออาชีพ:
  1. การใช้งานคำสั่ง: ใช้คำสั่ง dmidecode -t memory (หรือระบุประเภทอื่นๆ เช่น -t processor, -t baseboard, -t slot)
  2. ข้อมูลที่นำมาวิเคราะห์:
     • Locator / Bank Locator: บ่งบอกตำแหน่งทางกายภาพที่สกรีนอยู่บนแผงวงจร (เช่น DIMM_A0, CPU1_DIMM1) ช่วยให้เวลาช่างหน้างานไปเปลี่ยน ไม่หยิบสลับแถว
     • Size, Type, Speed: ตรวจดูว่าขนาดและบัสของแรมวิ่งเต็มตามสเปกหรือไม่
     • Serial Number และ Part Number: นำไปเช็กสต็อกอะไหล่สำรอง (Spare Part) ว่ามีรุ่นเดียวกันพร้อมเปลี่ยนหรือไม่
  3. ข้อจำกัด: ข้อมูล DMI อ่านมาจากตารางที่ BIOS จัดทำขึ้น หากชิ้นส่วนใดเสียถาวรจน BIOS มองไม่เห็นตั้งแต่ขั้นตอน POST ค่าใน dmidecode อาจจะว่างเปล่าหรือแสดงเป็น “Not Installed” จึงต้องตรวจควบคู่กับ Log ของ BMC เสมอ

ข้อที่ 23: กลไก Linux OOM (Out Of Memory) Killer vs Hardware Memory Fault

• คำถามสัมภาษณ์: “แอปพลิเคชันบนเซิร์ฟเวอร์เกิดดับกะทันหัน คุณมีวิธีแยกแยะอย่างไรว่าเกิดจากซอฟต์แวร์ถูก Linux OOM Killer ปลิดชีพ หรือเกิดจากฮาร์ดแวร์หน่วยความจำเสีย (Hardware Fault)?”
• ปูพื้นฐานและหลักการทำงาน:
  • Linux OOM Killer: เป็นกลไกซอฟต์แวร์ เมื่อแอปพลิเคชันกินแรมจนหมดเกลี้ยง (รวมถึง Swap Space) ระบบปฏิบัติการจะตกอยู่ในภาวะวิกฤต เคอร์เนลจึงมีฟังก์ชันคำนวณคะแนน oom_score เพื่อเลือกสังหารโปรเซสที่กินแรมมากที่สุดทิ้งทันที เพื่อรักษาชีวิตของระบบปฏิบัติการส่วนรวมไว้
  • Hardware Memory Fault: เป็นความเสียหายทางกายภาพ เมื่อข้อมูลในแรมบิตเพี้ยนจนแก้ไม่ได้ ซีพียูจะสั่งหยุดการทำงาน หรือหากโปรเซสพยายามอ่านแรมตำแหน่งที่เสียหาย เคอร์เนลจะส่งสัญญาณ SIGBUS ไปหยุดโปรเซสนั้น
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ทักษะการอ่าน Log และความสามารถในการระบุว่าต้องส่งเคสให้ทีมนักพัฒนาซอฟต์แวร์ หรือทีมวิศวกรซ่อมบำรุงฮาร์ดแวร์
• แนวทางการตอบแบบมืออาชีพ:
  1. การตรวจสอบ OOM Killer:
     • ตรวจสอบไฟล์ระบบด้วยคำสั่ง: journalctl -k -g "Out of memory" หรือ dmesg -T | grep -i oom
     • หากเป็น OOM Killer จะเห็นตารางการจัดสรรแรมและข้อความชัดเจน เช่น: Killed process 1234 (mysqld) total-vm:..., anon-rss:...
     • แปลผล: นี่คือปัญหาด้าน Software Workload / Memory Leak ฮาร์ดแวร์แรมไม่ได้เสียหาย
  2. การตรวจสอบ Memory Hardware Fault:
     • ตรวจสอบด้วย dmesg -T | grep -iE 'mce|hardware error|edac'
     • หากแรมเสีย จะพบข้อความประเภท EDAC MC0: UE (Uncorrectable Error) หรือพบสัญญาณ SIGBUS (Bus error) พร้อม Physical Memory Address
     • แปลผล: แถวแรมชำรุดทางกายภาพ ต้องจัดตารางซ่อมบำรุงเพื่อเปลี่ยนชิ้นส่วน

ข้อที่ 24: RAID Levels และพฤติกรรม Rebuild I/O Impact

• คำถามสัมภาษณ์: “ทำไมในศูนย์ข้อมูลขนาดใหญ่จึงหลีกเลี่ยงการใช้ RAID 5 กับฮาร์ดดิสก์ความจุสูง และเมื่อดิสก์ในชุด RAID ลูกหนึ่งเสียแล้วเปลี่ยนลูกใหม่เข้าไป จะเกิดผลกระทบใดต่อระบบ?”
• ปูพื้นฐานและหลักการทำงาน:
  • RAID 5: เป็นระบบรวมฮาร์ดดิสก์ที่ใช้ดิสก์อย่างน้อย 3 ลูก โดยกระจาย Parity (ข้อมูลตรวจสอบความถูกต้อง) ไปทุกไดรฟ์ สามารถทนต่อการเสียของดิสก์ได้พร้อมกันเพียง 1 ลูก
  • Rebuild Process: เมื่อเปลี่ยนดิสก์ลูกใหม่เข้าไป ระบบต้องอ่านข้อมูลจากดิสก์ทุกลูกที่เหลืออยู่ทั้งอาเรย์ 100% เพื่อนำมาคำนวณและเขียนข้อมูลคืนกลับลงไปในดิสก์ลูกใหม่
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องความเสี่ยงของ URE (Unrecoverable Read Error) และการลดทอนของ I/O Performance ในช่วงวิกฤต
• แนวทางการตอบแบบมืออาชีพ:
  1. ความเสี่ยงของ RAID 5 กับดิสก์ความจุสูง (เช่น 8TB+):
     • ดิสก์เชิงกลมีโอกาสเกิดข้อผิดพลาดในการอ่านข้อมูลตามธรรมชาติ (เช่น 1 บิตในทุก 10^14 บิต) เรียกว่า URE
     • ระหว่างที่ระบบกำลัง Rebuild ข้อมูลดิสก์ลูกใหม่ ต้องอ่านข้อมูลเดิมหลายสิบล้านล้านบิต หากไปเจอจุดที่อ่านไม่ออกเพียงจุดเดียว กระบวนการ Rebuild จะล้มเหลว และทำให้ข้อมูลทั้งชุด RAID พังทลายทันที
     • ปัจจุบันจึงนิยมขยับไปใช้ RAID 6 (ทนดิสก์เสียพร้อมกันได้ 2 ลูก) หรือใช้ระบบ Distributed Erasure Coding ในระดับซอฟต์แวร์แทน
  2. ผลกระทบเรื่อง I/O Impact:
     • ในระหว่าง Rebuild ประสิทธิภาพ Read/Write ของเซิร์ฟเวอร์จะตกลงอย่างมหาศาล เพราะหัวอ่านดิสก์ต้องแบ่งกำลังไปรันภาระงาน Rebuild อย่างต่อเนื่องเป็นเวลาหลายชั่วโมงหรือหลายวัน
     • วิศวกรต้องเข้าไปปรับค่าการจัดสรรลำดับความสำคัญ (Rebuild Priority / I/O Throttle) บนคอนโทรลเลอร์ เพื่อไม่ให้กระทบต่อทราฟฟิกของผู้ใช้งานจริงจนเกิด Latency Spike

ข้อที่ 25: ระบบส่งไฟล์บันทึกข้อผิดพลาด Kdump และ Crash Kernel

• คำถามสัมภาษณ์: “Kdump คืออะไร ทำงานอย่างไร และมีประโยชน์อย่างไรเมื่อเกิดปัญหาประเภทวิเคราะห์หาสาเหตุไม่ได้ (Heisenbug / Silent Panic)?”
• ปูพื้นฐานและหลักการทำงาน:
  • เมื่อเซิร์ฟเวอร์เกิด Kernel Panic ข้อมูลโปรแกรมและสถานะทั้งหมดที่ค้างอยู่ในแรมจะหายไปทันทีเมื่อเครื่องถูกรีบูต
  • ในสภาวะ Panic ตัวเคอร์เนลหลักได้รับความเสียหายไปแล้ว จึงไม่สามารถสั่งเขียนไฟล์ลงในฮาร์ดดิสก์หรือส่งออกเครือข่ายได้อย่างปลอดภัย เพราะโค้ดของตัวเองอาจจะพังอยู่
  • Kdump: เป็นกลไกความปลอดภัยที่อาศัยฟังก์ชัน kexec โดยระบบจะทำการ “แบ่งกันแรมผืนเล็กๆ เอาไว้ล่วงหน้า” เพื่อเก็บเคอร์เนลสำรองขนาดจิ๋ว (Capture Kernel) ไว้โดยเฉพาะ
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจการกู้ข้อมูลทางนิติวิทยาศาสตร์ของระบบปฏิบัติการ (Post-mortem Kernel Debugging)
• แนวทางการตอบแบบมืออาชีพ:
  1. กลไกการทำงาน:
     • เมื่อเคอร์เนลหลักเกิด Panic ซีพียูจะไม่ทำการชัตดาวน์ แต่จะกระโดดข้ามไปเรียกใช้งาน Capture Kernel ที่ถูกล็อกไว้ในแรมส่วนที่ปลอดภัยทันที โดยไม่ต้องผ่านการรีเซ็ตฮาร์ดแวร์ของบอร์ด (Bypass BIOS/POST)
     • Capture Kernel ขนาดจิ๋วจะทำการคัดลอกหน่วยความจำทั้งหมดของเคอร์เนลหลักที่เพิ่งตายไป บันทึกลงเป็นไฟล์ภาพขนาดยักษ์เรียกว่า vmcore เก็บไว้ในดิสก์ที่ปลอดภัย (เช่น /var/crash/) จากนั้นจึงสั่งรีบูตเครื่อง
  2. ประโยชน์:
     • วิศวกรสามารถนำไฟล์ vmcore ไปเปิดวิเคราะห์ด้วยเครื่องมือ crash ร่วมกับสัญลักษณ์ของเคอร์เนล (vmlinux-debuginfo) เพื่อตรวจดู Backtrace ของทุก Core และดูค่าตัวแปรในเสี้ยววินาทีก่อนที่เครื่องจะตาย ช่วยให้แก้บั๊กที่หาจุดจบไม่ได้ได้อย่างแม่นยำ

ข้อที่ 26: วงจรตัวควบคุมการกระจายสัญญาณนาฬิกา (Hardware Clock & NTP Drift)

• คำถามสัมภาษณ์: “หากเซิร์ฟเวอร์ในคลัสเตอร์มีเวลาเดินไม่ตรงกัน (Time Drift) จะส่งผลกระทบอะไร และคุณมีวิธีตรวจสอบความผิดปกติของ Hardware RTC อย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • ในคอมพิวเตอร์มีนาฬิกา 2 ตัว:
    1. System Clock (ซอฟต์แวร์): นับรอบการเดินของเวลาโดยตัวเคอร์เนล
    2. RTC (Real-Time Clock / Hardware Clock): ชิปนาฬิกาขนาดเล็กบนเมนบอร์ดที่ใช้พลังงานจากถ่านกระดุม (CR2032) เพื่อรักษาเวลาไว้แม้จะถอดปลั๊กเครื่อง
  • ระบบฐานข้อมูลแบบกระจายศูนย์ (Distributed Database เช่น Google Spanner) พึ่งพาเวลาที่เที่ยงตรงระดับไมโครวินาทีในการจัดลำดับธุรกรรม (Transaction Ordering)
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องความสำคัญของเวลาในระบบกระจายศูนย์ และการใช้เครื่องมือตรวจสอบเวลา
• แนวทางการตอบแบบมืออาชีพ:
  1. ผลกระทบของ Time Drift:
     • ทำให้เกิดการบันทึกข้อมูลทับซ้อนกัน (Data Corruption) ในฐานข้อมูลแบบกระจายศูนย์
     • ระบบยืนยันตัวตน เช่น Kerberos, TLS Certificates หรือ SSH Tokens จะหมดอายุหรือใช้งานไม่ได้ (Authentication Failures)
     • การเทียบ Timeline ของ Log จากเซิร์ฟเวอร์คนละเครื่องระหว่างสอบสวนเหตุการณ์จะผิดเพี้ยนไปหมด
  2. การตรวจสอบและแก้ไข:
     • ใช้คำสั่ง timedatectl status เพื่อดูว่า System Clock ซิงค์กับ Network Time หรือไม่ และดูว่า RTC ตรงกับเวลาท้องถิ่นหรือไม่
     • ตรวจสอบความเบี่ยงเบนของเวลาผ่านโปรโตคอล NTP/Chrony ด้วยคำสั่ง chronyc sources -v หรือ chronyc tracking ดูค่า RMS Offset ว่ามีค่าแกว่งเกินเกณฑ์มาตรฐานหรือไม่
     • หากเวลาบน RTC กระโดดผิดปกติทุกครั้งที่รีสตาร์ทเครื่อง หรือตั้งเวลาแล้วค่ากลับไปเป็นปี 1970 แปลว่าแบตเตอรี่ CMOS เสื่อม หรือคริสตัลออสซิลเลเตอร์บนเมนบอร์ดชำรุด ต้องเปลี่ยนถ่านหรือเปลี่ยนบอร์ด

ข้อที่ 27: การจัดการซีพียูข้ามสถาปัตยกรรมหน่วยความจำ NUMA (Non-Uniform Memory Access)

• คำถามสัมภาษณ์: “สถาปัตยกรรมแบบ NUMA คืออะไร และทำไมการจัดสรรแรมผิด Node จึงทำให้แอปพลิเคชันเกิดปัญหา Latency สูงขึ้นอย่างฉับพลัน?”
• ปูพื้นฐานและหลักการทำงาน:
  • ในเซิร์ฟเวอร์ระดับองค์กรที่มีซีพียูหลายตัว (เช่น 2 ซ็อกเก็ตขึ้นไป) แรมทั้งหมดในเครื่องจะไม่ได้ต่อรวมอยู่ที่จุดเดียว
  • แรมจะถูกแบ่งออกเป็นกลุ่มๆ เรียกว่า NUMA Node โดยแรมกลุ่มหนึ่งจะต่อสายตรงเข้ากับ Memory Controller ของ CPU Socket 1 และแรมอีกกลุ่มจะต่อตรงกับ CPU Socket 2
  • Local Access: หาก Core บน CPU 1 อ่านแรมที่ต่อกับตัวมันเอง จะได้ความเร็วสูงสุดและความหน่วงเวลาต่ำสุด
  • Remote Access: หาก Core บน CPU 1 จำเป็นต้องอ่านข้อมูลในแรมของ CPU 2 ข้อมูลจะต้องวิ่งข้ามบัสเชื่อมต่อระหว่างซีพียู (เช่น Intel UPI หรือ AMD Infinity Fabric) ซึ่งจะมีความหน่วงเวลาสูงกว่าอย่างมาก
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องโครงสร้างสถาปัตยกรรมฮาร์ดแวร์เชิงลึก และผลกระทบต่อประสิทธิภาพของเวิร์กโหลดความเร็วสูง
• แนวทางการตอบแบบมืออาชีพ:
  1. การตรวจสอบผัง NUMA: ใช้คำสั่ง numactl --hardware หรือ lscpu เพื่อดูจำนวนโหนดและระยะห่างของ Latency (NUMA Distance)
  2. การตรวจสอบปัญหา NUMA Miss: ดูสถิติผ่าน numastat หากพบว่าตัวเลขในแถว numa_miss หรือ other_node มีค่าสูงมาก แสดงว่าซีพียูกำลังเสียเวลาส่วนใหญ่ไปกับการดึงข้อมูลจากแรมฝั่งตรงข้าม
  3. แนวทางการแก้ไข:
     • ตั้งค่าเปิดใช้ NUMA Balancing ในระดับเคอร์เนล
     • สำหรับแอปพลิเคชันที่ต้องการประสิทธิภาพสูงมาก (เช่น ฐานข้อมูล หรือระบบประมวลผลเครือข่ายความเร็วสูง) ให้ใช้คำสั่ง numactl --cpunodebind=0 --membind=0 <คำสั่งรันแอป> เพื่อล็อกให้โปรเซสนั้นรันบนคอร์ของโหนด 0 และใช้แรมของโหนด 0 เท่านั้น (CPU Pinning / Core Affinity)

หมวดที่ 2: Networking (ระบบเครือข่ายศูนย์ข้อมูล)

ข้อที่ 28: ความแตกต่างของเส้นทางข้อมูล Overlay vs Underlay Network (VXLAN / Geneve)

• คำถามสัมภาษณ์: “อธิบายความหมายและความสัมพันธ์ระหว่าง Underlay Network กับ Overlay Network ในศูนย์ข้อมูลสมัยใหม่”
• ปูพื้นฐานและหลักการทำงาน:
  • Underlay Network: คือโครงสร้างเครือข่ายทางกายภาพจริง ประกอบด้วยสายไฟเบอร์, สวิตช์ ToR, สวิตช์ Spine และเราเตอร์ โดยรันโปรโตคอลเราติ้ง เช่น BGP เพื่อให้แน่ใจว่าอุปกรณ์ทุกชิ้นส่งข้อมูลระดับ IP ถึงกันได้อย่างเสถียรที่สุด
  • Overlay Network: คือระบบเครือข่ายเสมือนที่สร้างครอบทับลงไปบน Underlay อีกชั้นหนึ่ง โดยใช้การห่อหุ้มข้อมูล (Encapsulation) เช่น เทคโนโลยี VXLAN (Virtual Extensible LAN) เพื่อเชื่อมต่อ Virtual Machine หรือ Container ให้อยู่ในเครือข่ายเสมือนวงเดียวกัน แม้เครื่องแม่ข่ายจริงจะอยู่คนละตู้แร็กหรือคนละห้องก็ตาม
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจในการแยกแยะชั้นของระบบเครือข่ายเสมือน (Software-Defined Networking – SDN) ออกจากระบบเครือข่ายทางกายภาพ
• แนวทางการตอบแบบมืออาชีพ:
  • ความสัมพันธ์: Underlay ทำหน้าที่เป็นทางหลวงที่มีประสิทธิภาพสูง โดยไม่สนใจว่าผู้โดยสารเป็นใคร ส่วน Overlay ทำหน้าที่เหมือนรถบัสเสมือนที่พกพาโครงข่าย Layer 2 ของผู้ใช้งานวิ่งข้ามทางหลวง Layer 3
  • สิ่งที่ต้องระวังสำหรับ DCO:
    • เมื่อมีการห่อหุ้มส่วนหัวของ VXLAN เข้าไป ขนาดของแพ็กเก็ตจะบวมขึ้นอีกอย่างน้อย 50 ไบต์
    • ดังนั้น เครือข่าย Underlay ทางกายภาพทั้งหมดจะต้องปรับค่า MTU ให้รองรับขนาดอย่างน้อย 1,600 ไบต์ขึ้นไป (หรือเปิด Jumbo Frames 9,000 ไบต์) เพื่อป้องกันไม่ให้แพ็กเก็ตของ Overlay ถูกหั่นย่อย (Fragmentation) จนทำให้ความเร็วร่วง

ข้อที่ 29: การตรวจจับและแก้ปัญหา Link Flapping

• คำถามสัมภาษณ์: “ปรากฏการณ์ ‘Link Flapping’ คืออะไร ส่งผลเสียต่อเครือข่ายอย่างไร และมีขั้นตอนการตรวจหาสาเหตุอย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • Link Flapping: คือสภาวะที่พอร์ตเครือข่ายหรือสายสัญญาณมีสถานะสลับไปสลับมาระหว่าง UP และ DOWN อย่างรวดเร็วและต่อเนื่องภายในเวลาสั้นๆ
  • ผลกระทบ: สวิตช์เครือข่ายจะต้องส่งข้อความแจ้งเตือนการเปลี่ยนแปลงเส้นทาง (Routing Update เช่น BGP/OSPF State Change) ไปยังอุปกรณ์ตัวอื่นๆ ทั่วทั้งศูนย์ข้อมูลทุกครั้งที่สถานะเปลี่ยน การสลับไปมาอย่างต่อเนื่องจะทำให้ซีพียูของสวิตช์ทำงานหนัก 100% จนควบคุมระบบไม่อยู่
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องกลไกการรักษาเสถียรภาพของเครือข่าย (Route Flap Damping) และการแก้ไขปัญหาฮาร์ดแวร์ต้นทาง
• แนวทางการตอบแบบมืออาชีพ:
  1. สืบหาพอร์ตที่มีปัญหา: ตรวจสอบประวัติข้อความในเคอร์เนล dmesg -T | grep -iE 'link is up|link is down' หรือดึง Syslog จากสวิตช์
  2. กลไกการป้องกันตนเองของระบบ: สวิตช์ระดับองค์กรจะมีฟังก์ชันตรวจจับ หากพบพอร์ตใด Flap ถี่เกินเกณฑ์ ระบบจะสั่งปิดพอร์ตนั้นถาวรโดยอัตโนมัติ (Errdisable / Link Flap Damping) เพื่อรักษาเสถียรภาพของทั้งระบบ
  3. การตรวจสอบสาเหตุทางกายภาพ:
     • Optical Power อยู่ในจุดก้ำกึ่ง (Marginal Signal): แสงไฟเบอร์ไม่ได้ขาดสนิท แต่ความเข้มแสงต่ำเตี้ยติดเพดานต่ำสุดของ Transceiver ทำให้บิตข้อมูลขาดๆ หายๆ จนระบบควบคุมตัดสินใจว่าสายหลุด
     • ขาสลักล็อก (Latch) หลวม: หัว Transceiver หรือสาย Patch Cord เสียบเข้าช่องไม่สุด ทำให้หน้าสัมผัสขยับเมื่อมีแรงสั่นสะเทือนจากพัดลมระบายความร้อน
     • ความร้อนของโมดูล: โมดูล SFP ร้อนจัดจนวงจรภายในตัดการทำงานชั่วคราว

ข้อที่ 30: สถาปัตยกรรม SmartNIC / DPU (Data Processing Unit)

• คำถามสัมภาษณ์: “การ์ดแลนแบบ SmartNIC หรือ DPU มีบทบาทสำคัญอย่างไรในศูนย์ข้อมูล และแตกต่างจากการ์ดแลนมาตรฐานอย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • Standard NIC: มีหน้าที่แปลงสัญญาณบิตข้อมูลจากสายไฟเบอร์/ทองแดง ส่งผ่านบัส PCIe เข้าไปให้ซีพียูหลักของเครื่องประมวลผล (เช่น จัดการแพ็กเก็ต, ถอดรหัสความปลอดภัย, ทำไฟร์วอลล์)
  • SmartNIC / DPU: คือการ์ดแลนที่มี “ซีพียู (เช่น สถาปัตยกรรม ARM หลายสิบคอร์), หน่วยความจำ และวงจรเร่งความเร็วเฉพาะทาง (ASIC)” ฝังอยู่บนตัวการ์ดเอง เปรียบเสมือนมีมินิเซิร์ฟเวอร์เสียบอยู่บนสล็อต PCIe
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความทันสมัยต่อเทคโนโลยีโครงสร้างพื้นฐานระดับ Hyperscale (เช่น Google Andromeda / IPU Architecture)
• แนวทางการตอบแบบมืออาชีพ:
  1. การลดภาระของซีพียูหลัก (Infrastructure Workload Offloading):
     • ในระบบคลาวด์ ซีพียูหลักของเซิร์ฟเวอร์ต้องสูญเสียกำลังการประมวลผลไปถึง 20-30% (เรียกว่า Datacenter Tax) ไปกับการจัดการเครือข่ายเสมือน, การเข้ารหัสข้อมูล (IPsec/TLS), และการเข้าถึงระบบจัดเก็บข้อมูล (NVMe-over-Fabrics)
     • SmartNIC จะดึงงานระบบโครงสร้างพื้นฐานเหล่านี้ลงมาประมวลผลบนตัวการ์ดเองทั้งหมด ทำให้ซีพียูหลักของเครื่องสามารถมอบพลังประมวลผล 100% ให้กับงานของผู้ใช้งาน
  2. การรักษาความปลอดภัยระดับฮาร์ดแวร์ (Security Isolation):
     • การ์ด SmartNIC รันระบบปฏิบัติการแยกส่วนอิสระ แม้ระบบปฏิบัติการหลักของโฮสต์จะถูกแฮกหรือควบคุมโดยผู้ไม่หวังดี ผู้โจมตีก็ไม่สามารถทะลุเข้ามาควบคุมระดับคอนฟิกเครือข่ายหรือแอบดักฟังข้อมูลในระดับ DPU ได้

ข้อที่ 31: โปรโตคอล BGP ใน Data Center (BGP on the Host / Leaf-Spine Routing)

• คำถามสัมภาษณ์: “ทำไมศูนย์ข้อมูลสมัยใหม่จึงนิยมใช้โปรโตคอล BGP (Border Gateway Protocol) จัดการเส้นทางภายในตู้แร็ก ไปจนถึงระดับติดตั้ง BGP ลงบนโฮสต์เซิร์ฟเวอร์ (BGP-to-the-Host)?”
• ปูพื้นฐานและหลักการทำงาน:
  • ในอดีต BGP เป็นโปรโตคอลที่ใช้เชื่อมต่อระหว่างเครือข่ายผู้ให้บริการอินเทอร์เน็ต (ISP) ขนาดใหญ่เท่านั้น
  • ในโครงสร้างเครือข่าย Clos/Spine-and-Leaf ขนาดใหญ่ มีเส้นทางการส่งข้อมูลนับหมื่นนับแสนเส้นทาง โปรโตคอลแบบเดิม (เช่น OSPF) จะเริ่มแบกรับการคำนวณผังโครงสร้างไม่ไหวเมื่อมีการเปลี่ยนแปลง
  • BGP-to-the-Host: คือการรันโปรเซส BGP เล็กๆ (เช่น ใช้ซอฟต์แวร์ FRRouting หรือ BIRD) บนเซิร์ฟเวอร์แต่ละเครื่องโดยตรง เพื่อให้เซิร์ฟเวอร์ประกาศ IP Address ของตัวเองไปยัง ToR Switch
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องการออกแบบเครือข่ายระดับ Cloud-Native และการทำ Anycast Routing
• แนวทางการตอบแบบมืออาชีพ:
  1. ความสามารถในการปรับขนาดและความเสถียร (Scalability & Fault Isolation): BGP เป็นโปรโตคอลที่ออกแบบมาให้มีความเป็นระบบควบคุมตนเองสูง สามารถตัดเส้นทางที่มีปัญหาทิ้งได้อย่างแม่นยำโดยไม่ต้องคำนวณโครงสร้างโครงข่ายใหม่ทั้งหมดเหมือน OSPF
  2. ความยืดหยุ่นด้วย Anycast Routing: เซิร์ฟเวอร์หลายสิบเครื่องที่ให้บริการเดียวกัน สามารถประกาศหมายเลข IP เดียวกันผ่าน BGP ไปยังสวิตช์เครือข่าย เมื่อผู้ใช้เรียกใช้งาน ทราฟฟิกจะถูกกระจายไปยังเซิร์ฟเวอร์เครื่องที่อยู่ใกล้ที่สุดโดยอัตโนมัติผ่าน ECMP หากเครื่องใดเครื่องหนึ่งพัง เพียงแค่หยุดรันโปรเซส BGP ทราฟฟิกจะเปลี่ยนทิศทางไปยังเครื่องอื่นทันทีแบบไร้รอยต่อ

ข้อที่ 32: ปรากฏการณ์ BUM Traffic และ Broadcast Storms

• คำถามสัมภาษณ์: “BUM Traffic คืออะไร และหากเกิด Broadcast Storm ขึ้นในเครือข่ายของศูนย์ข้อมูล จะมีอาการและแนวทางรับมืออย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • BUM Traffic ย่อมาจาก:
    • Broadcast: ข้อมูลที่ส่งหาทุกคนในเครือข่าย (เช่น ARP Request)
    • Unknown Unicast: ข้อมูลที่รู้ IP แต่สวิตช์ยังไม่รู้ว่า MAC Address นี้อยู่ที่พอร์ตไหน
    • Multicast: ข้อมูลที่ส่งหากลุ่มผู้รับเฉพาะ
  • สวิตช์มาตรฐานจะจัดการกับข้อมูลทั้ง 3 ประเภทนี้ด้วยวิธีเดียวกันคือ: “การกระจายส่งออกไปทุกพอร์ตที่มีอยู่ในเครือข่ายวงนั้น (Flooding)”
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องความเสี่ยงของการขยาย Layer 2 Domain ใหญ่เกินไป และเครื่องมือควบคุมทราฟฟิกขยะ
• แนวทางการตอบแบบมืออาชีพ:
  1. การเกิด Broadcast Storm: หากเกิดการต่อสายวนลูป (Network Loop) หรือสวิตช์ตั้งค่าผิดพลาด แพ็กเก็ต BUM จะถูกกระจายต่อกันไปเป็นทอดๆ และสะท้อนวนซ้ำอย่างไร้ที่สิ้นสุดจนกินแบนด์วิดท์ของสายสัญญาณ 100%
  2. อาการที่สังเกตได้: หลอดไฟแสดงสถานะของพอร์ตบนสวิตช์และหลังเครื่องเซิร์ฟเวอร์จะกะพริบถี่รัวพร้อมกันทุกพอร์ตอย่างบ้าคลั่ง เซิร์ฟเวอร์ไม่ตอบสนองต่อคำสั่ง Ping หรือ SSH หลุดเพราะคิวบัฟเฟอร์เต็ม
  3. แนวทางการป้องกันและแก้ไข:
     • ลดขนาดของ Layer 2 Domain ให้เล็กที่สุดเท่าที่เป็นไปได้ (เช่น 1 แร็ก = 1 Subnet)
     • เปิดใช้งานฟังก์ชัน Storm Control บนสวิตช์ เพื่อจำกัดปริมาณทราฟฟิก BUM ไม่ให้เกินกี่เปอร์เซ็นต์ของพอร์ต (เช่น ไม่เกิน 5%) หากเกินให้สวิตช์ตัดทิ้งทันที
     • ใช้การแปลง ARP ไปเป็น Unicast ผ่าน BGP EVN ในเครือข่ายสมัยใหม่ เพื่อลดการยิง Broadcast โดยสิ้นเชิง

ข้อที่ 33: กลไก Address Resolution Protocol (ARP) Cache Poisoning และ Table Exhaustion

• คำถามสัมภาษณ์: “เมื่อตาราง ARP Table ของสวิตช์หรือเซิร์ฟเวอร์เต็ม (Table Overflow) หรือได้รับข้อมูลผิดพลาด จะส่งผลกระทบอย่างไรต่อการสื่อสารในศูนย์ข้อมูล?”
• ปูพื้นฐานและหลักการทำงาน:
  • คอมพิวเตอร์คุยกันด้วย IP Address แต่สายสัญญาณส่งข้อมูลกันด้วย Hardware MAC Address
  • ARP Table: ตารางสมุดหน้าเหลืองในแรมที่จดบันทึกว่า IP Address นี้ตรงกับ MAC Address ใด
  • ตารางนี้มีขนาดจำกัดในระดับหน่วยความจำของฮาร์ดแวร์ (TCAM บนสวิตช์ หรือเคอร์เนลแคชบนลินุกซ์)
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ทักษะการวิเคราะห์ปัญหาประสิทธิภาพเครือข่ายเมื่อระบบต้องเผชิญกับสเกลที่ขยายตัวอย่างมหาศาล
• แนวทางการตอบแบบมืออาชีพ:
  1. ผลกระทบเมื่อตาราง ARP เต็ม (ARP Cache Exhaustion):
     • บนเซิร์ฟเวอร์ลินุกซ์: หากขนาดตารางเกินขีดจำกัด gc_thresh เคอร์เนลจะเริ่มส่งข้อความเตือน neighbor table overflow และจะไม่สามารถเพิ่มเส้นทางสื่อสารกับเครื่องใหม่ได้ ทำให้การเชื่อมต่อใหม่เกิด Timeout
     • บนสวิตช์: เมื่อพื้นที่ TCAM เต็ม สวิตช์จะไม่สามารถเรียนรู้ MAC ใหม่ได้ ข้อมูลของอุปกรณ์ใหม่จึงต้องถูกส่งแบบ Flooding (กลายเป็น Unknown Unicast) วิ่งไปรบกวนพอร์ตอื่นทั่วทั้งตู้
  2. การตรวจสอบและปรับจูนบน Linux:
     • ดูขนาดตารางปัจจุบัน: ip neigh show | wc -l
     • หากตารางล้น ให้ขยายขนาดแคชในเคอร์เนลผ่าน /etc/sysctl.conf: net.ipv4.neigh.default.gc_thresh3 = 8192 (ปรับตามสเกลของตู้แร็ก)

ข้อที่ 34: ปัญหา Polarity, Pinout, และ Transceiver Cleanliness ของสาย MPO/MTP

• คำถามสัมภาษณ์: “สายเคเบิลแบบ MPO/MTP สำหรับเครือข่าย 40G/100G มีความซับซ้อนกว่าสายไฟเบอร์คู่แบบเดิม (Duplex LC) อย่างไร และมีข้อควรระวังพิเศษอะไรบ้างในการติดตั้ง?”
• ปูพื้นฐานและหลักการทำงาน:
  • Duplex LC: สายไฟเบอร์มาตรฐาน มีใยแก้ว 2 เส้น (เส้นส่ง TX หนึ่งเส้น, เส้นรับ RX หนึ่งเส้น)
  • MPO/MTP Connector: หัวต่อสี่เหลี่ยมขนาดเล็กที่รวมเอาเส้นใยแก้วขนาดจิ๋วเรียงหน้ากระดานไว้ภายในหัวเดียวจำนวน 8, 12, หรือ 24 เส้น สำหรับรองรับการส่งข้อมูลแบบขนาน (Parallel Optics เช่น 100G SR4 ที่ใช้ส่ง 4 ช่องทาง และรับ 4 ช่องทาง)
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเชี่ยวชาญการทำงานกับอุปกรณ์โครงข่ายความเร็วสูงทางกายภาพ (Layer 1 Specialization)
• แนวทางการตอบแบบมืออาชีพ:
  1. ปัญหาขั้วสัญญาณ (Polarity Type A, B, C):
     • เนื่องจากมีใยแก้วหลายเส้นวิ่งคู่ขนานกัน การต่อหัวต้องจับคู่ให้พอร์ต TX จากสวิตช์ต้นทาง วิ่งตรงเข้าไปเสียบตรงกับพอร์ต RX ของสวิตช์ปลายทางอย่างแม่นยำ
     • หากนำสายเคเบิล Type A (Straight-through) ไปเสียบสลับกับระบบที่ออกแบบมาสำหรับ Type B (Reversed/Crossed) ลิงก์จะไม่ขึ้นเด็ดขาดเพราะแสงจะยิงชนกันเอง (TX ชน TX)
  2. ความสะอาดของหน้าสัมผัส (End-face Cleanliness):
     • หน้าตัดของหัวต่อ MPO เป็นระนาบกว้าง หากมีฝุ่นขนาดเพียงไม่กี่ไมครอนเกาะอยู่เพียงเม็ดเดียว มันสามารถบดบังหรือสร้างช่องว่างทางอากาศ (Air Gap) ให้กับเส้นใยแก้วหลายเส้นพร้อมกัน
     • ต้องใช้หัวทำความสะอาดเฉพาะทาง (MPO One-Click Cleaner) และต้องใช้กล้องขยายพิเศษ (Fiber Scope) ตรวจสอบความสะอาดครบทุก Core ก่อนเสียบเข้าพอร์ตเสมอ

หมวดที่ 3: Troubleshooting and Maintenance (การแก้ไขปัญหาและการซ่อมบำรุง)

ข้อที่ 35: สภาวะ Split-Brain ในสถาปัตยกรรม High Availability (HA)

• คำถามสัมภาษณ์: “สภาวะ Split-Brain คืออะไร มักเกิดขึ้นได้อย่างไร และในระบบศูนย์ข้อมูลมีกลไกใดบ้างที่ใช้ป้องกันไม่ให้เกิดความเสียหาย?”
• ปูพื้นฐานและหลักการทำงาน:
  • ระบบทำงานร่วมกันเป็นคู่ (HA Cluster เช่น Active-Passive หรือ Active-Active) โดยเซิร์ฟเวอร์ทั้งสองเครื่องจะสื่อสารกันผ่านสายสัญญาณตรวจจับชีพจร (Heartbeat Link)
  • Split-Brain: เกิดขึ้นเมื่อสาย Heartbeat ขาดออกจากกัน แต่เซิร์ฟเวอร์ทั้งสองเครื่องยังคงมีชีวิตอยู่และต่อกับภายนอกได้ตามปกติ ต่างฝ่ายต่างคิดว่าอีกฝ่าย “ตายไปแล้ว”
  • ผลลัพธ์: เซิร์ฟเวอร์ทั้งคู่จึงยกตัวเองขึ้นมาเป็นตัวหลัก (Active) พร้อมกัน และพยายามแย่งกันเขียนข้อมูลลงในแหล่งจัดเก็บเดียวกัน (Shared Storage) ทำให้ไฟล์พังเสียหายทันที
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องความปลอดภัยของข้อมูลในระดับสถาปัตยกรรมคลัสเตอร์ และระบบตัดสินชี้ขาด (Quorum)
• แนวทางการตอบแบบมืออาชีพ:
  1. สาเหตุ: การต่อสาย Heartbeat แบบเส้นเดียวโดยไม่มีระบบสำรอง หรือเกิด Network Partitioning คั่นกลางระหว่างโหนด
  2. กลไกการป้องกัน:
     • Quorum Mechanism: กำหนดให้คลัสเตอร์ต้องมีจำนวนโหนดเป็นเลขคี่ (เช่น อย่างน้อย 3 โหนด) เพื่อให้สามารถ “ลงคะแนนเสียง” ได้ ฝั่งใดที่มีจำนวนโหนดเกินครึ่งหนึ่ง (มากกว่า 50%) จึงจะมีสิทธิ์ทำงานต่อ ส่วนฝั่งเสียงข้างน้อยต้องยอมสละสิทธิ์
     • Fencing / STONITH (Shoot The Other Node In The Head): เมื่อเกิดข้อสงสัย โหนดที่ยังทำงานอยู่จะส่งคำสั่งผ่านระบบ Out-of-Band (BMC/IPMI) หรือสั่งตัดไฟที่เต้ารับอัจฉริยะบน PDU โดยตรงเพื่อ “บังคับดับเครื่องอีกฝั่งหนึ่งทันที” ก่อนที่จะปล่อยให้ไปสร้างความเสียหายกับข้อมูล

ข้อที่ 36: วงจรชีวิตของเครื่องเซิร์ฟเวอร์ (Server Decommissioning & Data Sanitization)

• คำถามสัมภาษณ์: “เมื่อเซิร์ฟเวอร์หมดอายุการใช้งานและจำเป็นต้องปลดระวางออกจากศูนย์ข้อมูล (Decommission) มีขั้นตอนปฏิบัติด้านความปลอดภัยและการจัดการทรัพย์สินอย่างไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • การปลดระวางเซิร์ฟเวอร์ไม่ใช่แค่การถอดปลั๊กแล้วยกเครื่องไปทิ้ง แต่เป็นกระบวนการที่มีความเสี่ยงสูงสุดต่อการรั่วไหลของข้อมูลความลับ (Data Breach) ของผู้ใช้งาน
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: วินัยด้านการปฏิบัติตามมาตรฐานความปลอดภัยของข้อมูล (Data Compliance / NIST 800-88 Standards) และการติดตามทรัพย์สิน
• แนวทางการตอบแบบมืออาชีพ:
  1. Logical De-provisioning:
     • ปลด Node ออกจากระบบ Cluster, ลบ DNS Records, และตัดสิทธิ์การเข้าถึงเครือข่ายภายใน
  2. การทำลายข้อมูลบนสื่อบันทึก (Data Sanitization):
     • ปฏิบัติตามมาตรฐาน เช่น NIST SP 800-88 Rev. 1 Guidelines for Media Sanitization:
     • Clear / Cryptographic Erase: ใช้คำสั่งลบระดับฮาร์ดแวร์ (NVMe Format / ATA Secure Erase) หรือการล้าง Master Encryption Key เพื่อทำให้ข้อมูลทั้งหมดกลายเป็นขยะที่ไม่สามารถถอดรหัสได้
     • Purge / Degaussing: การใช้คลื่นแม่เหล็กความเข้มข้นสูงทำลายข้อมูล (สำหรับเทปหรือจานแม่เหล็ก)
     • Physical Destruction: หากเป็นดิสก์ที่มีข้อมูลสำคัญสูงสุดและไม่นำกลับมาใช้ใหม่ จะต้องนำเข้าเครื่องบดหรือเครื่องเจาะทำลายตัวถัง (Disk Shredder / Crusher) ภายในห้องที่ปลอดภัย พร้อมบันทึกภาพวิดีโอและออกใบรับรอง Certificate of Destruction
  3. Asset Tag Reconciliation: สแกนบาร์โค้ดหมายเลขทรัพย์สิน (Asset Tag) และซีเรียลนัมเบอร์ของทุกชิ้นส่วนเข้าระบบฐานข้อมูลคลังพัสดุ เพื่อปิดรอบวงจรชีวิตอย่างเป็นทางการ

ข้อที่ 37: ภาวะ Thermal Runaway และการจัดการจุดลมร้อนรั่วซึม (Blanking Panels)

• คำถามสัมภาษณ์: “แผ่นพลาสติกปิดช่องว่างในตู้แร็ก (Blanking Panel) ดูเหมือนเป็นแค่อุปกรณ์ตกแต่ง แต่ทำไมฝ่าย Data Center Operations จึงถือว่ามันเป็นอุปกรณ์ความปลอดภัยขั้นวิกฤต?”
• ปูพื้นฐานและหลักการทำงาน:
  • ในตู้แร็ก ลมเย็นจะถูกอัดเข้ามาทางด้านหน้า และลมร้อนจะถูกเป่าทิ้งออกทางด้านหลัง
  • ลมธรรมชาติจะไหลจากจุดที่มีแรงดันสูงไปยังจุดที่มีแรงดันต่ำเสมอ
  • หากมีช่องว่างที่ไม่มีการติดตั้งเซิร์ฟเวอร์ (เช่น มีช่องว่างขนาด 1U หรือ 2U โบ๋อยู่กลางตู้) ลมร้อนที่เป่าออกไปด้านหลังตู้ จะถูกพัดลมดูดวนย้อนกลับมาทางช่องว่างนั้นเข้ามาผสมกับลมเย็นด้านหน้าตู้ เรียกว่า Hot Air Recirculation
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความเข้าใจเรื่องอุณหพลศาสตร์และประสิทธิภาพการใช้พลังงาน (PUE – Power Usage Effectiveness) ในระดับกายภาพ
• แนวทางการตอบแบบมืออาชีพ:
  1. อันตรายของ Hot Air Recirculation:
     • เมื่อลมร้อนด้านหลังวนกลับมาด้านหน้า อุณหภูมิลมเข้า (Inlet Temperature) ของเซิร์ฟเวอร์ที่ติดตั้งอยู่ติดกับช่องว่างนั้นจะสูงขึ้นเรื่อยๆ
     • เครื่องจะสั่งเร่งพัดลม 100% ซึ่งยิ่งดูดลมร้อนเข้ามาเร็วขึ้น ส่งผลให้อุณหภูมิพุ่งทะยานเป็นทวีคูณ จนเกิดภาวะ Thermal Runaway และทำให้เซิร์ฟเวอร์ตัดการทำงานไปในที่สุด
  2. บทบาทของ Blanking Panel: การปิดแผ่นกั้นทุกช่องว่างเป็นการตัดวงจรการไหลย้อนกลับของอากาศ บังคับให้ลมร้อนต้องระบายออกสู่ช่องทางเดินลมร้อน (Hot Aisle) และกลับเข้าสู่เครื่องปรับอากาศเท่านั้น ช่วยรักษาระดับแรงดันอากาศและลดการสิ้นเปลืองพลังงานของระบบทำความเย็น

ข้อที่ 38: การจำลองสถานการณ์ DR (Disaster Recovery) และ Power Cut Simulation

• คำถามสัมภาษณ์: “ในการทดสอบการสลับแหล่งจ่ายไฟฉุกเฉินประจำปี (Generator & UPS Load Test) สิ่งที่ทีม Data Center Operations ต้องเตรียมตัวและเฝ้าระวังที่สุดคืออะไร?”
• ปูพื้นฐานและหลักการทำงาน:
  • ศูนย์ข้อมูลพึ่งพาไฟจากการไฟฟ้าเป็นหลัก หากไฟดับ ระบบ UPS (เครื่องสำรองไฟฟ้าด้วยแบตเตอรี่) จะเข้ามาจ่ายไฟทดแทนทันทีในเสี้ยววินาที จากนั้นระบบจะสั่งสตาร์ท เครื่องกำเนิดไฟฟ้าดีเซล (Diesel Generator) ขึ้นมาจ่ายไฟต่อเนื่อง
  • การทดสอบตัดไฟจริง (Black Building Test) เป็นการทดสอบว่าระบบอัตโนมัติทั้งหมดทำงานสอดประสานกันจริงหรือไม่
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความรอบคอบ การบริหารความเสี่ยง และความพร้อมรับมือกับเหตุการณ์ที่ไม่คาดฝัน
• แนวทางการตอบแบบมืออาชีพ:
  1. การเตรียมตัวก่อนการทดสอบ:
     • สำรองข้อมูลและบันทึกสถานะสุขภาพของทุกระบบล่วงหน้า
     • ตรวจสอบระบบบายพาสของตู้สวิตช์ไฟฟ้า (Static Transfer Switch – STS / ATS)
     • ประสานงานกับทีมซอฟต์แวร์ให้หลีกเลี่ยงการรันงานอัปเดตระบบใหญ่ในช่วงเวลาทดสอบ
  2. จุดเฝ้าระวังสูงสุด:
     • UPS Inrush Current: จังหวะที่ไฟจากเครื่องปั่นไฟเข้ามาแทนที่ แบตเตอรี่ UPS หรือหม้อแปลงอาจเกิดกระแสไฟกระชากสูง
     • Hidden Single Point of Failure: เซิร์ฟเวอร์บางเครื่องอาจมีสายไฟเส้นหนึ่งเสียบไว้หลวม หรือ PSU ฝั่งหนึ่งเสียอยู่โดยไม่มีใครสังเกต เมื่อตัดไฟทดสอบ เครื่องตัวนั้นจะดับทันที
     • Air Conditioning Interruption: ชิลเลอร์หรือแอร์บางตัวอาจใช้เวลา 3-5 นาทีในการรีสตาร์ทคอมเพรสเซอร์หลังจากไฟฟ้าเปลี่ยนแหล่งจ่าย ในช่วงเวลานี้ อุณหภูมิในห้องจะพุ่งสูงขึ้นอย่างรวดเร็ว ต้องมีทีมคอยวัดอุณหภูมิตามทางเดินตลอดเวลา

ข้อที่ 39: กระบวนการตรวจสอบและแยกแยะสายสัญญาณเครือข่าย (Visual Fault Locator & Tone Generator)

• คำถามสัมภาษณ์: “เมื่อคุณต้องเดินเข้าไปในห้อง Data Center ที่มีสายไฟเบอร์นับหมื่นเส้น เพื่อเปลี่ยนสายที่ขาดชำรุดใต้พื้นยก คุณมีเครื่องมือและขั้นตอนอย่างไรในการค้นหาสายให้ถูกต้องโดยไม่ดึงผิดเส้น?”
• ปูพื้นฐานและหลักการทำงาน:
  • การดึงสายผิดเส้นในศูนย์ข้อมูล หมายถึงการทำให้ทราฟฟิกของระบบที่กำลังรันอยู่ขาดหายไปทันที (Human-induced Outage)
  • วิศวกรต้องมีกระบวนการยืนยันตัวตนของสายเคเบิลแบบ 100% ก่อนลงมือกระทำ
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความระมัดระวังในการปฏิบัติงานจริง การใช้อุปกรณ์เครื่องมือช่างเฉพาะทาง และการปฏิบัติตามป้ายกำกับ
• แนวทางการตอบแบบมืออาชีพ:
  1. การตรวจสอบป้ายกำกับ (Labeling System):
     • ยึดถือระบบป้ายมาตรฐาน เช่น ANSI/TIA-606 ป้ายต้องระบุต้นทางและปลายทาง (Source Rack/Unit/Port to Destination Rack/Unit/Port) ทั้งสองฝั่งของสาย
  2. การใช้อุปกรณ์ตรวจจับทางกายภาพ:
     • Visual Fault Locator (VFL / ปากกายิงแสงเลเซอร์สีแดง): ปลดปลายสายฝั่งหนึ่ง แล้วยิงแสงเลเซอร์ความเข้มข้นสูงสีแดงเข้าไป แสงจะทะลุผ่านฉนวนออกมาให้เห็นเป็นจุดสีแดงสว่างที่จุดที่สายหัก หรือเห็นแสงเปล่งออกมาที่ปลายสายอีกฝั่งอย่างชัดเจน
     • Tone Generator and Probe (สำหรับสายทองแดง): ส่งคลื่นสัญญาณเสียงเข้าไปในสาย แล้วใช้เครื่องตรวจจับคลื่นไล่หาตำแหน่งปลายสาย
  3. กฎการทำงาน (Zero Disruption Policy):
     • ห้ามดึง กระชาก หรือใช้แรงรั้งสายในช่องทางเดินสายเด็ดขาด เพราะอาจทำให้สายเส้นข้างเคียงที่กำลังส่งข้อมูลอยู่หักงอหรือหลุดออกจากพอร์ต

ข้อที่ 40: ระเบียบวิธีวิเคราะห์สาเหตุที่แท้จริงแบบ 5 Whys ในหน้างาน DCO

• คำถามสัมภาษณ์: “ยกตัวอย่างการใช้เทคนิค 5 Whys เพื่อวิเคราะห์หาสาเหตุที่แท้จริงของปัญหา ‘เซิร์ฟเวอร์ 1 เครื่องหยุดทำงานกะทันหันเนื่องจากความร้อนสูงเกินไป’ ในระดับที่นำไปสู่การปรับปรุงระบบระยะยาว”
• ปูพื้นฐานและหลักการทำงาน:
  • 5 Whys Methodology: การตั้งคำถามว่า “ทำไม” ต่อเนื่องกันไปเป็นทอดๆ เพื่อขุดลึกลงไปให้พ้นจากอาการภายนอก (Symptoms) จนไปถึงข้อบกพร่องระดับโครงสร้าง นโยบาย หรือกระบวนการทำงาน (Root Cause)
• สิ่งที่ผู้สัมภาษณ์อยากเห็น: ความคิดเชิงระบบ การไม่ด่วนสรุปปัญหาแบบผิวเผิน และการมุ่งเน้นการป้องกันเชิงโครงสร้างตามแนวทางวิศวกรรมของ Google
• แนวทางการตอบแบบมืออาชีพ:
  • สถานการณ์: เซิร์ฟเวอร์ดับเพราะ Thermal Trip
    • Why 1: ทำไมเซิร์ฟเวอร์ถึงดับ? -> เพราะอุณหภูมิของซีพียูสูงเกิน 105°C จนวงจรตัดไฟทำงาน
    • Why 2: ทำไมซีพียูถึงร้อนจัด? -> เพราะแผ่นกั้นลม (Airflow Shroud) ภายในตัวเครื่องไม่ได้ถูกติดตั้งกลับเข้าที่ ลมเย็นจึงไม่พัดผ่าน Heatsink
    • Why 3: ทำไมแผ่นกั้นลมถึงไม่ได้ถูกติดตั้งกลับเข้าที่? -> เพราะช่างเทคนิคที่มาเปลี่ยนแรมเมื่อคืน รีบปิดฝาเครื่องโดยไม่ได้ใส่แผ่นกั้นลมกลับเข้าไป
    • Why 4: ทำไมช่างเทคนิคถึงลืมใส่และรีบปิดฝาเครื่อง? -> เพราะไม่มี Checklist ตรวจสอบขั้นตอนการประกอบ และระบบอนุญาตให้เปิดเครื่องบูตได้โดยไม่มีการตรวจสอบทางกายภาพ
    • Why 5 (Root Cause): ทำไมถึงไม่มีการบังคับใช้ระบบตรวจสอบ? -> เพราะกระบวนการบำรุงรักษาไม่ได้กำหนดให้ต้องมีขั้นตอน “Secondary Peer Review” หรือการใช้เซ็นเซอร์ตรวจจับตำแหน่งฝาครอบ (Chassis Intrusion Switch) เชื่อมโยงกับนโยบายของ BMC เพื่อเตือนก่อนคืนเครื่องเข้า Production
  • Action Item ที่ได้:
    1. ปรับปรุง Runbook เพิ่มรายการตรวจสอบการใส่ Shroud และปิดฝา
    2. ตั้งค่า BMC ให้ส่งสัญญาณเตือนไปยังระบบ Monitoring ทันทีหากเซ็นเซอร์ตรวจจับได้ว่าฝาครอบหรือ Shroud ยังปิดไม่สมบูรณ์เมื่อเปิดเครื่อง