วิศวกรเครือข่ายคำตอบสัมภาษณ์

ผมเริ่มจากข้อกำหนด: จำนวนผู้ใช้ แอปพลิเคชัน ความต้องการแบนด์วิดท์ ความต้องการความซ้ำซ้อน และข้อจำกัดด้านความปลอดภัย ผมออกแบบระดับความซ้ำซ้อนที่เหมาะสม — ไม่ใช่ทุกอย่างต้องเป็น N+2 แต่บริการที่สำคัญไม่ควรมีจุดล้มเหลวเดียว (single point of failure) ผมจัดทำการออกแบบเชิงตรรกะ (โครงสร้าง VLAN, การออกแบบการกำหนดเส้นทาง, โทโพโลยี WAN) ก่อนย้ายไปสู่การออกแบบเชิงกายภาพ ผมเอกสารการจัดสรรที่อยู่ IP, นโยบาย QoS, และโซนความปลอดภัย และวางแผนการติดตั้งเป็นขั้นตอนพร้อมขั้นตอนการย้อนกลับ (rollback) ในแต่ละขั้น

BGP (Border Gateway Protocol) เป็นโปรโตคอลการกำหนดเส้นทางของอินเทอร์เน็ต — มันกำหนดเส้นทางระหว่างระบบอิสระ (autonomous systems, AS) ในบริบทองค์กร ผมใช้ eBGP สำหรับการเชื่อมต่ออินเทอร์เน็ต (กับ ISP), SD-WAN underlay และการเชื่อมต่อแบบ multi-cloud ส่วน iBGP ใช้ในการเผยแพร่เส้นทางภายในเครือข่ายองค์กรขนาดใหญ่ซึ่ง OSPF หรือ EIGRP อาจไม่เหมาะสม BGP ให้การควบคุมที่แม่นยำต่อการเลือกเส้นทางผ่านแอตทริบิวต์เช่น AS-path, local preference, MED และ communities มันเป็นตัวเลือกที่เหมาะเมื่อคุณต้องการการกำหนดนโยบายการกำหนดเส้นทางระหว่างระบบอิสระ

ผมใช้แนวทางเป็นขั้นตอน: กำหนดปัญหาอย่างชัดเจน (อะไรได้รับผลกระทบ อะไรไม่เป็น และเมื่อเริ่มเกิด), รวบรวมข้อมูล (logs, การแจ้งเตือนจากมอนิเตอริ่ง, สถิติอินเทอร์เฟซ), ตั้งสมมติฐาน, ทดสอบโดยไม่ก่อให้เกิดผลกระทบรุนแรงเพิ่มเติม, ดำเนินการแก้ไข และยืนยันการกู้คืน ผมใช้โมเดล OSI เป็นกรอบการตรวจสอบ — ชั้นกายภาพ, ชั้นดาต้า ลิงก์, ชั้นเครือข่าย, ชั้นทรานสปอร์ต ผมตรวจสอบ spanning tree, เพื่อน CDP/LLDP, ตารางการกำหนดเส้นทาง และ logs ตามลำดับ และบันทึกทุกขั้นตอนระหว่างเหตุขัดข้องสำคัญเพื่อให้มีไทม์ไลน์สำหรับการวิเคราะห์ภายหลัง

ผมได้ออกแบบและติดตั้งโซลูชัน SD-WAN โดยใช้ Cisco Viptela, VMware (VeloCloud) และ Fortinet Secure SD-WAN ผมเคยทดแทน MPLS ด้วยการผสมผสานบรอดแบนด์ + LTE เป็น underlay และใช้นโยบายการกำหนดเส้นทางที่รับรู้แอปพลิเคชัน (application-aware), การเลือกเส้นทางแบบไดนามิกตามเมตริก SLA (latency, jitter, loss) และการจัดการแบบรวมศูนย์ SD-WAN ช่วยลดค่าใช้จ่าย WAN อย่างมีนัยสำคัญในขณะเดียวกันก็ปรับปรุงประสิทธิภาพของแอปพลิเคชันที่โฮสต์บนคลาวด์ กุญแจสู่การติดตั้ง SD-WAN ที่ประสบความสำเร็จคือการจัดประเภททราฟฟิกและการออกแบบนโยบาย SLA ให้ชัดเจนตั้งแต่ต้น

ผมใช้แนวทาง defense in depth: ความปลอดภัยที่ขอบเครือข่าย (next-gen firewalls, การบรรเทา DDoS), การแบ่งส่วนเครือข่าย (VLANs, micro-segmentation, โซนแบบ zero trust), การควบคุมการเข้าถึง (NAC, 802.1X, การประเมินสถานะอุปกรณ์), การสื่อสารที่เข้ารหัส (IPSec VPN, MACsec สำหรับภายใน), และการมอนิเตอร์ (NetFlow, การผนวกรวมกับ SIEM, IDS/IPS) ผมใช้หลัก least-privilege กับกฎไฟร์วอลล์ — ปฏิเสธทั้งหมด แล้วอนุญาตเป็นข้อยกเว้น ผมตรวจสอบ ACLs และกฎไฟร์วอลล์เป็นรายไตรมาสและดำเนินการประเมินช่องโหว่อย่างสม่ำเสมอ ความปลอดภัยเป็นการปฏิบัติอย่างต่อเนื่อง ไม่ใช่การตั้งค่าครั้งเดียว

ผมออกแบบสถาปัตยกรรมเครือข่ายบน AWS และ Azure: การออกแบบ VPC/VNet, Transit Gateway และ Virtual WAN สำหรับสถาปัตยกรรม hub-and-spoke, Direct Connect และ ExpressRoute สำหรับการเชื่อมต่อแบบส่วนตัว, และ AWS PrivateLink/Azure Private Endpoint สำหรับการเข้าถึงบริการอย่างปลอดภัย ผมนำแนวปฏิบัติด้านความปลอดภัยแบบเนทีฟของคลาวด์มาใช้: Security Groups, NACLs และ NSGs ผมใช้ Terraform เพื่อปรับใช้และจัดการโครงสร้างเครือข่ายคลาวด์เป็น Infrastructure as Code และผมเข้าใจโมเดลความรับผิดชอบร่วม (shared responsibility model) เพื่อให้แน่ใจว่าเราปฏิบัติตามความรับผิดชอบของเราในทุกการใช้งานคลาวด์

ผมถือใบรับรอง [CCNP/CCIE/PCNSE/NSE4] และรักษาให้อัปเดตตามข้อกำหนด CPD ผมติดตาม release notes ของ Cisco และผู้ขายสำหรับแพลตฟอร์มที่ผมดูแล, เข้าร่วม webinar ของผู้ขาย, และใช้แล็บทดสอบ (GNS3, EVE-NG หรือ vendor sandboxes) เพื่อทดสอบเทคโนโลยีและการตั้งค่าใหม่ก่อนนำไปใช้จริง ผมยังติดตามชุมชนด้านเครือข่าย — PacketPushers, ฟอรัมวิศวกรรมเครือข่าย และเอกสารการประชุม NANOG สำหรับแนวโน้มใหม่และการอภิปรายเกี่ยวกับการติดตั้งในโลกจริง

ผมปฏิบัติตามกระบวนการบริหารการเปลี่ยนแปลงที่เป็นระบบ: บันทึกการเปลี่ยนแปลงทั้งหมดพร้อมแผนรายละเอียด, ขั้นตอนการย้อนกลับ และแผนการทดสอบ ผมจัดประเภทการเปลี่ยนแปลงตามความเสี่ยง (standard, minor, major, emergency) และส่งผ่านคณะกรรมการพิจารณาการเปลี่ยนแปลง (CAB) ตามความเหมาะสม การเปลี่ยนแปลงที่มีความเสี่ยงสูง (major) จะทดสอบในแล็บก่อน การเปลี่ยนแปลงในระบบผลิตจะทำในหน้าต่างบำรุงรักษาที่กำหนด โดยมีทีมอยู่บนสายประชุม (bridge) และผมรักษาไทม์ไลน์สดของการเปลี่ยนแปลงที่ทำ การทดสอบหลังการเปลี่ยนแปลงยืนยันความสำเร็จก่อนยุติการประชุม และผมยังเขียน runbooks เพื่อให้สมาชิกทีมคนอื่นสามารถดำเนินการเปลี่ยนแปลงได้