Learn DevOps ตอนที่ 4: หลักการของ Feedback
Learn DevOps ตอนที่ 1 : จุดเริ่มต้นของการเปลี่ยนแปลง
Learn DevOps ตอนที่ 2 : DevOps คืออะไร ?
Learn DevOps ตอนที่ 3: หลักการของ Flow
→ Learn DevOps ตอนที่ 4: หลักการของ Feedback
Learn DevOps ตอนที่ 5: หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง
ในขณะที่ หลักการของ Flow กล่าวถึงการปรับปรุง flow การทำงานให้สามารถส่งต่องานไปยังหน่วยงานถัดไปให้ได้อย่างรวดเร็วที่สุด แต่อะไรจะเกิดขึ้นถ้าหน่วยงานต้นทางส่งงานที่มีปัญหาไปให้หน่วยงานถัดไป หลักการนี้จะกล่าวถึงวิธีการ ว่าจะทำอย่างไรให้หน่วยงานถัดไปสามารถส่ง feedback ในแง่ของปัญหากลับมาที่หน่วยงานต้นทางได้อย่างรวดเร็ว เพื่อให้แก้ไขปัญหาได้อย่างทันท่วงทีในขณะที่ปัญหายังมีขนาดเล็ก และยังแก้ไขได้ง่ายอยู่ ดีกว่าที่จะไปเจอปัญหาอีกทีในตอนที่เป็นปัญหาขนาดใหญ่อย่างเช่น ระบบทั้งหมดล่มหรือข้อมูลลูกค้ารั่วไหล เป็นต้น
การทำงานอย่างปลอดภัยในระบบที่ซับซ้อน
ก่อนอื่นเราต้องเข้าใจก่อนว่าระบบ IT เป็นระบบที่ซับซ้อน ซับซ้อนในที่นี้คือ คนใดคนหนึ่งไม่สามารถเข้าใจระบบได้ทั้งหมด ว่าส่วนประกอบของระบบทำงานร่วมกันอย่างไร และส่วนประกอบของระบบมี dependency สูง นั่นหมายถึงถ้าทำอะไรสักอย่างกับระบบที่ส่วนหนึ่ง อีกส่วนที่ไม่ได้ทำอะไรก็อาจจะเสียได้
เราไม่สามารถหลีกเลี่ยงความผิดพลาดเมื่อทำงานกับระบบที่ซับซ้อนได้เลย เพราะฉะนั้นเราควรออกแบบกระบวนการทำงานให้พนักงานรู้สึกปลอดภัยและสบายใจเมื่อได้ทำงาน ซึ่งจะทำให้พนักงานสามารถทำงานได้โดยไม่กลัวที่จะผิดพลาด และมั่นใจได้ว่าถึงจะผิดก็สามารถพบความผิดพลาดนั้นได้อย่างรวดเร็ว ก่อนที่จะเกิดปัญหาใหญ่ขึ้น ซึ่งเราสามารถทำได้โดยวิธีการต่อไปนี้
1. สร้าง Feedback Loop
การสร้าง feedback loop ที่มีประสิทธิภาพขึ้นมาในกระบวนการทำงาน จะทำให้สามารถหาข้อผิดพลาดได้อย่างรวดเร็ว สำหรับหน่วยงาน IT นั้น feedback ที่ช้าจะทำให้ได้ผลลัพธ์ที่ไม่ดีนัก ยกตัวอย่างเช่นใน software project ที่ใช้กระบวนการพัฒนาแบบ waterfall ซึ่งอาจจะใช้เวลาพัฒนาหลายเดือน และจะไม่ได้รับ feedback จากทีม QA จนกว่าจะเริ่มต้น test phase ทำให้เมื่อเกิดปัญหาขึ้นมา developer ต้องเสียเวลามานั่งนึกสิ่งที่เคยทำไว้เมื่อนานมาแล้วและต้องตามแก้ code ที่เป็น dependency กันมากมาย ส่งผลให้ส่งงานได้ช้าลง เป็นต้น
หน่วยงาน IT สามารถสร้าง feedback loop ได้โดยการสร้าง automate build และ automate test เพื่อให้ developer สามารถรับรู้ถึงปัญหาและแก้ไขได้ในทันที รวมถึงติดตั้งเครื่องมือ monitoring ต่างๆ ใน production environment เพื่อให้ตรวจพบปัญหาได้อย่างรวดเร็ว โดย monitor ทั้งในด้านของ server เช่น memory consumption, cpu utilization ในด้านของ infrastructure เช่น network, storage ในด้านของ security เช่น ข้อมูลรั่วไหล และในด้านของ application เช่น ดูปัญหาหรือดูพฤติกรรมของลูกค้าเพื่อนำ feedback มาปรับปรุงระบบจาก log เป็นต้น
2. ร่วมมือกันแก้ปัญหาในทันที
เพียงแค่สร้าง feedback loop เพื่อให้สามารถหาข้อผิดพลาดได้อย่างรวดเร็วนั้นยังไม่เพียงพอ เราต้องร่วมมือกับผู้เกี่ยวข้องแก้ปัญหาให้ได้เร็วที่สุดด้วย โดยการแก้ปัญหาในที่นี้ ไม่ใช่เป็นการแก้ปัญหาเฉพาะหน้า หรือว่าไปแก้ปัญหาในภายหลังเมื่อมีเวลา แต่เป็นการร่วมมือกันแก้ปัญหาในทันที ซึ่งถ้าแก้ไม่ได้ในเวลาที่กำหนด งานทั้งหมดต้องถูกหยุดเอาไว้ รอให้ผู้เกี่ยวข้องร่วมมือกันหาวิธีแก้ปัญหาให้เสร็จ โดยมีจุดประสงค์เพื่อป้องกันไม่ให้ปัญหาเล็กบานปลายกลายเป็นปัญหาใหญ่ ซึ่งต้องใช้กำลังคนและเวลาที่มากขึ้นในการแก้ปัญหา และป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำขึ้นอีกกับ งานอื่นๆ นอกจากนี้การแก้ปัญหาทันทีจะทำให้ข้อมูลรวมถึงบริบทของปัญหายังคงอยู่ครบถ้วนในความทรงจำ ทำให้วิเคราะห์ปัญหาได้ง่ายขึ้นและยังสามารถเรียนรู้จากข้อผิดพลาดได้อย่างรวดเร็วอีกด้วย
ถึงแม้ว่าวิธีที่ต้องให้หยุดงานทั้งหมดเพื่อรอการแก้ปัญหา จะดูเหมือนสุดโต่งจนเกินไป แต่วิธีนี้ถูกพิสูจน์มาแล้วว่าใช้ได้ผล โดยวิธีนี้เป็นหลักการในระบบการผลิตแบบลีน และบริษัทโตโยต้าก็ใช้วิธีแบบนี้มานานแล้ว โดยเมื่อเกิดปัญหาขึ้นในสายการผลิต จะมีคนกดปุ่ม andon ซึ่งคือดวงไฟที่แสดงสถานะการผลิตว่ามีปัญหาหรือไม่ เช่น สีเขียวเมื่อกำลังผลิตและไม่มีปัญหาอะไร สีเหลืองเมื่อมีเหตุขัดข้อง หรือสีแดงเมื่อเกิดการหยุดการผลิต หลังจากกดปุ่มแล้วหัวหน้าทีมจะเข้าไปแก้ปัญหาทันที แต่ถ้าไม่สามารถแก้ไขปัญหาได้ในระยะเวลาที่กำหนดทุกอย่างจะต้องหยุดและผู้เกี่ยวข้องต้องร่วมกันหาวิธีการแก้ไขปัญหา
ในการสร้าง software ก็มีหลักปฎิบัติคล้ายๆกับแบบนี้อยู่เรียกว่า Continuous Integration หรือ CI ที่บังคับให้ developer ทุกคน integrate code ของตัวเองลงไปรวมกับ code ของคนอื่นใน version control กลางอย่างน้อยวันละครั้ง โดยทุกครั้งที่ check in code เข้าไป จะมีการ run automate build และ unit testing ถ้าเกิดปัญหา build fail หรือ unit test fail จะมีเครื่องมือที่ทำหน้าที่คล้ายๆปุ่ม andon ก็คือจะแจ้งเตือนให้ทุกคนในทีมรู้ว่าเกิดปัญหา จากนั้น developer ทุกคนในทีมต้องไปช่วยกันแก้ปัญหาในทันที
3. ควบคุมคุณภาพที่แหล่งที่มาของปัญหา
ในองค์กรแบบ top down ทั่วไปเราอาจจะเห็นวิธีการควบคุมคุณภาพของงานในระบบที่ซับซ้อน ซึ่งส่งผลให้ทั้งกระบวนการช้าลงยกตัวอย่างเช่น
- เพิ่มเติมกระบวนการตรวจสอบ
- เพิ่มคนอนุมัติ ซึ่งนอกจากจะช้าแล้วประสิทธิภาพของกระบวนการอนุมัติจะลดลง ถ้าเราให้คนที่เกี่ยวข้องกับงานชิ้นนั้นเพียงเล็กน้อย หรืออยู่ห่างไกลจากงานเป็นคนอนุมัติ เพราะเหมือนเราบังคับให้เขาตัดสินใจทั้งๆที่เขามีความรู้เกี่ยวกับงานที่ทำไม่เพียงพอ
- ส่งงานจำนวนมากให้คณะกรรมการดำเนินการและอนุมัติในคราวเดียว
- เขียนเอกสารที่ไม่ได้นำไปใช้ประโยชน์ต่อในอนาคตออกมามากมาย และล้าสมัยไปหลังจากเขียนเสร็จได้ไม่นาน
เพราะฉะนั้นสิ่งที่เราควรทำคือให้ทุกๆคนที่ทำงานนั้น เป็นคนควบคุมคุณภาพของงานโดยการค้นหาและแก้ไขปัญหาที่เกิดขึ้นกับงานเป็นประจำ รวมถึงมอบอำนาจในการตัดสินใจให้คนที่ทำงานนั้นด้วย สำหรับหน่วยงาน Development ในแง่ของการควบคุมคุณภาพเราจะใช้เรื่องของ peer reviews และการ automate งานของทีม QA และ IT Security ให้มากที่สุดเท่าที่จะทำได้ เพื่อให้ developer สามารถทดสอบ code ของตัวเองให้ได้เร็วที่สุด แทนที่จะขอคนจากทีม QA มาทดสอบระบบให้ หรือแม้แต่ให้ developer สามารถ deploy code ลง production ได้เอง
การให้ developer มีส่วนร่วมกับคุณภาพของระบบนอกจากจะช่วยปรับปรุงผลลัพธ์แล้วยังช่วยเรื่องกระบวนการเรียนรู้ของ developer อีกด้วย เพราะว่าได้รับ feedback ที่เร็วนั่นเอง
4. ออกแบบงานให้เกื้อหนุนต่อลูกค้าภายใน
ระบบการผลิตแบบลีนแบ่งลูกค้าออกเป็น 2 ประเภท คือ
- ลูกค้าภายนอก คือ คนที่มาซื้อสินค้าและบริการของเรา
- ลูกค้าภายใน คือ หน่วยงานที่มารับงานจากหน่วยงานของเราไปทำต่อ
ตามปกติทั่วไปเวลาเราออกแบบงานเรามักจะให้ความสำคัญกับลูกค้าภายนอกและมองข้ามลูกค้าภายในไป แต่ระบบการผลิตแบบลีนให้ความสำคัญกับลูกค้าภายในเท่าๆกับลูกค้าภายนอก เพราะฉะนั้นเราจึงควรจะออกแบบงานของเราให้เหมาะสมและเพิ่มประสิทธิภาพให้กับลูกค้าภายในให้ได้มากที่สุด ยกตัวอย่างในหน่วยงาน Development ควรจะออกแบบสิ่งที่เป็น non-functional requirement เช่น performance, scalability, stability, testability, configurability, security เพื่อให้ลูกค้าภายในอย่าง QA และ Operations จะสามารถทำงานได้อย่างมีประสิทธิภาพมากขึ้น
การสร้าง feedback ที่รวดเร็วสำคัญมากต่อคุณภาพของระบบ โดยเฉพาะอย่างยิ่งในระบบที่ซับซ้อน เราควรสร้างพื้นที่ปลอดภัยให้กับพนักงาน โดยสร้างได้จากวิธีการทั้ง 4 ข้อที่ระบุไว้ข้างต้น เพื่อให้พนักงานไม่กลัวที่จะทำงานผิดพลาด เพราะรู้ว่าถ้าผิดพลาดก็จะสามารถแก้ไขได้อย่างรวดเร็ว ขอจบบทความแต่เพียงเท่านี้ สำหรับบทความตอนหน้า พบกับหลักการสำคัญของ DevOps ข้อสุดท้าย ในเรื่องหลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง ขอบคุณครับ
เอกสารอ้างอิง
หนังสือ DevOps Handbook : How to Create World-Class Agility, Reliability, and Security in Technology Organizations (2016). โดย Gene Kim, Jez Humble, Patrick Debois, John Willis.