เกริ่นเบาๆ กับ Stress Test

การทำ Stress Test กับระบบไอที เป็นสิ่งที่องค์กรขนาดใหญ่ในไทยควรให้ความสนใจกันให้มากขึ้นและเริ่มทำกันอย่างจริงจังมากขึ้น เนื่องจากหลายปีมานี้ระบบไอทีสำคัญๆ ในองค์กรขนาดใหญ่เกิดปัญหาจนเป็นข่าวบ่อยครั้ง อาทิ ระบบล่ม ระบบโดนแฮ็ก ฯ

Stress Test คือ การทดสอบความแข็งแกร่ง (robustness) ของระบบไอที ว่ามีความอดทน อึด ทนทาน (fault tolerance) แค่ไหน การทดสอบทำด้วยการจำลองสถานการณ์การทดสอบ (test scenario) ที่เลวร้าย ‘มากๆ’ หลากหลายรูปแบบ แล้วทดสอบระบบว่า ‘มันยังไหว’ อยู่ไหม ยังทำงานได้ดีอยู่หรือไม่ ช้าไหม ล่มไหม เกิดช่องโหว่ด้านความปลอดภัยไหม นอกจากนี้ในแง่ระบบไอทีควรออกแบบสถานการณ์ทดสอบแบบ ‘ปัญญาอ่อน’ ไว้ด้วย เพราะเหตุการณ์ปัญญาอ่อนง่ายๆ เช่น ความสะเพร่าโดยคนก็อาจก่อให้เกิดปัญหาใหญ่ต่อระบบได้

การทำ Stress Test ก็เหมือนการตรวจสุขภาพแบบ ‘จัดเต็ม’ ตรวจทุกอย่างในร่างกาย

Stress Test

ที่พบเห็นทั่วไปในหลายองค์กรที่มักทำกันคือ การทำ Load Test ซึ่งก็เป็นแนวปฏิบัติหนึ่งในการทำ Stress Test เพียงแต่เน้นไปที่ดูความสามารถในรองรับ Load ซึ่งเป็นหัวใจสำคัญของการทำงานของระบบไอที เป็นการดูคุณภาพด้าน Performance ของระบบไอที และยังใช้ประเมินระดับเสถียรภาพของระบบ (System Stability) เพื่อเอาไว้เซ็ตบรรทัดฐาน (Baseline) เพื่อใช้กำหนดขอบเขตในการติดตามและควบคุมคุณภาพ เช่นอาจอาศัยการดูจากการแกว่งตัวของช่วงคุณภาพในช่วงเวลาและสถานการณ์ต่างๆ

ส่วนที่พบเห็นกันทั่วไปในองค์กรขนาดใหญ่สมัยนี้คือ การทำ Stress Test ในแง่ IT Security ซึ่งก็พบว่าหลุดกันแทบทุกองค์กร ไม่สามารถทดสอบได้ครอบคลุมและละเอียดพอ เพราะการทำ Security Test แบบเข้มข้นต้องอาศัยบุคลากรที่มีความสามารถ การประสานงาน และ เครื่องมือ หลายองค์กรคิดว่าตัวเองมีซอฟต์แวร์ประเภท IDS (Intrusion Detection System), IPS (Instrusion Prevention System), Fraud Detection System (ตรวจจับการโกง) ฯ แล้วคิดว่าคงพอ ในวงการ IT Security / Cyber War ผู้เชี่ยวชาญเขาพัฒนาความสามารถและเทคนิควิธีการอยู่ตลอด ประเด็นก็คือ ผู้เชี่ยวชาญพวกนั้นอยู่ฝ่ายบุกหรือฝ่ายรับ ซึ่งมักพบกันว่าฝ่ายบุกมีมากกว่าฝ่ายรับ และยังมีความกระตือรือล้นในการพัฒนาความสามารถอยู่ตลอด

สำหรับการทำ Stress Test ในแง่ System Modifiability นั้นแทบไม่ค่อยได้พบเห็นกัน ระบบที่ดีนอกจากต้องมีประสิทธิภาพ (Performance), ปลอดภัย (Security), ใช้ง่าย (Usability) แล้วควรมีความยืดหยุ่น (Flexibility) ที่สามารถปรับปรุงแก้ไขได้ง่าย มีผลกระทบข้างเคียงน้อย มีต้นทุนในการปรับปรุงต่ำหรือไม่สูงเกินไป

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

การออกแบบระบบแบบ High Modifiable System ให้มีความยืดหยุ่นสูง เหมาะกับระบบในองค์กรขนาดใหญ่ที่มีการเปลี่ยนแปลงบางสิ่งบางอย่างบ่อยครั้ง อาทิ เป้าหมายธุรกิจ นโยบาย แผนฯ ความต้องการ ฯ

การออกแบบระบบให้ยืดหยุ่นปรับปรุงง่าย ‘ยากกว่า’ การออกแบบระบบให้เร็ว และอาจยากกว่าการออกแบบระบบให้ปลอดภัย เพราะยืดหยุ่นมักตรงข้ามกับปลอดภัย จุดไหนในระบบที่ยืดหยุ่นอาจเกิด Vulnerability ในแง่ IT Security ได้ ดังนั้นหากยืนยันต้องการให้จุดนั้นยืดหยุ่นจริงๆ ก็ต้องออกแบบให้ปลอดภัยด้วย จึงทำให้ออกแบบยากขึ้นไปอีก และยืดหยุ่นก็มักตรงข้ามกับเร็วด้วยเช่นกัน จุดไหนอยากให้เร็วมักไม่ยืดหยุ่น จุดไหนยืดหยุ่นมักไม่เร็ว ถ้าอยากได้ทั้งสองอย่างก็ต้องออกแบบยากขึ้นนั่นเอง

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

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s