การประชุมที่เกิดจากการดีพลอยที่ช้า (2015)
(tidyfirst.substack.com)- ในสถานการณ์ที่วิศวกรรู้สึกว่า “ปล่อยโค้ดไม่ได้เพราะมีประชุม” สาเหตุที่แท้จริงอาจเป็น ภาระงานระดับองค์กร ที่เกิดจากความสามารถในการดีพลอยที่ช้า
- Chuck Rossi แห่ง Facebook มองว่า จำนวนการเปลี่ยนแปลง ที่การดีพลอยหนึ่งครั้งรองรับได้ดูเหมือนจะค่อนข้างคงที่ และหากต้องการเพิ่มปริมาณการเปลี่ยนแปลง ก็ต้องเพิ่มจำนวนครั้งของการดีพลอย
- Facebook เพิ่มการดีพลอยโค้ด PHP จากรายสัปดาห์เป็นรายวัน และเป็นวันละ 3 ครั้ง อีกทั้งยังลดรอบการดีพลอยแอปมือถือจาก 6 สัปดาห์เป็น 4 สัปดาห์และ 2 สัปดาห์ โดยส่วนใหญ่ ทีมรีลีสเอนจิเนียริง เป็นผู้ขับเคลื่อนเรื่องนี้
- เมื่อปริมาณการเปลี่ยนแปลงที่สร้างขึ้นเกินขีดจำกัดของการดีพลอย จำนวนการเปลี่ยนแปลงต่อการดีพลอยจะไม่เพิ่มขึ้นได้ง่าย และองค์กรจะปรับตัวด้วยการเพิ่ม โอเวอร์เฮด เช่น การประชุม การรีวิว และการแฮนด์ออฟ จนทำให้ปริมาณการเปลี่ยนแปลงโดยรวมลดลง
- หากต้องการให้การเปลี่ยนแปลงผ่านไปได้มากขึ้น ไม่ใช่แค่ต้องลดการประชุม แต่ต้องเพิ่ม ความจุในการดีพลอย ด้วยการปรับปรุงรอบการดีพลอย การทดสอบ การมอนิเตอร์ริง การแยกส่วน และความสัมพันธ์ทางสังคมภายในทีม
การประชุมอาจไม่ใช่สาเหตุ แต่เป็นผลลัพธ์
- คำบ่นที่พบบ่อยว่า “มีประชุมเยอะจนปล่อยโค้ดไม่ได้” อาจเป็นการเข้าใจเหตุและผลกลับด้าน
- การเพิ่มหรือลดโอเวอร์เฮดขององค์กรทำได้ค่อนข้างง่าย แต่การเพิ่ม ความสามารถในการปล่อยโค้ด ขององค์กรนั้นยากกว่า
- การประชุมและการรีวิวอาจเป็นผลจากการที่องค์กรปรับตัวเพื่อไม่ให้ระบบดีพลอยทำงานเกินกำลัง
- Chuck Rossi สังเกตที่ Facebook ว่าจำนวนการเปลี่ยนแปลงที่การดีพลอยหนึ่งครั้งจัดการได้ ดูเหมือนมีค่าคงที่
- ถ้าต้องการการเปลี่ยนแปลงมากขึ้น ก็ต้องมีการดีพลอยมากขึ้น
- การดีพลอยโค้ด PHP เพิ่มจากรายสัปดาห์เป็นรายวัน และเป็นวันละ 3 ครั้ง
- รอบการดีพลอยแอปมือถือสั้นลงจาก 6 สัปดาห์เป็น 4 สัปดาห์และ 2 สัปดาห์
- การปรับปรุงนี้ส่วนใหญ่ขับเคลื่อนโดยทีมรีลีสเอนจิเนียริง
ถ้าไม่เพิ่มความจุในการดีพลอย โอเวอร์เฮดจะยิ่งสูงขึ้น
- “จำนวนการเปลี่ยนแปลงต่อการดีพลอย” ดูเหมือนเป็น ตัวชี้วัดที่ไม่ยืดหยุ่น ซึ่งจะปรับให้ดีขึ้นได้ก็ต่อเมื่อทุ่มความพยายามอย่างมาก
- หากจำนวนการเปลี่ยนแปลงที่สร้างขึ้นเกินขีดจำกัดปัจจุบัน จะเกิดแรงกดดันให้ปริมาณการเปลี่ยนแปลงรวมลดลง มากกว่าที่จำนวนการเปลี่ยนแปลงต่อการดีพลอยจะเพิ่มขึ้น
- การประชุม การรีวิว การแฮนด์ออฟ และโอเวอร์เฮดอื่น ๆ จะเพิ่มขึ้น
- เมื่อเวลาผ่านไป ความกระตือรือร้นและความเป็นเจ้าของงานก็อาจลดลงด้วย
- การเพิ่มขึ้นของโอเวอร์เฮดอาจสร้าง วงจรป้อนกลับเชิงบวก
- งานที่ดำเนินการได้ลดลง
- แรงกดดันเพิ่มขึ้น
- ความผิดพลาดเพิ่มขึ้น
- จำนวนการเปลี่ยนแปลงต่อการดีพลอยลดลงอีก
- โอเวอร์เฮดเพิ่มขึ้นอีกครั้ง
- ความพยายามแบบแยกส่วนที่มุ่งลดโอเวอร์เฮดอย่างเดียว อาจยิ่งเพิ่มแรงกดดันและทำให้โอเวอร์เฮดกลับมาสูงขึ้นอีก
- หากต้องการให้การเปลี่ยนแปลงผ่านไปได้มากขึ้น ต้องขยายความจุในการดีพลอยซึ่งเป็น “ปลายสายอีกด้านของสายยาง”
- วิธีที่ยาก: ลดรอบการดีพลอยและรับมือกับความวุ่นวายที่ตามมา
- วิธีที่ยากกว่า: เพิ่มจำนวนการเปลี่ยนแปลงต่อการดีพลอยด้วยการทดสอบที่ดีขึ้น การมอนิเตอร์ริงที่ดีขึ้น การแยกองค์ประกอบออกจากกัน และความสัมพันธ์ทางสังคมภายในทีมที่ดีขึ้น
- การพยายามลดการประชุมเพียงอย่างเดียว อาจลงเอยด้วย “การประชุมเพื่อคุยว่าจะลดการประชุมอย่างไร”
- นี่อาจเป็นตัวอย่างของ Reverse-Causality Thinkie ที่หยิบไอเดียซึ่งตอนแรกดูเหมือนผิดมาจัดวางใหม่
2 ความคิดเห็น
ความคิดเห็นนี้น่าสนใจมาก
ความคิดเห็นจาก Hacker News
น่าเสียดาย แต่ผมคิดว่าข้อสรุปของบทความนี้ดูจะกลับด้านไปหน่อย การปรับปรุงการทดสอบและคุณลักษณะเชิงองค์กรเพื่อลดความเสี่ยงในการ deploy เป็นเรื่องสำคัญ แต่ไม่ใช่วิธีเดียวที่ใช้ได้ผล
ผู้เขียนบอกว่าจำนวนการเปลี่ยนแปลงต่อการ deploy นั้นคงที่และเพิ่มได้ยาก แต่ผมมองว่า “Reversie Thinkie” ในที่นี้คือ การลดจำนวนการเปลี่ยนแปลงต่อการ deploy มากกว่า เหตุผลที่ต้องมีประชุม deploy ก็เพราะความเสี่ยง และยิ่งมีการเปลี่ยนแปลงมากในการ deploy ครั้งเดียว โอกาสที่บั๊กหรือปัญหาการปฏิบัติการจะหลุดเข้าไปก็ยิ่งสูง การ deploy การเปลี่ยนแปลงเล็ก ๆ บ่อย ๆ ช่วยส่งมอบคุณค่าได้เร็วขึ้น และทำให้ความล้มเหลวเล็กลงด้วย
หากผสานสิ่งนี้กับ canary deployment และการปล่อยแบบค่อยเป็นค่อยไป การ deploy ก็จะไม่ใช่โลกที่เหมือนเปิดสวิตช์แล้วพังหรือไม่พังอีกต่อไป แต่เป็นโลกที่เปลี่ยนความขัดข้องให้กลายเป็นการเสื่อมประสิทธิภาพหรือผลกระทบที่จำกัด แนวทางนี้ถูกกล่าวถึงไว้อย่างดีในงานวิจัย DORA[0], Accelerate[1], The Phoenix Project[2] และ The Goal[3] ซึ่งเป็นบรรพบุรุษทางความคิดของแนวทางนี้
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
ประเด็นหลักคือองค์กรลงทุนเวลาและทรัพยากรกับ automated testing มากแค่ไหน การประชุม release เกิดขึ้นเพราะไม่มีโครงสร้างพื้นฐานสำหรับตรวจสอบก่อนและหลัง deploy และไม่มีโครงสร้างพื้นฐานสำหรับ rollback การเปลี่ยนแปลงที่ล้มเหลว จึงต้องใช้การตรวจสอบด้วยมือชั่วคราวมาอุดช่องว่างของการขาดการตรวจสอบอัตโนมัติ หากองค์กร QA ขาดความสามารถทางเทคนิค ก็จะผลักดันขั้นตอนแบบ manual เพื่อรักษาบทบาทของตัวเอง
แย่กว่านั้นคือบางครั้งยังถูกห่อหุ้มให้ดูเหมือนว่าการผ่านการประชุมแบบนี้เป็นสัญญาณของความเป็นเลิศและ best practice เพราะคนที่ถูกจ้างมาเพื่อบรรเทาปัญหาไม่มีแรงจูงใจที่จะกำจัดปัญหานั้นให้หมดไปจากราก หากบั๊กหลุดไป production ก็จะกลายเป็นว่า “QA จับปัญหาที่นักพัฒนาสร้างขึ้นไม่ได้ด้วยเหตุผลสารพัด” แต่ถ้ามี automated testing อยู่แล้ว แม้แต่ในขั้น PR ก็ยากที่จะปล่อยให้หลุดไปได้
การประชุมไม่ได้เกิดเพราะความเสี่ยง แต่เกิดเพราะในองค์กรมีบทบาทที่ต้องอาศัยความเสี่ยงเพื่อให้มีเหตุผลในการคงอยู่ และขาดทักษะทางเทคนิคที่จะลดความเสี่ยงนั้น หากสามารถทำ automation สำหรับการตรวจขั้นต่ำว่าการเปลี่ยนแปลงหลัง deploy ถูกเรียกใช้และทำงานได้จริง รวมถึง rollback อัตโนมัติเมื่อเกิดความล้มเหลว การประชุมก็ไม่จำเป็นอีกต่อไป
ผมมองว่ากระบวนการจำนวนมากเหล่านี้เป็นการตอบสนองที่สมเหตุสมผลแต่ไม่ใช่เชิงเทคนิค เพื่อให้ทนกับสถานการณ์แย่ ๆ ให้ได้มากที่สุดเมื่อยังไม่มีวิธีแก้ที่รากฐาน เพียงแต่มันไม่ได้ไม่เป็นอันตรายเสียทีเดียว ในบางองค์กร แม้แต่โปรเจกต์ใหม่หรือโปรเจกต์กำจัดความไร้ประสิทธิภาพเดิม ๆ ผู้มีอำนาจตัดสินใจก็ยังผลัก กระบวนการที่มีคนเป็นศูนย์กลาง มาเป็นคำตอบอยู่เรื่อย ๆ
นั่นเป็นกรณีที่ขาดจินตนาการเชิงเทคนิคหรือถูกขังอยู่ในกรอบปัญหาเดิม ๆ คนที่มีจินตนาการแบบนั้นจึงต้องออกมาพูดว่า ในที่ที่ทำได้ ควรลดกระบวนการที่อาศัยคนด้วยการเปลี่ยนแปลงทางเทคนิคให้เหลือน้อยที่สุด เราไม่สามารถกำจัดทุกกระบวนการของคนด้วยเทคโนโลยีได้ แต่ก็ไม่อยากกระจายตัวบาง ๆ ไปกับสิ่งที่ไม่จำเป็น
ในช่วงเวลาหนึ่ง อาจประเมินได้ว่าการเปลี่ยนแปลง มากกว่า 2% ของกระบวนการทั้งหมดคือ “มากเกินไป” และค่านี้สามารถปรับได้ แต่ละโดเมนก็คงต่างกัน ดังนั้นทีมโค้ดด้านการประมวลผลการชำระเงินกับทีมโค้ด HR ควรมีเกณฑ์ต่างกัน และอาจสมเหตุสมผลที่จะหมุนเวียน release หรือทีม
ช่วงนี้ทีมนี้ทำงานยาก พอขึ้น live แล้วค่อยหมุนกลับไปทำงานง่าย หลักเดียวกันนี้ใช้ได้กับการโจมตีสนามเพลาะ การรุกของกองพัน และการปฏิบัติการผสมเหล่าทัพ
แน่นอนว่านี่เป็นปัญหาด้านการจัดการ แต่สามารถทำ automation ได้ในระดับหนึ่ง และอินพุตเชิงความรู้สึกอย่างทีมไหนเพิ่ง commit ในโมดูลที่อ่อนไหวก็มีประโยชน์เช่นกัน สุดท้าย มุมมองนี้ทำให้ sprint ของ Agile/Scrum ดูแปลกไป เรารู้ว่าไม่สามารถวิ่งเต็มสปีดตลอดทั้งมาราธอนได้ แล้วจะเตรียมการหมุนเวียน sprint อย่างไร
ใช้ feature flag ได้ก็จริง แต่จะทำให้เกิด “backlog ของฟีเจอร์ที่ยังไม่เปิดใช้งาน” สุดท้ายฟีเจอร์ส่วนใหญ่ถูกใช้งานโดยมนุษย์ และมนุษย์ต้องการ การอบรม เกี่ยวกับการเปลี่ยนแปลง
เขาจัดการเรื่อง flow แปลหลักการของ Toyota Production System และนำฟิสิกส์มาประยุกต์กับกระบวนการทางธุรกิจมาตั้งนานก่อนจะมีใครเขียน The Phoenix Project เสียอีก ผมก็ชอบ The Phoenix Project แต่เมื่อเทียบกับ The Goal แล้ว มันใกล้เคียงกับฉบับดัดแปลงราคาถูกที่ทำให้คนในวงการ IT อ่านเรื่องสายการผลิตแล้วไม่หนีไปด้วยข้ออ้างว่า “ฉันเป็น PrOgrAmmEr งานสร้างสรรค์จึงปรับให้เหมือนโรงงานไม่ได้”
ดังนั้น The Phoenix Project จึงเป็น ภาคต่อทางจิตวิญญาณ ของ The Goal ไม่ใช่กลับกัน
กำลังพยายามอธิบายแนวคิดที่เรียกว่า “ความรู้เท่าทันซอฟต์แวร์” หมายความว่า ทุกวันนี้บริษัทดำเนินงานด้วยประโยคภาษาอังกฤษอย่างเอกสารนโยบายและอีเมลได้อย่างไร ธุรกิจก็สามารถดำเนินงานด้วยโค้ดได้เช่นกัน
จากจุดนี้จึงนำไปสู่ข้อสรุปทำนองว่า “ถ้า GPU เป็นผู้ทำงาน คนเขียนโค้ดก็คือผู้จัดการคนใหม่” หรือจำเป็นต้องมี ชุดทดสอบระดับทั้งองค์กร เพื่อให้ผลกระทบของการเปลี่ยนแปลงชัดเจน ดูเหมือนจะเกี่ยวข้องโดยตรงกับบทความยอดเยี่ยมนี้ด้วย หากผู้มีอำนาจตัดสินใจทุกคนไม่ได้มองว่าโค้ดเป็นวัตถุชั้นหนึ่งของกระบวนการเปลี่ยนแปลง ไม่ใช่ Jira หรือแผนโครงการ นั่นก็หมายความว่าผู้มีอำนาจตัดสินใจเหล่านั้นไม่มีความรู้เท่าทันในเชิงซอฟต์แวร์
มักมีคำถามว่า “จะคุยเรื่องนี้กับผู้บริหารที่ไม่ใช่สายเทคนิคอย่างไร” คำตอบคือทำไม่ได้ ผู้บริหารเหล่านั้นต้องเปลี่ยนเอง นี่คือช่องว่างระหว่างรุ่นขนาดใหญ่ที่เมื่อ 30 ปีก่อนก็คิดว่าเป็นปัญหา แต่เคยมองอย่างไร้เดียงสาว่ามันจะหายไปเมื่อคนเขียนโค้ดเติบโตขึ้น ทว่าเพราะการ “บริหาร” บริษัทไม่จำเป็นต้องเขียนโค้ด จึงเป็นเรื่องยากที่จะก้าวข้ามได้ จนกว่าการเขียนโค้ดไม่เป็นจะกลายเป็นเรื่องน่าอาย เหมือนบรรณาธิการหนังสือพิมพ์ที่เขียนหนังสือไม่เป็น
ใจความสำคัญคือ สิ่งที่ต้องมีไม่ใช่ SOP, การทดสอบ หรือการประชุม แต่เป็นบริษัทที่ดำเนินงานได้ด้วยชุดแนวคิดใหม่ที่เสริมแรงกันและกัน เช่น ระบบในฐานะการสื่อสาร
แต่ไม่แน่ใจว่าทำไมถึงเรียกว่า “ความรู้เท่าทัน” คำว่า autopoiesis ของ Maturana & Varela น่าจะเข้าใกล้แก่นมากกว่า และ Autopoietic Systems ของ Stafford Beer ก็น่าจะให้ฐานทางความคิดที่ดีได้เช่นกัน
แต่พอถึงจุดหนึ่ง “ธุรกิจ” ซอฟต์แวร์ล้วน ๆ ก็ดูเหมือนจะกลายเป็น SaaS ไปเฉย ๆ ไม่ใช่หรือ
องค์กรจะขัดขวางความพยายามในการปรับปรุงการ deploy อย่างจริงจัง พวกเขาจะพูดด้วยสีหน้าจริงจังว่า “ห้ามเอา Jenkins ไปไว้ใกล้ production”, “ห้ามขึ้น live ถ้าไม่มี QA”, “เราต้องใช้เวลาขนาดนี้เพื่อรับประกันคุณภาพซอฟต์แวร์ให้เพียงพอ”
ขณะเดียวกัน bug ใน production ก็มีเป็นล้าน ๆ และผลิตภัณฑ์แทบไม่ตอบโจทย์ความต้องการของผู้ใช้ สุดท้ายแล้ว ในองค์กรส่วนใหญ่ การสู้กับระบบราชการแทบเป็นไปไม่ได้ โดยเฉพาะถ้าคุณไม่ได้อยู่ในชั้นบริหาร 200 ชั้นที่สร้างการประชุมแบบนี้ขึ้นมา
อยากให้ไล่ทุกคนออกให้หมด เหลือแค่โปรแกรมเมอร์กับดีไซเนอร์สักสองคน แล้วปล่อยให้พวกเขาลุยกันเองโดยไม่มี agile coach, product owner, scrum master หรือ product expert การ deploy ช้าเป็นปัญหา แต่ไม่ใช่ ตัวปัญหาเอง
หากคุณมักไปอยู่แต่ในที่ที่ดูเหมือนเปลี่ยนแปลงอะไรไม่ได้ ก็ควรถามเรื่องนี้ให้มากขึ้นตอนสัมภาษณ์ ในบริษัทเล็ก ๆ มีหลายแห่งที่ไม่มีระบบราชการบ้า ๆ ตามแบบที่ผมชอบ และตอนนี้ผมอยู่บริษัทใหญ่ แต่ถ้าเคลื่อนไหวอย่างสม่ำเสมอและมีเหตุผลโน้มน้าว หลายอย่างก็ค่อย ๆ ไปในทิศทางที่ถูกต้องได้
ต้องเข้าใจว่างานต้องใช้เวลา และต้องเข้าใจว่าทำไมผู้คนถึงทำให้มันเป็นแบบนั้น จากนั้นจึงหาเหตุผลที่น่าเชื่อเพื่อทำให้มันดีขึ้น ที่ที่แย่จริง ๆ ก็มี ดังนั้นไม่ควรอยู่ต่อในที่แบบนั้น แต่ความสิ้นหวังไม่ได้ช่วยอะไรมากนัก
คงมีหลายอย่างต้องคลี่ออกมา แต่ bias ของผมอยู่ข้างข้อเสนอนี้
Jenkins คือ Wordpress ของโลกการพัฒนาซอฟต์แวร์ มันเป็นลูปสถานะขนาดมหึมาที่รันปลั๊กอินโดยไม่มีการแยกสิทธิ์ การให้ credentials ของผู้ดูแล production กับอินสแตนซ์ Jenkins อาจเทียบได้กับการมอบ root key ให้ใครสักคนในโรมาเนียที่ทำปลั๊กอินซึ่งไม่เคยผ่านการ audit มาก่อน เข้าใจได้เต็มที่ว่าทุกคนอาจไม่อยากทำแบบนั้น
“ห้ามขึ้น live ถ้าไม่มี QA” ก็เช่นกัน ถ้าจะ deploy สิ่งที่ไม่เคยผ่าน QA ไปยัง production แล้ว QA มีไว้ทำไม? ไว้ค่อยแก้ทีหลังหรือ? ถ้าไม่ให้อำนาจ QA ก็ไม่มีทั้งโอกาสทำงานให้ดีและโอกาสภูมิใจในงานของตัวเอง
ทุก initiative ตั้งแต่วันแรก Jenkins ก็เชื่อมต่อไปถึง production และมักไปตรง ๆ ด้วย trunk-based development คุณภาพเป็นความรับผิดชอบของนักพัฒนาทุกคน ในระดับ individual contributor ไม่มี “การสู้กับระบบราชการ” แต่ในกรณีที่มีพาร์ตเนอร์ภายนอกและผู้มีส่วนได้ส่วนเสียเกี่ยวพันลึก ๆ ระดับ leadership ก็คงมีการถกเถียงกันดุเดือดเป็นครั้งคราว
วิธีที่เหลือไว้แค่โปรแกรมเมอร์กับดีไซเนอร์นั้นสำหรับผมถือว่าดี แต่สเกลไม่ได้ อย่างน้อยต้องมี product “owner”, “expert” หรือ “manager” สักคนเพื่อจัดคิวลำดับความสำคัญของผู้มีส่วนได้ส่วนเสีย จะให้บทบาทนี้เป็น “หมวก” ที่นักพัฒนากับดีไซเนอร์ผลัดกันสวมก็ได้ แต่บางคนก็เก่งทักษะนี้เป็นพิเศษ
ผมเข้าใจด้วยว่าหลายองค์กรไม่ได้ดำเนินงานแบบนี้ เวลาจะเปลี่ยนบริษัทไปในทิศทางนี้ วิธีที่ช่วยได้คือสร้างทีมทดลองทีมเดียวแบบอาสาสมัครที่ทุ่มเทให้แนวปฏิบัติเหล่านี้ และให้การคุ้มครองด้วยอำนาจจากข้างบน แต่ไม่ใช่การสั่งการ แน่นอนว่าที่นี่คือ California
เรื่องที่เกี่ยวข้องกันเล็กน้อย ผมเคยทำงานในที่ที่ CI pipeline ใช้เวลาประมาณ 25 นาที และในนั้น test ระดับ unit/integration กว่า 3,000 ตัวกินเวลาไป 18 นาที
ทุกครั้งที่เกิดปัญหาใน production ก็เพิ่ม test เข้าไปอีก และแน่นอนว่าเมื่อเกิดเรื่องผิดพลาด การกู้คืนต้องใช้เวลาอย่างน้อย 50 นาที หลังคิดหนักอยู่มาก เราตัดสินใจโฟกัสที่การกู้คืน ผ่อนและทำให้ test บางส่วนง่ายลงจนทั้งหมดใช้เวลาต่ำกว่า 5 นาที และใช้ canary deployment แทน rolling update
สำหรับพวกเราเป็นประสบการณ์ที่สดใหม่มาก แต่ในบางแง่ก็รู้สึกเหมือนว่ามันไม่ถูกต้องนัก
แน่นอนว่าในความเร็วของการ deploy นั้นมีสารพัดองค์ประกอบพันเกี่ยวอยู่ แต่แทบทั้งหมดเป็นองค์ประกอบที่ดี
ออกนอกเรื่องเล็กน้อย แต่ทำไม CloudFormation ถึงช้าแบบนี้?
เคยมีกรณีที่ลบ Lambda ใน VPC แล้วเชื่อมกับ EFS ตัว deploy เองค่อนข้างเร็ว แต่ CloudFormation ใช้เวลาประมาณ 20 นาทีในการเก็บกวาดและจบงาน
ทุกครั้งที่ deploy การเปลี่ยนสถานะเป็น transaction ต้องตรวจสอบ precondition และ postcondition ในแต่ละขั้นตอน หากจะ release ชุดการเปลี่ยนแปลงที่มี dependency ต่อกันแม้เพียงเล็กน้อย ก็เลี่ยงไม่ได้ที่จะต้อง deploy การเปลี่ยนแปลงแต่ละรายการเป็นขั้นตอนตามลำดับ แต่ละขั้นตอนต้องเรียกเครือข่ายหลายครั้งเพื่อ apply change, ยืนยัน, และ poll สถานะ ซึ่งแต่ละครั้งใช้เวลาประมาณ 50–200ms และสะสมขึ้นมาอย่างรวดเร็ว
ต่อให้ deploy แอปเดียวกันไปยัง cloud provider อื่นด้วย Terraform หรือ Ansible ผลลัพธ์ก็คล้ายกัน ถ้า deploy การเปลี่ยนแปลงเดียวกันด้วยมือ งานระดับไม่กี่นาทีก็จะกลายเป็นความทรมานทั้งวัน
ปัญหาใหญ่ที่สุดของ IaC คือมันอยู่ในระดับ abstraction สูงเกินไป และทำงานภายในมากเกินไป จนทำให้มีคนที่ไม่รู้ว่าจริง ๆ แล้วกำลัง apply การเปลี่ยนแปลงอะไรหรือกำลังทำอะไรอยู่ แล้วก็ไปบ่นว่ามันใช้เวลานาน
มีเรื่องที่ผมเคยเจอเองในที่ทำงาน ก่อนวันหยุดคริสต์มาสมีการเปลี่ยนแปลงครั้งใหญ่และทุกคนกลัวมาก องค์กรตอบสนองด้วยการเพิ่มการทดสอบ กล่าวคือเพิ่ม regression test จน overhead สูงขึ้น
สิ่งนี้ทำให้ความเสี่ยงที่การเปลี่ยนแปลงใน dev จะทำให้การเปลี่ยนแปลงใน branch ของผมพังสูงขึ้น ไม่ใช่ความเสี่ยงแบบ code merge conflict แต่เป็นความเสี่ยงในมุมของ complex adaptive system ผมรับมือกับความเสี่ยงนี้ด้วยการจัดประชุม และตอนประกาศแผนโครงการก็อธิบายความคาดหวังกับเพื่อนร่วมงานว่า ถ้าทิ้งคอมเมนต์เรื่อง code style ไว้ใน PR มันจะถูกเลื่อนไปเป็น PR ถัดไป และสุดท้ายก็จะถูกเพิกเฉย
สิ่งที่ต้องการจริง ๆ คือ การทดสอบที่ละเอียดขึ้น ซึ่งแยก isolation ระหว่าง component ได้ดีกว่า ปัญหาคือผู้บริหารมองจากระดับสูงเกินไป และมองการประชุมไม่ใช่เป็นเครื่องมือ แต่เป็นเป้าหมายที่มีคุณค่าในตัวเอง ยิ่งมีประชุมมากก็ยิ่งมีการทำงานร่วมกันมาก แล้วก็ดี แบบนั้น อยากเห็นคำแนะนำเรื่องการขับเคลื่อนการเปลี่ยนแปลงทางเทคนิคกับผู้บริหารที่ไม่ใช่สายเทคนิค
บทความที่เกี่ยวข้อง: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - พฤศจิกายน 2015, 26 ความคิดเห็น
ถ้าใช้ microservices ก็ scale ความถี่ในการ deploy ในแนวนอนได้ด้วย
แม้เป็นแอป monolithic ที่ประกอบด้วย module อิสระ ก็ deploy ได้มากพอ ๆ กันโดยไม่ต้องใช้ microservices และยังหลีกเลี่ยงข้อเสียหลักอย่างความซับซ้อนของ infrastructure/CI·CD หรือการเปลี่ยน function call ในแอปให้กลายเป็นปัญหาการสื่อสารของ distributed system ที่ไม่น่าเชื่อถือได้ด้วย ต้องต่อต้าน ความซับซ้อนโดยบังเอิญ ที่ไม่จำเป็น
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
แล้วก็มีปัญหาใหม่แสนสนุกเรื่องการวางแผน deploy และการ sync การปล่อย feature
ไม่เช่นนั้นก็จะได้ทั้งปัญหา distributed data และระดับความซับซ้อนที่เพิ่มขึ้น หรือก็คือได้ประชุมมากกว่า monolith ไปพร้อมกัน
ใน monolith มีความเสี่ยงที่จะจมอยู่ในความยุ่งเหยิงมหาศาลของ SOLID, DRY และเรื่องไร้สาระสไตล์ “clean code” อื่น ๆ จนไม่มีใครกล้าเปลี่ยนอะไรเพราะกลัวว่าจะทำให้พัง ไม่ได้หมายความว่าหลักการ OOP เองผิดอย่างชัดเจน แต่บ่อยครั้งมันคลุมเครือสุดขั้วจนไม่มีใครนำไปใช้ได้ถูกต้อง
ผมหัวเราะทุกครั้งที่เห็น Uncle Bob ปัดคำวิจารณ์ว่า “พวกเขาเข้าใจหลักการผิด” ถ้าคนจำนวนมากผิดขนาดนั้น เป็นไปได้ไหมว่าหลักการต่างหากที่แย่? microservices ก็ไม่ได้ปกป้องคุณจาก governance ที่แย่ มันแค่เผยปัญหาออกมาในรูปแบบอื่น ผมคิดว่าสถานการณ์ที่สร้าง microservices หลายตัวแล้วไม่มีใครรู้ว่าการเปลี่ยนแปลงหนึ่งจะกระทบ service อื่นอย่างไรนั้นเกิดขึ้นง่ายและพบได้บ่อยมาก
สุดท้ายเป็นปัญหาการบริหารทีม และจากประสบการณ์ นี่คือด้านที่อุตสาหกรรมของเราทำได้แย่ที่สุด คงดีขึ้นเมื่อคนรุ่นใหม่อย่าง “Team Topologies” เข้ามา แต่ถึงมันจะจบลงจริง ๆ ก็น่าจะใช้เวลาหลายสิบปี หากองค์กรยังมอง “IT” เป็นเพียง cost center และไม่ได้เรียกร้องในรูปแบบที่สามารถผนวกเข้ากับกระบวนการ best practices ของ software engineering ได้ หลายครั้งเรื่องนี้ก็หลุดมือฝ่าย digitalization ไปด้วย
หนึ่งในเหตุผลที่ผมชอบ Go ในฐานะภาษา general-purpose คือมันเรียบง่ายโดยการออกแบบ จึงมักนำไปสู่ codebase ที่เปลี่ยนแปลงได้ง่าย ผมเห็นธนาคารออนไลน์และแพลตฟอร์มเช่า/บริหารสินทรัพย์บางแห่งย้ายมาใช้ Go แล้วเติบโตขึ้นเพราะสามารถส่งมอบสิ่งที่ธุรกิจต้องการได้จริง ในขณะที่คู่แข่งติดอยู่กับ codebase Java หรือ C# ที่จัดการยาก และถ้าโชคดีก็ออก feature ที่เต็มไปด้วย bug ได้สักครั้งในครึ่งปี
นี่ไม่ใช่ปัญหาของ Go, Java หรือ C# เอง แต่เป็นเพราะสถาปัตยกรรมและการออกแบบ OOP แบบเก่าทำให้พังได้ง่ายเกินไป ที่ทำงานเก่าของผมเคยมี C# interface มากกว่าหนึ่งพันตัว แต่ไม่มี interface ไหนถูกใช้โดย class มากกว่าหนึ่งตัวเลย interface หลายหมื่นตัวทั้งหมดอยู่ใน folder และ namespace เดียวกัน การจะหาสิ่งที่ต้องการต้องอาศัยโชคเท่านั้น คุณทำแบบนั้นใน Go หรือภาษาอะไรก็ได้ แต่ถ้าไม่ได้อยู่ในวัฒนธรรมภาษา OOP clean code แบบเก่า โอกาสจะเป็นแบบนั้นก็น้อยกว่า โดยเฉพาะใน C# abstraction โดย default ฝังลึกในวัฒนธรรมมากจนการไม่ทำกลับยากกว่า
ส่วนตัวผมมีความเอ็นดูอย่างลับ ๆ ต่อองค์กรที่ใช้ Python พวกเขามักส่งมอบได้เร็วเสมอ และ code ก็เละเทะ น่ารักดี
โดยรวมก็ถูก แต่ก็ไม่ค่อยเกี่ยวเท่าไร
สรุปคือ สิ่งที่สำคัญมีแค่ประสิทธิภาพของซอฟต์แวร์ และดังนั้นก็คือ ประสิทธิภาพของมนุษย์ การจัดการความเสี่ยงและการยอมรับความเสี่ยงสามารถวัดเป็นตัวเลขได้ ในซอฟต์แวร์ เรื่องนี้ง่ายกว่าวิชาชีพอื่นมาก เพราะวิศวกรซอฟต์แวร์สามารถยอมรับความเสี่ยงได้เฉพาะภายในข้อจำกัดด้านการปฏิบัติการที่ทราบอยู่แล้วเท่านั้น ส่วนที่เหลือทั้งหมดก็ถูกเลื่อนออกไป
ถ้าอยากเร็วขึ้น สิ่งสำคัญที่สุดคือต้องเพิ่มความถี่ของการวนรอบโดยมนุษย์ให้สูงสุด ถ้าคุณวนรอบไม่ได้เพราะต้องรออนุมัติ แปลว่าติดขัด และถ้าคุณต้องรอ build หรือรอ refresh หน้าจอ แปลว่าช้าลง เรื่องนี้ก็วัดเป็นตัวเลขได้เช่นกัน
ถ้า A สามารถวนรอบได้เร็วกว่า B 100 เท่า ความถูกต้องก็กลายเป็นเรื่องรอง B จำเป็นต้องเพิ่มความถูกต้องให้สูงสุดเพราะช้า ส่วน A มีความยืดหยุ่นอย่างมากที่จะเรียนรู้ ล้มเหลว และปรับปรุง เพื่อให้เร็วขึ้นและถูกต้องขึ้น
ส่วนหนึ่งของการลดความเสี่ยงไปพร้อมกับการวนรอบให้เร็วขึ้นคือการทำ test automation ที่รวดเร็ว หาก A สามารถรัน test coverage ได้มากกว่า 90% ภายในเวลาที่มนุษย์วนรอบ 4 ครั้ง test automation นั้นก็ยังเร็วกว่า B ที่วนรอบครั้งเดียวถึง 25 เท่า และลดความเสี่ยงของ regression ได้มากกว่า 90%
การ deploy ที่รวดเร็วทำให้เกิด war room สำหรับรับมือ incident
สิ่งที่สำคัญกว่าการลดลงนั้นมาก คือเมื่อเกิดปัญหา ความเร็วในการหาสาเหตุเร็วขึ้นมาก การเปลี่ยนแปลงที่ถูก rollback มีน้อยมาก จึงปลอดภัยและง่ายกว่ามากที่จะย้อนกลับ ไม่มีใครอยากย้อนงาน 3 สัปดาห์กลับไป นั่นคือความโกลาหล