การวิเคราะห์ และ แก้ปัญหา บางครั้งปัญหามันก็ไม่ได้เกิดจากการทำงานของเราเสมอไป

วันนี้เข้าไป แก้ปัญหาที่ site ลุกค้าเจ้าหนึ่ง

      ปัญหานี้เดิมที ลูกค้าส่ง log มาให้ดูว่า Program ที่ใช้งานเป็นประจำอยุ่ๆเกิด

มีปัญหา เมื่อทำการเพิ่มข้อมูลของพนักงานคนหนึ่งเข้าไป ซึ่งพอกดปุ่ม submit 

Program ก้เจ๊งในบัดดล ทำให้งานเข้า พวกเราที่รับ บำรุงรักษา Application ตัวนี้อยุ่

       ในเบื้องต้นคิดว่าไม่น่าจะมีอะไรผิดปกติ คงเป็นที่ข้อมูลของ พนักงาน คนที่ทีปัญหา

เกิดอะไรแปลกๆขึ้น เลยส่งน้องในทีมไปดุก่อน แต่แล้วเหตการณ์ก็ไม่คลี่ตลาย เมื่อพบว่า

ปัยหานี้เกิดขึ้นแค่ที่เครื่อง Server ของลุกค้าเท่านั้น เครื่องที่ทำการ พัฒนาและดีบักไม่พบปัญหานี้ในรายข้อมูลเดียวกัน ทำให้เราเสียเวลาไปวันหนึ่งโดยที่ไม่สามารถระบุได้ว่าปัญหาเกิดขึ้น ณ.จุดไหน ทราบเพียงแต่ว่า error ที่เกิดขึ้นเป็น error HTTP 406 ซึ่งเมื่อใช้ อากู๋ (google) ค้นหาดูแล้ว พบว่่ามันคือปัญหาเมื่อ Browser ไม่สามารถแปลความหมายที่ส่งมาจาก Server ได้ แต่น้องที่ส่ง ไปแก้ปัญหาก็หมดเวลาเสียแล้ว ต้องไปทำงานอื่นต่อ งานนี้จึงตกมาถึงมือผมซึ่งต้องผลัดไม่เข้าไปในวันถัดมา

       เมื่อผมเข้าไปที่ Site ลูกค้าก็ทำการบทวนปัญหาที่เกิดขึ้นก่อนว่าลักษณะของการที่ทำให้เกิดปัญหาคืออะไร

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

1. ค้นหาข้อมูลที่เกี่ยวข้องกับ พนักงานคนนี้ในฐานข้อมูลเสียก่อน และดูข่้อมูลของคนอื่นๆ ประกอบว่าคนที่อยู่ แผนกเดียวกัน ตำแหน่งงานเดียวกันมีลักษณะข้อมูลเป็นอย่างไร ซึ่งก็พบว่า ข้อมูลของพนักงานที่มีปัญหา น่าจะถูกต้องครบถ้วนแล้ว

2. คราวนี้ก็เจาะดูข้อมูลของพนักงานที่มีปัญหาว่ามีอักระพิเศษ ปนมาด้วยหรือไม่ ซึ่งก็พบว่าเรียบร้อยดี

3. ทดลองเพิ่มข้อมูลของพนักงานคนอื่นที่ใกล้เคียงกันก็พบว่า ไม่มีปัญหาใดๆ

4. สรุปผลเบื้องต้นได้ว่าข้อมูลไม่น่ามีปัญหา คราวนี้ก็ไปสุ่ขั้นตอนถัดไป

เมื่อฐานข้อมูลไม่ใช่ปัญหาคราวนี้เราก็มาดูที่ตัว application กันว่าเมื่อดึงข้อมูลมาใช้แล้วเกิดปัญหาอะไรหรือไม่

1. ทดลองใช้ application สร้างข้อมูลตามขั้นตอนแล้ว ดู source code ที่หน้า page ว่ามีอะไรผิดปกติหรือไม่ ซึ่งก็พบว่าไม่มีอะไรผิดปกติเลย คราวนี้เริ่มเครียดเล็กน้อย

2. เขียน debug code เพื่อดูว่า Application น่าจะมีปัญหาเมื่อขั้นตอนไหน ก็พบกับปัญหาใหม่คือ application server ไม่แสดง log ออกมาเลยต้องมาวิเคราะห์ใหม่ว่าขั้นตอนไหนที่น่าจะมีปัญหา

3. เมื่อสังเกตแล้วพบว่าน่าจะมีปัญหาขระที่ Browser จะส่งค่าให้ server เพราะหากมีการประมวลผลแล้ว   Error ที่ได้น่าจะเป็น HTTP 500 , 403 , 503 มากกว่า

4. ฝ่าย IT ที่รับผิดชอบเข้ามาบอกว่าเกิดปัญหานี้ที่อีกหน้า Page หนึ่งซึ่งไม่เกี่ยวข้องกับ ข้อมูลของพนักกงาน ที่ีมีปัญหา ตามที่แจ้งมาครั้งแรก

เมื่อทราบดังนั้น ผมจึงวิเคราะห์ ต่อไปอีกว่าถ้าอย่างนั้นแล้วไม่น่าจะเป็นปัญหาที่ระดับ Application เนื่องจาก Error ที่เกิดขึ้นเกิดขึ้นในลักษณะอื่น ที่ไม่เหมือนกัน เลยถามซักกับ IT ที่รับผิดชอบว่ากอ่นหน้านี้ที่ Server มีการเปลี่ยนแปลงอะไรบ้าง ซึ่งได้คำตอบว่าน่าจะมีเพราะมี audit มาตรวจสอบเรื่องความปลอดภัยจึงมีการ เปลี่ยนแปลงค่า config บางอย่างของระบบ 

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

ผมจึงให้ทาง IT ที่รับผิดชอบส่ง File ที่แก้ไขเพื่อมาเปรียบเทียบกันว่ามีจุดไหนที่เปลี่ยนไปบ้าง พบว่า file ได้ถูกแก้ไข ให้ดักจับ POST request รวมทั้ง Body ทุกตัว หากไม่เป็นมาตรฐานแล้ว จะ reject ออกมาเป็น Error 406 จึงได้ทดลอง เปลี่ยนให้ดักจับเฉพาะตัว Request ส่วน Body ไม่ต้องดัก พบว่า Application สามาถทำงานได้เหมือนเดิม จึงเป็นอันเรียบร้อย ปิด case นี้ได้สำเร็จ

จะเห็นได้ว่าการ investigate นั้นทำจากวงแคบ(ข้อมูล) ไปจนถึงระดับใหญ่สุด(Config)

 Data ==> Program ==> Application ==> Server Configuration

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