15 เทคนิคเพื่อลดปัญหาคอขวดไอทีในองค์กร

15 เทคนิคเพื่อลดปัญหาคอขวดไอทีในองค์กร

ที่มา dnsthailand 01 มิถุนายน 2007

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

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

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



1. มันมักจะไม่ได้เกิดจากเซิร์ฟเวอร์

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

ความเห็นดังกล่าวมีผลต่อเนื่องกันมาตราบจนปัจจุบัน แน่นอนมันยังคงให้ผลดีในบางกรณี แต่จะมีสักกี่งานไอทีกันเชียว ที่ใช้งานการคำนวณของหน่วยประมวลผลเป็นจุดสำคัญอย่างยิ่งยวด โดยทั่วไปแล้วคุณสามารถประหยัดเวลาและเงินทองได้เป็นอันมาก เพียงแค่ละสายตาแสนสงสัยไปจากหัวข้อเซิร์ฟเวอร์เพียงเท่านั้น แม้แต่เซิร์ฟเวอร์ในระดับที่มีความเร็วต่ำที่สุด ก็มีแรงม้าเพียงพอที่จะดูแลการดำเนินงานประจำวันต่างๆ มาลองดูกันสักหนึ่งตัวอย่างสิครับมีเครือข่ายผู้ใช้งานระดับ 125 รายสมาชิกอยู่ที่องค์กรแห่งหนึ่ง เครื่องเซิร์ฟเวอร์ที่ดูแลควบคุมงานโดเมนคอนโทรลเลอร์ให้กับระบบปฏิบัติการวินโดวส์ที่ถึงอายุจะตกรุ่น น่าจะมีการเปลี่ยนอัพเกรดตามยุคตามสมัย ก่อนหน้านั้นเจ้าเซิร์ฟเวอร์ดังกล่าวนี้ทำงานด้วยระบบปฏิบัติการวินโดวส์ 2000 เซิร์ฟเวอร์ และได้รับการอัพเกรดเป็นวินโดวส์ 2003 มาสักพักหนึ่งแล้ว แต่ฮาร์ดแวร์ยังคงเป็นเครื่องเก่าอยู่ นั่นคือเครื่อง HP ML330 หน่วยประมวลผลสัญญาณนาฬิกา 1 GHz และแรม 128 เมกกะไบต์ ทำงานเป็น Active Directory Domain Controller เรียกว่าดูแลหน้าที่หลักทั้งหมด รวมถึงให้บริการ DHCP, DNS และ IAS (Internet Authentication Service) น่าทึ่งใช่ไหมครับ!

ในความเป็นจริงที่เป็นอยู่นั้นคือ มันสามารถดูแลงานมากมายนั้นได้อย่างสบาย ในขณะที่ตัวแทนหลังการอัพเกรดได้แก่เครื่องเซิร์ฟเวอร์ HP DL360 G4 มากับหน่วยประมวลผลความเร็ว 3 GHz, แรม 1 กิกะไบต์ พร้อมด้วยระบบ Mirror SCSI drives ขนาด 72 กิกะไบต์ มาทำหน้าที่แทนด้วยความหรูหราฟู่ฟ่ากว่า เสียเวลาเซตอัพให้ทั้งหมดทำงานแทนได้อย่างยากลำบาก แต่กลับไม่พบความรู้สึกแตกต่างในการใช้งานแม้แต่น้อย นั่นแหละนะครับ มันไม่ยากนักที่จะระบุแอพพลิเคชันที่กินทรัพยากรของหน่วยประมวลผลและหน่วยความจำอย่างแรม แต่มันต้องอาศัยความละเอียดและกึ๋นพอประมาณที่จะตัดสินใจทำมัน เกือบทุกสถานการณ์ที่เครื่องเดิมนั่นแหละสามารถทำงานได้เป็นอย่างดีอยู่แล้ว...พบเป็นประจำ

2. เพิ่มความเร็วการค้นหาข้อมูล

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

ดังนั้นการปรับจูนความเร็วในการเข้าถึงข้อมูลในฐานข้อมูลให้ได้ประสิทธิภาพสูงสุดก็เป็นอีกเรื่องหนึ่งที่สำคัญ มีตัวชี้วัดพื้นฐานที่สำคัญอยู่ด้วยกันสามตัว ที่สามารถช่วยให้คุณปรับปรุงประสิทธิภาพของการค้นหาข้อมูลจากฐานข้อมูลได้ดีขึ้น อันแรกก็คือ ผลิตภัณฑ์ซอฟแวร์จัดการฐานข้อมูลทั้งหลายนั้น มักจะมีเครื่องมืออุปกรณ์ (อาทิ DB2 UDB สำหรับ iSieires ของ Visual Explain) ในการวิเคราะห์ประสิทธิภาพ การค้นหาข้อมูลที่ทำงานได้ในระหว่างออกแบบพัฒนาฐานข้อมูลนั้นๆ เลย ไม่ต้องรอลุ้นตอนใช้งานจริงแล้วตามแก้ไขกันแบบรีบสุดขีด โดยโปรแกรมจะสามารถให้ข้อแนะนำเกี่ยวกับ Syntax หรือโครงสร้างการเขียนโปรแกรมจัดการฐานข้อมูล รวมถึงประมาณการเวลาที่จะใช้งานค้นหาข้อมูลกันจริงๆ ในแต่ละส่วนของคำสั่ง SQL ที่เรากำหนดการจัดการข้อมูลรูปแบบต่างๆ ให้เราได้ จากข้อมูลดังกล่าวนั้นเราก็สามารถปรับปรุงแก้ไขโค้ดโปรแกรมได้อย่างถูกตำแหน่ง เรียกได้ว่าเกาถูกที่คัน ส่วนไหนที่ใช้เวลาการทำงานนานมาก เมื่อมีการเรียกใช้งานก็จะได้ตัดตอน ย่นย่อเสียให้ได้เวลาการทำงานที่ดีขึ้น โปรแกรมฐานข้อมูลบางตัว แถมทูลในการแนะนำการปรับปรุงให้ประสิทธิภาพการทำงานของฐานข้อมูลดีขึ้น มาด้วยกันเป็นแพ็กเกจเลยเสียด้วยซ้ำ อย่าง Automatic Database Diagnostic Monitor ของออราเคิลที่สามารถให้คำแนะนำถึงขนาดให้คุณสร้างดัชนีบางตัวในการค้นหาขึ้นมาใหม่จะให้ผลการค้นหาที่ดีกว่าเก่า ทำกันได้ขนาดนี้เลยทีเดียว อันดับต่อไปลองเปิดตัวมอนิเตอร์การทำงานฐานข้อมูลขึ้นที่เซิร์ฟเวอร์ อาจจะใช้บริการซอฟแวร์พวกนี้จากเธิร์ดปาร์ตี้ อาทิ NetVigil ของ Fidelia ก็ได้ หากว่าซอฟแวร์ฐานข้อมูลของคุณไม่ได้มีมาให้ ขณะเดียวกันนั้นเองลองสร้างทราฟฟิกการใช้งานฐานข้อมูลผ่าน Load-testing scripts ดูว่าการทำงานของมันเป็นอย่างไร เมื่ออยู่ในสถานการณ์ที่มีโหลดเกิดกับเซิร์ฟเวอร์อยู่ด้วย และหากว่าเซิร์ฟเวอร์ของคุณยังมีทรัพยากรเหลือเพียงพอ ที่ยังสามารถรันงานเพิ่มได้อยู่ ลองใส่คำสั่งค้นหาซ้ำไปอีกเป็นรอบที่สามพร้อมๆ กันด้วยการจำลองจาก Load testing tools อย่าง Open-STA ทั้งๆ ที่ Database monitor ยังเปิดอยู่นั่นแหละ และเมื่อใดที่เงื่อนไขของการใช้งานฐานข้อมูลเปลี่ยนไม่ว่าจะเป็นโวลุ่มที่โตขึ้น การลบเรคคอร์คข้อมูลหรืออื่นๆ ล้วนแล้วแต่ต้องการการทดสอบและปรับจูน ที่มักจะคุ้มค่าที่จะเหนื่อยแรงใส่ทรัพยากรลงไปสำหรับงานนี้เสมอ

3. โปรแกรมป้องกันไวรัส กินทรัพยากรไปสักเท่าไร?

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

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

4. เพิ่มเติมประสิทธิภาพของคนกลางไปด้วย

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

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


หากว่าคุณรู้ปริมาณการเชื่อมต่อใช้งานตามปกติ (ซึ่งเป็นเรื่องที่ผู้ดูแลควรรู้ในระดับหนึ่ง) ก็ทดสอบหาระดับที่เหมาะสมได้ จากการทดลองรันโหลดพร้อมกับตัวมอนิเตอร์ประสิทธิภาพอย่าง Tivoli Performance Viewer ที่มากับ WebSphere ของ IBM บนเซิร์ฟเวอร์ ใช้ตัวจำลองโหลดงานสร้างโหลดในปริมาณดังกล่าว บันทึกผลการมอนิเตอร์การทำงานดังกล่าวเอาไว้ นำมาสำรวจดูเพื่อวิเคราะห์หาปุ่มปรับค่าที่ควรเข้าไปดูแลปรับจูน ในระหว่างการใช้งานจริงก็เป็นการดีที่จะเปิดการมอนิเตอร์ในบางส่วนที่จำเป็นเอาไว้ด้วยเหมือนกัน เผื่อว่าโหลดงานของคุณมีการเปลี่ยนแปลงชีวิตก็ต้องเปลี่ยนแปลงไปเช่นเดียวกัน


5. หาจุดสมดุลย์ของการเชื่อมต่อสู่เครือข่าย

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

6. ผูกเชื่อมเว็บเซิร์ฟเวอร์เข้าด้วยกัน

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


7. ความเศร้าของเครือข่าย WAN

หากคุณต้องการเพิ่มแบนด์วิดธ์ของเครือข่าย WAN คุณสามารถทำได้ง่ายๆ คือการเพิ่มแพ็กเกจในการจัดการทราฟฟิกโดยการทำ Shaping appliances หรือ Caching engine ให้การใช้งานแบนด์วิดธ์บนเครือข่ายถูกใช้งานเต็มที่ที่สุด ซึ่งนั่นหมายถึงเม็ดเงินที่ต้องลงทุนซื้อหาอุปกรณ์มาเพิ่ม จะเป็นอย่างไรเล่าหากว่าเราไปผิดทางก็คงจะเสียเงินไปฟรีโดยไม่มีใครรู้ เราควรทำสิ่งที่ควรทำก่อนเป็นอันดับแรก ก่อนที่คุณจะซื้อหาสิ่งใดมาเพิ่มเติมควรจะมีไอเดียที่ชัดเจนเสียก่อนว่า การจราจรบนเครือข่ายมีหน้าตาเป็นอย่างไรกันแน่ เครื่องไม้เครื่องมือที่ช่วยวิเคราะห์การทำงานของเครือข่ายอาทิ Ethereal, ntop, Network Instrument จาก Observer หรือ EtherPeek NX ของ WildPacket จะให้ข้อมูลกับคุณได้ในส่วนนี้ คุณอาจจะพบว่าการตั้งค่า Replication time สำหรับ Active Directory ไม่เหมาะสมก็เป็นได้ ผลที่ตามมาก็จะทำให้เครือข่ายช้าลงอย่างไม่น่าเชื่อ หรือว่ามีผู้ใช้งานผ่านบริการรีโมทที่เชื่อมต่อค้างเอาไว้หลังการใช้งานเสร็จสิ้นไปแล้ว กินเนื้อที่ใช้งานไปอย่างเปล่าประโยชน์ หรือแม้แต่เชื่อมต่อผิดเซิร์ฟเวอร์และดาวน์โหลดไฟล์มหึมาผ่านเครือข่ายโดยผู้ใช้งานไม่รู้ตัว


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

8. ลองทำตัวให้ดีขึ้น

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


9. Caching, Shaping ข้อจำกัดของเซิร์ฟเวอร์

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

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

10. การทำนายการอัพเดตต่างๆ

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


11. ทำตัวให้เย็นเข้าไว้

อ้อ! ไม่ใช่สิต้องบอกว่ารักษาสภาพแวดล้อมการทำงานให้เย็นพอเหมาะ แม้จะดูน่าประหลาดใจแต่สภาพแวดล้อมไม่ว่าจะในห้องเซิร์ฟเวอร์หรือตู้ใส่อุปกรณ์เครือข่ายนั้น มีผลทำให้การจราจรหรือความเร็วบนเครือข่ายช้าลงได้จริงๆ อากาศที่ร้อนทำให้เซิร์ฟเวอร์สุขภาพแย่ลง เนื่องจากการระบายความร้อนที่แย่ลงได้ สำหรับฮาร์ดแวร์หรืออุปกรณ์ฮับ, สวิตช์ต่างๆ ก็เช่นกัน คุณควรจะแน่ใจว่าสภาพแวดล้อมดังกล่าวไม่มีการเปลี่ยนขึ้นๆ ลงๆ เราอาจจะต้องมีเซ็นเซอร์คอยดูแลการเปลี่ยนแปลงดังกล่าวนี้ มันเป็นความคิดที่ดีที่จะใช้งานโปรแกรมยูทิลิตี้ที่มีมากับเซิร์ฟเวอร์จัดการเรื่องนี้ OpenManage จาก Dell และ Insight Manager ของ HP ให้ข้อมูลที่ดีในเรื่องเหล่านี้ไม่ว่าจะเป็นการทำงานของเซิร์ฟเวอร์หรือแม้แต่สภาพอากาศที่เปลี่ยนไป

12. จงเป็นผู้นำในการทำ Mirroring และ Replication

อาการการทำงานช้าลงของเครือข่ายที่ใช้งานเทคโนโลยี Mirroring หรือ Replication เพื่อความปลอดภัยของข้อมูลแม้มีปัญหากับเซิร์ฟเวอร์บางแห่ง ก็ยังมีข้อมูลสำรองอยู่อีกแห่งเสมอๆ นั้นเป็นเรื่องปกติธรรมดาที่พบกันได้ง่ายๆ หากว่าคุณมีสถานที่เก็บข้อมูลอยู่หลายๆ แห่ง หรือจะเป็นการแลกเปลี่ยนข้อมูลประมวลผลที่ต้องการการซิงก์โครไนซ์ของข้อมูลจากหลายๆ ที่ ต้องจับตามองให้ดีคุณสามารถสูญเสียความเร็วในการทำงานไปง่ายๆ เลยทีเดียว หากจะให้ดีควรจะรัน Mirroring หรือ Replication แยกออกมาอีกเส้นทางหนึ่งในเครือข่าย แยกจากที่ใช้งานถ่ายเทข้อมูลปกติจะได้ไม่แย่งแบนด์วิดธ์ในการทำงานกับงานประจำวัน ทีมออกแบบเครือข่ายของคุณคงจะให้คำปรึกษาเกี่ยวกับรูปแบบการจัดผังของเครือข่ายที่เหมาะสมได้เป็นอย่างดี ในเวลาเดียวกันก็ลองปรึกษาเวนเดอร์ผู้ขายซอฟแวร์ดูถึงการตั้งค่าที่เหมาะสมไม่ให้เกิดการใช้งานจนถึงขั้นอิ่มตัวหรือเต็มแบนด์วิดธ์เกิดขึ้นได้โดยที่เราไม่รู้ตัว ซ็อฟแวร์ Mirroring และ Replication อย่าง WANSyncHA Oracle ของ XOsoft หรือ Heartbeat จาก High Availability Linux Project มักจะมีออปชันที่ช่วยควบคุมเวลา และการสื่อสารที่เกิดขึ้นระหว่างไซต์ข้อมูลได้ บ้างก็ให้คุณกำหนดแผนการซิงก์ข้อมูลในช่วงเวลากลางคืน ที่ไม่มีการใช้งานเครือข่ายมากนัก หรือให้คุณทำซิงก์ได้ เมื่อเครือข่ายมีทรัพยากรเพียงพอเท่านั้น จงใช้มันเหมือนกับที่เตรียมเอาไว้ให้


13. เคเบิลที่บ้านผมยังเร็วกว่า

สายส่งข้อมูล T1 นั้นเคยเป็นสายส่งข้อมูลที่เร็วที่สุด แต่ในปัจจุบันให้ความเร็วได้ไม่ถึงครึ่งของที่เราใช้งานกันตามบ้านเสียด้วยซ้ำ คงจะมีบ้างที่ผู้ใช้งานมักจะบ่นว่า การเชื่อมต่อผ่านเครือข่ายบรอดแบนด์ที่บ้านของเขายังใช้งานได้เร็วกว่านี้เสียอีก ลองมาเดากันดูซิว่าเพราะอะไร? ลองหาซื้อเคเบิลอะซิงโครนัสแบบดีดีหน่อยมาต่อพ่วงเชื่อมต่อเข้ากับสาย T1 เดิมดู เพียงเท่านี้อะไรๆ ก็จะดูดีขึ้นแล้วล่ะครับ เพราะอะไรน่ะเหรอ เนื่องจากข้อมูลทราฟฟิกทั่วไปจะถูกถ่ายเทมาให้กับสายเคเบิลดังกล่าวโดยเราเตอร์ ในขณะที่ข้อมูลที่มีระดับความสำคัญสูงกว่าก็จะวิ่งไปบนท่อ T1 ดังเดิม แต่ด้วยการจราจรที่คับคั่งน้อยลงทำให้คุณได้ผลการทำงานที่ดีขึ้นทั้งสองส่วนพร้อมกัน การทำ Traffic-shaping ก็จำเป็นอย่างขาดเสียมิได้ ไฟร์วอลล์หลายยี่ห้อก็ใส่ความสามารถนี้เอาไว้ให้อยู่แล้ว การบล็อกหรือจำกัดการใช้งานของแอพพลิเคชันที่ไม่เกี่ยวข้องกับงานเอาไว้ด้วยไฟร์วอลล์ก็ช่วยในเรื่องนี้ได้ ทั้งการติดตั้ง Proxy ก็จะแยกการจราจรที่จำเป็นและไม่จำเป็นออกคนละทาง เพื่อให้มีการใช้งานที่เหมาะสมเท่าที่จำเป็นจริงๆ ไม่มีข้อมูลวิ่งบนเครือข่ายอย่างไร้ประโยชน์อ้อมไปมา ใช้งานผลิตภัณฑ์ AUP enforcement อย่าง Websense ก็จะติดตามการใช้งานอินเทอร์เน็ตที่น่าสงสัยได้ การจัดวางตำแหน่งเซิร์ฟเวอร์ที่เหมาะสม กรณีใช้งานเฉพาะเพียงภายในก็ควรนำมาไว้ภายในเครือข่ายแทนที่จะต้องวิ่งออกไปผ่านเครือข่ายอินเทอร์เน็ตให้เปลืองแบนด์วิดธ์เสมอๆ แถมยังเพิ่มความเร็วในเครือข่ายขึ้นมาได้อีก เนื่องจากข้อมูลไม่ต้องวิ่งไปผ่านหลายๆ ด่านที่คุณตั้งขึ้นไม่เหมาะสมเอง

14. คาดเดาอนาคตให้ทันกาล

งานที่ดูจะยากเย็นไม่น้อยก็คือ การทำนายโครงสร้างพื้นฐานของระบบที่ควรจะเป็นในอนาคตตอบสนองต่อองค์กรที่เติบโตขึ้นอย่างทันท่วงที ผู้คนส่วนใหญ่เริ่มต้นจากการใช้งาน Capacity planning tools อาทิ View and Modelling ของ TeamQuest แต่เพียงเครื่องมืออย่างเดียวช่วยอะไรไม่ได้ เนื่องจากเรายังคงต้องการข้อมูลการคาดคะเนโหลดงานในอนาคตวันพรุ่งนี้อยู่ดี คุณต้องสวมหมวกนักสืบเพื่อคิดในเรื่องนี้ เมื่อคิดออกแล้วก็ยังต้องหาข้อพิสูจน์หรือการันตีว่ามันมีโอกาสจะเป็นอย่างที่คาดคะเนเอาไว้จริงๆ หลังจากนั้นใจก็ต้องมานั่งจำลองการทำงานจริงบนเงื่อนไขที่เลวร้ายที่สุดเพื่อดูผลอีกครั้งหนึ่ง เงื่อนไขที่คุณใช้คาดคะเน ควรจะเป็นจริงกับการใช้งานปัจจุบันด้วย ซึ่งข้อสังเกตอันนี้จะช่วยให้เราทดสอบการทำงานตามข้อคาดคะเนเทียบกับปัจจุบันได้ ต้องทำแผนพร้อมทดสอบล่วงหน้า 6 เดือน ที่ใส่จำนวนคนใช้งานที่เพิ่มขึ้นตามด้วยตามความเป็นจริงที่ควรจะเป็น ใส่ปัญหาต่างๆ การตั้งค่าหลายๆ รูปแบบ เพื่อนำไปสู่คำตอบว่าควรจะลงทุนปรับปรุงระบบเมื่อไร ให้ทันกับการเติบโตที่มีขึ้นไม่ให้ประสิทธิภาพการทำงานหยุดชะงัก


15. ทำประวัติการใช้งานเพื่อให้ได้ประสิทธิภาพสูงสุด

จงมีหัวคิดก้าวหน้าอยู่เสมอในการป้องกันมิให้เกิดคอขวดของประสิทธิภาพการทำงานให้เกิดขึ้นได้ง่ายๆ สร้างมาตรฐานให้การพัฒนาปรับปรุงเปลี่ยนแปลงต่างๆ ไม่ให้ตกหล่นหายไปไหน การร่างภาพรวมของบริการบนเว็บเอาไว้ จะช่วยให้คุณตรวจสอบได้ว่าโค้ดของคุณยังทันสมัยและมีประสิทธิภาพอยู่เสมอ Profile tools ช่วยวิเคราะห์และรายงานผลจำนวนแอตทริบิวส์ต่างๆ ที่เกิดขึ้นระหว่างการทำงาน บอกคุณถึงส่วนไหนของโค้ดที่ยาวที่สุด หรือคุณใช้งานทรัพยากรของหน่วยประมวลผลได้ดีแค่ไหน หรือโค้ดของคุณใช้งานหน่วยความจำอย่างไร ถ้าคุณใช้งาน IDEs หลักๆ อยู่ เช่น VisualStudio หรือ WebSphere Studio ก็จะมีโปรแกรมมาให้อยู่แล้ว หรือถ้าไม่ใช่ก็มีโปรแกรมอย่าง DevPartner ของ Compuware, YourKit, InfraRed และ J-Sprint ระหว่างการพัฒนาแอพพลิเคชันก็ต้องเริ่มสนใจว่าโค้ดที่คุณมีการทำงานอย่างไรแล้ว ลองจำลองสภาพการทำงานจริงที่อาจจะเกิดขึ้น เพื่อวิเคราะห์ผลที่ได้หากว่าโค้ดของคุณมีการใช้งานหลายแพลทฟอร์มก็ต้องตรวจสอบทั้งหมดด้วย หลังการทดสอบทั้งหมดนั้นข้อมูลที่รวบรวมได้ จะถูกเก็บเอาไว้ใน Profile session วิเคราะห์ข้อมูลทั้งหมดก็จะเห็นภาพรวมของประสิทธิผลของโค้ดที่มีอยู่แบบเบ็ดเสร็จ ใช้ภาพที่ได้ในการปรับปรุงการทำงานต่อไป รับรองว่าประสิทธิภาพที่ดีไม่หนีคุณไปไหนแน่นอน