Learn DevOps ตอนที่ 3: หลักการของ Flow
Learn DevOps ตอนที่ 1 : จุดเริ่มต้นของการเปลี่ยนแปลง
Learn DevOps ตอนที่ 2 : DevOps คืออะไร ?
→ Learn DevOps ตอนที่ 3: หลักการของ Flow
Learn DevOps ตอนที่ 4: หลักการของ Feedback
Learn DevOps ตอนที่ 5: หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง
หลังจากที่เรารู้แล้วว่า DevOps คืออะไรจากบทความตอนที่แล้ว บทความตอนนี้จะกล่าวถึงรายละเอียดในเรื่อง “หลักการของ Flow” ซึ่งเป็น 1 ใน 3 หลักการสำคัญของ DevOps ว่าด้วยเรื่องของ การปรับปรุง flow การทำงานหรือการส่งต่องานระหว่างหน่วยงานตั้งแต่ Business เริ่มคิด requirement ไป Development ไป Operations จนถึงลูกค้าให้ไหลไปอย่างราบรื่น และรวดเร็วที่สุด ทั้งนี้แต่ละหน่วยงานต้องปรับปรุง flow โดยคำนึงถึงเป้าหมายรวมของบริษัท มากกว่าเป้าหมายเฉพาะของหน่วยงานนั้นๆ (เช่น Dev มองที่ความรวดเร็วในการพัฒนาระบบ Ops มองที่ความเสถียรของระบบ) หลักการของ Flow สามารถทำได้ด้วยวิธีการต่อไปนี้
1. แสดงภาพของงานทั้งหมดให้ทั้งทีมเห็นอย่างชัดเจน
flow การทำงานของ IT ไม่สามารถมองเห็นได้ด้วยตาเปล่าเหมือนกับ flow การทำงานของสายการผลิตในโรงงานอุตสาหกรรม ที่เมื่อเกิดปัญหา ณ จุดใดจุดหนึ่ง จะสามารถมองเห็นได้ง่ายและสามารถเข้าไปแก้ปัญหาได้อย่างทันท่วงที แต่อย่างไรก็ตามการส่งต่องานของ IT สามารถทำได้ง่ายและรวดเร็วกว่ามาก เพียงแค่คลิกเมาส์ก็สามารถส่งต่องานได้ทันที(อย่างเช่นการส่ง incident ไปยังหน่วยงานที่เกี่ยวข้องผ่านระบบ) ในขณะที่โรงงานนั้นต้องส่งต่อชิ้นงานผ่านสายพานลำเลียงทำให้ส่งต่องานได้ช้ากว่า แต่ความง่ายของการส่งต่องานของ IT อาจทำให้เกิดปัญหาอย่างเช่น การส่งต่องานกลับไปกลับมาระหว่างหน่วยงานแบบไม่มีที่สิ้นสุดสาเหตุจากส่งผิดหน่วยงานบ้าง ข้อมูลที่ส่งมาไม่ครบบ้าง, การส่งต่องานที่ยังมีปัญหาอยู่ไปยังหน่วยงานปลายทางส่งผลให้พบปัญหาได้ช้าและต้องส่งต่องานกลับมาแก้ไข, การส่งต่องานที่ไม่ได้มีการวางแผนไว้ก่อนทำให้มาเบียดเบียนเวลางานหลัก สิ่งต่างๆเหล่านี้ทำให้งานเสร็จได้ช้าลง
เพื่อที่จะแก้ปัญหาเหล่านี้เราจำเป็นต้องแสดงภาพของงานทั้งหมดออกมา โดยใช้เครื่องมือต่างๆ อย่างเช่น Kanban Board เพื่อให้เห็น flow การทำงานทั้งหมดว่ามีงานอะไรบ้าง อยู่ในคิวกี่งาน มีงานติดขัดอยู่ที่จุดไหน และควรจะจัดลำดับความสำคัญของงานอย่างไร
จากรูปตัวอย่าง การ์ดหนึ่งอันแทนงานหนึ่งงาน สีของการ์ดหมายถึงชนิดของงาน คอลัมน์แต่ละอันจะแทนหน่วยงาน โดยเราสามารถออกแบบคอลัมน์เองได้เลยไม่จำเป็นต้องเหมือนรูปตัวอย่าง การวางการ์ดจะเริ่มจากคอลัมน์ To do คืองานที่รออยู่ในคิว และจะค่อยไหลไปเรื่อยๆจากซ้ายไปขวาจนไปถึงคอลัมน์ Done คืองานที่ทำเสร็จแล้ว
สมองมนุษย์สามารถประมวลผลรูปภาพได้ไวกว่าตัวอักษรถึง 60,000 เท่า การแสดงภาพของงานทั้งหมดออกมาจะช่วยให้เราเข้าใจ status และ progress ของงานได้ง่ายและไวขึ้นทำให้สามารถบริหารจัดการให้ flow การทำงานให้ไวขึ้นได้ การใช้ภาพจะช่วยให้สื่อสารกับคนในทีมได้มีประสิทธิภาพมากขึ้น ช่วยให้ผู้เกี่ยวข้องกับงานทุกคนสามารถจัดลำดับความสำคัญของงานได้ง่ายขึ้น รวมถึงสามารถวัดผลว่าใช้เวลาการทำงานบวกกับเวลาที่งานอยู่ในคิวนานแค่ไหน โดยวัดตั้งแต่คอลัมน์ To do จนงานไปถึงคอลัมน์ Done เพื่อนำผลนั้นมาปรับปรุงการทำงานต่อไปได้อีกด้วย
2. การจำกัด Work in process
งานของแต่ละหน่วยงานใน IT มักจะอยู่ในลักษณะของ shared services ที่หน่วยงานหนึ่งต้องรับผิดชอบงานจากหลายๆหน่วยงาน เช่นทีม Database รับผิดชอบ Database ให้หลายๆ Application เป็นต้น ผลของงานลักษณะนี้คือผู้ทำงานต้องจัดลำดับความสำคัญระหว่างงานประจำวันกับงานด่วนที่แทรกเข้ามา ผ่านทางช่องทางต่างๆเช่น โทรศัพท์, อีเมลล์, Line หรือการสั่งงานโดยตรงจากผู้บริหารระดับสูง
สำหรับคน IT การแทรกงานอื่นเข้ามาในขณะที่กำลังทำงานประจำวันอยู่นั้น ส่งผลโดยตรงต่อประสิทธิภาพการทำงาน ผลวิจัยบ่งชี้ว่างานง่ายๆอย่างการแบ่งประเภทรูปทรงเรขาคณิต ยังทำได้ช้าลงถ้าเราทำแบบ multitasking (หมายถึง การทำงานหลายอย่างในเวลาเดียวกันหรือสลับไปสลับมา) การทำ multitasking กับงาน IT ที่ค่อนข้างซับซ้อนก็ยิ่งทำให้ประสิทธิภาพการทำงานยิ่งลดลงไปอีก
เราสามารถจำกัดการ multitasking ได้ด้วยการจำกัด work in process ใน Kanban Board โดย work in process หรือ WIP หมายถึง งานในระหว่างกระบวนการ หรือถ้ามองจาก Kanban Board ก็คืองานที่ไม่ได้อยู่ในคอลัมน์ Done นั่นเอง วิธีการจำกัด WIP ก็คือจำกัดจำนวนการ์ดที่อยู่ในคอลัมน์เหมือนตัวอย่างดังรูป ที่คอลัมน์ Test ถูกจำกัดให้มี WIP ได้เพียง 3 งาน และจะไม่สามารถเพิ่มงานใหม่ได้ถ้ายังทำงานที่มีอยู่ไม่เสร็จ ทั้งนี้ในการใช้งานจริง เราไม่ควรทำงานที่ยังไม่ได้เขียนลงใน Kanban Board เพื่อให้เราเห็นจำนวนงานทั้งหมดใน flow การทำงาน
สรุปประโยชน์ของการจำกัด WIP คือทำให้เรามองเห็นปัญหาได้ง่ายขึ้นและไวขึ้น ซึ่งช่วยให้เราหาสาเหตุและแก้ปัญหาได้ไวขึ้น เช่นเราอาจจะพบว่าบางหน่วยงานไม่มีอะไรทำเพราะว่ากำลังรอหน่วยงานอื่นอยู่ เราก็จะเข้าไปแก้ปัญหาได้อย่างทันท่วงทีเป็นต้น นอกจากนี้ยังช่วยแก้ปัญหาเรื่องการจัดลำดับความสำคัญของงานที่เกิดจากการ multitasking ได้อีกด้วย
3. การลด Batch size
สิ่งสำคัญอีกอย่างที่ทำให้ flow การทำงานดำเนินไปได้อย่างราบรื่นและรวดเร็ว คือการลด Batch size ซึ่งก็คือ ปริมาณการผลิตต่อรอบ ยกตัวอย่างง่ายๆจากการเตรียมจดหมาย สมมติว่าเราต้องการเตรียมจดหมาย 5 ฉบับ ซึ่งมีขั้นตอนดังนี้
- พับจดหมาย
- ใส่จดหมายเข้าไปในซอง
- ปิดผนึกจดหมาย
- ติดแสตมป์
ถ้าเราพับจดหมายให้เสร็จทั้ง 5 อันก่อนจากนั้นก็ทำขั้นตอนต่อไปให้เสร็จทั้ง 5 อัน ทำอย่างนี้ไปเรื่อยๆจนเสร็จขั้นตอนสุดท้าย การทำแบบนี้คือมี Batch size ขนาดใหญ่
แต่ถ้าเราพับจดหมาย, ใส่จดหมายเข้าไปในซอง, ปิดผนึกจดหมาย, ติดแสตมป์ ให้เสร็จทีละอันไป การทำแบบนี้คือมี Batch size ขนาดเล็ก
ความแตกต่างระหว่าง Batch size ขนาดใหญ่และเล็กคือ Batch size ขนาดเล็กสามารถออกผลิตภัณฑ์ที่เสร็จสมบูรณ์ได้เร็วกว่ามาก จากตัวอย่างสมมติว่าแต่ละขั้นตอนใช้เวลา 10 วินาที ถ้า Batch size ขนาดใหญ่จดหมายฉบับแรกจะเสร็จเมื่อเวลาผ่านไป 160 วินาที แต่ถ้า Batch size ขนาดเล็กจดหมายฉบับแรกจะเสร็จเมื่อเวลาผ่านไปเพียง 40 วินาทีเท่านั้น ยิ่งถ้าเปลี่ยนจากจดหมาย 5 อันเป็น 50 อัน Batch size ขนาดใหญ่ ต้องใช้เวลาถึง 1510 วินาทีกว่าจดหมายฉบับแรกจะเสร็จ
นอกจากนี้สมมติว่าเราไม่สามารถปิดผนึกจดหมายได้ เพราะพับจดหมายใหญ่ไป ถ้าเป็น Batch size ขนาดใหญ่ เราจะพบปัญหาในวินาทีที่ 100 ในตอนที่เราทำขั้นตอนพับจดหมายและใส่จดหมายเข้าไปในซองเสร็จหมดแล้ว ทำให้เราต้องเสียเวลาถอดจดหมายออกจากซองแล้วพับใหม่ทั้งหมด แต่ถ้าเป็น Batch size ขนาดเล็ก เราจะรู้ปัญหาตั้งแต่ทำจดหมายฉบับแรกในวินาทีที่ 20 แล้ว
สรุปประโยชน์ของการลด Batch size ก็คือเวลาผลิตเร็วขึ้น พบปัญหาได้ไวขึ้น และลดเวลาการทำงานซ้ำที่เกิดจากปัญหานั่นเอง
สำหรับกระบวนการพัฒนา Software Batch size ก็คือจำนวน code สะสม ก่อนที่จะ ลง Production นั่นเอง ยิ่งถ้าเรา release software ปีล่ะครั้ง ทำให้ Batch size มีขนาดใหญ่ ซึ่งมีผลกระทบสูงเมื่อเกิดปัญหา ยิ่งถ้าลูกค้าเปลี่ยน requirement กะทันหันหรือลูกค้าตรวจพบ error ในตอน UAT การกลับมาแก้ code เดิมจะใช้เวลานานกว่าปกติเพราะ programmer ลืมไปหมดแล้วว่าทำอะไรลงไป และยังต้องเสียเวลามา ทดสอบระบบใหม่ทั้งหมดซ้ำอีกรอบ นอกจากนี้ software ยังถึงมือลูกค้าได้ช้าอีกด้วย
เพราะฉะนั้นแล้วเราควรจะ release software ทีละน้อยๆแต่บ่อยๆดีกว่า เพราะจะได้พบปัญหาได้ไวขึ้น ผลกระทบต่ำเมื่อเกิดปัญหา และในกรณีที่มี error หรือลูกค้าเปลี่ยน requirement จะเสียเวลาในการแก้ไขและ ทดสอบระบบซ้ำน้อยลง อีกทั้ง software ยังถึงมือลูกค้าไวขึ้นอีกด้วย โดยจะมีเทคนิคที่เรียกว่า Continuous Delivery ที่คอยสนับสนุนการ release software บ่อยๆซึ่งจะกล่าวถึงเรื่องนี้ในบทความตอนต่อๆไป
4. การลดจำนวนการส่งต่องาน
สาเหตุหนึ่งที่ทำให้กระบวนการพัฒนา software ทำได้ช้าลง ก็คือขั้นตอนการทำงานตั้งแต่รับ requirement ไปจนลง production ต้องผ่านหน่วยงานหลายหน่วยงานมาก ซึ่งการส่งต่องานระหว่างหน่วยงานแต่ละครั้ง นอกจากจะเสียเวลาไปกับการสื่อสารผ่านการประชุม อีเมลล์ หรือโทรศัพท์แล้ว ยังเสียเวลาไปกับการรอคิวจากหน่วยงานถัดไป ว่าจะมีคนว่างทำงานให้เมื่อไหร่อีกด้วย
เพื่อที่จะปรับ flow การทำงานให้ไวขึ้น เราต้องพยายามลดจำนวนการส่งต่องานลงเพื่อลดเวลาสื่อสารและเวลาที่ต้องรอคิว โดยใช้วิธีการต่างๆ เช่น การ automate งานบางส่วน หรือ การ reorganize หน่วยงานให้สามารถทำงานได้ครบ flow ตั้งแต่รับ requirement ไปจนถึงลง production ได้ด้วยหน่วยงานเดียว
5. การหาจุดคอขวดของ flow การทำงานแล้วกำจัดออกไปอย่างต่อเนื่อง
เพื่อที่จะปรับปรุง flow การทำงานให้ได้รวดเร็วที่สุด เราต้องอาศัยทฤษฎีข้อจำกัด (Theory of Constraint) ซึ่งเป็นวิธีการเพิ่มอัตราเร็วของทั้งกระบวนการโดยการหาจุดคอขวดแล้วกำจัดออกไปมาช่วย โดยเทคนิคในการหาจุดคอขวดจะใช้สิ่งที่เรียกว่า value stream mapping ซึ่งจะกล่าวถึงในบทต่อๆไป รายละเอียดเพิ่มเติมสามารถดูได้ในบทความ Learn DevOps ตอนที่ 1 : จุดเริ่มต้นของการเปลี่ยนแปลง
โดยปกติแล้วบริษัทจะมีจุดคอขวดที่ทำให้ไม่สามารถทำให้ release software ได้อย่างรวดเร็ว ดังต่อไปนี้
- การที่ Development ไม่สามารถสร้างหรือจำลอง test environment และ production environment ตามความต้องการได้ ต้องรอให้ Operations ทำให้ ซึ่งอาจจะใช้เวลาเป็นสัปดาห์หรือเป็นเดือนวิธีแก้ไขคือทำให้การสร้างหรือจำลอง environment อยู่ในรูปแบบของ self-serviced ที่ Operations เตรียมไว้ให้ Development นำไปใช้
- การที่ใช้เวลา deploy code เพื่อ test หรือลง production นานเกินไป ซึ่งมักจะเกิดจากการ deploy แบบ manual ที่มีโอกาสผิดพลาดได้สูง วิธีการแก้ไขคือให้ automate การ deploy code ให้มากที่สุดเท่าที่จะทำได้
- การใช้เวลาทดสอบระบบนานเกินไป เช่นใช้เวลา 3 สัปดาห์ ในการ manual regression test วิธีแก้ไขคือการทำ automate test
- การที่สถาปัตยกรรมระบบมี dependencies สูง หมายถึงว่าทุกๆครั้งที่มีการ change ระบบ เราต้องส่งคนไปขออนุมัติการ change จากคณะกรรมการ เพราะว่ามีโอกาสที่จะไปกระทบต่อระบบอื่นๆทำให้เกิดปัญหาได้ วิธีแก้ไขคือปรับเปลี่ยนสถาปัตยกรรมระบบใหม่ให้มี dependencies น้อยที่สุด
6. การกำจัดความสูญเปล่าใน flow การทำงาน
เป็นแนวคิดที่มาจากการผลิตแบบลีน ซึ่งเป็นหลักการที่เน้นลูกค้าเป็นศูนย์กลางโดยปรับปรุงกระบวนการทำงานอย่างต่อเนื่องด้วยการกำจัดความสูญเปล่าที่ไม่ได้เพิ่มคุณค่าให้กับลูกค้า ความสูญเปล่าในกระบวนการพัฒนา software มีดังต่อไปนี้
- การรอคอย เช่น รอคนอนุมัติ รอคนทำงานว่าง เป็นต้น
- งานที่ไม่ได้เพิ่มคุณค่าให้กับลูกค้า เช่นการทำเอกสารบางอย่างที่ไม่ได้ใช้งานจริง แต่แค่ทำไปตามกฎระเบียบ
- การสร้าง feature ที่ลูกค้าไม่ได้ใช้งาน
- การ multitasking
- การสื่อสารในกรณีที่ส่งต่องานให้หลายๆหน่วยงาน หรือคนที่คุยด้วยอยู่คนละสถานที่
- defect ที่ยิ่งพบช้าจะยิ่งแก้ยากขึ้น
- การทำงานแบบ manual หรือทำงานแบบไม่มีมาตรฐาน ดังนั้นควรจะ automate งานให้มากที่สุดเท่าที่จะทำได้
- การที่คนบางคนหรือทีมต้องทำอะไรที่ไม่สมเหตุสมผล เพื่อที่จะให้งานสำเร็จ เช่น แก้ปัญหา production ตอนตีสอง หรือเปิดใบงานใหม่เป็นร้อยๆใบในทุกๆครั้งที่มีการ release software เป็นต้น
โดยสรุปแล้วการปรับปรุง flow การทำงานเป็นสิ่งสำคัญที่จะทำให้ DevOps เกิดขึ้นมาได้ โดยใช้วิธีการแสดงภาพของงานทั้งหมดให้ทั้งทีมเห็นอย่างชัดเจน, การจำกัด Work in process, การลด Batch size, การลดจำนวนการส่งต่องาน, การหาจุดคอขวดของ flow การทำงานแล้วกำจัดออกไปอย่างต่อเนื่อง และการกำจัดความสูญเปล่าใน flow การทำงาน สำหรับบทความตอนหน้าเราจะมาพูดถึงหลักการสำคัญของ DevOps ข้อที่ 2 นั่นก็คือหลักการของ feedback อย่าลืมติดตามชมกันนะครับ
เอกสารอ้างอิง
หนังสือ DevOps Handbook : How to Create World-Class Agility, Reliability, and Security in Technology Organizations (2016). โดย Gene Kim, Jez Humble, Patrick Debois, John Willis.