เก่งในที่นี้แปลว่า
แก้ได้เร็ว.. แก้แล้วจบ.. แก้เสร็จแล้ว.. สามารถทำกลับให้มีปัญหาเหมือนเดิมได้… และแก้ซ้ำอีกทีก็ได้ จนลูกค้าเลิกพูดว่า “เดี๋ยวคุณกลับไป มันก็จะเป็นอีก“
● เก่ง ยังแปลว่า เราจะอ้างว่าปัญหามันเกิดเพราะอะไร เราก็โชว์หลักฐานให้เห็นได้ ไม่ใช่พูดขึ้นมาลอย ๆ ว่า Firewall มัน RAM ไม่พอ
● เก่ง แปลว่า เมื่อแก้ตามที่เราบอกว่าให้แก้แบบนี้ ปัญหามันจะต้องจบได้จริง ๆ
● เก่ง ยังสามารถบอกได้ว่า เดี๋ยวพอแก้แล้ว อะไรจะเกิด บอกก่อนจะลงมือ และพอลงมือแล้ว ก็เปิด Log ให้สามารถติดตามผล ชี้ชัดได้ว่า สิ่งที่ได้กล่าวเอาไว้นั้น ได้เกิดขึ้นจริง
#เก่ง ไม่ได้แปลว่า แก้ได้หมดทุกปัญหา แต่ปัญหาที่แก้ไม่ได้ สามารถอธิบายได้ว่า ทำไมถึงแก้ไม่ได้
เช่น แก้ไปจนถึงจุดที่แสดงได้ว่าเป็นปัญหาของเฟิร์มแวร์ โดยไม่ใข่แค่อ้างขึ้นมาลอย ๆ ให้พ้น ๆ ตัวเองไป แต่เป็นคำอ้างที่มีคำยืนยันเป็น Support case เปิดไปที่ Vendor และเขายอมรับว่า เฟิร์มแวร์มีปัญหาจริง ซึ่ง Vendor รับเคสนั้นไว้เป็น Bug report
และทั้งหมดของความเก่งนี้ สามารถเขียนเป็นรายงาน เป็นหลักฐานมอบให้ลูกค้า เผื่อว่าลูกค้ามีข้อสงสัย ก็ยังสามารถเอารายงานนั้นไปให้มืออาชีพคนอื่น ๆ ได้ดู ให้คนอื่นสามารถแสดงความคิดเห็นในลักษณะ Second opinion ได้
หลายครั้งที่ผมมักได้รับคำถามว่า “พี่เคยเจอเคสแบบนี้หรือเปล่า” หรือ “สรุปว่าเคสนี้แก้อย่างไร” ผมมักมีความวิตกที่จะให้คำตอบ ผมคิดว่าน่าจะเป็นความรู้สึกเดียวกันถ้าเราไปถามหมอว่า “หมอครับ สรุปว่าถ้าผมปวดท้อง ก็คือยาตัวนี้ใช่มั้ย จะได้จดเอาไว้ไปซื้อกินเอง” ผมรับรองว่า ไม่มีหมอคนไหนจะตอบว่าใช่ หรือไม่ใช่ หมอคงจะตอบว่า “ปวดท้องครั้งหน้า มาหาหมอดีกว่านะครับ”
เพราะประสบการณ์ ไม่ใช่ส่วนสำคัญของการแก้ปัญหา Network ได้เก่ง ๆ ครับ จริง ๆ แล้วมันเป็นส่วนเล็กมาก ๆ เอาซะ 10% ก็พอแล้ว แล้วอะไรคือ 90% ของสิ่งที่จำเป็นในการแก้ปัญหา Network
ผมว่า การบอกได้ว่า สิ่งที่ถูกต้องนั้น “ขั้นตอนอย่างละเอียด” นั้นเป็นอย่างไร เป็นเรื่องสำคัญมาก จะยกให้สูงถึง 80% ยังได้เลย
มาดูกันง่าย ๆ เอาแค่ ping นะครับ ผมเคยตั้งคำถามสนุก ๆ ถามคนที่ทำงาน Network ด้วยกันว่า IP-A ping IP-B มันเกิดอะไรขึ้นบ้าง
คำตอบที่ได้ก็คือ เครื่อง IP-A มันก็จะส่งไปบอกเครื่อง IP-B ให้ตอบ ping กลับมา ซึ่งผมก็ถามต่อไปว่า “บอกยังไง” บางคน (ส่วนน้อย) สามารถไปต่อได้โดยการตอบกลับมาว่า “ใช้ ping packet” ผมก็ยังดันจะถามต่อไปอีกว่า “ping packet หน้าตาเป็นอย่างไร แสดงให้ดูหน่อย” น้อยคนที่จะไปต่อได้ถึง 3 คำถาม ซึ่งผมสามารถจะลากต่อไปได้ถึง 15 คำถาม โดยทุก ๆ คำถาม ก็วนอยู่ในแค่ ping เรื่องเดียวนี่แหละครับ
ที่น่าสนใจคือ ใคร ๆ ก็ตั้งคำถามกับตัวเองได้ทั้งนั้นครับ จะศึกษาอะไร ลองตั้งคำถามกวนความรู้ของตัวเองอย่าให้มันตกตะกอน อย่าหยุดแค่เท่าที่อ่าน อย่าหยุดเท่าที่คิดว่ามันใช่ ซึ่งถ้าคุณอ่านแบบไม่หยุดถามนะ ด้วยคำสั่ง Ping คุณจะได้เรียนรู้เรื่องต่าง ๆ เหล่านี้แถมมาด้วย
– Routing table
– IP subnet และ calculation ของ subnet
– ARP cache
– ARP table
– ขบวนการของ ARP request / reply
– ICMP protocol และวิธีการใช้ Protocol นี้เพื่อเป็น Control Message ที่นอกเหนือจาก ping
และถ้าถามไปลึกมากจริง ก็จะเลยเถิดไปอ่านเรื่องของวิธีการทำงานของสวิตช์ ก็จะได้รู้เรื่องของ Dynamic MAC memory บนสวิตช์ด้วย
คนอื่นอ่านเรื่อง ping แบบไม่มีการตั้งคำถาม เขาจะใช้แค่ 30 นาที แต่ถ้าคุณอ่านแบบตั้งคำถามไปเรื่อย ๆ กวนประสาทตัวเองไปเรื่อย ๆ คุณจะใช้เวลา 1 สัปดาห์ในการอ่าน ping เรื่องเดียว
คนที่อ่านเรื่องพวกนี้ซ้ำแล้วซ้ำอีก ก็จะรู้ว่า ping มีขั้นตอนละเอียดยิก ๆ อะไรบ้าง พอคนแบบนี้เห็นปัญหา IP-A ping IP-B ไม่ได้ เขาจะนึกไล่ไปทีละขั้นตอนที่ละเอียดมาก ว่า IP-A จะ ping IP-B ได้นั้น จะต้องทำอะไรก่อน ต่อไปทำอะไร ก็ค่อย ๆ ไปไล่ดูว่า ที่ต้องทำนั้นได้ทำหรือยัง มันไปติดที่ตรงไหน
– Routing table ของเครื่องต้นทางเป็นอย่างไร
– IP-A มีการส่ง ARP request ออกไปตามหา Default gateway หรือ Destination IP หรือเปล่า
– มีอะไรอยู่ใน ARP cache ของ IP-A
– ARP reply กลับมาจาก MAC address มากกว่า 1 หรือเปล่า (IP ซ้ำกัน) หรือไม่มี ARP reply กลับมา
– เครื่องมีการส่ง ICMP request ออกไปหรือไม่
– ปลายทางได้รับ ICMP request หรือไม่
– ปลายทางส่ง ICMP reply กลับมาหรือไม่
– ต้นทางได้รับ ICMP reply กลับมาหรือไม่
นี่เป็นคร่าว ๆ ของคำถามว่า ping ไม่ได้ จะต้องเช็คที่ไหน เมื่อเช็คเจอแล้วว่า อะไรมันผิดพลาด ไม่ทำงานตามที่ควรจะเป็น การแก้ปัญหาก็จะแม่นตรง ไม่พลาด ไม่ต้องลอง บอกได้ล่วงหน้าว่า แก้แล้วจะจบหรือไม่จบ
ดังนั้น นอกจากจะรู้ว่า การทำงานที่ถูกต้องเป็นอย่างไรแล้ว ยังจะต้องรู้ด้วยว่า จะ Diag อย่างไร เช่น
– Routing table ของเครื่อง A จะใช้คำสั่งอะไรเพื่อแสดงมันออกมา
– เราจะใช้ Utility หรือ Tool ตัวไหนในการแสดงว่า เครื่องส่ง ARP request ออกไปหรือไม่
– คำสั่งอะไรใช้แสดง ARP cache
ฯลฯ
การเรียนรู้เครื่องมือที่ใช้ในการ Diag ถือว่าเป็นอีกแค่ 10% ของการแก้ปัญหา Network ที่ผมให้แค่ 10% เพราะมันไม่ใช่เรื่องใหญ่ อยากรู้เมื่อไหร่ก็ถามเฮียกูเอาก็ได้ และในตลาดก็มีคนใช้ Diag tools พวกนี้ได้เป็นเยอะแยะอยู่แล้ว สะกิดถามคนข้าง ๆ หรือให้คนขาย remote มาทำให้ ก็ไม่ซับซ้อนยุ่งยาก แต่คนที่จะรู้ว่าต้องใช้ Tool นั้นเมื่อไหร่ เพื่อแสดงอะไร ตีความอย่างไร คนพวกเนี้ย…มีน้อยครับ
จะแก้ปัญหา Network ได้เก่งนะครับ อ่านเยอะ ๆ ตั้งคำถามแยะ ๆ โดยเฉพาะ Protocol ทั้งหลาย แล้วก็มาเรียนรู้วิธีการ Diag ของอุปกรณ์นั้น ๆ หรือ OS นั้น ๆ ส่วนใหญ่มักจะเป็นการเปิด Debug Log หรือ Diag screen หรือแสดง Status แล้วก็อ่านสิ่งที่แสดงนั้น ตามขบวนการของ Protocol ตรงนี้ใช้ประสบการณ์นิดหน่อยมาช่วยให้เราจับสิ่งที่ผิดปกติใน Log ได้เร็วขึ้น
ส่วนใหญ่คนมักไม่ทนกับการอ่าน ทำให้รู้ Protocol ไม่ลึก แต่มักยินดีใช้เวลาเยอะกับการลงมือ คนส่วนใหญ่จึงมีความเชี่ยวชาญในการใช้ Diag tools เช่นการเปิดหน้าจอหรือพิมพ์ command line ได้อย่างคล่องแคล่ว ผลก็คือการจะแก้ปัญหา ก็มักจะลงมือซะมากกว่าจะใช้เวลาวางแผน และมักไปลงเอยด้วยการแก้ได้จากการใช้ประสบการณ์มากกว่าทฤษฎี ซึ่งก็โชคดีที่ความผิดพลาดใน Network นั้นมักเป็นปัญหาที่ซ้ำ ๆ กัน การลองทำในสิ่งที่เคยทำแล้วแก้ได้ จึงมักได้ผล แต่คนแก้ได้กลับอธิบายเป็นขั้นเป็นตอนไม่ได้ว่า ที่ได้ลงมือไปนั้น แก้ปัญหาได้อย่างไร
รู้ต้นทางคือลงมือ รู้ปลายทางคือปัญหาจบ แต่ตรงกลางเกิดอะไรขึ้น หาจุดเชื่อมโยงไม่ได้ อธิบายไม่ค่อยเหมือนกันซักคนและไม่ค่อยเหมือนทฤษฎีของ Protocol นั้น ๆ ยิ่งถ้าให้หาอ้างอิงด้วยแล้ว เช่น Log หรือ Indicator อื่น ๆ มาประกอบการอธิบาย Development ของปัญหา น้อยคนที่จะหยิบหลักฐานมาประกอบเรื่องเล่าได้อย่างหนักแน่น
ถ้าเคสนั้นแก้ไม่ได้ด้วยความคุ้นเคยหรือประสบการณ์ ก็มักจบท้ายด้วยการ Reboot ตามด้วยการเซ็ตใหม่หมด อาจต่อด้วยการเปลี่ยนอุปกรณ์ บางทีลองผิดลองถูกไปไม่รอด เลยเถิดไปโทษว่าอุปกรณ์ยี่ห้อนี้ไม่ดีเอาซะเลย แบบนี้ก็มีให้เห็นพอควร โดยเฉพาะถ้ามีกรอบเวลาเข้ามาเป็นแรงกดดัน ก็จะยิ่งได้เห็นทางออกที่แปลกประหลาดหลากหลายวิธี ยกเว้นวิธีที่จะใช้ทฤษฎีเข้ามาตั้งต้นขบวนการแก้ปัญหา
การแก้ได้เพราะประสบการณ์ เป็นสิ่งที่มีให้เห็นได้บ่อยครั้ง ทำให้คนหลงเชื่อไปว่า ประสบการณ์เป็นเรื่องสำคัญกว่าการทำความเข้าใจหลักการทำงานของ Protocol และ Process ผมเห็นหลายคนเน้นการลงมือลองเล่นอุปกรณ์ก่อนการอ่านทำความเข้าใจ ก็เข้าใจได้ว่ากำลังมุ่งจะเอาประสบการณ์จากอุปกรณ์ตัวนั้น อยากจะเซ็ตเป็น ว่ากันง่าย ๆ แต่ผลสุดท้ายเพราะไม่มีทฤษฎีกำกับ จึงเกิดการ “สร้างความเข้าใจขึ้นมาเอง” ว่าสิ่งที่เห็นจากการลองทำนั้น มันเป็นเพราะอุปกรณ์ทำงานแบบนี้ ผลิตความเข้าใจแบบที่ไปขัดแย้งกับหลักการทำงานจริงของ Protocol เรียกสั้น ๆ ว่า “มโน”
มโน มันเป็น Inside-Out product ซึ่ง Outside-in process หรือความพยายามจะแกะมโนของคนนั้น มักไม่ได้ผล คนโบราณเขาเรียกว่า น้ำเต็มแก้ว แถมน้ำในแก้วยังกินไม่ได้ซะอีก เหตุนี้แหละครับ ที่ทำให้คนเก่งได้ยาก
● จะแก้ Network ได้เก่ง เริ่มจากสนใจ ต่อมาก็อ่านครับ อ่านแล้วถามแหย่ความรู้ของตัวเอง คุณจะพบจุดที่ไม่รู้ ก็อ่านต่อ หันมาอีกที คุณรู้ไปตั้งหลายเรื่องแล้ว เรื่องของการเซ็ตอุปกรณ์มันเรื่องเล็กมากครับ เรียนรู้ไม่กี่ชั่วโมงก็ทำได้แล้ว ยิ่งเป็นพวก Enterprise equipment จะยิ่งมี Diag tool ให้เลือกหลากหลายและมีประสิทธิภาพด้วย ยิ่งใช้เวลาเรียนรู้น้อยเข้าไปอีก
และก่อนจะลงมือแก้ปัญหาอะไร ให้คิดถึงขั้นตอนที่ถูกต้องของ Protocol และ Process เอาไว้ก่อน ถ้ารู้ไม่ครบ กลับไปอ่านก่อนครับ อย่าลงมือโดยไม่รู้หรือรู้ไม่ครบ เพราะมันคือต้นกำเนิดของความบรรลัยที่จะตามมา
#เสร็จแล้วไล่เช็คตาม Process ของ Protocol นั้นโดยไม่ใช้ประสบการณ์ สิ่งที่เราเห็นอาจไม่เหมือนสิ่งที่เราเคยทำ งัด Diag tool ขึ้นมาแสดงผลและสรุปด้วยหลักฐาน ก่อนจะก้าวไปเช็คในขั้นตอนถัดไปของ Protocol ทำไปทีละขั้นทีละตอน ฝึกแบบนี้ไปจนเป็นรูปแบบที่ถนัด ฝึกที่จะเชื่อประสบการณ์ให้น้อย ๆ และคิดไหลตาม Process ของ Protocol ให้มาก ๆ แล้วคุณจะเป็นคนที่แก้ปัญหา Network ได้เก่งครับ