5
SELECTING WHICH VALUE STREAM TO START WITH (การเลือก Value Stream ที่จะเริ่มต้น)
ก ารเลือก value stream สำหรับการปรับเปลี่ยนสู่ DevOps เป็นเรื่องที่ต้องพิจารณาอย่างรอบคอบ เพราะ value stream ที่เราเลือกไม่เพียงแต่กำหนดระดับความยากของการเปลี่ยนแปลงเท่านั้น แต่ยังกำหนดด้วยว่าใครบ้างที่ต้องเข้ามามีส่วนร่วมในการเปลี่ยนแปลงนี้ มันจะส่งผลต่อวิธีการจัดทีม และวิธีที่ดีที่สุดในการสนับสนุนทีมและสมาชิกแต่ละคนในทีม
Michael Rembetsy ผู้ช่วยนำทีมการปรับเปลี่ยน DevOps ในบทบาท Director of Operations ที่ Etsy ในปี 2009 ได้ชี้ให้เห็นถึงความท้าทายอีกประการหนึ่ง เขากล่าวว่า "เราต้องเลือกโครงการปรับเปลี่ยนของเราอย่างรอบคอบ — เมื่อเรากำลังมีปัญหา เราจะมีโอกาสไม่มากนัก เพราะฉะนั้น เราจึงต้องเลือกอย่างระมัดระวัง และปกป้องโครงการปรับปรุงเหล่านั้นที่จะช่วยปรับปรุงสภาพขององค์กรเราได้มากที่สุด" 1
Nordstrom's DevOps Transformation (การปรับเปลี่ยน DevOps ของ Nordstrom)
มาดูกันว่า Nordstrom เริ่มต้นโครงการปรับเปลี่ยน DevOps ของพวกเขาในปี 2013 ได้อย่างไร ซึ่ง Courtney Kissler รองประธานฝ่าย E-Commerce และ Store Technologies ได้เล่าไว้ที่งาน DevOps Enterprise Summit ในปี 2014 และ 2015
Nordstrom ก่อตั้งขึ้นในปี 1901 เป็นร้านค้าปลีกแฟชั่นชั้นนำที่มุ่งเน้นการมอบประสบการณ์การช้อปปิ้งที่ดีที่สุดให้กับลูกค้า ในปี 2015 Nordstrom มีรายได้ต่อปี 13.5 พันล้านดอลลาร์ 2
จุดเริ่มต้นของเส้นทาง DevOps ของ Nordstrom น่าจะถูกกำหนดขึ้นในปี 2011 ในการประชุมคณะกรรมการบริหารประจำปีครั้งหนึ่ง 3 ในปีนั้น หัวข้อเชิงกลยุทธ์ที่ถูกอภิปรายคือความจำเป็นในการเติบโตของรายได้ออนไลน์ พวกเขาได้ศึกษาชะตากรรมของ Blockbuster, Borders และ Barnes & Noble ซึ่งแสดงให้เห็นถึงผลลัพธ์อันเลวร้ายเมื่อร้านค้าปลีกแบบดั้งเดิมปรับตัวช้าในการสร้างขีดความสามารถด้าน e-commerce ที่แข่งขันได้ องค์กรเหล่านี้มีความเสี่ยงอย่างชัดเจนที่จะสูญเสียตำแหน่งในตลาด หรือแม้กระทั่งเลิกกิจการไปเลย *
ในเวลานั้น Courtney Kissler ดำรงตำแหน่ง senior director ของ Systems Delivery and Selling Technology และรับผิดชอบส่วนสำคัญขององค์กรด้านเทคโนโลยี รวมถึงระบบภายในร้านค้าและเว็บไซต์ e-commerce ออนไลน์ ดังที่ Kissler ได้อธิบายไว้
ในปี 2011 องค์กรด้านเทคโนโลยีของ Nordstrom ถูกปรับให้เหมาะสมกับต้นทุนเป็นอย่างมาก — เราได้ outsource ฟังก์ชันด้านเทคโนโลยีจำนวนมาก เรามีวงจรการวางแผนประจำปีพร้อมการปล่อยซอฟต์แวร์ " waterfall " แบบ large batch แม้ว่าเราจะมีอัตราความสำเร็จ 97% ในการบรรลุเป้าหมายด้านตารางเวลา งบประมาณ และขอบเขต แต่เราก็ไม่พร้อมที่จะบรรลุสิ่งที่กลยุทธ์ทางธุรกิจระยะ 5 ปีต้องการจากเรา เนื่องจาก Nordstrom เริ่มปรับให้เหมาะสมกับความเร็วแทนที่จะปรับให้เหมาะสมกับต้นทุนเพียงอย่างเดียว 5
Kissler และทีมผู้บริหารด้านเทคโนโลยีของ Nordstrom ต้องตัดสินใจว่าจะเริ่มต้นความพยายามในการปรับเปลี่ยนที่จุดใด พวกเขาไม่ต้องการก่อให้เกิดความปั่นป่วนทั้งระบบ แต่ต้องการมุ่งเน้นไปที่พื้นที่เฉพาะของธุรกิจเพื่อให้สามารถทดลองและเรียนรู้ได้ เป้าหมายของพวกเขาคือการแสดงความสำเร็จในช่วงต้น ซึ่งจะทำให้ทุกคนมั่นใจว่าการปรับปรุงเหล่านี้สามารถนำไปใช้ในพื้นที่อื่นๆ ขององค์กรได้ อย่างไรก็ตาม ยังไม่ทราบแน่ชัดว่าจะทำได้อย่างไร
พวกเขามุ่งเน้นไปที่สามพื้นที่: แอปพลิเคชันมือถือสำหรับลูกค้า ระบบร้านอาหารภายในร้านค้า และทรัพย์สินทางดิจิทัล แต่ละพื้นที่เหล่านี้มีเป้าหมายทางธุรกิจที่ไม่ได้รับการตอบสนอง ดังนั้นพวกเขาจึงเปิดรับการพิจารณาวิธีการทำงานที่แตกต่างออกไป เรื่องราวของสองพื้นที่แรกได้อธิบายไว้ด้านล่างนี้
แอปพลิเคชันมือถือของ Nordstrom เริ่มต้นได้อย่างไม่สวยงามนัก ดังที่ Kissler กล่าวว่า "ลูกค้าของเรารู้สึกหงุดหงิดกับผลิตภัณฑ์เป็นอย่างมาก และเราได้รับรีวิวเชิงลบอย่างสม่ำเสมอเมื่อเราเปิดตัวใน App Store" 6 ที่แย่กว่านั้นคือ โครงสร้างและกระบวนการที่มีอยู่ออกแบบมาให้สามารถปล่อยอัปเดตได้เพียงปีละสองครั้งเท่านั้น กล่าวอีกนัยหนึ่ง การแก้ไขใดๆ ในแอปพลิเคชันจะต้องรอเป็นเดือนกว่าจะถึงมือลูกค้า
เป้าหมายแรกของพวกเขาคือการทำให้สามารถปล่อย release ได้เร็วขึ้นหรือตามต้องการ เพื่อให้สามารถ iterate ได้เร็วขึ้นและตอบสนองต่อ feedback จากลูกค้าได้อย่างรวดเร็ว พวกเขาสร้าง product team ที่ทุ่มเทให้กับการสนับสนุนแอปพลิเคชันมือถือโดยเฉพาะ โดยมีเป้าหมายให้ทีมแอปพลิเคชันมือถือสามารถ implement, test และส่งมอบคุณค่าให้กับลูกค้าได้อย่างอิสระ การทำเช่นนี้ทำให้ทีมแอปพลิเคชันมือถือไม่ต้องพึ่งพาและประสานงานกับทีมอื่นๆ มากมายภายใน Nordstrom อีกต่อไป
ยิ่งไปกว่านั้น ทีมแอปพลิเคชันมือถือได้เปลี่ยนจากการวางแผนปีละครั้งไปเป็นกระบวนการวางแผนแบบต่อเนื่อง ผลลัพธ์ที่ได้คือ backlog ของงานสำหรับแอปมือถือที่มีลำดับความสำคัญเดียวตามความต้องการของลูกค้า — ความขัดแย้งด้านลำดับความสำคัญทั้งหมดที่เคยมีเมื่อทีมต้องสนับสนุนหลายผลิตภัณฑ์ก็หมดไป
ตลอดปีถัดมา พวกเขากำจัดขั้นตอนการทดสอบที่เป็น phase แยกต่างหากออกไป และผสานการทดสอบเป็นส่วนหนึ่งของงานประจำวันของทุกคนแทน † พวกเขาเพิ่มจำนวนฟีเจอร์ที่ส่งมอบต่อเดือนเป็นสองเท่า และลดจำนวน缺陷 ลงครึ่งหนึ่ง — สร้างผลลัพธ์ที่ประสบความสำเร็จ
พื้นที่ที่สองที่พวกเขาให้ความสำคัญคือระบบที่สนับสนุนร้านอาหาร Café Bistro ภายในร้านค้า ซึ่งแตกต่างจาก value stream ของแอปมือถือที่ความต้องการทางธุรกิจคือการลดเวลาในการออกสู่ตลาดและเพิ่มปริมาณฟีเจอร์ ความต้องการทางธุรกิจในที่นี้คือการลดต้นทุนและเพิ่มคุณภาพ ในปี 2013 Nordstrom ได้ดำเนินการ "ปรับแนวคิดร้านอาหาร" ไปแล้วสิบเอ็ดครั้ง ซึ่งต้องมีการเปลี่ยนแปลงแอปพลิเคชันภายในร้านค้า ทำให้เกิด incidents ที่ส่งผลกระทบต่อลูกค้าจำนวนมาก ยิ่งไปกว่านั้น พวกเขายังวางแผนจะปรับแนวคิดเพิ่มอีกสี่สิบสี่ครั้งในปี 2014 — ซึ่งมากกว่าปีก่อนหน้าถึงสี่เท่า
ดังที่ Kissler กล่าวไว้ว่า "หนึ่งในผู้นำธุรกิจของเราแนะนำให้เพิ่มขนาดทีมเป็นสามเท่าเพื่อรองรับความต้องการใหม่ๆ แต่ฉันเสนอว่าเราต้องหยุดการเอาคนเพิ่มเข้าไปแก้ปัญหา และหันมาปรับปรุงวิธีการทำงานของเราแทน" 7
ทีมของ Kissler สามารถระบุพื้นที่ที่เป็นปัญหา เช่น กระบวนการรับงานและการ deploy ซึ่งเป็นจุดที่พวกเขามุ่งเน้นความพยายามในการปรับปรุง พวกเขาสามารถลด lead time การ deploy โค้ดลงได้ 60% และลดจำนวน incidents ใน production ลงได้ 60–90%
ความสำเร็จเหล่านี้ทำให้ทีมงานมั่นใจว่าหลักการและแนวปฏิบัติของ DevOps สามารถนำไปใช้กับ value stream ได้หลากหลายประเภท Kissler ได้รับการเลื่อนตำแหน่งเป็น VP ของ E-Commerce and Store Technologies ในปี 2014
ในปี 2015 Kissler กล่าวว่าเพื่อให้องค์กรด้านเทคโนโลยีที่ขายสินค้าหรือ面向ลูกค้าสามารถช่วยให้ธุรกิจบรรลุเป้าหมายได้ "...เราจำเป็นต้องเพิ่ม productivity ในทุกร价值 stream ด้านเทคโนโลยีของเรา ไม่ใช่แค่บางส่วนเท่านั้น ในระดับผู้บริหาร เราสร้างคำสั่งแบบข้ามทุกแผนกให้ลด cycle times ลง 20% สำหรับทุกร services ที่面向ลูกค้า" 8
เธอกล่าวต่อว่า "นี่คือความท้าทายที่กล้าหาญ เรามีปัญหามากมายในสถานะปัจจุบันของเรา — กระบวนการและ cycle times ไม่ได้ถูกวัดอย่างสม่ำเสมอในทุกทีม และก็ไม่สามารถมองเห็นได้ เงื่อนไขเป้าหมายแรกของเราคือการช่วยให้ทุกทีมของเราสามารถวัด ทำ [งาน] ให้มองเห็นได้ และทำการทดลองเพื่อเริ่มลดระยะเวลากระบวนการของพวกเขา iteration ต่อ iteration" 9 Kissler สรุปว่า
จากมุมมองระดับสูง เราเชื่อว่าเทคนิคต่างๆ เช่น value stream mapping การลด batch sizes ของเราไปสู่ single-piece flow รวมถึงการใช้ continuous delivery และ microservices จะนำเราไปสู่สถานะที่ต้องการ อย่างไรก็ตาม ในขณะที่เรายังคงเรียนรู้อยู่ เรามั่นใจว่าเรากำลังมุ่งหน้าไปในทิศทางที่ถูกต้อง และทุกคนรู้ดีว่าความพยายามนี้ได้รับการสนับสนุนจากระดับสูงสุดของผู้บริหาร 10
ในบทนี้ เราจะนำเสนอแบบจำลองต่างๆ ที่จะช่วยให้เราสามารถจำลองกระบวนการคิดที่ทีม Nordstrom ใช้ในการตัดสินใจว่า value stream ใดควรเริ่มต้นก่อน เราจะประเมิน candidate value stream ของเราในหลายๆ ด้าน รวมถึงว่าเป็น greenfield หรือ brownfield service, system of engagement หรือ system of record นอกจากนี้เรายังจะประมาณความสมดุลระหว่างความเสี่ยงและผลตอบแทนของการปรับเปลี่ยน และประเมินระดับการต่อต้านที่อาจเกิดขึ้นจากทีมที่เราจะทำงานด้วย
Greenfield vs. Brownfield Services (Greenfield กับ Brownfield Services)
เรามักจะจัดหมวดหมู่ซอฟต์แวร์ services หรือผลิตภัณฑ์ของเราว่าเป็น greenfield หรือ brownfield คำศัพท์เหล่านี้เดิมใช้ในการวางผังเมืองและโครงการก่อสร้าง Greenfield development คือการที่เราสร้างบนที่ดินที่ยังไม่ถูกพัฒนา Brownfield development คือการที่เราสร้างบนที่ดินที่เคยถูกใช้เพื่ออุตสาหกรรมมาก่อน ซึ่งอาจปนเปื้อนด้วยของเสียอันตรายหรือมลพิษ ในการพัฒนาเมือง ปัจจัยหลายอย่างทำให้โครงการ greenfield ง่ายกว่าโครงการ brownfield — ไม่มีโครงสร้างเดิมที่ต้องรื้อถอน และไม่มีวัสดุที่เป็นพิษที่ต้องกำจัด
ในทางเทคโนโลยี โครงการ greenfield คือโครงการหรือ initiative ซอฟต์แวร์ใหม่ ซึ่งมักจะอยู่ในช่วงเริ่มต้นของการวางแผนหรือการ implement โดยเราสร้างแอปพลิเคชันและ infrastructure ของเราจากศูนย์ โดยมีข้อจำกัดน้อย การเริ่มต้นด้วยโครงการซอฟต์แวร์ greenfield อาจง่ายกว่า โดยเฉพาะอย่างยิ่งถ้าโครงการมี funding อยู่แล้วและทีมกำลังถูกสร้างขึ้นหรือมีอยู่แล้ว ยิ่งไปกว่านั้น เพราะเราเริ่มต้นจากศูนย์ เราจึงกังวลเกี่ยวกับ code bases, architectures, processes และทีมที่มีอยู่น้อยลง
โครงการ DevOps แบบ greenfield มักจะเป็น pilot เพื่อแสดงให้เห็นถึงความเป็นไปได้ของ public หรือ private clouds, การ pilot ระบบ deployment automation และเครื่องมือที่คล้ายคลึงกัน ตัวอย่างของโครงการ DevOps แบบ greenfield คือผลิตภัณฑ์ Hosted LabVIEW ในปี 2009 ที่ National Instruments ซึ่งเป็นองค์กรอายุสามสิบปีที่มีพนักงานห้าพันคนและรายได้ต่อปี 1 พันล้านดอลลาร์
เพื่อนำผลิตภัณฑ์นี้ออกสู่ตลาดอย่างรวดเร็วจึงได้สร้างทีมใหม่ขึ้นมา พวกเขาได้รับอนุญาตให้ทำงานนอกเหนือจากกระบวนการ IT ที่มีอยู่ และสำรวจการใช้งาน public clouds ทีมเริ่มต้นประกอบด้วย applications architect, systems architect, นักพัฒนาสองคน, system automation developer, operations lead และเจ้าหน้าที่ปฏิบัติการ offshore อีกสองคน ด้วยการใช้แนวทาง DevOps พวกเขาสามารถส่งมอบ Hosted LabVIEW ออกสู่ตลาดได้ในเวลาครึ่งหนึ่งของการแนะนำผลิตภัณฑ์ปกติของพวกเขา 11
อีกด้านหนึ่งของสเปกตรัมคือโครงการ DevOps แบบ brownfield ซึ่งเป็นผลิตภัณฑ์หรือ services ที่มีอยู่แล้วและให้บริการลูกค้าอยู่ ซึ่งอาจดำเนินการมาหลายปีหรือหลายทศวรรษ โครงการ brownfield มักมาพร้อมกับ technical debt ในปริมาณมาก เช่น ไม่มี test automation หรือรันบน platform ที่ไม่ได้รับการสนับสนุนอีกต่อไป ในตัวอย่างของ Nordstrom ที่นำเสนอก่อนหน้านี้ในบทนี้ ทั้งระบบร้านอาหารภายในร้านค้าและระบบ e-commerce ต่างก็เป็นโครงการ brownfield
แม้หลายคนจะเชื่อว่า DevOps เหมาะกับโครงการ greenfield เป็นหลัก แต่ DevOps ก็ถูกนำมาใช้ในการปรับเปลี่ยนโครงการ brownfield ทุกประเภทได้สำเร็จ ในความเป็นจริง กว่า 60% ของเรื่องราวการปรับเปลี่ยนที่ถูกแชร์ในงาน DevOps Enterprise Summit ในปี 2014 เป็นโครงการ brownfield 12 ในกรณีเหล่านี้ มีช่องว่างด้านประสิทธิภาพขนาดใหญ่ระหว่างสิ่งที่ลูกค้าต้องการกับสิ่งที่องค์กรกำลังส่งมอบอยู่ และการปรับเปลี่ยน DevOps ได้สร้างประโยชน์ทางธุรกิจอย่างมหาศาล
อันที่จริง งานวิจัยจาก State of DevOps Report พบว่าอายุของแอปพลิเคชันหรือแม้แต่เทคโนโลยีที่ใช้ไม่ใช่ตัวทำนายประสิทธิภาพที่สำคัญ สิ่งที่ทำนายประสิทธิภาพคือว่าแอปพลิเคชันถูกออกแบบสถาปัตยกรรม (หรือสามารถออกแบบสถาปัตยกรรมใหม่) สำหรับ testability และ deployability หรือไม่ 13
ทีมที่ดูแลโครงการ brownfield อาจเปิดรับการทดลองใช้ DevOps มาก โดยเฉพาะอย่างยิ่งเมื่อมีความเชื่ออย่างกว้างขวางว่าวิธีการแบบดั้งเดิมนั้นไม่เพียงพอที่จะบรรลุเป้าหมาย — และโดยเฉพาะอย่างยิ่งถ้ามีความรู้สึกเร่งด่วนอย่างมากเกี่ยวกับความจำเป็นในการปรับปรุง ‡
เมื่อปรับเปลี่ยนโครงการ brownfield เราอาจเผชิญกับอุปสรรคและปัญหาที่สำคัญ โดยเฉพาะอย่างยิ่งเมื่อไม่มีการทดสอบอัตโนมัติ หรือเมื่อมีสถาปัตยกรรมที่มีการ coupling สูงซึ่งป้องกันไม่ให้ทีมขนาดเล็กพัฒนา ทดสอบ และ deploy โค้ดได้อย่างอิสระ วิธีการเอาชนะปัญหาเหล่านี้ได้อธิบายไว้ทั่วทั้งเล่มนี้
Examples of successful brownfield transformations include: (ตัวอย่างการปรับเปลี่ยน brownfield ที่ประสบความสำเร็จ ได้แก่:)
• American Airlines (2020): แนวทาง DevOps สามารถนำไปใช้กับ legacy COTS (commercial off-the-shelf product) ได้เช่นกัน ที่ American Airlines ผลิตภัณฑ์ loyalty ของพวกเขาทำงานบน Seibel AA ได้ย้ายมันไปยังโมเดล hybrid cloud แล้วลงทุนใน CI/CD pipelines เพื่อ automate การส่งมอบและ infrastructure แบบ end to end สำหรับผลิตภัณฑ์ loyalty ของพวกเขา นับตั้งแต่การย้ายครั้งนั้น ทีมต่างๆ deploy บ่อยขึ้น โดยมีการ deploy อัตโนมัติมากกว่าห้าสิบครั้งในเวลาเพียงไม่กี่เดือน รวมถึง loyalty web service response times เร็วขึ้นเป็นสองเท่า และ cost optimization ใน cloud ได้ 32% ยิ่งไปกว่านั้น การย้ายครั้งนี้ทำให้การสนทนาระหว่างฝ่ายธุรกิจและ IT เปลี่ยนไป แทนที่ธุรกิจจะต้องรอ IT ในการเปลี่ยนแปลง ทีมต่างๆ สามารถ deploy ได้บ่อยและราบรื่นกว่าที่ธุรกิจจะตรวจสอบและยอมรับได้ ปัจจุบัน product teams ร่วมมือกับฝ่ายธุรกิจและ IT teams กำลังมองหาวิธีoptimize กระบวนการ end-to-end เพื่อให้ได้ deployment frequency ที่สูงขึ้น 14
• CSG (2013): ในปี 2013 CSG International มีรายได้ 747 ล้านดอลลาร์และพนักงานมากกว่าสามพันห้าร้อยคน สนับสนุนตัวแทนฝ่ายบริการลูกค้ากว่าเก้าหมื่นคนในการให้บริการ billing และการดูแลลูกค้าแก่ลูกค้าด้านวิดีโอ เสียง และข้อมูลมากกว่าห้าสิบล้านราย ดำเนินการมากกว่าหกพันล้านรายการ และพิมพ์และส่งใบแจ้งหนี้กระดาษมากกว่าเจ็ดสิบล้านฉบับทุกเดือน ขอบเขตเริ่มต้นของการปรับปรุงคือการพิมพ์ใบแจ้งหนี้ ซึ่งเป็นหนึ่งในธุรกิจหลักของพวกเขา และเกี่ยวข้องกับแอปพลิเคชัน COBOL บน mainframe และ platform เทคโนโลยีโดยรอบอีกยี่สิบแพลตฟอร์ม ในการปรับเปลี่ยนของพวกเขา พวกเขาเริ่มทำการ deploy รายวันไปยังสภาพแวดล้อมที่เหมือน production และเพิ่มความถี่ของการปล่อย release ให้ลูกค้าจากปีละสองครั้งเป็นปีละสี่ครั้ง ผลลัพธ์คือพวกเขาเพิ่มความน่าเชื่อถือของแอปพลิเคชันได้อย่างมีนัยสำคัญ และลด lead time การ deploy โค้ดจากสองสัปดาห์เหลือน้อยกว่าหนึ่งวัน 15
• Etsy (2009): ในปี 2009 Etsy มีพนักงานสามสิบห้าคนและสร้างรายได้ 87 ล้านดอลลาร์ แต่หลังจากที่พวกเขา "แทบจะไม่รอดจากเทศกาลช้อปปิ้งช่วงวันหยุด" พวกเขาก็เริ่มปรับเปลี่ยนแทบทุกแง่มุมของวิธีการทำงานขององค์กร ในที่สุดก็เปลี่ยนบริษัทให้เป็นหนึ่งในองค์กร DevOps ที่ได้รับการชื่นชมมากที่สุด และสร้างเวทีสำหรับ IPO ที่ประสบความสำเร็จในปี 2015 16
• HP LaserJet (2007): ด้วยการ implement automated testing และ continuous integration ทำให้ HP สร้าง feedback ที่เร็วขึ้นและช่วยให้นักพัฒนาสามารถยืนยันได้อย่างรวดเร็วว่า command codes ของพวกเขาทำงานได้จริง คุณสามารถอ่าน case study ฉบับเต็มได้ใน Chapter 11 .
CASE STUDY: NEW TO SECOND EDITION (กรณีศึกษา: เพิ่มเติมในฉบับพิมพ์ครั้งที่สอง)
Kessel Run: The Brownfield Transformation of a Mid-Air Refueling System (2020) (Kessel Run: การปรับเปลี่ยน Brownfield ของระบบเติมเชื้อเพลิงกลางอากาศ)
ในเดือนตุลาคม 2015 กองทัพอากาศสหรัฐฯ ได้โจมตีโรงพยาบาลขององค์การแพทย์ไร้พรมแดนในอัฟกานิสถาน โดยเข้าใจผิดว่าเป็นฐานที่มั่นของศัตรู ทหารคอมมานโดอัฟกานิสถานกำลังถูกโจมตี และสหรัฐฯ จำเป็นต้องตอบสนองอย่างรวดเร็ว การวิเคราะห์ที่ไม่เป็นความลับในภายหลังพบว่ามีความล้มเหลวหลายประการที่นำไปสู่ผลลัพธ์ที่เลวร้ายนี้: ไม่มีเวลาในการbrief ลูกเรืออย่างเต็มที่ และเครื่องบินไม่มีข้อมูลล่าสุดเพื่อระบุโรงพยาบาล ดังที่ Adam Furtado หัวหน้า Platform ของ Kessel Run กล่าวว่า "โดยพื้นฐานแล้ว ระบบนิเวศ IT ที่ล้มเหลวทำให้ AC130 gunship โจมตีอาคารผิดหลัง" 17
Furtado อธิบายต่อในงาน DevOps Enterprise Summit-Virtual Las Vegas 2020 ว่า "สิ่งที่เกิดขึ้นที่นี่ไม่ใช่เหตุการณ์ black swan ประเภทไหน มันเป็นสิ่งที่คาดการณ์ได้ และมันจะเกิดขึ้นอีก" 18 พวกเขาต้องการทางออก
ตั้งชื่อตามเส้นทางลักลอบขนของที่มีชื่อเสียงของ Han Solo ซึ่งเป็นการแสดงความเคารพต่อความต้องการของพวกเขาในการ "ลักลอบ" วิธีการทำงานใหม่ๆ เหล่านี้เข้าไปในกระทรวงกลาโหมสหรัฐฯ (DOD) Kessel Run คือความพยายามอย่างต่อเนื่องภายในกองทัพอากาศสหรัฐฯ เพื่อแก้ปัญหาความท้าทายทางธุรกิจที่ยากลำบากซึ่งระบบ IT แบบดั้งเดิมของกองทัพไม่สามารถแก้ไขได้อย่างมีประสิทธิภาพ กลุ่มซึ่งประกอบด้วยพันธมิตรเล็กๆ ได้ทดสอบแนวปฏิบัติ กระบวนการ และหลักการซอฟต์แวร์สมัยใหม่ จุดเน้นของพวกเขาคือภารกิจและการไม่ยอมรับสภาพที่เป็นอยู่
ในช่วงเริ่มต้นราวปี 2010 การเดินเข้าไปใน DOD เพื่อทำงานก็เหมือนกับการเดินเข้าไปในไทม์แมชชีน ซึ่งเป็นสภาพแวดล้อมแบบแอนะล็อกโดยสมบูรณ์ในยุคประมาณปี 1974 ที่เครื่องมือการทำงานร่วมกันหลายอย่าง เช่น chats และ Google Docs ไม่สามารถใช้งานได้ ดังที่ Adam Furtado กล่าวว่า "คุณไม่ควรต้องย้อนเวลากลับไปเพื่อไปทำงาน" 19
Eric Schmidt ประธานกรรมการบริหารของ Google ถึงกับให้การต่อรัฐสภาสหรัฐฯ ในเดือนกันยายน 2020 ว่า "DOD ละเมิดกฎทุกข้อของการพัฒนาผลิตภัณฑ์สมัยใหม่" 20
ปัญหาเหล่านี้ไม่ได้เกิดขึ้นเฉพาะกับ DOD เท่านั้น ตามรายงานของ US Digital Service พบว่า 94% ของโครงการ IT ของรัฐบาลกลางทั้งหมดทั่วทั้งหน่วยงานราชการล่าช้ากว่ากำหนดหรือเกินงบประมาณ และ 40% ไม่เคยถูกส่งมอบเลย 21
พันธมิตรของ Kessel Run กำลังดูบริษัทอย่าง Adidas และ Walmart ที่กลายเป็นบริษัทซอฟต์แวร์ พวกเขาต้องการเปลี่ยนกองทัพอากาศสหรัฐฯ ให้เป็นบริษัทซอฟต์แวร์ที่สามารถชนะสงครามได้ ดังนั้นพวกเขาจึงหันไปสนใจผลลัพธ์ทางธุรกิจที่สำคัญที่อยู่ตรงหน้า: การปรับปรุง Air Operation Center ของกองทัพอากาศให้ทันสมัย
มี Air Operation Centers (AOCs) ทางกายภาพหลายแห่งทั่วโลกที่กองทัพอากาศสหรัฐฯ ใช้ในการวางกลยุทธ์ วางแผน และปฏิบัติการทางอากาศ เนื่องจาก infrastructure ที่ล้าสมัย งานทั้งหมดนี้จึงทำโดยคนเฉพาะ ในอาคารเฉพาะ ในสถานที่เฉพาะ เพื่อเข้าถึงข้อมูลเฉพาะบนฮาร์ดแวร์เฉพาะ ซึ่งเป็นแนวทางแบบ brick-and-mortar ที่มีมานานหลายทศวรรษ การอัปเดตเพียงอย่างเดียวที่พวกเขาสามารถ implement ได้คือการอัปเดต Microsoft Office
"คุณอาจคิดว่าฉันกำลังโกหก แต่การค้นหาล่าสุดพบไฟล์ Excel และ PowerPoint 2.8 ล้านไฟล์บนเซิร์ฟเวอร์ตัวหนึ่งในสถานที่ตั้งแห่งหนึ่ง" Adam Furtado กล่าว 22
Gall's Law กล่าวว่าถ้าคุณต้องการให้ระบบที่ซับซ้อนทำงานได้ ให้สร้างระบบที่ง่ายกว่าก่อน แล้วค่อยปรับปรุงตามเวลา พันธมิตร Kessel Run ทำเช่นนั้นโดยการใช้ Strangler Fig Pattern หรือที่รู้จักกันในชื่อ Encasement Strategy เพื่อ implement ระบบและกระบวนการซอฟต์แวร์ที่ทันสมัยอย่างค่อยเป็นค่อยไปและทำซ้ำๆ ในสถานที่จริง 22 แห่ง แต่ละแห่งมีซอฟต์แวร์และฮาร์ดแวร์ของตัวเอง ในขณะที่ยังรักษาระบบโดยรวมให้ทำงานได้
พวกเขาเริ่มต้นด้วยกระบวนการเฉพาะ: การเติมเชื้อเพลิงกลางอากาศ กระบวนการนี้ต้องการการประสานงานอย่างมหาศาลเพื่อให้แน่ใจว่า tanker เติมเชื้อเพลิงอยู่ในตำแหน่งที่ถูกต้อง ในเวลาที่ถูกต้อง ที่ระดับความสูงที่ถูกต้อง พร้อมฮาร์ดแวร์ที่ถูกต้อง เพื่อเติมเชื้อเพลิงให้กับอากาศยานที่ถูกต้อง กระบวนการเกี่ยวข้องกับนักบินหลายคนในการวางแผนทุกวันโดยใช้ color pucks, Excel macro และการป้อนข้อมูลจำนวนมาก พวกเขามีประสิทธิภาพโดยรวม แต่ก็เท่าที่สมองของพวกเขาจะเอื้ออำนวย และพวกเขาไม่สามารถตอบสนองต่อการเปลี่ยนแปลงได้อย่างรวดเร็ว
Kessel Run นำทีมเข้ามาเพื่อแปลงกระบวนการของพวกเขาให้เป็นดิจิทัลโดยใช้หลักการ DevOps, extreme programming และโมเดลทีมที่สมดุล พวกเขาได้ผลิตภัณฑ์ minimally viable เริ่มต้นออกไปให้ผู้ใช้ภายในเวลาเพียงไม่กี่สัปดาห์ โปรแกรมแรกเริ่มนี้สร้างประสิทธิภาพมากพอที่จะทำให้อากาศยานหนึ่งลำและลูกเรือไม่ต้องบินทุกวัน ซึ่งเป็นการประหยัดน้ำมันได้ 214,000 ดอลลาร์ต่อวัน 23
พวกเขายังคง iterate ต่อไป หลังจากสามสิบ iteration พวกเขาสามารถเพิ่มการประหยัดเป็นสองเท่า โดยทำให้อากาศยานสองลำและลูกเรือไม่ต้องบินหนึ่งวันต่อวัน แนวทางใหม่นี้ประหยัดน้ำมันได้ 13 ล้านดอลลาร์ต่อเดือน และลดจำนวนเจ้าหน้าที่วางแผนลงครึ่งหนึ่ง 24
แม้ว่า case study นี้จะแสดงให้เห็นถึงการปรับเปลี่ยน DevOps ที่ยอดเยี่ยมโดยทั่วไป แต่ก็ยังแสดงให้เห็นถึงการปรับเปลี่ยนแนวปฏิบัติแบบ brownfield ได้อย่างยอดเยี่ยมอีกด้วย Kessel Run ลดความซับซ้อนและปรับปรุงความน่าเชื่อถือและความเสถียรของระบบเติมเชื้อเพลิงกลางอากาศได้สำเร็จ ช่วยให้กองทัพอากาศสหรัฐฯ เคลื่อนไหวและเปลี่ยนแปลงได้เร็วขึ้นและปลอดภัยขึ้น
Consider Both Systems of Record and Systems of Engagement (พิจารณาทั้ง Systems of Record และ Systems of Engagement)
Gartner บริษัทวิจัยและให้คำปรึกษาระดับโลกทำให้แนวคิดเรื่อง bimodal IT เป็นที่นิยม ซึ่งหมายถึงสเปกตรัมกว้างๆ ของ services ที่องค์กรทั่วไปต้องให้การสนับสนุน 25 ภายใน bimodal IT มี systems of recor d ซึ่งเป็นระบบคล้าย ERP ที่ขับเคลื่อนธุรกิจของเรา (เช่น MRP, HR, ระบบรายงานทางการเงิน) ซึ่งความถูกต้องของรายการและข้อมูลเป็นสิ่งสำคัญยิ่ง; และ systems of engagement ซึ่งเป็นระบบที่面向ลูกค้าหรือพนักงาน เช่น ระบบ e-commerce และแอปพลิเคชันเพิ่ม productivity
Systems of record โดยทั่วไปมีจังหวะการเปลี่ยนแปลงที่ช้ากว่า และมักมีข้อกำหนดด้านกฎระเบียบและการปฏิบัติตามข้อกำหนด (เช่น SOX) Gartner เรียกระบบประเภทนี้ว่า "Type 1" ซึ่งองค์กรจะมุ่งเน้นที่ "doing it right" (ทำให้ถูกต้อง) 26
Systems of engagement โดยทั่วไปมีจังหวะการเปลี่ยนแปลงที่เร็วกว่ามากเพื่อรองรับ feedback loops ที่รวดเร็ว ซึ่งช่วยให้พวกเขาสามารถทดลองเพื่อค้นหาวิธีที่ดีที่สุดในการตอบสนองความต้องการของลูกค้า Gartner เรียกระบบประเภทนี้ว่า "Type 2" ซึ่งองค์กรจะมุ่งเน้นที่ "doing it fast" (ทำให้เร็ว) 27
อาจสะดวกที่จะแบ่งระบบของเราออกเป็นหมวดหมู่เหล่านี้ อย่างไรก็ตาม เรารู้ว่าความขัดแย้งหลักที่เรื้อรังระหว่าง "doing it right" และ "doing it fast" สามารถถูกทำลายได้ด้วย DevOps ข้อมูลจากหกปีของ State of DevOps Report แสดงให้เห็นว่าองค์กรที่มีประสิทธิภาพสูงสามารถส่งมอบทั้ง throughput และ reliability ในระดับที่สูงขึ้นพร้อมกันได้ 28
ยิ่งไปกว่านั้น เนื่องจากระบบของเราพึ่งพาซึ่งกันและกัน ความสามารถของเราในการเปลี่ยนแปลงระบบใดๆ ก็ตามจึงถูกจำกัดโดยระบบที่เปลี่ยนแปลงได้ยากที่สุดอย่างปลอดภัย ซึ่งเกือบจะเป็นระบบของ record เสมอ
Scott Prugh รองประธานฝ่าย Product Development ที่ CSG กล่าวว่า "เราได้นำปรัชญาที่ปฏิเสธ bi-modal IT มาใช้ เพราะลูกค้าทุกคนของเราสมควรได้รับทั้งความเร็วและคุณภาพ ซึ่งหมายความว่าเราต้องมีความเป็นเลิศทางเทคนิค ไม่ว่าทีมจะสนับสนุนแอปพลิเคชัน mainframe อายุสามสิบปี แอปพลิเคชัน Java หรือแอปพลิเคชันมือถือก็ตาม" 29
ดังนั้น เมื่อเราปรับปรุงระบบ brownfield เราไม่เพียงแต่มุ่งมั่นที่จะลดความซับซ้อนและปรับปรุงความน่าเชื่อถือและความเสถียรของระบบเหล่านั้น แต่ยังทำให้เปลี่ยนแปลงได้เร็วขึ้น ปลอดภัยขึ้น และง่ายขึ้นอีกด้วย แม้ว่าจะเพิ่มฟังก์ชันการทำงานใหม่เฉพาะในระบบ greenfield systems of engagement ก็มักจะก่อให้เกิดปัญหาด้านความน่าเชื่อถือในระบบ brownfield systems of record ที่พวกเขาพึ่งพาอยู่ การทำให้ระบบ downstream เหล่านี้ปลอดภัยต่อการเปลี่ยนแปลงมากขึ้น จะช่วยให้ทั้งองค์กรบรรลุเป้าหมายได้เร็วและปลอดภัยยิ่งขึ้น
Start With the Most Sympathetic and Innovative Groups (เริ่มต้นกับกลุ่มที่เห็นด้วยและมีนวัตกรรมมากที่สุด)
ภายในทุกองค์กร จะมีทีมและบุคคลที่มีทัศนคติที่หลากหลายต่อการนำแนวคิดใหม่ๆ มาใช้ Geoffrey A. Moore ได้นำเสนอสเปกตรัมนี้ในรูปแบบของ technology adoption life cycle ในหนังสือ Crossing the Chasm โดยที่ chasm แสดงถึงความยากลำบากแบบคลาสสิกในการเข้าถึงกลุ่มที่อยู่เหนือ innovators และ early adopters (ดู Figure 5.1 ) 30
Figure 5.1: The Technology Adoption Curve (เส้นโค้งการยอมรับเทคโนโลยี)
Source: Moore and McKenna, Crossing the Chasm , 15.
กล่าวอีกนัยหนึ่ง แนวคิดใหม่ๆ มักถูกนำไปใช้อย่างรวดเร็วโดย innovators และ early adopters ในขณะที่คนอื่นๆ ที่มีทัศนคติอนุรักษ์นิยมกว่าจะต่อต้าน (พวก early majority , late majority และ laggards) เป้าหมายของเราคือการหาทีมเหล่านั้นที่เชื่อมั่นในความต้องการหลักการและแนวปฏิบัติของ DevOps อยู่แล้ว และมีความปรารถนาและความสามารถที่แสดงให้เห็นในการสร้างนวัตกรรมและปรับปรุงกระบวนการของตนเอง ตาม ideal แล้ว กลุ่มเหล่านี้จะเป็นผู้สนับสนุนที่กระตือรือร้นในการเดินทางสู่ DevOps
โดยเฉพาะอย่างยิ่งในช่วงแรก เราจะไม่ใช้เวลามากในการพยายามเปลี่ยนกลุ่มอนุรักษ์นิยม แต่เราจะมุ่งเน้นพลังงานของเราไปที่การสร้างความสำเร็จกับกลุ่มที่กลัวความเสี่ยงน้อยกว่า และสร้างฐานของเราจากที่นั่น (กระบวนการที่ถูกอภิปรายเพิ่มเติมในหัวข้อถัดไป) แม้ว่าเราจะมีการสนับสนุนจากผู้บริหารระดับสูงสุด เราก็จะหลีกเลี่ยง big-bang approach (คือการเริ่มต้นทุกที่พร้อมกันทั้งหมด) โดยเลือกที่จะมุ่งเน้นความพยายามของเราในบางพื้นที่ขององค์กร ทำให้มั่นใจว่าโครงการเหล่านั้นประสบความสำเร็จ และขยายออกจากจุดนั้น §
Expanding DevOps Across Our Organization (การขยาย DevOps ไปทั่วทั้งองค์กร)
ไม่ว่าเราจะขอบเขตความพยายามเริ่มต้นของเราอย่างไร เราต้องแสดงความสำเร็จในช่วงต้นและเผยแพร่ความสำเร็จของเรา เราทำสิ่งนี้โดยการแบ่งเป้าหมายการปรับปรุงที่ใหญ่กว่าของเราออกเป็นขั้นตอนเล็กๆ ที่เพิ่มขึ้นทีละน้อย สิ่งนี้ไม่เพียงสร้างการปรับปรุงของเราได้เร็วขึ้น แต่ยังช่วยให้เราค้นพบเมื่อเราเลือก value stream ผิด — โดยการตรวจจับข้อผิดพลาดของเราได้เร็ว เราสามารถถอยกลับและลองอีกครั้งอย่างรวดเร็ว โดยตัดสินใจที่แตกต่างออกไปพร้อมกับการเรียนรู้ใหม่ๆ ของเรา
เมื่อเราสร้างความสำเร็จ เราก็ได้รับสิทธิ์ในการขยายขอบเขตของโครงการ DevOps ของเรา เราต้องการปฏิบัติตามลำดับที่ปลอดภัยซึ่งค่อยๆ เพิ่มระดับความน่าเชื่อถือ อิทธิพล และการสนับสนุนของเรา รายการต่อไปนี้ ซึ่งปรับจากหลักสูตรที่สอนโดย Dr. Roberto Fernandez ศาสตราจารย์ William F. Pounds ด้านการจัดการที่ MIT อธิบายถึงช่วงที่ ideal ที่ผู้เปลี่ยนแปลงองค์กรใช้ในการสร้างและขยายพันธมิตรและฐานการสนับสนุน: 31
• Find innovators and early adopters (ค้นหา innovators และ early adopters): ในช่วงเริ่มต้น เรามุ่งเน้นความพยายามไปที่ทีมที่ต้องการช่วยเหลือจริงๆ — คนเหล่านี้คือ kindred spirits (ผู้มีจิตวิญญาณร่วมกัน) และ fellow travelers (ผู้ร่วมเดินทาง) ที่เป็นคนแรกที่อาสาเริ่มต้นการเดินทาง DevOps ในอุดมคติ คนเหล่านี้คือผู้ที่ได้รับความเคารพนับถือและมีอิทธิพลสูงต่อส่วนอื่นๆ ขององค์กร ซึ่งจะทำให้โครงการของเรามีความน่าเชื่อถือมากขึ้น
• Build critical mass and silent majority (สร้างมวลวิกฤตและเสียงส่วนใหญ่ที่เงียบ): ในระยะถัดไป เราพยายามขยายแนวปฏิบัติ DevOps ไปยังทีมและ value streams เพิ่มขึ้น โดยมีเป้าหมายเพื่อสร้างฐานการสนับสนุนที่มั่นคง การทำงานร่วมกับทีมที่เปิดรับแนวคิดของเรา แม้ว่าพวกเขาจะไม่ใช่กลุ่มที่มี visibility หรืออิทธิพลมากที่สุด เราก็ขยายพันธมิตรของเราที่สร้างความสำเร็จมากขึ้น ก่อให้เกิด "bandwagon effect" ที่เพิ่มอิทธิพลของเราต่อไป เราจะหลีกเลี่ยงการต่อสู้ทางการเมืองที่อันตรายซึ่งอาจเป็นอันตรายต่อโครงการของเราโดยเฉพาะ
• Identify the holdouts (ระบุผู้ที่ยังไม่ยอมรับ): "holdouts" คือผู้คัดค้านที่มีชื่อเสียงและมีอิทธิพลสูงซึ่งมีแนวโน้มที่จะต่อต้าน (และอาจถึงขั้นก่อวินาศกรรม) ความพยายามของเรา โดยทั่วไปเราจะจัดการกับกลุ่มนี้หลังจากที่เราบรรลุ silent majority และสร้างความสำเร็จเพียงพอที่จะปกป้องโครงการของเราได้สำเร็จ
การขยาย DevOps ไปทั่วทั้งองค์กรไม่ใช่เรื่องเล็กน้อย มันสามารถสร้างความเสี่ยงต่อบุคคล แผนก และองค์กรโดยรวมได้ แต่ดังที่ Ron van Kemenade CIO ของ ING ผู้ช่วยเปลี่ยนแปลงองค์กรให้เป็นหนึ่งในองค์กรเทคโนโลยีที่ได้รับการชื่นชมมากที่สุดกล่าวว่า "การนำการเปลี่ยนแปลงต้องใช้ความกล้าหาญ โดยเฉพาะในสภาพแวดล้อมขององค์กรที่ผู้คนกลัวและต่อต้านคุณ แต่ถ้าคุณเริ่มต้นเล็กๆ คุณก็ไม่มีอะไรต้องกลัวจริงๆ ผู้นำทุกคนต้องกล้าพอที่จะจัดสรรทีมเพื่อรับความเสี่ยงที่คำนวณไว้แล้ว" 32
CASE STUDY: NEW TO SECOND EDITION (กรณีศึกษา: เพิ่มเติมในฉบับพิมพ์ครั้งที่สอง)
Scaling DevOps across the Business: American Airlines'
DevOps Journey ( Part 2 ) (2020) (การขยาย DevOps ทั่วทั้งธุรกิจ: การเดินทาง DevOps ของ American Airlines (ตอนที่ 2))
ดังที่เราได้เรียนรู้ใน Part 1 ของการปรับเปลี่ยน DevOps ของ American Airlines การเดินทางของพวกเขากินเวลาหลายปี เมื่อถึงปีที่สาม พวกเขาตระหนักว่า DevOps เป็นการเปลี่ยนแปลงที่ใหญ่กว่าแค่แนวทางการทำงานใน IT — มันคือการเปลี่ยนแปลงทางธุรกิจ
ความท้าทายถัดไปของพวกเขาคือการขยายวิธีการทำงานใหม่ๆ เหล่านี้ไปทั่วทั้งธุรกิจเพื่อเร่งและดำเนินการเปลี่ยนแปลงและการเรียนรู้ของพวกเขาต่อไป พวกเขาได้นำ Ross Clanton เข้ามาเป็น Chief Architect และ Managing Director เพื่อช่วยชี้แนะพวกเขาไปสู่ระดับถัดไป
เพื่อขับเคลื่อนการสนทนาทั่วทั้งองค์กร American Airlines มุ่งเน้นไปที่สองสิ่ง: 33 the why (การสร้างความได้เปรียบในการแข่งขัน) และ the how (ทีมธุรกิจและ IT ทำงานร่วมกันเพื่อเพิ่มมูลค่าทางธุรกิจให้สูงสุด)
เพื่อขยายวิสัยทัศน์ที่ตั้งไว้ใน IT คือ "ส่งมอบคุณค่าได้เร็วขึ้น" พวกเขาจึงวางแผนการเปลี่ยนแปลงโดยอิงจากโครงสร้างเสาหลักสี่ประการดังต่อไปนี้: 34
• delivery excellence (ความเป็นเลิศด้านการส่งมอบ): วิธีการทำงานของเรา (แนวปฏิบัติ, product mindset)
• operating excellence (ความเป็นเลิศด้านการดำเนินงาน): โครงสร้างของเรา (product taxonomy, funding model, operating model, การจัดลำดับความสำคัญ)
• people excellence (ความเป็นเลิศด้านบุคลากร): การพัฒนาพรสวรรค์และวัฒนธรรม (รวมถึงการปรับเปลี่ยนพฤติกรรมผู้นำ)
• technology excellence (ความเป็นเลิศด้านเทคโนโลยี): การปรับปรุงให้ทันสมัย (infrastructure และพื้นฐานเทคโนโลยี, automation, การย้ายไปยัง cloud ฯลฯ)
Figure 5.2: American Airlines' Delivery Transformation (การเปลี่ยนแปลงด้านการส่งมอบของ American Airlines)
Source: Maya Leibman and Ross Clanton, "DevOps: Approaching Cruising Altitude," presentation at DevOps Enterprise Summit-Virtual Las Vegas 2020, videolibrary.doesvirtual.com/?video=467488959 .
เมื่อพวกเขามีกลยุทธ์การขยายการเปลี่ยนแปลงใน place แล้ว พวกเขาต้องมุ่งเน้นที่การขยายวัฒนธรรมทั่วทั้งธุรกิจเพื่อขับเคลื่อนการเปลี่ยนแปลงต่อไป
ดังที่ Clanton กล่าวในงานนำเสนอของเขาที่ DevOps Enterprise Summit ในปี 2020 โดยอ้างถึง Peter Drucker ว่า "วัฒนธรรมกินกลยุทธ์เป็นอาหารเช้า" 35
เพื่อขยายวัฒนธรรม พวกเขามุ่งเน้นไปที่คุณลักษณะสำคัญสามประการ: 36
-
Passion (ความหลงใหล): ทีมที่มุ่งเน้นการทำให้ลูกค้าพึงพอใจ การเป็นสิ่งที่ดีที่สุดในการพัฒนาตนเอง การยอมรับความล้มเหลวและแข็งแกร่งขึ้นเพราะมัน
-
Selflessness (ความเสียสละ): การทำงานร่วมกันและแบ่งปันความรู้และโค้ดทั่วทั้งองค์กร, innersourcing, การเปิดพื้นที่ให้เสียงของผู้อื่น ' และช่วยให้ผู้อื่นประสบความสำเร็จ
-
Accountability (ความรับผิดชอบ): การรับผิดชอบต่อผลลัพธ์แม้ว่ามันจะยาก วิธีการที่คุณทำสิ่งต่างๆ มีความสำคัญเท่ากับสิ่งที่คุณทำ
ด้วยการมุ่งเน้นที่เสาหลักทางวัฒนธรรมทั้งสามนี้ ทีมงานที่ American Airlines ตอนนี้ "ได้รับอำนาจและออกไปนอกเหนือวิถีทางเพื่อเพิ่มอำนาจให้ผู้อื่น" ตามที่ Clanton กล่าว 37 เมื่อการแพร่ระบาดทั่วโลกเกิดขึ้นในปี 2020 American Airlines มุ่งเน้นที่ค่านิยมต่อไปนี้เพื่อให้แน่ใจว่าทีมของพวกเขายังคงประสบความสำเร็จและได้ผลลัพธ์ท่ามกลางการเปลี่ยนแปลงระดับโลก: 38
• action and doing over analysis (การลงมือทำและปฏิบัติมากกว่าการวิเคราะห์)
• collaboration over silos (การทำงานร่วมกันมากกว่าการแยกส่วน)
• clarity of mission over trying to do everything (ความชัดเจนของภารกิจมากกว่าการพยายามทำทุกอย่าง)
• empowerment over personal stamp on every effort (การให้อำนาจมากกว่าการประทับตราส่วนตัวในทุกความพยายาม — ตั้งเป้าหมายและให้อำนาจทีมไปถึง那儿)
• getting something out (MVP) versus getting something perfect (การส่งมอบอะไรบางอย่าง (MVP) มากกว่าการทำให้สมบูรณ์แบบ)
• "We can do this" versus hierarchy (การทำงานร่วมกันข้ามขอบเขตองค์กร)
• finishing versus starting (การเสร็จสิ้นมากกว่าการเริ่มต้น — การจำกัด WIP และมุ่งเน้นที่ลำดับความสำคัญสูงสุด)
แทนที่จะโยน requirements ข้ามกำแพง American Airlines ตอนนี้มีทีมผู้มีส่วนได้ส่วนเสียจากฝ่ายธุรกิจ, IT, Design ฯลฯ พวกเขาปรับเปลี่ยนโมเดลการวางแผนเพื่อให้ผู้นำกำหนดผลลัพธ์ที่ชัดเจน และทีมสามารถตัดสินใจได้ว่าพวกเขาจะส่งมอบผลลัพธ์เหล่านั้นอย่างไร ทีมส่งมอบโดยมุ่งเน้นที่งานเล็กๆ ที่เพิ่มคุณค่าแบบทีละน้อย ด้วยการทำให้งานมีขนาดเล็ก ทีมจึงสามารถทำเสร็จได้เร็ว (ขับเคลื่อนคุณค่าได้เร็วยิ่งขึ้น) และมุ่งเน้นที่การทำให้เสร็จ ไม่ใช่การเริ่มต้น
เพื่อให้การเปลี่ยนแปลงทั้งหมดนี้เกิดขึ้นได้ ผู้นำจำเป็นต้องเปลี่ยนแปลงวิธีการทำงานของพวกเขาเช่นกัน ผู้นำได้ปรับเปลี่ยนมาให้บริการทีม ขจัดอุปสรรคและข้อจำกัดที่ขัดขวางไม่ให้ทีมส่งมอบคุณค่า แทนที่จะเป็นการประชุมสถานะ ผู้นำเข้าร่วมการประชุม playback (demo) เพื่อดูว่าทีมกำลังทำอะไรอยู่และให้คำแนะนำในขณะนั้น
American Airlines ยังตระหนักว่าเพื่อช่วยเปลี่ยน mindset ของผู้นำ และทำให้ทุกคนมีความสอดคล้องในการคิด พูด และดำเนินการจากมุมมองของ Agile/DevOps พวกเขาจำเป็นต้องจัดหาคำศัพท์ใหม่ Table 5.1 แสดงวิธีการบางอย่างที่พวกเขาช่วยปรับเปลี่ยนการสนทนา
As Doug Parker, CEO of American Airlines related, (Doug Parker ซีอีโอของ American Airlines กล่าวว่า)
. . . [การเปลี่ยนแปลง] ทำให้เรามีประสิทธิภาพมากขึ้น เราได้โครงการต่างๆ เสร็จเร็วขึ้น โครงการที่ส่งมอบได้รับการออกแบบมากขึ้นตามสิ่งที่ผู้ใช้ต้องการ . . . มันสร้างความแตกต่างอย่างมากต่อวิธีการบริหารจัดการโครงการที่ American Airlines
สิ่งที่ฉันภูมิใจที่สุดคือแชมป์ของการเปลี่ยนแปลงการส่งมอบไม่ใช่ IT อีกต่อไป แต่เป็นผู้นำทางธุรกิจที่ embrace มัน พวกเขาเห็นว่าพวกเขาได้รับงานเสร็จเร็วขึ้นมากแค่ไหน และพวกเขากำลังเผยแพร่ข่าวนี้ไปทุกที่ และนั่นกำลังสร้างความแตกต่างอย่างมาก 39
Table 5.1: American Airlines' New Vocabulary (คำศัพท์ใหม่ของ American Airlines)
Before (ก่อน) | After (หลัง) |
I want to create a pop-up to incentivize people to download the mobile app. (ฉันต้องการสร้าง pop-up เพื่อจูงใจให้คนดาวน์โหลดแอปมือถือ) | Fragile applications are prone to failure. (แอปพลิเคชันที่เปราะบางมีแนวโน้มที่จะล้มเหลว) |
What did our competitors do? (คู่แข่งของเราทำอะไร?) | What do our customers value? (ลูกค้าของเราให้คุณค่ากับอะไร?) |
When will this project be done? (โครงการนี้จะเสร็จเมื่อไหร่?) | When do we start seeing value? (เมื่อไหร่เราจะเริ่มเห็นคุณค่า?) |
What went wrong? (อะไรผิดพลาด?) | What did we learn and how can I help? (เราเรียนรู้อะไรและฉันจะช่วยได้อย่างไร?) |
I want a completely new website. (ฉันต้องการเว็บไซต์ใหม่ทั้งหมด) | What's the first thing we can try to experiment with this idea? (สิ่งแรกที่เราสามารถลองทดลองกับแนวคิดนี้คืออะไร?) |
Source: Maya Leibman and Ross Clanton, "DevOps: Approaching Cruising Altitude," presentation at DevOps Enterprise Summit-Virtual Las Vegas 2020, ideolibrary.doesvirtual.com/?video=467488959 .
American Airlines สร้าง critical mass และ silent majority โดยการมุ่งเน้นที่ how และ why รวมถึงการเปลี่ยนคำศัพท์เพื่อให้มีภาษากลางร่วมกัน
CASE STUDY: NEW FOR SECOND EDITION (กรณีศึกษา: เพิ่มเติมสำหรับฉบับพิมพ์ครั้งที่สอง)
Saving the Economy From Ruin (With a Hyperscale PaaS) at HMRC (2020) (กอบกู้เศรษฐกิจจากความหายนะด้วย Hyperscale PaaS ที่ HMRC)
HMRC หรือ Her Majesty ' s Revenue and Customs เป็นหน่วยงานจัดเก็บภาษีของรัฐบาลสหราชอาณาจักร ในปี 2020 HMRC ได้แจกจ่ายเงินหลายแสนล้านปอนด์ให้กับพลเมืองและธุรกิจของสหราชอาณาจักรในแพ็คเกจสนับสนุนทางการเงินที่ไม่เคยมีมาก่อน ซึ่งในที่สุดจะเห็นแรงงานทั้งประเทศของสหราชอาณาจักรประมาณ 25% ที่ได้รับการสนับสนุนด้วยเงินสาธารณะ HMRC สร้างเทคโนโลยีเพื่อทำสิ่งนี้ภายในเวลาเพียงสี่สัปดาห์ ภายใต้สภาวะที่มีความกดดันและความไม่แน่นอนอย่างไม่น่าเชื่อ 40
ความท้าทายของ HMRC นั้นเกินกว่ากรอบเวลาที่ aggressive ไปมาก "เรารู้ว่าเราจะมีผู้ใช้หลายล้านคน แต่ไม่มีใครสามารถบอกเราได้จริงๆ ว่ากี่คน ดังนั้นไม่ว่าเราจะสร้างอะไรก็ตาม มันต้องเข้าถึงได้สำหรับทุกคน และต้องสามารถจ่ายเงินหลายพันล้านไปยังบัญชีธนาคารได้ภายในไม่กี่ชั่วโมงหลังจากเปิดตัว นอกจากนี้มันยังต้องปลอดภัย โดยมีการตรวจสอบก่อนที่จะจ่ายเงิน" Ben Conrad หัวหน้าฝ่าย Agile Delivery ของ HMRC กล่าวในงาน DevOps Enterprise Summit-Europe ปี 2021 41
และพวกเขาก็ทำได้สำเร็จ services ทั้งหมดเปิดตัวตรงเวลา โดยส่วนใหญ่เปิดตัวเร็วขึ้นหนึ่งหรือสองสัปดาห์โดยไม่มีปัญหาใดๆ ส่งผลให้อัตราความพึงพอใจของผู้ใช้อยู่ที่ 94% 42 HMRC เปลี่ยนจากหน่วยงานรัฐบาลที่ไม่เป็นที่นิยมที่สุด มาเป็นหน่วยงานที่ประชาชนพึ่งพาในการช่วยเหลือ
เพื่อให้บรรลุผลลัพธ์ที่น่าทึ่งนี้ HMRC ได้นำกระบวนการสำคัญบางอย่างมาใช้ และใช้ประโยชน์จากแพลตฟอร์มดิจิทัลที่เติบโตเต็มที่ ซึ่งพัฒนามาในช่วงเจ็ดปีที่ผ่านมาเพื่อให้ทีมสามารถสร้าง services ดิจิทัลได้อย่างรวดเร็วและส่งมอบในระดับ hyperscale
Platform ของ HMRC ' (Multichannel Digital Tax Platform หรือ MDTP) คือชุดของ infrastructure technologies ที่ช่วยให้องค์กรสามารถให้บริการเนื้อหาแก่ผู้ใช้ผ่านอินเทอร์เน็ต โดเมนธุรกิจภายใน HMRC สามารถเปิดเผยบริการภาษีสู่สาธารณะโดยการให้ทุนกับทีม cross-functional ขนาดเล็กเพื่อสร้าง microservice หรือชุดของ microservices บน platform นั้น MDTP ขจัดความเจ็บปวดและความซับซ้อนส่วนใหญ่ในการนำบริการดิจิทัลไปสู่ผู้ใช้ โดยการจัดหา tenant ด้วยชุดของ common components ที่จำเป็นในการพัฒนาและดำเนินการผลิตภัณฑ์ดิจิทัลที่มีคุณภาพสูง
MDTP เป็นแพลตฟอร์มดิจิทัลที่ใหญ่ที่สุดในรัฐบาลสหราชอาณาจักร และเป็นหนึ่งในแพลตฟอร์มที่ใหญ่ที่สุดในสหราชอาณาจักรโดยรวม มันโฮสต์ microservices ประมาณ 1,200 ตัวที่สร้างโดยคนมากกว่าสองพันคน แบ่งเป็นเจ็ดสิบทีมในแปดสถานที่ตั้งทางภูมิศาสตร์ (แม้ว่าตั้งแต่เดือนมีนาคม 2020 ทุกทีมทำงานระยะไกล 100%) 43 ทีมเหล่านี้ทำการ deploy ขึ้น production ประมาณหนึ่งร้อยครั้งทุกวัน
"ทีมต่างๆ ใช้วิธีการแบบ agile ด้วย governance ที่เบาโดยเจตนา และพวกเขา ' ได้รับความไว้วางใจให้ทำการเปลี่ยนแปลงด้วยตัวเองเมื่อใดก็ตามและเท่าที่พวกเขาเห็นสมควร" Matt Hyatt ผู้จัดการฝ่ายส่งมอบทางเทคนิคของ Equal Experts กล่าว "ใช้เวลาเพียงไม่กี่วินาทีในการ push การเปลี่ยนแปลงผ่าน infrastructure ของเรา ดังนั้นการนำผลิตภัณฑ์และ services ไปสู่ผู้ใช้จึงเกิดขึ้นได้อย่างรวดเร็วจริงๆ" 44
หัวใจสำคัญของความสำเร็จของ platform คือการมุ่งเน้นอย่างต่อเนื่องในสามสิ่งสำคัญ: วัฒนธรรม, เครื่องมือ และแนวปฏิบัติ เป้าหมายของ MDTP ' คือการทำให้ง่ายต่อการเพิ่มทีม สร้าง services และส่งมอบคุณค่าได้อย่างรวดเร็ว Platform ได้พัฒนาตามเป้าหมายนั้น เพื่อให้ทีม cross-functional สามารถตั้งค่าได้อย่างรวดเร็ว แล้วใช้เครื่องมือทั่วไปในการออกแบบ พัฒนา และดำเนินการ service ใหม่ที่面向สาธารณะ
ในทางปฏิบัติ MDTP จัดเตรียมสถานที่ให้โค้ดของทีมดิจิทัล ' อยู่ และ pipelines อัตโนมัติสำหรับโค้ดที่จะถูก build และ deploy ผ่านสภาพแวดล้อมต่างๆ และเข้าสู่ production ซึ่งทีมสามารถรับ feedback จากผู้ใช้ได้อย่างรวดเร็ว เครื่องมือ telemetry ทั่วไปถูกกำหนดค่าเพื่อให้ทีมสามารถ monitor services ของตนผ่าน dashboard อัตโนมัติและกลไกการแจ้งเตือน เพื่อให้พวกเขารู้เสมอว่าเกิดอะไรขึ้น ' Platform จัดเตรียมเครื่องมือการทำงานร่วมกันให้ทีมเพื่อช่วยให้พวกเขาสื่อสารทั้งภายในและระหว่างกัน เพื่อให้สามารถทำงานได้อย่างมีประสิทธิภาพทั้งระยะไกลและในสถานที่ทำงาน ทั้งหมดนี้พร้อมให้ทีมใช้งานได้แทบจะในทันที โดยมีการกำหนดค่าหรือขั้นตอน manual เพียงเล็กน้อย แนวคิดคือการปลดปล่อยทีมดิจิทัลให้สามารถมุ่งเน้นที่การแก้ปัญหาทางธุรกิจเพียงอย่างเดียว
ด้วยคนกว่า 2,000 คนที่ทำการเปลี่ยนแปลง ซึ่งอาจหลายครั้งต่อวัน สิ่งต่างๆ อาจยุ่งเหยิงมากได้ เพื่อหลีกเลี่ยงปัญหานี้ MDTP ใช้แนวคิดของ opinionated platform (หรือที่เรียกว่า paved road platform หรือ guardrails) ตัวอย่างเช่น ถ้าคุณสร้าง microservice มันต้องเขียนด้วย Scala และใช้ Play framework ถ้า service ของคุณต้องการ persistence มันต้องใช้ Mongo ถ้าผู้ใช้จำเป็นต้องดำเนินการทั่วไปเช่นการอัปโหลดไฟล์ ทีมต้องใช้ platform service ทั่วไปเมื่อมีอยู่ โดยพื้นฐานแล้ว governance เล็กๆ น้อยๆ ถูก baked ไว้ใน platform เอง ประโยชน์สำหรับทีมที่ยึดตามรางเหล่านี้คือพวกเขาสามารถส่งมอบ services ได้อย่างรวดเร็วเป็นพิเศษ
แต่ประโยชน์ไม่ได้หยุดเพียงแค่นั้น ด้วยการจำกัดเทคโนโลยีที่ใช้บน platform การสนับสนุน ' ก็ง่ายกว่ามาก ยิ่งไปกว่านั้น ทีมดิจิทัลยังถูกป้องกันไม่ให้เสียเวลาในการสร้างโซลูชันของตนเองสำหรับปัญหาที่ได้รับการแก้ไขแล้วที่อื่น
"เราสามารถให้บริการทั่วไปและส่วนประกอบที่นำกลับมาใช้ใหม่ได้ซึ่งเรารู้ว่าทำงานได้กับ all services นอกจากนี้มันยังช่วยให้คนสามารถย้ายระหว่าง services ได้ และแน่นอนว่าช่วยให้ services สามารถย้ายไปยังทีมใหม่ได้โดยไม่ต้องกังวลว่าคนของเรามีทักษะที่จำเป็นในการทำงานหรือไม่" Hyatt กล่าว 45
ความแตกต่างสำคัญอีกประการหนึ่งคือ MDTP ทำให้ทีมดิจิทัลไม่ต้องกังวลเกี่ยวกับ infrastructure ทำให้พวกเขาสามารถมุ่งเน้นที่แอปของตนเท่านั้น "พวกเขายังคงสามารถสังเกต infrastructure ผ่านเครื่องมืออย่าง Kibana และ Grafana ได้ แต่ไม่มีทีม service ใดที่สามารถเข้าถึง AWS accounts ได้ด้วยตนเอง" Hyatt กล่าว 46
ที่สำคัญ ความคิดเห็นของ "opinionated platform" นี้สามารถและเปลี่ยนแปลงได้ตามความต้องการและความต้องการของผู้ใช้ โดยมุ่งเน้นที่ self-service "service สามารถถูกสร้าง พัฒนา และ deploy บน platform ของเราโดยไม่ต้องมีส่วนร่วมโดยตรงจาก platform teams เลย" Hyatt กล่าว 47
MDTP มีบทบาทสำคัญในการทำให้การส่งมอบแพ็คเกจสนับสนุนทางการเงิน COVID-19 เป็นไปอย่างรวดเร็ว แต่นี่ไม่ใช่ ' ทั้งหมดของเรื่องราว ยังคงต้องอาศัยความพยายามอย่างมหาศาลจากทีม การตัดสินใจที่ดีและการปรับกระบวนการอย่างรวดเร็วยังพิสูจน์ให้เห็นว่ามีความสำคัญ
"สิ่งสำคัญที่สุดของการส่งมอบระบบด้วยความเร็วคือความสามารถของวิศวกรในการ 'ลงมือทำเลย'" ' Hyatt กล่าว 48 การผสมผสานระหว่าง governance ที่สมดุล แนวปฏิบัติที่ดีที่สุดที่กำหนดไว้ และคำสั่งจากทีม HMRC ให้ใช้เครื่องมือที่พิสูจน์แล้ว ทำให้พวกเขาไม่ต้อง ' เสี่ยงกับปัญหาเทคโนโลยีใหม่หรือข้อกังวลด้านความปลอดภัยที่อาจทำให้การส่งมอบล่าช้า
เพื่อให้บรรลุกรอบเวลาที่ aggressive ทีมต่างๆ ยังปรับเปลี่ยนองค์ประกอบและการสื่อสารของพวกเขา วิศวกร platform ถูกฝังอยู่ในทีม service ดิจิทัล COVID-19 แต่ละทีมเพื่อ "short-circuit" กระบวนการที่มีอยู่อย่างปลอดภัย สิ่งนี้ทำให้ทีมสามารถขจัดความเสี่ยงได้ตั้งแต่เนิ่นๆ และเพิ่มการทำงานร่วมกันให้สูงสุด โดยเฉพาะอย่างยิ่งในการขอส่วนประกอบ infrastructure ใหม่และขอความช่วยเหลือในการทดสอบประสิทธิภาพ ผู้ที่ทำงานใน services ที่สำคัญยังถูกทำใหสามารถระบุตัวตนได้ง่ายผ่านเครื่องมือการทำงานร่วมกัน เช่น Slack เพื่อให้การขอความช่วยเหลือได้รับการจัดลำดับความสำคัญ ไม่ใช่แค่โดย platform teams แต่โดยชุมชนดิจิทัลทั้งหมดที่มีคนกว่า 2,000 คน
ความสามารถของทีมและผู้นำทางธุรกิจในการปรับตัวอย่างรวดเร็วพร้อมกัน แล้วกลับเข้าที่เมื่อ services เปิดตัวแล้ว เป็นการสาธิตที่ยอดเยี่ยมของวัฒนธรรม DevOps ที่เติบโตเต็มที่ที่ HMRC
กรณีศึกษา HMRC แสดงให้เห็นว่าสามารถบรรลุผลได้มากเพียงใดโดยใช้ PaaS ในองค์กรขนาดใหญ่ใดๆ
Conclusion (บทสรุป)
Peter Drucker ผู้นำด้านการพัฒนาการศึกษาด้านการจัดการ เคยสังเกตว่า "ปลาเล็กเรียนรู้ที่จะเป็นปลาใหญ่ในบ่อเล็ก" 49 ด้วยการเลือกอย่างรอบคอบว่าจะเริ่มต้นที่ไหนและอย่างไร เราจึงสามารถทดลองและเรียนรู้ในพื้นที่ขององค์กรของเราที่สร้างคุณค่าโดยไม่ทำให้ส่วนอื่นขององค์กรตกอยู่ในความเสี่ยง การทำเช่นนี้ทำให้เราสร้างฐานการสนับสนุน ได้รับสิทธิ์ในการขยายการใช้ DevOps ในองค์กรของเรา และได้รับการยอมรับและความกตัญญูจากกลุ่มคนที่กว้างขึ้นเรื่อยๆ