สรุปเรื่อง QA in Production นิดหน่อย

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

ถ้าเรามีระบบ monitoring, logging, alert ที่ดี

ถ้าเรามีขั้นตอนของ Continuous Delivery หรือการ deploy ระบบงานที่ดี จะช่วยทำให้เรารู้ปัญหาได้อย่างรวดเร็ว สามารถแก้ไขและ deploy ได้อย่างรวดเร็ว จะช่วยทำให้เราเข้าใจปัญหาของระบบจริง ๆ ซึ่งเป็นอีกแนวทางหนึ่งในการปรับปรุงคุณภาพของระบบงาน แน่นอนว่าแตกต่างจาก QA แบบเดิม ๆ คือ ให้ความสำคัญกับการทดสอบระบบงาน ก่อนที่จะทำการ deploy และ release บน production เพื่อทำให้แน่ใจว่าระบบพร้อมสำหรับขึ้น production แสดงการทำงานทั้งสองแบบดังรูป

จากบทความแบ่งการเรียนรู้จากข้อมูลบน Production เป็นดังนี้

• การรวบรวมข้อมูล
• การเรียนรู้จากข้อมูล

1. การรวบรวมข้อมูล

บน production นั้นมีข้อมูลเยอะมาก ๆ ทั้งข้อมูลของ server ทั้งข้อมูลจากระบบงาน และอื่น ๆ อีกมากมาย คำถามที่น่าสนใจคือ จะให้ระบบงานสอนเราหรือเป็นครูของเราอย่างไร ? เพื่อทำให้เราเรียนรู้และเข้าใจระบบมากยิ่งขึ้น ยกตัวอย่างเช่น

Logging

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

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

บทความยกตัวอย่างของการจัดการ log ไว้อย่างน่าสนใจคือ การทำงานหลักจะไม่เก็บ log ไว้ แต่ละส่งข้อมูลไปเก็บที่ server หรือ service อื่น ๆ แทน โดย server หรือ service ที่จัดการนั้น จะเก็บข้อมูลลง Database ที่สนับสนุน full-text search เช่น Elasticsearch และ Apache Solr เป็นต้น ทำให้สามารถค้นหาข้อมูลได้อย่างง่ายดาย ทั้งสนับสนุนการ query ทั้งสนับสนุนการแสดงผลในรูปแบบรูปกราฟสวย ๆ แน่นอนว่า ทาง business เข้าใจได้ง่าย ทั้งสนับสนุนการทำ aggregation ข้อมูลเพื่อสรุปและดูแนวโน้มต่าง ๆ น่าจะช่วยทำให้เห็นปัญหาได้เร็วขึ้น ไม่ใช่รู้ปัญหาจากผู้ใช้งานเท่านั้น !! หรือว่าทีมสร้างรู้ปัญหาจากผู้ใช้งาน มันแปลก ๆ นะ

Metrics

ส่วนเพิ่มเติมของ logging คือ metric ต่าง ๆ เป็นสิ่งที่ใช้วัดค่าต่าง ๆ ที่เราต้องการ ยกตัวอย่างเช่น จำนวนการกดปุ่มในแต่ละชั่วโมง จำนวนการ register ในแต่ละชั่วโมงในแต่ละวัน จำนวนของการ register ไม่สำเร็จในแต่ละชั่วโมงในแต่ละวัน ซึ่งเป็นประโยชน์อย่างมากต่อการ monitoring การทำงานของระบบ เครื่องมือที่ชอบให้งานกันเช่น Statd และ Prometheus เป็นต้น

โดยเก็บข้อมูลทั้ง technical และ business ช่วยทำให้เห็นแนวโน้มการใช้งานและทำงาน ช่วยทำให้เราเรียนรู้ระบบได้เป็นอย่างดี ช่วยทำให้เราเห็นแนวโน้มของปัญหาได้อย่างดี

2. การเรียนรู้จากข้อมูล

เมื่อทำการเก็บและรวบรวมข้อมูลได้ดีแล้ว จากนั้นคือการเรียนรู้จากข้อมูล ข้อมูลจะไร้ค่ามาก ๆ ถ้ามันนอนนิ่ง ๆ อยู่ในระบบ ดังนั้นเราควรนำข้อมูลมาใช้งานและใช้ประโยชน์ให้ได้มากที่สุด ประกอบไปด้วยระบบ Alert และ Dashboard แบบ realtime

ระบบ Alert

เพื่อทำการ monitoring การทำงานของระบบว่า มีจำนวนหรือปริมาณถึงจุดที่อาจจะก่อให้เกิดปัญหาหรือไม่ เช่น Latency หรือ reponse time ของการทำงาน การใช้งาน CPU และ Memory ที่สูง จากนั้นทำการแจ้งเตือนผ่านช่องทางต่าง ๆ เช่น Email, Instant messaging เป็นต้น แต่ถ้าแจ้งเตือนบ่อยเกินไปก็ไม่ดี เพราะว่าสุดท้ายแล้วจะเป็นการรบกวนมากจนเกินไป

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

ระบบ Dashboard

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

แล้ว QA จะปรับตัวอย่างไร ?

เมื่อพูดถึง QA (Quality Assurance) แล้วจะคิดว่าคือ กลุ่มคนที่มาทำการทดสอบระบบ เป็นกลุ่มคนที่จะบอกว่าระบบงานมีคุณภาพหรือไม่ ? หรือตัดสินใจได้ว่าจะ deploy และ release ระบบหรือไม่ ? ดังนั้นเรื่องของการเรียนรู้และวิเคราะห์ปัญหาเชิงคุณภาพจึงเป็นสิ่งที่ถูกมองข้ามไป !! การทดสอบนั้นเป็นเพียงการบอกว่า ระบบทำการตาม scenario ที่กำหนดไว้ได้เท่านั้น การทดสอบมันช่วยหาข้อมูลผิดพลาดตามที่เราคาดหวังไว้เท่านั้น แต่บน production นั้นมักจะมีแต่เรื่องแปลกประหลาดเกิดขึ้นทุกครั้งไป ทั้งพฤติกรรมของผู้ใช้งานที่แตกต่างกัน ทั้งระบบ network มีความเร็วที่แตกต่างกัน ทั้ง browser ที่ใช้งานมีหลากหลายมาก ทั้ง device ที่ใช้งานมีหลากหลายมาก ซึ่งมีหลายสิ่งอย่างมาก ที่สำคัญทำนายหรือคาดเดาไม่ได้เลย ดังนั้นการทดสอบจึงไม่ครอบคลุมอย่างแน่นอน สิ่งที่เราต้องการเพิ่มเติมคือ ระบบ monitoring ที่ดี เพื่อทำให้เราเห็นว่าเกิด scenarioที่เราคาดไม่ถึงได้อย่างรวดเร็ว จากนั้นจึงนำมาเพิ่มเติมในหารทดสอบ นั่นคือการเรียนรู้นั่นเอง

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

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

คำถามที่น่าสนใจคือ คุณพร้อมไหม ?

ส่วนการประยุกต์ใช้งานนั้น มันขึ้นอยู่กับบริบทขององค์กรด้วย

เช่นถ้าระบบมันทดสอบยาก หรือ ต้องใช้เวลาและค่าใช้จ่ายสูงมาก ๆ ดังนั้นไปลงทุนกับทำระบบ monitoring ดีกว่าไหม ซึ่งทำให้เราและองค์กรเดินไปข้างหน้าได้รวดเร็วขึ้น ดังนั้นต้อง balance ให้ดีด้วย ถ้าองค์กรมีระบบ Continuous Delivery ที่ดีและเร็ว อาจจะไม่ต้องมีการทดสอบเลย เนื่องจากถ้ามีปัญหาที่ production ก็สามารถรู้และแก้ไขได้อย่างรวดเร็ว บางระบบมันยากต่อการ recovery และแก้ไขปัญหา ดังนั้นสิ่งที่ควรทำคือ ต้องลงทุนในส่วนของ pre-production environment ให้เหมือน production เพื่อทำให้มั่นใจว่า จะไม่เกิดข้อผิดพลาดที่ production บางที่อาจจะทดสอบและแก้ไขบน production กันไปเลย ซึ่งถือว่าเป็น anti-pattern อย่างหนึ่ง !!

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

ขอให้สนุกกับการ coding ครับ