บางคนที่ไม่เคยเรียนทางคอมพิวเตอร์มาอาจจะคิดว่าการสร้างซอฟต์แวร์เป็นเรื่องยาก เหอ ๆ ผมจะบอกอะไรให้ว่า งานดูแลรักษาซอฟต์แวร์น่ะ ยากกว่าจมเลย T-T
โดยเฉพาะกับองค์กรขนาดใหญ่ระดับประเทศนี่ยิ่งแล้วใหญ่ครับ เพราะจะมีกลไกการเชื่อมต่อซอฟต์แวร์ที่ยุ่งยากสลับซับซ้อนมาก ๆ โดยเฉพาะระบบบริการลูกค้า ผนวกเข้ากับระบบ Billing ผนวกเข้ากับระบบบัญชีด้วยเนี่ยอ่ะนะ โคตร ๆ เลยล่ะ
จริง ๆ ถ้าเราไม่ได้ไปเปลี่ยนอะไรมัน มันก็คงจะอยู่ของมันดี ๆ ทำงานได้อยู่แล้ว แต่ถ้าเมื่อไหร่ก็ตามที่ทีมวิศวกรระบบ หรือทีมวิศวกรเครือข่ายมาบอกเราว่า …
วิศวกรระบบ – “พี่ไท้ครับ คืนนี้ทีมผมจะขอ restart database server ทุกตัวของพี่จะได้มั้ยครับ?”
วิศวกรระบบ – “พี่ไท้ครับ เดี๋ยววันหยุดนี้ทาง HP กับ DELL จะเข้ามา Install Server Patch นะพี่”
HP – “พี่ไท้ครับ ผมจะ down ระบบเกินเวลา เพราะจะ configure clustering นะครับ”
DELL – “พอดีทางเราจะ configure core system หน่อย ยังไงทีมคุณไท้ก็ช่วยอยู่ stand by หน่อยนะ”
วิศวกรเครือข่าย – “พอดีทางเราจะ reset switching ทั้งศูนย์คอมพิวเตอร์เลย ยังไงทีมคุณไท้ .. บรา บรา บรา”
ทำไมเมื่อวิศวกรระบบหรือวิศวกรเครือข่ายขอทำอะไรพวกนี้แล้ว คนทางซอฟต์แวร์อย่างเราต้องเดือดร้อน???
เพราะซอฟต์แวร์ระดับใหญ่ มันไม่ได้อยู่อย่างเดียวดายครับ มันมีการต่อเชื่อมกับซอฟต์แวร์ตัวอื่นผ่านทางระบบเครือข่าย มันต้องต่อเชื่อมกับฐานข้อมูล ต่อเชื่อมกับซอฟต์แวร์ที่เป็น Broker อีกเยอะแยะ
ดังนั้นเมื่อมีการ down ระบบ หรือมีการเปลี่ยนแปลงอะไรก็ตามในระดับ Basis หรือ Infrastructure เราจึงจำเป็นต้องมาตรวจสอบการ Configure ในทุก ๆ จุดของซอฟต์แวร์เรา ภายหลังจากที่ระบบมัน up ขึ้นมา ว่ามันสามารถทำได้เหมือนกับก่อนที่จะมีการเปลี่ยนแปลงหรือเปล่า
แผนในการตรวจสอบการ Configure จึงสำคัญมาก และก็ไม่ใช่มีแค่แผนเดียวด้วย แต่ต้องมีแผนสำรองเผื่อไว้อีกต่างหาก
ไม่อยากจะโม้ แต่จะบอกว่าเอาเข้าจริง ขนาดมีแผนสำรองถึงสองแผนแล้ว พอถึงเวลากลียุคเข้าจริง ๆ คือไม่สามารถจะ up ระบบขึ้นมาได้ แผนอะไรก็ใช้ไม่ได้เลย สุดท้ายก็ต้องใช้ประสบการณ์และวิจารณญาณจนได้ แล้วก็ไม่ใช่ประสบการณ์ของคน ๆ คนเดียวด้วย แต่เป็นของคนทั้งทีมเลย
ถึงสุดท้ายแล้วคนคอมพิวเตอร์นี่คงต้องใช้ทักษะส่วนนึง และก็ประสบการณ์ส่วนนึง รวมกับความเป็นน้ำหนึ่งใจเดียวกันของทีมอีกส่วนนึง ในการแก้ปัญหาให้มันผ่านพ้นไปได้ จริง ๆ
[tags]maintenance,คอมพิวเตอร์,ซอฟต์แวร์,การจัดการ[/tags]
โม้ไปตั้งแยะแล้วค่ะพี่ไท้
เอามาโม้เอ๊ยประจานบ้างดีกว่า มีบริษัทหนึ่ง ส่งทีม maintenance โดยเฉพาะ้เดินทางไปทำ maintenance ให้กับระบบที่ติดตั้งอยู่ในหลายประเทศเมื่อกลางปีที่แล้ว … เวลาผ่านไป … ไวเหมือนโกหก … ต้นปีนี้ ระบบดันเกิดปัญหา ณ จุดที่ไม่ควรจะเกิด เพราะเราส่งทีมวิศวกรไป maintenance ระบบนั้นไว้ล่วงหน้าแล้ว … ในที่สุดตรวจสอบพบว่า … การ maintenance ที่ว่า คือการติดตั้งอุปกรณ์เสริมเพื่อป้องกันปัญหา ทีม maintenance ทำการติดไว้จริงๆ … แต่ไม่ได้ต่อสาย … โดยให้เหตุผลน่าตื้บว่า … “ก็ตอนนั้นมันยังไม่เกิดปัญหา เลยไม่ได้ต่อไว้” เมื่อถามว่า “แล้วทำไมไม่แจ้งให้ทราบว่าไม่ได้ต่อ” กลับไม่มีคำตอบจากสวรรค์ … โอ พระเจ้า ช่วยเอามันไปเก็บทีเถอะ …
นิทานเรื่องนี้สอนว่า “อย่าไว้ใจทีม maintenance หน้าไหนทั้งสิ้น ควรมี procedure ในการตรวจสอบทุกขั้นตอนว่า ทำครบถ้วนสมบูรณ์แล้วจริง”
บริษัทไหนไม่รู้ เล่าได้ละเอียดจริงๆ เลยนะฉัน
วันหยุด ก็เลยไม่ได้เป็นวันหยุดเลยนะครับ
มีการพาดพิงถึง vender ด้วย ระวังโดนฟ้องเน้อ พี่ไท้
แหมะ จะให้เดามั้ยเนี่ย ว่าคุณ aoyoyo กำลังบ่นถึงบริษัทไหนอยู่ อิ อิ
ปรกติวันหยุดมันก็ไม่ค่อยเป็นวันหยุดอยู่แล้วครับคุณ panuta อย่างคุณ panuta เองวันหยุดยังต้องมารื้อห้อง, ต่อเตียงเลยนี่เน้อะ
ข้อความที่เขียนไม่ได้ทำให้ vendor ถูกดูหมิ่นเกลียดชังหรือทำให้เสียชื่อเสียงครับคุณ nameless อัยการไม่รับฟ้องหรอก หรือถ้าอัยการรับฟ้อง ศาลก็ยกฟ้องอยู่ดี ^o^ เรื่องหมิ่นประมาทเนี่ย บล็อกเกอร์ทุกคนต้องระวังครับ เพราะเห็นโดนกันบ่อย อิ อิ จะเอามาคุยทำไมเนี่ย เรื่องจังไรแบบนี้ ^o^
ตอบรวดเร็วเจง ๆ คุณพี่ไท้
ผมมีคำถามเกี่ยวกับการ Backup ระบบครับพี่ไท้
เคยเจอมั้ยครับแบบองค์กรมีการ backup กันทุกวัน แต่เวลาระบบล่มหนักๆ ทีไรสิ่งที่อุตส่าห์ backup ไว้ทุกวันกลับช่วยอะไรไม่ได้ทุกที มันดันไม่เวิร์ค
ถ้าหากจะซ้อม restore ให้เหมือนจริงแบบสุดๆ ไปเลยเวลา restore จึงจะได้เวิร์คก็กลัวจะไปรบกวนระบบที่ production อยู่ ก็เลยต้องซ้อมแบบคล้ายๆ แต่ไม่เหมือนอย่างแท้จริง พอมันไม่เหมือนอย่างแท้จริงเวลา restore จิงๆ ก็เลย restore ไม่ได้ เพราะมันชอบมีปัญหาอะไรที่คาดไม่ถึงทุกที
แบบนี้แก้ไงครับ
การ backup และ restore ฐานข้อมูลนั้น เป็นการใช้กลไกของ RDBMS ที่สามารถทำได้ แต่ปรกติมันไม่ค่อยเวิร์คนัก เพราะที่ทำงานผมก็เจอปัญหาติงต๊องที่ว่าเทป backup มันเกิดใช้ไม่ได้ขึ้นมาซะงั้นตอนที่จะ restore อันนี้เจ็บใจยิ่งนัก
ทางวิศวกรระบบจึงแก้ไขครับ โดยการทำดังต่อไปนี้
1. ทำให้ฐานข้อมูลเป็นระบบ clustering ถ้าฐานข้อมูลตัวไหนล่ม มันจะสลับไปใช้ฐานข้อมูลตัวอื่นทันที ฐานข้อมูลตัวที่เราใช้อยู่นั้น เป็น Virtual Database ซอฟต์แวร์เราก็ชี้เข้าหา Virtual Database ดังกล่าว ดังนั้นตัวระบบ Clustering จะเป็นผู้ไปจัดการเองว่า Physical Database ตัวจริง ๆ อยู่ตรงไหน ระบบนี้ดีนะท่านสุมาอี้ เพราะถ้าเรามี Server อยู่ 5 เครื่อง ฐานข้อมูลตัวเดียวอาจกระจายอยู่ทั้ง 5 เครื่องเลยก็ได้ ขึ้นอยู่กับ Clustering จะจัดการให้ ดังนั้นพอล่ม มันก็สลับไปใช้จุดอื่นทันที
2. ทำการ ghost ข้อมูลของ Server เอาไว้ การ ghost เป็นการ diskcopy ฮาร์ดดิสก์ทั้งลูกนั่นเอง ดังนั้นจึงเป็นการสำรองข้อมูลในระดับของ File System Management ซึ่งเหนือกว่า Relational Database Management System ครับ
แต่ทั้งสองแบบนะท่านสุมาอี้ พวกเราทำกันเองไม่ได้หรอก เราคงต้องจ้างวิศวกรระบบมาทำให้อ่ะครับ เพราะเขาเก่งกว่าเรามาก อาจจะจ้าง IBM, HP หรือ DELL มาทำให้ แต่ราคาก็คงแพงใช่เล่นเหมือนกัน