Networking

คุณต้องรู้อะไรถึงจะก้ปัญหา Network ได้เก่ง ๆ

เก่งในที่นี้แปลว่า

แก้ได้เร็ว.. แก้แล้วจบ.. แก้เสร็จแล้ว.. สามารถทำกลับให้มีปัญหาเหมือนเดิมได้… และแก้ซ้ำอีกทีก็ได้ จนลูกค้าเลิกพูดว่า “เดี๋ยวคุณกลับไป มันก็จะเป็นอีก“

● เก่ง ยังแปลว่า เราจะอ้างว่าปัญหามันเกิดเพราะอะไร เราก็โชว์หลักฐานให้เห็นได้ ไม่ใช่พูดขึ้นมาลอย ๆ ว่า 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 ได้เก่งครับ

ทฤษฎี “ใช้ไม่ได้” ในทางปฏิบัติ

ผมเป็นคนที่ทำงานด้าน Network และ Cybersecurity อย่างตรงไปตรงมาตามทฤษฎี ตั้งแต่ Design, Implementation, Integration และ Trouble shooting ซึ่งแน่นอนว่า ต้องทำงานร่วมกับหลาย ๆ ฝ่าย ผมทำงานชัดเจน อ้างอิงทฤษฎีเป็นขั้นเป็นตอน จนผู้ร่วมงานสังเกตได้ และมักบอก (เหมือนกับจะหวังดี) กับผมว่า “พี่ครับ…ทฤษฎีบางทีมันก็ใช้ไม่ได้ในทางปฏิบัตินะครับ”

มันเป็นอย่างนั้นจริง ๆ เหรอ…

ยกตัวอย่างเช่น

ตอนนี้ระบบมันล่มแล้ว ไล่ Reboot อุปกรณ์ทีละตัวเลยดีมั้ย หรือลองถอดสายเส้นที่เพิ่งเสียบดี นั่งดู log มันจะช้านะ

หรือ

ทฤษฎีมันใช้กับโปรเจคนี้ไม่ได้ งบมันไม่พอ

หรือ

ลูกค้าเขาอยากได้แบบนี้ เขาไม่สนว่ามันเป็นไปตามทฤษฎีหรือเปล่า

คุ้น ๆ มั้ยครับ พอจะรำลึกได้หรือเปล่าว่า ประสบการณ์ของเราวันนั้น วันที่เราอยู่ในสถานการณ์ที่เราต้องเลือก ระหว่าง ทฤษฎี กับ สัญชาตญาณ วันนั้นเราเลือกอะไร

ไม่ได้แปลว่าทำตามทฤษฎีจะเป็นคำตอบที่ถูกเสมอไป และไม่ได้แปลว่า การใช้สามัญสำนึกจะเป็นเรื่องผิด สำหรับผม ผม มีทั้ง 2 แบบครับ คือทำตามทฤษฎีในหลายครั้ง ทำตามสัญชาตญาณในบางที สิ่งที่น่าสนใจคือ วิธีคิดครับ ตอนไหนควรเลือกยึดมั่นตามทฤษฎี ตอนไหนควรทิ้งทฤษฎีเอาไว้แล้วใช้วิจารณญาณ วิธีคิดนี่แหละครับที่สำคัญ

เมื่อไหร่ใช้ทฤษฎี

สมมติว่า คุณได้รับคำสั่งให้ติดตั้งเซิร์ฟเวอร์เข้าตู้ ปรากฎว่า ตู้นั้นเป็นตู้แบบตื้น แต่เซิร์ฟเวอร์ของคุณเป็นแบบที่จะต้องติดในตู้ลึก อ่ะ…ทำไงดี เดินอ้อมไปดูหลังตู้ อ้าว…เซิร์ฟเวอร์ 4 ตัวที่มีอยู่ก่อนแล้ว มันเป็นแบบยาวทั้งนั้นเลยนี่หว่า ว่ากันง่าย ๆ เซิร์ฟเวอร์ 4 ตัวตูดโผล่ยื่นออกไปหลังตู้อยู่ก่อนแล้ว มันจะมีตูดโผล่เพิ่มอีกซักตูด จะเป็นรัยปั๊ย…ไหน ๆ ฝาตู้ด้านหลังมันก็ไม่เคยปิดมาเป็นปีแล้ว

เรื่องนี้สอนให้รู้ว่า ทฤษฎีใช้ไม่ได้ กับระบบไม่ทำตามทฤษฎี ก็คือถ้าระบบได้เตรียมตู้ลึกเอาไว้ เราก็คงไม่ต้องเล่นนอกตำรากันแบบนี้

ย้อนไปเมื่อ 2 ปีที่แล้ว ณ ตู้เดิมที่ยังไม่มีเซิร์ฟเวอร์ติดตั้งอยู่เลย เพราะมันคือตู้ B เป็นตู้ตื้นที่เอาไว้ติดตั้ง Network equipment และ Network cable ส่วนเซิร์ฟเวอร์นั้นอยู่ในตู้ A เป็นตู้ลึกที่ค่อนข้างเต็มแล้ว ตู้ A ใส่เซิร์ฟเวอร์ ตู้ B เป็น Network equipment ระบบออกแบบเอาไว้อย่างนี้

จนวันหนึ่ง มีการสั่งซื้อเซิร์ฟเวอร์ใหม่ 4 ตัวโดยที่ไม่ได้ผ่านการคิดอย่างรอบคอบ ก็เลยเพิ่งมารู้ว่า ไม่มีที่เหลือในตู้ A แล้ว ครั้นจะทำเรื่องขอซื้อตู้เพิ่ม ก็ไม่รู้ว่าจะต้องรออนุมัติกันอีกนานเท่าไหร่ อ่ะ…ตู้ B มีที่ว่าง เซิร์ฟเวอร์ใหม่ 4 ตัวก็ติดมันซะในตู้ B กลายเป็นเซิร์ฟเวอร์ตูดโผล่ ส่วนตู้ B ที่เคยปิดฝาตู้เรียบร้อย ก็กลายเป็นตู้เปิดฝาหลังตั้งแต่วันนั้นเป็นต้นมา

เรื่องนี้สอนให้รู้ว่า การออกนอกทฤษฎีในวันนี้ มันพาลทำให้คนอื่นที่มาต่องาน ต้องออกนอกทฤษฎีด้วยในวันข้างหน้า ยิ่งเดินระบบไปก็ยิ่ง Off road นอกตำรากันมากขึ้นเรื่อย ๆ เรามาดูกันต่อว่า ตู้ B จะมีอนาคตอย่างไร

แล้วเรื่องมันก็มาเกิดวันที่ไฟดับ UPS ที่เตรียมเอาไว้ เพื่อให้ตู้ B ทำงานต่อได้ 1 ชั่วโมง กลับสำรองไฟได้แค่ 10 นาทีเพราะมันดันมีเซิร์ฟเวอร์ 5 ตัวช่วยกันดูดไฟจาก UPS ไปจนเกลี้ยง เซิร์ฟเวอร์ยังไม่ทันได้ shutdown ไฟหมดซะแล้ว ไม่แตกต่างจากการกระชากปลั๊กของเซิร์ฟเวอร์ทั้ง 5 ตัวซะงั้น ส่งผลให้ OS พัง Boot ไม่ขึ้นไปซะ 1 ตัว

ส่วน Network equipment แทนที่จะทำงาน 1 ชั่วโมงก็ดับไปใน 10 นาที มาดูเซิร์ฟเวอร์ในตู้ A เขามี UPS ตามขนาดที่ออกแบบเอาไว้แต่ต้น ช่วยต่อลมหายใจออกไปอีก 1 ชั่วโมงอย่างไร้ความหมาย อ่ะ…ก็ Network equipment มัน Down ไปหมดแล้ว เซิร์ฟเวอร์มันตื่นตาสว่างอยู่คุยกับใครได้

เรื่องนี้สอนให้รู้ว่า การออกนอกทฤษฎี แม้จะดูเหมือนทำงานได้ ไม่ช้าก็เร็ว มันจะส่งผลลบในทางใดทางหนึ่ง แบบที่เรามักจะเดาไม่ได้ว่าจะเกิดอะไรขึ้น แถมบางทีความวิบัติเกิดขึ้นแล้ว ก็ยังดันวิเคราะห์ไม่ได้ด้วยว่า สาเหตุมันมาจากการออกนอกตำราที่จุดใด เพราะมัวแต่ไปโฟกัสที่ความเสียหาย จนลืมยกทฤษฎีมาเป็นหลักในการค้นหาสาเหตุ

ปัญหาของตู้ B ถ้าคิดแก้แบบง่าย ๆ ก็แค่ซื้อ UPS ใหม่ ใหญ่กว่าเดิม มาเพิ่มให้ตู้ B นั่นคือตัวอย่างที่ดีของการโฟกัสที่ความเสียหาย โดยไม่ใช้ทฤษฎีมาวิเคราะห์หาสาเหตุ มองไปที่ UPS ว่ามันเล็กไป แต่ไม่ได้ให้ความสำคัญกับทฤษฎี ที่ชี้ชัดว่า เซิร์ฟเวอร์ไม่ควรอยู่ในตู้ B ตั้งแต่ต้น

ทฤษฎีจะใช้ไม่ได้ในทางปฏิบัติ ถ้าเป็นการปฏิบัติงานกับระบบที่ไม่เคยทำตามทฤษฎีมาก่อน ความพยายามที่จะตบระบบให้เข้าตามตำราอีกครั้ง มักใช้ความพยายาม ใช้แรงงาน ใช้งบประมาณมากกว่าการเริ่มต้นอย่างถูกต้องตั้งแต่วันแรก และแม้ระบบจะทำไว้ดีถูกต้องตามทฤษฎีเพียงใด ขอให้มีแค่ครั้งเดียวที่มีคนคิดว่า “ทฤษฎีมันใช้ไม่ได้” แล้วเริ่มงัดเอา “วิธีที่ไม่มีชื่อเรียก” มาใช้ ระบบนั้นก็จะกลายเป็นครึ่งผีครึ่งคนที่ไม่มีใครรู้จัก ไม่มีใคร Follow ระบบนั้นได้ เป็นภาระกรรมให้คนต่อ ๆ ไปต้องออกนอกทฤษฎีด้วยความจนใจ จนกว่าจะมีใครใจกล้า ยอมเงินเสียเวลา รื้อระบบกลับเข้าที่ สู่ทฤษฎีที่ถูกต้องอีกครั้ง

ทฤษฎีใช้ไม่ได้ อันนั้นเรื่องนึง แต่ความไม่เข้าใจในทฤษฎี อันนั้นหนังคนละม้วน พอไม่เข้าใจก็ประยุกต์ใช้ไม่ถูกต้อง แล้วมันก็ทำให้เกิดผลในทางที่ไม่คาดหวัง พองานไม่สำเร็จอย่างที่คิด ก็ไปสร้างข้อสรุปว่า “ทฤษฎีใช้ไม่ได้ในทางปฏิบัติ” หาทางลงให้กับข้อผิดพลาด จนตัวเองหลงเชื่อไปจริง ๆ ว่า ทฤษฎีมันเป็นแค่เรื่องสวยหรูในตำราของพวกนั่งอยู่ในห้อง ไม่เคยอยู่หน้างาน คิดกันไปไกลซะแบบนั้นก็มี

ทฤษฎีไม่ใช่ข้อบังคับ แต่เป็น Guide line ให้เราสามารถหยิบไปปฏิบัติแบบไม่ต้องคิดตามก็ได้ แต่จะดีมากถ้าเราพยายามวิเคราะห์ว่า อะไรทำให้ทฤษฎีแนะนำให้เราทำแบบนั้นแบบนี้ ถ้าเราเข้าใจ เราจะไม่ต้องท่องจำอะไร เราจะไม่รู้สึกฝืน แต่เราจะปฏิบัติงานตามทฤษฎีอย่างเป็นธรรมชาติ เราจะสังเกตเห็นข้อผิดพลาดได้เร็วกว่าคนอื่น เห็นมันตั้งแต่ปัญหายังไม่เกิด และเมื่อเกิดปัญหา เราจะแก้มันได้เร็วและตรงจุด แก้แล้วปัญหาไม่เกิดซ้ำ และมีชีวิตที่สงบสุขโดยไม่ต้องลุ้นระทึกว่า จะมีเรื่องด่วนเกิดขึ้นเมื่อไหร่

ทฤษฎีใช้ไม่ได้ในทางปฏิบัติ “เฉพาะบางกรณี” เท่านั้นครับ

เราต้องซื้อ SUBSCRIPTION กันจริง ๆ เหรอ

ผมได้ยินมานับครั้งไม่ถ้วนที่ลูกค้าต่อรองจะซื้อแต่ฮาร์ดแวร์ โดยไม่ต้องการซื้อ Subscription สิ่งที่ผมกังวลไม่ใช่เรื่องถูกลงหรือแพงขึ้น แต่ผมห่วงเรื่องความเข้าใจที่ถูกต้องต่างหาก

Subscription ที่เข้าใจกันทั่วไปคือสิ่งที่ต้องจ่ายเพิ่ม (บางทีถูกบังคับซื้อ) มันพ่วงมากับฮาร์ดแวร์ ควรซื้อไว้ “จะได้มีประกัน” เข้าใจกันง่าย ๆ ว่า ถ้าไม่จ่ายค่า Sub เกิดฮาร์ดแวร์เสียขึ้นมา ก็จะเคลมไม่ได้ เข้าใจกันไปแบบนี้

ความเข้าใจแบบนี้แหละครับ ที่น่าเป็นห่วง แล้วมักจะไปกลายเป็นปัญหาในวันหลัง

ฮาร์ดแวร์ที่ว่านี้ จะเป็นตัวอะไรก็ได้ครับ Access Point, Firewall, Switch, Router, Server, SAN ฯลฯ เดี๋ยวนี้มี Subscription แล้วทั้งนั้น

ผมว่าตอนนี้ทุกคนก็พอจะรู้อยู่ในใจลึก ๆ ว่า ฮาร์ดแวร์มันราคาไม่เท่าไหร่ มีที่ไหนครับ กะอีแค่กล่องพลาสติกหุ้มแผงวงจรขนาดเท่าจานข้าว กับลวดอีกไม่กี่เส้น จะมาขายกันตั้งหลายหมื่น เราแน่ใจเหรอครับว่า เงินที่เราจ่ายค่าฮาร์ดแวร์นั้น มันคือค่าพลาสติกกับค่าแผงวงจร มันแพงขนาดนั้นเลยเหรอ ไม่ใช่มั้ง…..

คำตอบคือ ซอฟต์แวร์หรือเฟิร์มแวร์ครับ ไอ้นี่แหละตัวแพงเลย คิดง่าย ๆ ครับ แค่เอา iOS ออกจาก iPhone ไอ้ก้อนแบน ๆ นั่นเป็นโทรศัพท์ยังไม่ได้เล้ย ประโยชน์ของมันเหลือ 0 ทันที

หยิบเอาฮาร์ดแวร์อะไรมาก็ได้ครับ แค่ปลดซอฟต์แวร์ออก ฮาร์ดแวร์นั้นหมดความหมายทันที รู้แบบนี้ คุณว่าที่เราจ่ายเงินซื้อฮาร์ดแวร์นั้น เราจ่ายค่าวัสดุ หรือเราจ่ายค่าซอฟต์แวร์ พอจะมองออกมั้ยครับ

ซอฟต์แวร์ที่ควบคุมฮาร์ดแวร์ ก็จะเรียกว่าเฟิร์มแวร์ เรียกกลับไปกลับมา ซอฟตแวร์/เฟิร์มแวร์ ไม่งงนะครับ

ซอฟต์แวร์มันมาจากคนที่ลงแรงเขียนมันขึ้นมา ซึ่งมันก็มีการปรับปรุงเมื่อพบข้อผิดพลาด เรียกว่า Bug fix แล้วมันก็ทำให้ดีขึ้นได้ เรียกว่า Upgrade แต่ไม่ว่าจะเป็น Bug fix หรือ Upgrade มันก็คือต้องจ้างคนมานั่งทำ ก็ไม่ได้จ้างแค่คน-สองคนนะครับ ทีมนึงบางทีก็มีหลายร้อยคน แต่ละคนค่าตัวก็ไม่ถูก เงินค่า Subscription ของเราก็จ่ายให้กับทีมพัฒนาซอฟต์แวร์ที่มาทำ Bug fix และ Upgrade นี่แหละครับ และเราก็อัพเกรดเฟิร์มแวร์ เพื่อให้ฮาร์ดแวร์ที่เราซื้อนั้นไม่มีปัญหา และทำงานได้มากขึ้น

การ Upgrade บางทีก็ไม่ได้ Upgrade ตัวซอฟต์แวร์นะครับ แต่เป็นการ Upgrade database เช่น Antivirus ก็มีการ Upgrade Virus signature database นี่ก็มีคนทำอยู่เบื้องหลังเหมือนกัน ค่า Subscription บางทีก็หักไปจ่ายให้ส่วนนี้ด้วยครับ

เดี๋ยวนี้เฟิร์มแวร์ก็ไม่ได้ทำงานด้วยตัวเองแล้ว แต่ทำงานกับ Cloud service อย่าง Wifi Access Point เดี๋ยวนี้ก็มี Cloud controller ให้เลือกใช้ ไม่ต้องซื้อฮาร์ดแวร์มาตั้งที่ออฟฟิศให้เปลืองไฟเปลืองที่ Cloud Service มันก็ไม่ใช่ว่าจะได้มาฟรี ๆ นะครับ ต้องมีใครซักคนจ่ายค่า Data center เพื่อตั้ง Cloud service ขึ้นมา เงินจำนวนนั้นก็มาจาก Subscription ที่เราจ่ายออกไป

ฮาร์ดแวร์ที่เราซื้อนั้น ก็ซื้อมาประกอบกันเป็นระบบ ยิ่งหลายชิ้นก็ยิ่งซับซ้อน พอมีปัญหา ใครจะรู้เรื่องดีที่สุดถ้าไม่ใช่ผู้ผลิต ซึ่งเวลาเราติดต่อไปก็คุยกับฝ่าย Support ของผู้ผลิต ค่า Subscription ของเราก็เอาไปจ้างฝ่าย Support มาคอยตอบปัญหาของเรานี่แหละครับ

เห็นมั้ยครับ ค่า Subscription มันมีอะไรตั้งเยอะที่นอกเหนือจากเรื่อง “ประกันฮาร์ดแวร์”

ที่ผมอธิบายทั้งหมด ถ้าจะให้เห็นภาพง่าย ๆ ลองนึกถึงเวลาไปกินเอ็มเคแล้วสั่งลูกชิ้นมา 1 ถาด ในถาดนับได้ 6 ลูก ถาดละ 60 บาท ในขณะที่ลูกชิ้นหน้าตาคล้าย ๆ กันขายในห้างเดียวกันกับที่เรานั่งกินสุกี้นั้น ขายอยู่ขีดละไม่ถึง 20 บาท มีตั้งเกือบ 10 ลูก ลูกละไม่ถึง 2 บาท แบบนี้เราจะเปรียบเทียบราคาลูกชิ้นแล้วรู้สึกว่าเรากินแพงหรือเปล่า ครอบครัวเรากำลังลวกจิ้มอย่างเมามันกับการจ่ายแพงขึ้น 5 เท่าอย่างนั้นหรือ ???

ดูจากคิวที่นั่งรอกันหน้าเอ็มเค ผมว่าทุกคนเข้าใจนะครับว่า ลูกชิ้นถาดนั้นมันรวมต้นทุนอื่น ๆ เข้าไปด้วย ทั้งค่าสถานที่ ค่าพนักงาน ค่าหม้อต้ม-เตาไฟฟ้า ไหนจะน้ำจิ้มอีก น้ำชาที่เราคิดว่าฟรีจริง ๆ แล้ว มันก็จ่ายผ่านค่าลูกชิ้นนี่แหละครับ ถ้าเข้าใจกันและยอมรับกันได้ลักษณะนี้ ก็ไม่น่าจะยากเลยที่จะเข้าใจว่า Subscription มันมีบริการอื่นอีกเยอะแยะตามมา ไม่ใช่แค่เรื่องประกันฮาร์ดแวร์อย่างที่เข้าใจกัน

ค่า Subscription ถ้าเรามองเห็นแค่ว่ามันคือค่าประกันฮาร์ดแวร์ ก็ไม่แตกต่างจากการไปที่เอ็มเค แล้วสั่งลูกชิ้น 1 ถาดราคา 60 บาท แล้วขอห่อสด ๆ กลับบ้าน โดยไม่ได้นั่งในร้านของเขา ไม่ได้ใช้บริการจากพนักงานของเขา ไม่ได้ลวกจิ้ม ไม่ได้จิบน้ำชาอะไรกันเลย นั่นแหละครับ ลูกละ 10 บาทเห็น ๆ เลย แพงยับแน่นอน ถูกมั้ยครับ ก็ไม่แปลกนะครับที่เราจะรู้สึกไม่อยากจ่ายค่า Sub เพราะเรามัวแต่คิดว่า ค่า Sub มันคือค่าเคลมฮาร์ดแวร์ คิดแบบนี้ค่า Sub มันก็แพงยับเหมือนกัน

คำถามสำคัญคืออันนี้ครับ...เราเคยถามคนขายหรือเปล่าว่า เราจ่ายค่า Subscription ให้กับทางผู้ผลิตแล้ว เราจะได้อะไร ???

ได้อัพเกรดเฟิร์มแวร์หรือเปล่า ได้อัพเกรด Signature หรือเปล่า ได้ใช้ Cloud มั้ย ได้ติดต่อกับ Support ของผู้ผลิตมั้ย ติดต่อทางไหน e-mail, chat, web, โทร ผู้ผลิตทุกรายเขามีเอกสารให้อ่านครับ ซื้อ Sub แล้วได้อะไร ศึกษาไว้อธิบายให้ผู้บริหารฟังได้ ก็จะของบกันง่ายขึ้นนะครับ

อีกเคสนึงนะครับ ผมเคยได้ยินลูกค้าบอกว่า ฮาร์ดแวร์ตัวละ 10,000 ซื้อมาล้อตเดียว 10 ตัว เป็นเงินแสนนึง ค่า Sub ปีที่ 2 คิด 15% เป็นเงิน 15,000 โอ้ย…จะซื้อ Sub ไปทำแป๊ะอะไร ก็เอาเงินแค่หมื่นเดียวซื้อฮาร์ดแวร์ Spare มาทิ้งไว้ที่ออฟฟิศเพิ่มอีกตัวนึง ประหยัดไปได้ตั้ง 5,000 แบบนี้โอเคมั้ย

ผมว่าเหมือนซื้อรถแล้วไม่เอาเข้าศูนย์ แต่ใช้วิธีหาซื้ออะไหล่มาพยายามใส่เอง ถูกกว่าแน่นอนครับ เพราะจ่ายแต่ค่าฮาร์ดแวร์ แต่เราต้องวิเคราะห์เอง ซ่อมเอง มุดใต้ท้องรถ มอมแมมทำทุกอย่างเองจนจบ จะไปนั่งห้องแอร์จิบกาแฟอย่างคนที่เขาเข้าศูนย์ คงไม่ได้ นั่นแหละครับ ฮาร์ดแวร์โอนลี่ ภาพจะเป็นแบบนั้น บางคนที่มีความสุขกับ Slow life เรียนรู้เอง ทำเอง DIY กันสุด ๆ ก็อาจจะชอบ แต่ทางภาคธุรกิจเจ้าของเงิน เขาจะแฮปปี้ Slowly กับเราด้วยหรือเปล่า คิดดูให้ดีครับ

ผมรู้ว่า หลายคนไม่อยากซื้อ Sub ไม่ใช่เพราะไม่อยากได้ แต่ไม่รู้จะใช้มันยังไง คือไม่อยากอัพเกรดเพราะกลัวว่าอัพไปแล้วระบบจะมีปัญหา ไม่เปิดเคสกับทางผู้ผลิตเพราะภาษาอังกฤษไม่แข็งแรง ก็เลยซื้อ Sub เพราะจะเอาประกันฮาร์ดแวร์เท่านั้น กึ่ง ๆ โดนบังคับซื้อ แบบนี้ควรซื้อ Sub มั้ย หรือซื้อฮาร์ดแวร์มา Spare อย่างที่ว่าจะดีกว่า

ในความเป็นจริง เวลาเรามีปัญหา เราแก้ไม่ได้ ก็ขอให้ฝ่าย Support ของคนขายมาช่วย หลายครั้งปัญหามันถูกแก้ด้วยการอัพเกรดเฟิร์มแวร์ บางทีปัญหานั้นต้องหันไปปรึกษากับผู้ผลิต Subscription ก็จะได้ใช้กันตอนนี้ล่ะ ก็คือว่าแม้เราจะไม่ได้ใช้เอง ก็ยังต้องมี Subscription เอาไว้ให้คนที่แก้ปัญหาเขาหยิบมาใช้ได้ครับ

ตราบใดที่ฮาร์ดแวร์ ยังต้องใช้จ้างทีมมาพัฒนาซอฟต์แวร์ และยังต้องจ้างทีม Support มาคอยให้บริการ ค่า Subscription มันจะต้องมีอยู่ที่ไหนซักแห่ง เราจะต้องจ่ายค่า Subscription ในทางใดทางหนึ่งอย่างเลี่ยงไม่ได้ ไม่จ่ายรวมเป็นก้อนเดียวตอนซื้อ ก็จ่ายแยกเป็นรายปี หรือรวมอยู่ในค่าบริการรายเดือน อยู่ที่ว่าเราจะมองออกหรือเปล่าเท่านั้น

คนไอที ต้องพึ่งสิ่งศักดิ์สิทธิ์มากแค่ไหน

ระบบล่มเพราะหนูกัดสายไฟเบอร์

ออกเน็ตไม่ได้เพราะไฟไหม้อาคารถนนถัดไป ลามไปหาสายไฟเบอร์ของ ISP ที่เราใช้บริการอยู่

เฟิร์มแวร์มีบั๊ก ใครจะไปรู้ล่วงหน้า

2 ปีมีตั้งหลายวัน ทำไมบอร์ดของเซิร์ฟเวอร์มันต้องมาเลือกพังเอาวันนี้

เดี๋ยวกล้องนู้นดับ เดี๋ยวกล้องนี้มีปัญหา ส่งงานไม่ได้ซะที เตรียมพวงมาลัย จุดธูปไหว้เจ้าที่ทีเดียว ทุกอย่างทำงานปกติ ส่งงานฉลุย

เรื่องซวย ๆ ที่ผมยกตัวอย่าง ที่บางคนอาจเคยเจอกับตัว บางคนไม่เคยเจอปัญหาเหล่านี้เลย บางคนอาจจะนึกในใจว่า มันไม่เกี่ยวกับดวงหรอก มันเรื่องป้องกันได้ทั้งนั้น บางคนอาจจะบอกว่า ไม่เชื่ออย่าลบหลู่ เรื่องแบบนี้ต้องเจอกับตัวเอง ไอทีกับเรื่องดวง เกี่ยวกันมั้ย มาดูกันครับ

เริ่มแรกก่อนคือ คนที่มีปัญหา และหาคำตอบไม่ได้ ไม่มีทางออก คือคนที่เครียดนะครับ ซึ่งพอเครียด งานก็ไม่ดี ไม่เหมือนคนที่สบายใจ ตั้งสติทำงานได้ดีกว่า พอใจไม่ว้าวุ่น สติก็ค่อย ๆ มา บางคนก็ตั้งสติได้โดยไม่ต้องพึ่งพาอะไร บางคนใช้กาแฟเป็นเครื่องสงบจิตใจ จึงไม่แปลกอะไรที่คนไทยอย่างเราจะใช้ธูปเทียนและการบูชาสิ่งศักดิ์สิทธิ์ ทำให้เราสงบใจจากปัญหาที่แก้ไม่ตก เครื่องเซ่นไหว้อย่างน้ำแดงซักขวด ก็ทำให้ความมั่นใจเพิ่มขึ้นว่า ตัวช่วยมาแล้ว ผมจึงเห็นดีในแง่นี้ ถ้าเราทำอะไรแล้วคิดว่าจิตใจเราสงบ แม้จะอธิบายไม่ได้ว่า สัญญาณไฟฟ้าหรือซอฟต์แวร์มันจะดีขึ้นได้อย่างไร ก็ทำไปเถอะครับ

ซึ่งที่ผ่านมา ผมก็ยังไม่เคยเห็นทีมเดินสาย LAN ที่เดินทางมาหน้างานพร้อมคณะนางรำ แล้วตรงดิ่งไปที่ศาลพระภูมิหน้าออฟฟิศก่อนจะเริ่มงาน ผมยังไม่เคยเห็นพิธีบวงสรวงใหญ่โตก่อนเปิด Data center แปลว่าเท่าที่ทำ ๆ กันอยู่ในวงการไอที ผมว่าก็พองามแล้ว โยงสายสิญจน์ เจิมหน้าห้อง หรือใครอัญเชิญพระไปวางเหนือตู้ Rack ถ้าสบายใจก็ทำไปเถอะครับ มองรอบตัวหน่อยละกัน คนเข้าใจก็มี คนไม่เข้าใจก็เยอะ

ความสบายใจคือผลตอบแทนที่หวังผลได้ แต่การไปหวังผลลัพธ์อัศจรรย์ด้านอื่น อาจจะเป็นการลงทุนที่มีความเสี่ยง ผู้ลงทุนควรคิดดี ๆ ก่อนการตัดสินใจลงทุน ผลตอบแทนอาจเป็นศูนย์ แม้ท่านจะได้ทุนคืนเป็นน้ำแดงไม่ดูดเล่นซะหนึ่งขวดก็ตาม

ถัดมาที่น่าคิด ผมขอหยิบคำฝรั่งที่เขาพูดกันว่า Murphy’s Law ซึ่งเขาบอกว่า “ถ้ามีวิธีที่จะทำให้ความผิดพลาดเกิดขึ้นได้ มันก็จะเกิดในที่สุด” ยกตัวอย่างเช่น คุณเคยกลัดกระดุมเสื้อเชิ้ตเม็ดแรกผิดมั้ยครับ กว่าจะไปรู้ตัวก็ตอนเม็ดสุดท้ายที่ชายเสื้อมันไม่เท่ากันนั่นแหละ เกิดขึ้นไม่บ่อย แต่มีโอกาสเกิดขึ้นได้ แล้วมันก็จะเกิดในที่สุด

คุณเคยเผลอบีบโฟมล้างหน้าบนแปรงสีฟันมั้ยครับ คนธรรมดาอย่างเราไม่ต้องเป็นอัลไซเมอร์ก็มีโอกาสพลาดได้ แค่เอื้อมไปหยิบผิดหลอดก็คือว่าโอกาสพลาดได้เป็นจริงแล้ว ซึ่งถ้าคิดแบบ Murphy’s Law โอกาสผิดพลาดแบบนี้จะถูกป้องกันเอาไว้ก่อน

มีโอกาสที่หนูจะมาแทะสายไฟเบอร์ของเราได้มั้ย ถ้าคิดแบบ Murphy’s Law เราจะรอบคอบขึ้น เราจะ “เคารพโอกาสที่จะเกิดความผิดพลาด” มากขึ้น เราจะเริ่มมองเห็นหัวของมัน เราจะเริ่มเห็นอนาคตว่า ตำแหน่งเดินสายแบบนั้น หนูกัด…มีโอกาสเกิดขึ้นได้ พอคิดได้แบบนี้ เราก็เลยเลือกสาย Fiber ที่มีเกราะหุ้มเป็นอลูมิเนียม หรือไม่ก็ร้อยสายไฟเบอร์ในท่อเหล็กซะเลย หรือไม่ก็เดินสายไฟเบอร์อ้อมไปอีกเส้นทางหนึ่งสำรองเอาไว้

การคิดแบบ Murphy’s Law ไม่ได้หวังผลว่าเราจะต้องลงทุนป้องกันอย่างเอาเป็นเอาตายนะครับ ไม่ใช่ทุกระบบที่จะต้องมี Backup system แต่มันเป็นแนวคิดที่ทำให้เรารู้ว่า โอกาสที่ความซวยจะมาเยือนเรามีมากแค่ไหน ในรูปแบบไหน และที่สำคัญ คนที่จะได้รับผลกระทบจากความซวยนั้น ควรจะได้รับรู้ชะตากรรมล่วงหน้าร่วมกัน ฝ่ายไอที ฝ่ายบริหาร ฝ่ายผู้ใช้ระบบ ได้รับอัพเดตล่วงหน้าว่า ระบบของเรากำลังพึ่งพาโชคมากกว่าพึ่งพามาตรการ หรือธุรกิจของเรายินดีรับ Downtime อันเกิดขึ้นจากสิ่งที่คาดการณ์เอาไว้ล่วงหน้า ถ้าร่วมหัวจมท้ายกันแบบนี้ เวลาระบบล่ม นิ้วคงไม่ชี้มาที่ฝ่ายไอทีเพียงแผนกเดียว

ความซวยที่เรารู้ล่วงหน้า ไม่เรียกว่าความซวยแล้ว ถูกมั้ยครับ จะเรียกสวย ๆ ว่า Part of the plan ยังได้เลย ไม่มีใครประสบความสำเร็จจากการทำระบบที่ไม่มีวันล่ม เพราะใช้งบประมาณบานปลายและจ่ายแพงไม่รู้จบ แต่ Murphy’s Law ทำให้เรามองเห็นโอกาสของความล้มเหลวและค่าใช้จ่ายในการป้องกัน เป็นเนื้อหาที่จะนำเสนอให้ฝ่ายบริหาร นำไปคิดต่อได้ว่า ถ้าไม่ล่มแล้วธุรกิจจะได้อะไร ธุรกิจได้เงินจากการไม่ล่ม มากกว่าที่จะจ่ายค่าป้องกันหรือเปล่า แล้วฝ่ายบริหารเขาจะเลือกรับความเสี่ยงและกำหนดงบประมาณออกมาเอง ฝ่ายไอทีก็รับงบประมาณมาทำระบบที่สามารถล่มได้ตามแผน แบบนี้ก็คือการทำความซวยให้เป็น Part of the plan โดยใช้แนวคิด Murphy’s Law ครับ

ก็ไม่ใช่ทุกคนที่จะสามารถมโนภาพให้เห็นความซวยในอนาคตได้ ประสบการณ์ของเราไม่เท่ากัน ความรู้ไม่เท่ากัน ถึงเวลาที่จะต้องล้างซวยสะเดาะเคราะห์ หันหน้าเข้าหาสิ่งศักดิ์สิทธิ์กันแล้วหรือเปล่า

อย่างที่ผมบอก เราบูชาสิ่งศักดิ์สิทธิ์เพื่อความสบายใจได้ แต่ท่านไม่ได้มานั่งวางระบบกับเรา ท่านไม่ใช่ Audit ใช้ท่านเป็นเครื่องยึดเหนื่ยวได้ แต่สิ่งที่เราจะพึ่งพาได้นั้น ในวงการไอทีเราพึ่งพาหลักการที่มีคนเขียนตำราเอาไว้เยอะแยะครับ Risk Management, ISO, PCI, HIPAA, COBIT, FISMA, มาตรฐานงานโยธา, มาตรฐาน Data Center, เครื่องมือในช่วยในการบริหาร Team Developer และอีกเยอะแยะมากมาย เหล่านี้ แม้จะไม่มี Audit คอยจี้ตูดหรือองค์กรของเราจะไม่มีนโยบายที่จะผลักดันให้ผ่านมาตรฐานพวกนี้ ผมแนะนำให้หยิบมาตรฐานพวกนี้มาอ่านตาม scope งานที่เรารับผิดชอบ ทำความเข้าใจ เพราะมาตรฐานพวกนี้ “เขียนมาจากการประสพพบความซวย” ของระบบในอดีต สะสมมาจนเป็นสารานุกรมของสิ่งที่ควรทำ เพื่อไม่ให้คนอื่นต้องซวยซ้ำซ้อนตามกันไปในอนาคต ไม่แตกต่างจากมาตรฐานการบินที่เขียนขึ้นมาจากความผิดพลาดในอดีตที่ค่อย ๆ ค้นพบตอนอยู่บนฟ้านั่นแหละครับ

ลองอ่านดูครับ ถ้าเราคิดออกว่า หัวข้อที่เขาให้เราทำนั้น มันถือกำเนิดมาจากความซวยหน้าตาอย่างไร แค่เราเห็นภาพก็ถือว่าเราบรรลุ และพร้อมจะรับมือกับความซวยหน้าตาแบบนั้น ภายในกรอบงบประมาณของเราแล้ว ก็วางมาตรการป้องกันกันต่อไปเท่าที่ปัจจัยของเราจะอำนวย

เรื่องความซวยในวงการไอที ป้องกันได้ ตามปัจจัยและงบประมาณของแต่ละองค์กร ตราบเท่าที่เราไม่วางใจและฝากทุกอย่างไว้กับอำนาจเหนือธรรมชาติ

สิ่งศักดิ์สิทธิ์เป็นเครื่องยึดเหนี่ยวจิตใจไม่ให้ฟุ้งซ่าน คลายกังวล เรียกสติ สร้างกำลังใจ ให้เราทำงานได้ดีขึ้นครับ

ต้องการข้อมูลเพิ่มเติมเรามีพันธมิตรพร้อมให้คำปรึกษาติดต่อแผนก Marketing

02-2479898 ต่อ 87

เคล็ดลับการ BLOCK YOUTUBE ลงแรงน้อย ได้ผลมาก

IT หลายท่าน ได้รับมอบหมายภาระกิจสำคัญให้ Block Youtube ให้พ้นออกไปจากองค์กร และหลายท่านก็มุ่งมั่นที่จะบรรลุเป้าหมายนั้นให้จงได้ มารร้าย Youtube ต้องหายไปจากระบบ แต่มันยังมี…User อีก 2 คนที่มันยังแอบไปเอา UltraSurf มามุดรอดผ่าน Firewall ของเรา UltraSurf คือเป้าหมายตัวต่อไปของเรา เราจะต้องจัดการกับมันให้จงด้ายยยยย !!!!

บรรยากาศนี้ ผมนึกถึงหน่วย Shield ขึ้นมาเลย Alien เปิดมิติทะลุฟ้าบุกมหานครนิวยอร์ค super hero ก็ฟัดกับ alian ล่อกันซะตึกรามบ้านช่องปนปี้ยับเยิน ท้ายสุดแม้จะชนะ แต่ฝ่ายชนะก็ไม่เหลืออะไร เรียกว่า ชนะเพื่อชนะจริง ๆ

Shield กับ IT มีข้อเหมือนกันคือ กำจัดเหล่าวายร้าย และมีข้อเหมือนกันอีกข้อคือ กำจัดมันหมดไปอย่างสิ้นซาก ฆ่าทุกตัว ตายยกรัง ไม่มีหลุดรอด

เราดูหนังพวกนี้แต่เด็ก เราถูกใส่ Method ในการไล่บี้มาในหัวมาช้านานและต่อเนื่อง เราถูกสอนให้มี 2 ฝ่ายที่จะต้องไล่เข่นฆ่าล้างบางกัน IT บางท่านแอบแค้นใจลึก ๆ เวลาเห็น User หลุดรอดไปใช้ youtube ได้สำเร็จ ผมว่าปัญหามันไม่น่าจะแก้ได้ด้วยวิธีเดียวนะครับ

วันนี้ผมจะมาชวนมองต่างมุม มองจากมุมของคนที่ดูแล Firewall เหมือนกับแผนก IT ทั่วไป

แต่ผมมีวิธีที่ลงแรงน้อยกว่า แต่ได้ผลเกินคาด เคล็ดลับมันมีอยู่ 2 ข้อครับ

เคล็ดลับอยู่ที่ตอนรับคำสั่งครับ ท่านที่ทำแผนก IT เมื่อได้รับมอบหมายให้ block youtube ให้ถามคนที่สั่งกลับไปให้ชัดก่อนครับ “จะให้ block youtube หรือจะให้คนตั้งใจทำงานมากขึ้น ?” เพราะเคล็ดลับข้อแรกนี้คือ คนไม่เล่น youtube มันก็ไปเล่นอย่างอื่น คนมีลำดับพฤติกรรมคือ เริ่มจากไม่ตั้งใจทำงาน ก็เลยหาอย่างอื่นทำที่ไม่ใช่งาน ก็เลยเปิด youtube ขึ้นมา แผนก IT ที่มัวแต่ไปวิ่งไล่เก็บของเล่นให้เด็ก มันไม่ทำให้เด็กเลิกซน ถูกมั้ยครับ

หลายครั้ง คนที่สั่งเรา เขาไม่เข้าใจคำถาม เขาก็จะยืนยันในสิ่งที่เขาถูกสั่งมาอีกที คือให้ block youtube อันนี้แล้วแต่เวรกรรมของใครจะได้ทำงานกับผู้นำแบบไหนนะครับ ไม่แปลกที่บรรยากาศในแผนก IT จะไปคล้ายห้องบัญชาการรบของหน่วย Shield ที่เห็น youtube เป็นศัตรู และเห็น Firewall เป็นอาวุธ มากกว่าจะให้ความสำคัญกับ Productivity ที่องค์กรจะได้คืนมาจากพนักงานที่กลับมาตั้งใจทำงาน ถ้าหัวหน้าหรือผู้บริหารเขาสวมบท Nick Fury คุณก็ต้องเริ่มปฏิบัติการไล่บี้ไปตามระเบียบ

ฝ่าย IT เองก็ต้องปรับตัวเช่นกัน ถ้าคำตอบออกมาว่า องค์กรต้องการ Productivity ของพนักงาน โจทย์เปลี่ยน Method ก็เปลี่ยนนะครับ เพราะ Productivity ของการทำงานนั้น มาจากคน และในองค์กรมีแผนกที่จัดการคนคือแผนก HR ครับ HR คือเคล็ดลับข้อ 2

ลองคิดตามนะครับว่า HR มีพลังในการเรียก Productivity คืนกลับมาจากพนักงานเหลวไหลได้แค่ไหน และผลที่ได้ตามมานั้น คือการใช้ YouTube ก็ลดลงตามไปด้วย

– HR ออกประกาศทั้งออฟฟิศ ต่อไปนี้องค์กรจะมีการเฝ้าระวังการใช้ YouTube ของพนักงาน ให้อยู่ในระดับพอเหมาะ

– HR เรียกพนักงาน 3 คนแรกที่เปิดดู YouTube สูงสุดประจำสัปดาห์ อ้างตาม Report ที่แผนก IT ส่งให้

– ฝ่าย IT ชี้ให้เห็น่วา โต๊ะที่หันหลังเข้ากำแพง คือโต๊ะที่เล่น youtube เยอะ HR ประสานงานหัวหน้าแผนกปรับหมุนโต๊ะใหม่ การใช้ YouTube ลดลงอย่าได้ผล

– HR ขอความร่วมมือไปยังหัวหน้าแผนก ให้กำชับพนักงานให้ใช้ YouTube เพื่อการทำงาน และอย่าเล่นให้มากเกินไป

ในทางกลับกัน หาก IT ลงไปเล่นบท HR ซะเอง อุปสรรคเกิดขึ้นมากมาย ไปเจอตอทางเทคนิคอย่าง Proxy avoidance ที่มีให้เลือกมากมายหลายร้อยตัว ไปเจอตอทางพฤติกรรมที่ User ก็หนีไปเล่นอย่างอื่น ซึ่ง IT จะต้องตามไล่ block กันต่อไป หรือจะไปเจอตอโดยอำนาจ ไม่ต้องเป็นผู้บริหาร เป็นแค่เซลส์ตัวเล็กที่อ้างว่าระบบมีปัญหาบ่อย เพื่อเอาคืนแผนก IT แบบคลื่นใต้น้ำ แค่นี้ก็เหนื่อยแล้วครับ

แผนก IT ที่ตกอยู่ในสภาวะ HR จำแลง ต้องคิดใหม่โดยใช้ Productivity เป็นธงชัย แล้วเราจะเหนื่อยน้อยลง โครงสร้างขององค์กรถูกใช้ตามหน้าที่ ไม่มี policy บน Firewall ต้องทำเยอะแยะ ไม่ต้องมี exception ยกเว้นให้คนนั้นคนนี้ในเวลานั้นเวลานี้ ทำให้เหมือนเครื่องสแกนนิ้วลงเวลา ที่ไม่มีใครจะมาขอต่อรองกับแผนก IT ให้ช่วยขยับเวลาเข้างานเป็น 10 โมง คำตอบคือ “ไปขอ HR นู่น”

ขอให้ทำงานได้ผล และเหนื่อยกันน้อย ๆ ครับ…

FIREWARE OS รองรับ EDNS จะเกือบ 10 ปีแล้ว

หลายท่านคงจะได้รับทราบข่าว DNS Flag day คือการที่ DNS server จะพร้อมใจกันหันมาใช้ eDNS ที่มีขนาด packet ใหญ่กว่า 512 ไบต์กันอย่างเต็มตัว ซึ่งมีความหมายในทำนองเดียวกันกว่า DNS server ทั่วโลกก็จะปฏิเสธ DNS query แบบเก่าที่มีจุดอ่อนมากมาย โดยมีการกำหนดวันที่จะเริ่ม “เอาจริง” กันในวันที่ 1 กุมภาพันธ์ 2019 นี้

ผลก็คือ เกิดความโกลาหลกันไปพอสมควร องค์กรในไทยอย่าง ThaiCERT ก็ออกโรงเตือน และคนเขียนข่าว-เขียนเรื่องด้านไอทีอีกหลายคน Blogger, post, share, comment ต่างก็หยิบเอาเรื่องนี้มาเตือนต่อ ๆ กันไป ลามมาถึง Firewall และ UTM ที่ถูกตั้งคำถามเหมือนกันว่า รองรับ eDNS หรือไม่ และจะมีปัญหาในการทำงานในวันที่ 1 กุมภาพันธ์นี้ หรือไม่

ต้องบอกว่า eDNS นั้นมีมาจะเกือบ 10 ปีแล้วครับ และ Vendor ใหญ่ ๆ ทุกค่ายต่างก็รองรับ eDNS นี้หมดเลย อย่าง Fireware OS ก็รองรับมาตรฐานนี้ตั้งแต่ 9 ปีที่แล้วนู่น หรือยกตัวอย่าง Windows ก็มี DNS server ในตัวที่รองรับ eDNS ตั้งแต่ Windows 2003 นู่นแล้ว และเชื่อว่า Firewall อื่น ๆ รวมถึง DNS server อีกหลาย ๆ ตัวในตลาด ก็รองรับ eDNS เรียบร้อยแล้วเช่นกัน อาจจะหลงเหลือ DNS server เพียงบางตัวเท่านั้นที่ยังใช้ code เก่าแก่ ซึ่งถึงเวลาจะต้องปรับเปลี่ยนซะที เพราะ code เก่าก็เต็มไปด้วยช่องทางให้โจรใช้ DNS server นั้นเพื่อโจมตีคนอื่น

Fireware OS ของ WatchGuard รองรับทั้ง eDNS และรองรับไปถึง DNSSEC ที่เป็นมาตรฐานที่ใหญ่กว่าและมีความปลอดภัยสูงกว่า ตามเอกสารนี้

สบายใจได้ครับ รอบตัวของเราเต็มไปด้วยอุปกรณ์ที่รองรับ eDNS เกือบทั้งหมด มาตั้งแต่นมนานแล้ว เรียกว่า ถ้าอยากจะหา DNS server ที่ไม่รองรับ eDNS จากรอบตัวเรา กลับเป็นเรื่องที่หายากกว่า แทบจะต้องควานหากันเลยทีเดียว

OPT-Care โดย บริษัท ออพติมุส (ประเทศไทย) จำกัด

REDUNDANCY ควรทำหรือไม่ เพราะอะไร

หลายครั้งที่ผมเห็นการขึ้นระบบใหม่ และข้อหนึ่งที่มักจะถูกหยิบมาพูดกัน คือ เงื่อนไขว่า ระบบจะต้องไม่ล่ม ข้อมูลต้องไม่หาย หรือเน็ตต้องใช้ได้ตลอดเวลา และข้อสรุปก็มักนำไปสู่การซื้อ Redundancy เช่น Redundant Power Supply, RAID Disk, Cluster ของอุปกรณ์ต่าง ๆ เช่น Firewall หรือ Core Switch, Multiple Fiber Optic Cabling และอื่น ๆ อีกมาก

ทีนี้พอถึงคราวพิจารณางบประมาณ Redundancy ที่วางเอาไว้มากมายกลับถูกตัดออกอย่างง่ายดาย ความกังวลเรื่องระบบจะไม่ต่อเนื่อง มันหายไปไหนไม่รู้ ละลายหายไปเฉยเลย คำว่า “ไม่มีงบ” สยบทุกอย่าง สรุปว่าคนที่วาง Redundancy แต่แรกนั้น พี่แกเยอะ หรือคนที่มาตัดออกทีหลังมันซี้ซั้ว คนเสนอมักเป็นฝ่ายไอที คนตัดออกมักเป็นฝ่ายบริหาร ตกลงใครถูกใครผิด

มีตลกร้ายกว่านั้น คือในวันที่ฮาร์ดแวร์มีปัญหา ระบบล่มเพราะไม่มี Redundancy ฝ่ายไอทีตะโกนก้องในใจ “กูบอกมึงแล้วไงให้ซื้อ Redundant” แม้ความจริงฝ่ายไอที จะเป็นฝ่ายที่ถูกเฉ่งอยู่ตลอดก็ตาม ในขณะเดียวกัน ฝ่ายบริหารเองก็รู้สึกเหมือนโดนมัดมือชก ถ้าไม่จ่ายตามที่เสนอตอนต้นปี มันก็ตามมาราวีตอนกลางปี พังกันซะตรงหน้า อ่ะ…ยังไงก็ต้องจ่าย นี่มันมัดมือชกชัด ๆ เลย ต่างฝ่ายต่างก็ไม่แฮปปี้ แล้วอย่างนี้ Redundancy มันมีเรื่องดี ๆ อยู่ตรงไหน

เวลาพูดถึง Redundancy ผมอยากให้นึกกว้างไปถึงทุกอย่างที่มีซ้ำกันมากกว่าหนึ่งที่สามารถทำงานทดแทนกันได้ ซึ่งเราจะคิดถึง Redundancy ใน 3 ระดับครับ ไล่จากง่ายไปยาก, ถูกไปแพง, Manual ไป Auto

Redundancy แบบ Active/Standby หรือ Active/Passive แปลว่า ตัวหนึ่งทำงาน อีกตัวอยู่เฉย ๆ และเวลาที่เกิดปัญหา จะต้องมีใครซักคนไปสลับการทำงานจากตัว Active ที่หยุดทำงานไปแล้ว ให้ Passive มาทำงานแทน เช่น สวิตช์สำรองที่ซื้อเก็บไว้, Generator ที่ต้องมีคนไปเปิดใช้ตอนไฟดับ

แบบแรกนี้จะ”ถูกสุด”เพราะไม่ต้องมีระบบหรือกลไกอะไรมาบอกว่าเมื่อไหร่ตัวสำรองจะเริ่มทำงาน เพราะเราเอาคนมาทำงานตรงนี้ และแน่นอนว่าการสลับจากระบบหลักไประบบสำรอง ย่อมใช้เวลาพอสมควร

Redundancy ถัดมาคือแบบ Failover คือความสามารถในการที่อุปกรณ์ตัวสำรอง จะสามารถรับภาระของตัวหลักได้ทันที โดยที่คนไม่ต้องเข้าไปเกี่ยวข้อง แบบที่สองนี้จะมีราคาและความยุ่งยากเพิ่มขึ้นมา เพราะระบบสำรองต้องมีกลไกเอาไว้คอยดูระบบหลักว่ายังทำงานอยู่หรือเปล่า (Heartbeat) และระบบสำรองอาจต้องตื่นขึ้นมาทำงานแทนแบบทันทีทันใด (High availability) โดยงานที่ทำนั้น จะต้องต่อเนื่องสมบูรณ์ ไม่ใช่ว่าต้องเริ่มทำใหม่ (Active/Standby Synchronization)

Redundancy แบบสุดท้าย คือ Load Balancing ก็คือ อุปกรณ์ทุกตัวใน Redundant set ทำงานพร้อมกันหมด รับภาระงานด้วยกันหมด ถ้าตัวใดหยุดทำงาน ตัวที่ทำงานอยู่ก็จะรับภาระนั้นไป จะเรียกว่าเป็น Active/Active ที่ตรงข้ามกับ Active/Standby ก็ได้ ทั้งนี้ ต้องไม่ลืมประเมินว่า อุปกรณ์ที่คอยรับภาระจากตัวที่หยุดทำงานไปนั้น ต้องมี Capacity พอจะรับงานได้ นั่นจึงเป็นที่มาของ Redundancy แบบ N+1

แบบที่ 3 นี้มักจะเป็นระบบที่”แพงที่สุด”ด้วย Performance ของอุปกรณ์ที่อาจจะต้องใกล้เคียงกับ License ที่จะต้องเหมือนกัน ฯลฯ แต่ก็ได้ข้อดีคือ Capacity ของระบบเพิ่มขึ้นเพราะอุปกรณ์ทุกตัวทำงานหมด ไม่มีตัวไหนอยู่เฉย ๆ

หลายระบบมีออพชั่นให้ซื้อ Redundancy เพิ่มเติมได้ จะเป็นแบบไหนก็ไปเลือกกันดูครับ ค่าใช้จ่ายถูกแพงแตกต่างกันไป แต่คำถามแรกก่อนที่จะลงมือเลือก Redundancy เราควรจะรู้ว่า เมื่อไหร่ควรจะมี Redundancy ไม่ใช่ว่าถ้ามีงบก็ซื้อ มันดีที่จะมีไว้ ไม่ใช่แบบนั้นนะครับ และคงไม่ใช่ว่าไม่ซื้อเพราะไม่มีงบ ผมมีข้อให้คิดแบบนี้ครับ “อย่าลงทุนกับการป้องกัน มากกว่ามูลค่าความเสียหาย”

เช่น ถ้าฝ่ายไอที จะเสนอให้องค์กรซื้อ Cluster Firewall ลองถามฝ่ายบริหารว่า ถ้าฮาร์ดแวร์ของ Firewall เกิดเสียขึ้นมา คุณขอเวลา 4 ชั่วโมงในการทำให้คนในองค์กรออกเน็ตได้ หรือเข้าถึงเซิร์ฟเวอร์ใน DMZ ได้ โดยเป็นแบบใช้งานไปก่อน ไม่ใช่ Full recovery ฝ่ายบริหารคิดว่า 4 ชั่วโมงที่ออกเน็ตและเข้าเซิร์ฟเวอร์ไม่ได้นั้น จะเกิดความเสียหายต่อธุรกิจคิดเป็นเงินเท่าไหร่ ถ้าคำตอบมันคือ 25,000 บาท คำตอบนี้จะทำให้คุณเลือกประเภทของ Redundancy ที่เหมาะสมกับ “ความต้องการทางธุรกิจ” ซึ่งคุณคงจะไม่เลือกอะไรที่เกินกว่า 25,000 บาท

ฝ่ายไอทีควรจะเลือก Redundancy แบบไหน หรือไม่ควรจะเสียเงินให้มันเลย…

ลองเอาแนวคิดเรื่อง “Downtime cost” มาตั้งเป็นงบประมาณในการเลือกและซื้อ Redundancy นะครับ ถ้าทำได้แบบนี้ ฝ่ายบริหารกับฝ่าย IT จะพูดภาษาเดียวกัน เรื่องมีงบหรือไม่มีงบ มันจะมาจากความเข้าใจร่วมกันคือเอา “ความต้องการทางธุรกิจเป็นที่ตั้ง” โดยใช้ Downtime cost มาเป็นตัวอธิบาย

ลองไปตั้งคำถามเหล่านี้ดูนะครับ…

● ถ้าฮาร์ดดิสก์ในเซิร์ฟเวอร์นี้เสีย Downtime cost แพงพอจะซื้อ RAID หรือไม่

● ถ้าสาย Fiber เส้นนี้ขาด Downtime cost ของเน็ตเวิร์คที่ปลายสาย Fiber นี้ แพงพอจะมี Fiber ในอีกเส้นทางหนึ่งหรือไม่

● ถ้า Wifi controller หยุดทำงาน ทั้งออฟฟิศใช้ Wifi ไม่ได้ ความวุ่นวายนี้มีมูลค่าต่อชั่วโมง เมื่อคูณด้วย Recovery time แล้วมันถูกหรือแพงกว่า Redundant controller

รำลึกไว้เสมอว่า ไม่มีธุรกิจไหนอยากอยู่บนความเสี่ยง Redundancy มีไว้ลดความเสี่ยงและป้องกันความเสียหาย ว่ากันง่าย ๆ ใจจริงธุรกิจก็อยากได้ Redundancy ครับ ถ้าฝ่ายไอทีกับภาคธุรกิจเห็นภาพเดียวกัน Redundancy เป็นสิ่งที่คุ้มค่าต่อการลงทุน และไม่ใช่ค่าใช้จ่ายสูญเปล่าอย่างแน่นอน ขอเพียงแต่ให้ค่าใช้จ่ายเรื่อง Redundancy ต่ำกว่า Downtime cost เป็นอันว่าใช้ได้ครับ

สอบถามรายละเอียดเพิ่มเติม เรามีพันธมิตรพร้อมให้คำปรึกษา

02-2479898 ต่อ 87

OPT-Care โดย บริษัท ออพติมุส (ประเทศไทย) จำกัด

จัดการอย่างไร เมื่อ FILE SERVER บวม

ไม่ว่าออฟฟิศไหน มันจะต้องมีซักเครื่อง ที่เป็นที่เก็บไฟล์ ให้ทุกคนสามารถมาใช้ไฟล์จากเครื่องนี้ได้ จะทำแบบง่าย ๆ แค่ Windows file sharing จากเครื่องใช้งานเครื่องหนึ่งในออฟฟิศ หรือจะเล่นท่ายากเป็น File sharing บน Windows server หรือ NAS (Network Attached Storage) ที่มีการกำหนดสิทธิ์ให้กับ User แต่ละคน หรือจะล้ำหน่อยก็ใช้ File sharing on cloud ทั้งหมดทั้งมวลนี้ มันก็คือ File sharing ที่เมื่อใช้ไประยะหนึ่ง มันก็จะเริ่มบวมไปด้วยไฟล์จากทุกคนทุกแผนก บวมจนใกล้เต็ม และใกล้เต็มจนเป็นปัญหา

คนที่ดูแล File server มักเป็นแผนกไอที ส่วนใหญ่ก็จะงัดเอามาตรการมาใช ้เพื่อรักษาอาการบวมของ File server มาตรการมีจากเบาไปหาหนัก เริ่มจากขอความร่วมมือ จนถึงขั้นขอร้อง บางออฟฟิศดีหน่อย งบถึง ก็เพิ่มขนาด Storage ให้ใช้ได้ยาว ๆ, บางออฟฟิศ แห้งแล้งด้านงบประมาณ แผนกไอทีก็จะหันไปแยกเขี้ยวกับผู้ใช้ (ตัวเล็ก ๆ) ไม่ลบงั้นกรูลบให้ 5555555

มันพอจะมีวิธีจัดการ File server อย่างไร ให้ผู้ใช้มีที่เก็บไฟล์ได้อย่างน่าพอใจ และไม่เป็นภาระกับแผนกไอทีต้องมานั่งเก็บกวาดหรือเคลียร์ขยะ ไม่เกิดการปะทะระหว่างผู้ใช้กับไอที นี่คือสิ่งที่เราจะว่ากันในครั้งนี้

1. แยกถัง

แปลว่าแยกถังเก็บข้อมูลครับ ทุกออฟฟิศมักจะมีอยู่แล้ว 2 ถัง คือ File storage กับ Backup storage ซึ่งมันยังไม่ครบครับ ถังสำคัญที่ขาดไป เรียกว่า “Archive storage” เรียกว่า ถังเก็บของเก่า ก็ได้

คิดแบบนี้ครับ Active storage ก็คือ File storage ที่ใช้ประจำ เป็น share drive ที่ผู้ใช้เข้าถึงได้ตลอดเวลา และทุกวัน หรือทุกสัปดาห์ ก็จะมีการ Backup active storage นี้ มาไว้ที่ Backup storage สำรองเอาไว้เพื่อกู้คืนหาก Active storage เกิดเสียหาย ส่วนไฟล์ใน Active storage ที่เก่าแล้ว ก็เอามาไว้ที่ Archive storage ไม่งงนะครับ ถ้างงอ่านใหม่อีกรอบ

สังเกตให้ดีนะครับ Backup storage จะ backup เฉพาะไฟล์ที่อยู่ใน Active เท่านั้น ไม่ได้ Backup file จาก Archive

อย่างไรถึงจะเรียกว่า “ไฟล์เก่า”

บ้านเก่าอายุร้อยปีที่มีคนอาศัยอยู่ เราไม่ทุบทิ้ง แต่บ้านใหม่ที่ยังสร้างไม่เสร็จ โดนธนาคารยึดไป ปล่อยร้างมา 5 ปี ก็น่าทุบทิ้ง ไฟล์เก่าก็เช่นเดียวกัน แม้ไฟล์จะเก่า แต่ถ้ายังมีคนเปิดใช้อยู่เรื่อย ๆ ก็ไม่ควรจะย้าย ถ้าไม่มีใครแตะไฟล์นี้เลยมาระยะหนึ่ง อาจจะ 1 ปีขึ้นไป ก็น่าจะถือเป็นไฟล์ที่ควรถูก Archive ได้ ถูกมั้ยครับ ปีนึงไม่เคยมีใครแตะไฟล์นี้แล้ว จะเก็บไว้ทำแบ๊ะอะไรล่ะครับ

ดังนั้น ไฟล์เก่าเราดูกันที่ Last access ครับ

ทีนี้ต้องไม่เข้าใจผิดนะครับ เราไม่ได้มากำหนดว่า ไฟล์เก่าแค่ไหนแล้วจะ “ลบ” แต่เรากำลังกำหนดว่า ไฟล์เก่าแค่ไหนที่เราจะ “ย้าย” คือย้ายจาก Active storage ไปยัง Archive storage

Archive storage ยังแปลว่า ถ้าใครจะเอา Archived file คงจะต้องตะโกนดัง ๆ ว่า

“แผนกไอทีคร้าบ ผมจะเอาไฟล์นี้จาก Archive ช่วย Copy มาใส่ใน Active ให้ผมหน่อยคร้าบ”

หน้าที่นี้จะเป็น Archive storage manager ครับ ซึ่งเมื่อหยิบไฟล์ Archive มาใส่ใน Active แล้ว ก็ต้องถาม User ว่า มีการแก้หรือไม่ ถ้าไม่มี ใช้ไฟล์แล้วก็ลบทิ้งจาก Active storage ได้เลย แต่ถ้ามีการแก้ไข ก็ต้องมีการอัพเดต Archive ตามด้วย

2. ข้อมูลแบบไหน เก่าแค่ไหน ถึงควรย้าย ไป Archive

นั่นดิครับ ผมบอกไม่ได้ แผนกไอทีไม่ควรจะเป็นคนบอก ใครจะบอกได้ ก็ผู้ใช้นั่นแหละครับ

แผนกไอที ควรจะประชุมกับผู้ใช้ แนะนำให้รู้ขบวนการ Life cycle ของไฟล์ว่า ไฟล์มันมีเกิด ก็ย่อมมีดับ ชีวิตไม่ยั่งยืนฉันใด ไฟล์ย่อมตายและสูญสลายไปจากเซิร์ฟเวอร์ได้ฉันนั้น แผนกไหนมีไฟล์อะไรเก็บอยู่ มาคิดกันครับว่า นานเท่าไหร่ที่เราคิดว่า เราคงจะไม่ไปเปิดไฟล์นั้นอีก ไม่แก้ไฟล์นั้นแล้ว แต่ยังลบไม่ได้ แต่ละแผนก แต่ละประเภทของไฟล์ กำหนดกันขึ้นมา เอาแค่ไฟล์หลัก ๆ หรือโฟลเดอร์หลัก ๆ ก็พอ แค่นี้ แล้วประกาศให้ทุกคนรู้จักกับขบวนการ Archive file

เมื่อแต่ละแผนก ตกลงกันได้เช่นนี้ การบวมเพราะการเก็บไฟล์แบบ Unlimit ก็ไม่เกิดขึ้นแล้วครับ

การ Archive file ไม่ต้องทำบ่อยครับ ปีละครั้ง ก็พอแล้ว

3. ควรเลือกใช้ Archive storage แบบไหน

Archive storage ควรจะเป็นแบบนี้ครับ

1. ไม่ต้องเสียบปลั๊กมันไว้ตลอด (เสียบทำไม นาน ๆ ใช้ที)

2. เก็บได้หลาย TB (Terabyte) เพราะ Archive จะถูกพอกขึ้นไปเรื่อย ๆ

3. เก็บได้นาน (เป็นปี ๆ) โดยข้อมูลไม่สูญหาย ไม่เสื่อมสภาพ

4. สถานที่เก็บไม่ยุ่งยาก ไม่ค่อยแคร์เรื่องอุณหภูมิ ความชื้น สั่นสะเทือน (ทำหล่น) ไม่กลัวแสงสว่างหรือไม่ต้องการความมืด

5. เอากลับมาได้ไม่ยาก ไม่ยุ่งยากถ้าต้องการอ่านข้อมูลกลับออกมา และใช้เวลาอ่านกลับไม่นานเกินรอ

6. ราคาต่อ GB หรือต่อ TB แล้ว ไม่ทำกระเป๋าฉีก

ตามข้างบนนี้ คือคุณสมบัติที่ Ideal ครับ มาดูว่า เรามีตัวเลือกอะไรบ้าง ราคาเป็นอย่างไร และ Storage ประเภทนั้นขาดคุณสมบัติแค่ไหน

HDD – หาง่ายครับ เก่งมากเรื่องข้อ 5 ส่วนข้อที่เหลือด้อยหมด เพราะ HDD มีจุดให้พังเยอะเหลือเกิน มอเตอร์พัง, หัวอ่านพัง, วงจรพัง, สารแม่เหล็กเสื่อม, Connector เสื่อม อะไรซักอย่างเกิดพังขึ้นมา ก็จะ access ข้อมูลไม่ได้แล้ว แถมการพังยังสามารถเกิดขึ้นได้โดยไม่ต้องเสียบปลั๊ก เช่น ห้องแอร์อาการแห้งไฟฟ้าสถิตย์อยู่ที่มือ ก็ทำ HDD พังได้แล้ว ยิ่งยืดระยะเวลาออกไปซัก 10 ปี โอกาสพังก็ยิ่งมีมาก คุ้มหรือเปล่าที่จะเอา HDD มาทำ Archive storage ต้องคิดให้หนักครับ

Blu ray disc – เคยมอง Media นี้มั้ยครับ แผ่นนึงไม่กี่ร้อย เก็บได้ตั้ง 50GB แค่ 300-400 บาทเท่านั้นเอง Drive ที่ใช้อ่านเขียนก็ราคาแค่หลักพันต้น ๆ เท่านั้น อายุแผ่นเขาคุยว่าเก็บได้เป็นร้อยปี แต่เพียงแค่รอยนิ้วมือหรือรอยขูดขีด ก็อาจมีผลกับข้อมูลบนแผ่นแล้ว ที่เหลือ Blu ray disc ถือว่าผ่านได้ดีเกือบทุกข้อ

ผมคิดว่า ถ้าใช้ Blu ray disc อาจจะตั้งเอาไว้ว่า ทุก ๆ 10 ปี ก็มาถ่ายขึ้น Media ใหม่ซักทีก็ได้ครับ ร้อยปีออกจะเว่อร์ไปนิด

แต่ Media ช้ินละ 50GB อาจจะไม่เหมาะกับบางงาน และบางออฟฟิศก็ต้องการขนาดของ Archive storage ที่โหดเหี้ยมกว่านั้น อย่างงานเขียนแบบ บางทีอาจต้องเก็บหลาย TB จะมานั่งเก็บแผ่นละ 50GB บางทีก็กองท่วมหัวล้นห้องได้เหมือนกัน

LTO tape – มีมานานกว่า 30 ปีแล้วครับ และค่อย ๆ เก่งขึ้นเรื่อย ๆ จนถึงปัจจุบัน ตลับหนึ่งเก็บข้อมูลได้กว่า 12TB (คุยว่า compressed แล้วจะได้ถึง 30TB….โอ้แม่เจ้า) และการพัฒนายังไม่หยุดครับ ในอนาคต เขามีแผนจะทำให้แต่ละตลับจุได้มากถึงระดับ 100TB++ กันเลย

ถ้าแปลกใจว่า ทำไมเทปตลับนึงถึงเก็บข้อมูลได้เยอะ ทำแบบนี้ครับ กำเงินซัก 5,000 ซื้อ LTO-7 มาซักม้วน แล้วก็ดึงเทปมันออกมานะครับ จะพบว่า เทปมันโคตรยาวจนพันรอบสนามกรีฑามาตรฐานได้ 2 รอบ ยาวรวมกันก็เกือบกิโลเมตร ถ้าคิดเป็นพื้นที่ก็เกือบ 12 ตารางเมตร ขนาดฮาร์ดดิสก์แผ่นเท่าฝ่ามือ ยังเก็บได้ตั้งหลาย TB แล้วนี่พื้นที่ขนาด 12 ตารางเมตรจะเก็บได้แค่ไหน คิดดูละกันครับ

เทียบราคาต่อ TB แล้ว ถือว่า LTO ถูกกว่าแผ่น Blu ray เกือบ 25 เท่า (โดย Media เท่านั้น) แต่ก็จะไปแพงที่ Tape drive ครับ มีให้เลือกตั้งแค่ครึ่งแสนไปจนถึงแสนกลาง แถมเทคโนโลยีของ LTO ก็มักจะมีการอัพเกรดทุก 3-5 ปี แปลว่าเราต้องคอยมาเปลี่ยนเทปใหม่ และเปลี่ยน Drive ใหม่กันอยู่เรื่อย เพราะ Drive ใหม่จะอ่านเทปมาตรฐานเก่าลงไป 1 รุ่นเท่านั้น หรือคิดเป็นอายุ Drive กับอายุเทปที่ห่างกันได้ไม่เกิน 10 ปี

ดังนั้น แม้ LTO จะคุยว่า ข้อมูลสามารถอยู่บนเทปได้ 30 ปี แต่ด้วย Drive ที่มีอายุในตลาดแค่ 5 ปี อย่างเก่งถ้าเราซื้อ LTO-7 วันนี้ เราคงใช้มันได้แค่ 10 ปีก่อนที่จะหา Drive มาอ่านมันไม่ได้ครับ

ที่ควรรู้เอาไว้อีกเรื่องคือ อุณหภูมิสำหรับเก็บ LTO เพื่อเป็น Archive ก็น่าจะพอประมาณที่ห้องแอร์แบบ Data center ครับ ไม่เกิน 25 องศา ถ้าคิดจะเก็บในตู้ออฟฟิศทั่วไปที่เปิดแอร์บ้าง ปิดแอร์หลังเลิกงาน มันมีผลกับอายุข้อมูลบนเทปครับ สั้นลงเท่าไหร่ คงต้องลุ้นกันไป

ผลิตภัณฑ์เฉพาะทาง – จริง ๆ แล้วในตลาด ก็มีผลิตภัณฑ์เฉพาะทางที่เอาไว้ทำ Archive อีกครับ ใหญ่กว่านี้ แพงกว่านี้ เก็บได้นานกว่านี้ อาจจะเหมาะกับคนกลุ่มเล็ก ๆ หรือเฉพาะบางวงการ ผมไม่พูดถึงละกันครับ

4. Archive ไว้นานเท่าไหร่

เช่นเคยครับ ทุกอย่างย่อมมีการสูญสลาย Archive ก็เช่นกัน กลับมาที่เรืองเดิมครับ แผนก IT ต้องประชุมสร้างข้อตกลงกับทุก ๆ แผนกว่า ข้อมูลของเขาจะอยู่ใน Archive นานเท่าไหร่ อย่างแผนกบัญชีเขาสนใจแค่ 15-20 ปีเท่านั้น นานกว่านั้นมันพ้นภาระเขาแล้ว อยากลบก็เชิญเลย เป็นต้น

ทำตาม 4 ข้อนี้ File storage จะไม่มีบวม ส่วนใหญ่ที่บวมกันเพราะไม่คุยกัน ไม่สร้างข้อตกลง จู่ ๆ ก็ตั้งโจทย์จากไหนไม่รู้ว่า ข้อมูลต้องไม่หาย และต้องเก็บตลอดไป โจทย์แบบนี้ ไม่มีใครทำได้ และไม่มีธุรกิจไหนยอมจ่ายค่าเก็บข้อมูลชั่วนิจนิรันดร์ขนาดนั้น

คุยกันให้เข้าใจ และทุกฝ่ายจะทำงานสนองกันได้

ผู้ใช้เข้าใจขบวนการ และแผนกไอทีไม่ต้องแบกภาระเกินจริง

ธุรกิจก็ไม่ต้องจ่ายค่า Storage เกินตัวครับ

สินค้าที่เกี่ยวข้อง

–LeverSync

● ติดตามข่าวสารไอทีหลากหลายเรื่องจากผู้เขียนมือโปรได้ที่ >> http://www.optimus.co.th/Training/

● หรืออีกช่องทางในแอปพลิเคชั่น Blockdit โหลดแอปพลิเคชั่นได้ที่ blockdit.com พิมพ์ค้นหาคำว่า “Optimus Thailand”

สนใจผลิตภัณฑ์เรามีพันธมิตรพร้อมให้คำปรึกษา ติดต่อแผนก Marketing

02-2479898 ต่อ 87

เก็บไว้บน CLOUD หรือ เก็บไว้บนบ้าน

ข้อมูลของใคร ก็อยากเก็บไว้กับตัวเอง ถ้าจะต้องเอาข้อมูลไปฝากกับคนอื่น มันก็รู้สึกโหวงโหวง ผิดนโยบายมั้ง ข้อมูลบริษัทเราทำไมคิดจะเอาไปเก็บไว้กับคนอื่นล่ะ เพี้ยนไปป่ะคุณ

อ่ะ จริง ดิ !!

สมมุติรถโดนทุกกระจก โจรฉกเอาโน้ตบุ๊คไป ในโน้ตบุ๊คมีข้อมูลสำคัญ

ถ้าเกิดมี Backup Data เก็บไว้ที่บ้าน แบบนี้เรียกข้อมูลหายป่าว ??? อ่ะ…โน้ตบุ๊คที่ใช้เก็บข้อมูลไม่ได้อยู่กะเจ้าตัวแล้วนะ

ถ้าเราแจ้งความกับตำรวจว่า ข้อมูลมันก็หาย จะได้มั้ย เพราะข้อมูลมันไปกับโน้ตบุ๊ค ตำรวจกำลังลงบันทึกประจำวันอยู่ อาจต้องหยุด ขอมองบนแพร้บ

ถ้าโจรมันได้โน้ตบุ๊คไป แล้วมันเก่ง แกะฮาร์ดดิสก์ออกมาก๊อปไฟล์สำคัญออกไป แบบนี้อาจจะไม่เรียกข้อมูลหาย แต่ข้อมูลบางอย่าง ไฟล์รูป ไฟล์คลิป อาจทำให้บางคน อยากหายตัวไปจากสังคมก็ได้

สถานที่เก็บข้อมูล มันสำคัญจริง ๆ เหรอท่าน….

เอาอีกเรื่อง เอาไปคิดให้ผมหงอกเล่น บริษัทเราเก็บไฟล์บนเซิร์ฟเวอร์ โดน Ransomware เล่นใหญ่ จัดหนักไป 1 คืน เหลือไว้แค่เลข Bitcoin บนหน้าจอแดง ๆ ข้อมูลยังตั้งโด่อยู่ตรงหน้าเรานะ แต่แง่เปิดใช้ไม่ได้ ต้องส่งเงิน Bitcoin ไปให้ท่านมหาโจร กราบเรียนขอความกรุณาโปรดส่งมอบกุญแจรหัสมาด้วยเถิด

● การเข้าถึงข้อมูลได้ อันนี้สำคัญ

● การถือครองข้อมูล อันนี้ก็สำคัญ

● การถือรหัสที่จะเข้าถึงข้อมูล นี่ก็โคตรสำคัญ

แต่ที่เก็บข้อมูล มันไม่สำคัญแล้ว

เอาเซิร์ฟเวอร์ไปตั้งที่หัวนอน หวงข้อมูลมาก แต่ดันจิ้มเน็ตคาตูดเซิร์ฟเวอร์เอาไว้เส้นนึง ข้อมูลมันก็สามารถออกไปตะแว้ดข้างนอกได้ง่าย ๆ แล้วนะครับ

ถ้าข้อมูลของเราเอาไว้บน Cloud แล้วเราไม่บอก Password กับใครเลย ข้อมูลก็เป็นของเราครับ อย่าห่วงว่า Cloud มันจะดับ เพราะถ้า Cloud มันดับขึ้นมา……….

มัน ก็ ดับ ซะ งั้น แหละ ครับ

พระท่านสอนว่า ทุกอย่างมีวันดับ เช่น ไฟฟ้า เมื่อฝนตก ไฟมันก็ดับ เทศน์ต่อไม่ได้

ข้อมูล มันจะเก็บอยู่ออฟฟิศเรา หรือจะไปเก็บอยู่กับ Cloud ข้างนอก ทั้ง 2 แบบมันย่อมมีวันดับ อย่าเถียงพระ….. แต่เดี๋ยวมันก็มาครับ คำถามคือ ใครจะมาเร็วกว่ากัน เซิร์ฟเวอร์เรา หรือ Cloud ข้างนอก ตรงนี้อยู่ที่เงินลงทุนทำระบบครับ ใครลงเงินเยอะกว่า ระบบพร้อมมากกว่า บุคลากรพร้อมมากกว่า โอกาสฟื้นกลับมาย่อมเร็วกว่า ซึ่ง Cloud ใหญ่ ๆ เขาใช้เงินไม่มากหรอกครับ บริษัทเราลงเงินตั้ง Data center แข่งได้อยู่แล้ว…..อ่ะโด่

พอจะเข้าใจนะครับ แล้วเวลามีใครมาถามว่า ทำไมเราเลือกเก็บข้อมูลเอาไว้ที่ออฟฟิศ ทำไมเรายังไม่ใช้ Cloud ก็หาคำตอบแบบที่มัน 4.0 กันหน่อยนะครับ

● สินค้าที่เกี่ยวข้อง LevelSync

สนใจสินค้า LevelSync เรามีพันธมิตรพร้อมให้คำปรึกษาติดต่อแผนก Marketing

02-2479898 ต่อ 87