20
CONVERT LOCAL DISCOVERIES INTO GLOBAL IMPROVEMENTS (แปลงการค้นพบในระดับท้องถิ่นให้เป็นการปรับปรุงในระดับองค์กร)
ใ นบทที่แล้ว เราได้พูดถึงการพัฒนาวัฒนธรรมการเรียนรู้ที่ปลอดภัย โดยสนับสนุนให้ทุกคนพูดคุยเกี่ยวกับข้อผิดพลาดและอุบัติเหตุผ่านการทำ blameless post-mortems นอกจากนี้เรายังได้สำรวจการค้นหาและแก้ไขสัญญาณความล้มเหลวที่อ่อนแรงลงเรื่อยๆ รวมถึงการเสริมสร้างและให้รางวัลกับการทดลองและการกล้าเสี่ยง ยิ่งไปกว่านั้น เรายังช่วยทำให้ระบบการทำงานของเรามีความยืดหยุ่นมากขึ้นโดยการวางแผนและทดสอบสถานการณ์ความล้มเหลวเชิงรุก ทำให้ระบบของเราปลอดภัยยิ่งขึ้นด้วยการค้นหาข้อบกพร่องที่ซ่อนอยู่และแก้ไขสิ่งเหล่านั้น
ในบทนี้ เราจะสร้างกลไกที่ทำให้การเรียนรู้และการปรับปรุงใหม่ๆ ที่ค้นพบในระดับท้องถิ่นสามารถถูกบันทึกและแบ่งปันไปทั่วทั้งองค์กร ช่วยทวีคูณผลกระทบของความรู้และการปรับปรุงในระดับโลก การทำเช่นนี้จะยกระดับมาตรฐานการปฏิบัติของทั้งองค์กร ทำให้ทุกคนที่ทำงานได้รับประโยชน์จากประสบการณ์สะสมขององค์กร
Use Chat Rooms and Chat Bots to Automate and Capture Organizational Knowledge (ใช้ Chat Rooms และ Chat Bots เพื่อ Automate และรวบรวมความรู้ขององค์กร)
หลายองค์กรได้สร้าง chat rooms เพื่ออำนวยความสะดวกในการสื่อสารที่รวดเร็วภายในทีม Chat rooms ยังสามารถใช้เพื่อ trigger ระบบ automation ได้อีกด้วย
เทคนิคนี้เริ่มต้นจากการเดินทางของ ChatOps ที่ GitHub เป้าหมายคือการนำเครื่องมือ automation มาอยู่ในศูนย์กลางของการสนทนาใน chat rooms ช่วยสร้างความโปร่งใสและเก็บบันทึกการทำงาน Jesse Newland วิศวกรระบบที่ GitHub อธิบายว่า "แม้คุณจะเพิ่งเข้ามาในทีม คุณก็สามารถดู chat logs และเห็นว่าทุกอย่างทำกันอย่างไร เหมือนกับว่าคุณได้ pair-programming กับพวกเขาตลอดเวลา" 1
พวกเขาสร้าง Hubot ซึ่งเป็นซอฟต์แวร์ที่โต้ตอบกับทีม Ops ใน chat rooms โดยสามารถสั่งให้ทำงานต่างๆ ได้เพียงแค่ส่งคำสั่งไป (เช่น "@hubot deploy owl to production") ผลลัพธ์ก็จะถูกส่งกลับเข้ามาใน chat room เช่นกัน 2
การให้ automation ทำงานเหล่านี้ใน chat room (แทนที่จะรัน automated scripts ผ่าน command line) มีประโยชน์มากมาย ได้แก่:
• ทุกคนเห็นทุกอย่างที่เกิดขึ้น
• วิศวกรในวันแรกของการทำงานสามารถเห็นว่างานประจำวันเป็นอย่างไรและทำกันอย่างไร
• ผู้คนกล้าที่จะขอความช่วยเหลือมากขึ้นเมื่อเห็นคนอื่นช่วยเหลือกัน
• การเรียนรู้ขององค์กรที่รวดเร็วเกิดขึ้นและสะสมอย่างต่อเนื่อง
ยิ่งไปกว่านั้น นอกเหนือจากประโยชน์ที่ทดสอบแล้วข้างต้น chat rooms จะบันทึกและเปิดเผยการสื่อสารทั้งหมดให้สาธารณะโดยอัตโนมัติ ในทางตรงกันข้าม อีเมลเป็นแบบส่วนตัวโดยค่าเริ่มต้น และข้อมูลในอีเมลไม่สามารถค้นพบหรือแพร่กระจายภายในองค์กรได้ง่าย
การผสานรวม automation ของเราเข้ากับ chat rooms ช่วยบันทึกและแบ่งปันข้อสังเกตและการแก้ปัญหาของเราให้เป็นส่วนหนึ่งของการทำงานโดยธรรมชาติ สิ่งนี้ช่วยเสริมสร้างวัฒนธรรมแห่งความโปร่งใสและการทำงานร่วมกันในทุกสิ่งที่เราทำ
Hubot at GitHub (Hubot ที่ GitHub)
นี่ยังเป็นวิธีที่มีประสิทธิภาพอย่างยิ่งในการเปลี่ยนการเรียนรู้ระดับท้องถิ่นให้เป็นความรู้ระดับองค์กร ที่ GitHub พนักงาน Operations ทุกคนทำงานระยะไกล—อันที่จริงไม่มีวิศวกรสองคนที่ทำงานในเมืองเดียวกัน Mark Imbriaco อดีตรองประธานฝ่าย Operations ที่ GitHub เล่าว่า "ที่ GitHub ไม่มี watercooler จริงๆ Chat room คือ water cooler" 3
GitHub ให้ Hubot สามารถ trigger เทคโนโลยี automation ต่างๆ ของพวกเขา รวมถึง Puppet, Capistrano, Jenkins, resque (library ที่ใช้ Redis สำหรับสร้าง background jobs) และ graphme (ซึ่งสร้าง graphs จาก Graphite) 4
การดำเนินการที่ทำผ่าน Hubot รวมถึงการตรวจสอบสุขภาพของบริการ, การทำ Puppet push หรือ code deployment ขึ้น production, และการปิดการแจ้งเตือนเมื่อบริการเข้าสู่โหมด maintenance การดำเนินการที่ทำซ้ำหลายครั้ง เช่น การเรียกดู smoke test logs เมื่อ deployment ล้มเหลว, การนำ production servers ออกจาก rotation, การ revert ไปที่ master สำหรับ production front-end services, หรือแม้แต่การขอโทษวิศวกรที่อยู่ on call ก็กลายเป็นการดำเนินการของ Hubot เช่นกัน 5 *
ในทำนองเดียวกัน การ commit ไปยัง source code repository และคำสั่งที่ trigger production deployment ต่างก็ส่งข้อความไปยัง chat room นอกจากนี้ เมื่อการเปลี่ยนแปลงเคลื่อนผ่าน deployment pipeline สถานะของมันก็จะถูกโพสต์ใน chat room
ตัวอย่างการสนทนาใน chat room ทั่วไปที่รวดเร็วอาจมีลักษณะดังนี้:
@sr: @jnewland, คุณหาลิสต์ repo ใหญ่ๆ ได้ยังไง? disk_hogs หรืออะไรประมาณนั้น?
@jnewland: /disk-hogs
Newland สังเกตว่าคำถามบางอย่างที่เคยถูกถามระหว่างโปรเจกต์ตอนนี้แทบจะไม่ถูกถามอีกแล้ว 6 ตัวอย่างเช่น วิศวกรอาจถามกันว่า "Deploy เป็นยังไงบ้าง?" หรือ "คุณกำลัง deploy อยู่หรือฉันควร deploy?" หรือ "Load ดูเป็นอย่างไรบ้าง?"
ในบรรดาประโยชน์ทั้งหมดที่ Newland บรรยาย ซึ่งรวมถึงการ onboarding วิศวกรใหม่ที่เร็วขึ้นและการทำให้วิศวกรทุกคนมีประสิทธิผลมากขึ้น ผลลัพธ์ที่เขารู้สึกว่าสำคัญที่สุดคืองาน Ops มีมนุษยธรรมมากขึ้น เนื่องจากวิศวกร Ops สามารถค้นพบปัญหาและช่วยเหลือกันได้อย่างรวดเร็วและง่ายดาย 7
GitHub สร้างสภาพแวดล้อมสำหรับการเรียนรู้ร่วมกันในระดับท้องถิ่นที่สามารถเปลี่ยนเป็นการเรียนรู้ทั่วทั้งองค์กร ในส่วนที่เหลือของบทนี้ เราจะสำรวจวิธีการสร้างและเร่งการแพร่กระจายการเรียนรู้ระดับองค์กรใหม่ๆ
Automate Standardized Processes in Software for Reuse (ทำให้กระบวนการมาตรฐานเป็น Automation ในซอฟต์แวร์เพื่อนำกลับมาใช้ซ้ำ)
บ่อยครั้งเกินไปที่เราจดมาตรฐานและกระบวนการสำหรับสถาปัตยกรรม การทดสอบ การ deploy และการจัดการ infrastructure ไว้ในเอกสาร Word แล้วอัปโหลดไว้ที่ไหนสักแห่ง ปัญหาคือวิศวกรที่กำลังสร้างแอปพลิเคชันหรือสภาพแวดล้อมใหม่มักไม่รู้ว่าเอกสารเหล่านี้มีอยู่ หรือไม่มีเวลาที่จะนำมาตรฐานที่บันทึกไว้ไปปฏิบัติ ผลลัพธ์คือพวกเขาสร้างเครื่องมือและกระบวนการของตัวเอง ซึ่งให้ผลลัพธ์ที่น่าผิดหวังอย่างที่คาดไว้: แอปพลิเคชันและสภาพแวดล้อมที่เปราะบาง ไม่ปลอดภัย และบำรุงรักษายาก ซึ่งมีค่าใช้จ่ายสูงในการรัน ดูแล และพัฒนา
แทนที่จะใส่ความเชี่ยวชาญของเราลงในเอกสาร Word เราต้องเปลี่ยนมาตรฐานและกระบวนการที่บันทึกไว้เหล่านี้ ซึ่งรวมเอาความรู้และการเรียนรู้ทั้งหมดขององค์กร ไปเป็นรูปแบบที่ปฏิบัติการได้ (executable form) ที่ทำให้ง่ายต่อการนำกลับมาใช้ซ้ำ 8 หนึ่งในวิธีที่ดีที่สุดในการทำให้ความรู้นี้สามารถนำกลับมาใช้ซ้ำได้คือการนำมันใส่ไว้ใน centralized source code repository ทำให้เครื่องมือพร้อมให้ทุกคนค้นหาและใช้งาน
Justin Arbuckle เป็น chief architect ที่ GE Capital ในปี 2013 เมื่อเขากล่าวว่า "เราจำเป็นต้องสร้างกลไกที่จะช่วยให้ทีมต่างๆ ปฏิบัติตามนโยบายได้อย่างง่ายดาย—ไม่ว่าจะเป็นข้อบังคับระดับประเทศ ระดับภูมิภาค และระดับอุตสาหกรรมในกรอบการกำกับดูแลนับสิบข้อ ครอบคลุมแอปพลิเคชันนับพันที่รันบนเซิร์ฟเวอร์นับหมื่นในศูนย์ข้อมูลนับสิบแห่ง" 9
กลไกที่พวกเขาสร้างขึ้นเรียกว่า ArchOps ซึ่ง "ทำให้วิศวกรของเราเป็น builder ไม่ใช่ bricklayer การใส่มาตรฐานการออกแบบของเราลงใน automated blueprints ที่ใครก็สามารถใช้งานได้ง่าย ทำให้เราได้ความสอดคล้องเป็นผลพลอยได้" 10
การเข้ารหัสกระบวนการ manual ของเราเป็น code ที่ทำงานอัตโนมัติ ช่วยให้กระบวนการสามารถถูกนำไปใช้อย่างกว้างขวาง สร้างคุณค่าให้กับทุกคนที่ใช้งาน Arbuckle สรุปว่า "การปฏิบัติตามข้อกำหนดที่แท้จริงขององค์กรนั้นเป็นสัดส่วนโดยตรงกับระดับที่นโยบายถูกแสดงเป็น code" 11
การทำให้กระบวนการอัตโนมัตินี้เป็นวิธีที่ง่ายที่สุดในการบรรลุเป้าหมาย จะช่วยให้แนวปฏิบัติต่างๆ ถูกนำไปใช้อย่างกว้างขวาง—เราอาจพิจารณาเปลี่ยนให้เป็น shared services ที่ได้รับการสนับสนุนจากองค์กร
Create a Single, Shared Source Code Repository for Our Entire Organization (สร้าง Source Code Repository เดียวที่ใช้ร่วมกันทั่วทั้งองค์กร)
source code repository ที่ใช้ร่วมกันทั่วทั้งบริษัทเป็นหนึ่งในกลไกที่ทรงพลังที่สุดในการผสานรวมการค้นพบในระดับท้องถิ่นทั่วทั้งองค์กร เมื่อเราอัปเดตอะไรก็ตามใน source code repository (เช่น shared library) มันจะแพร่กระจายไปยัง service อื่นๆ ที่ใช้ library นั้นอย่างรวดเร็วและอัตโนมัติ ผ่านการผสานรวมใน deployment pipeline ของแต่ละทีม
Google เป็นหนึ่งในตัวอย่างที่ใหญ่ที่สุดของการใช้ shared source code repository ทั่วทั้งองค์กร ภายในปี 2015 Google มี shared source code repository เดียวที่มีไฟล์กว่าพันล้านไฟล์และโค้ดกว่าสองพันล้านบรรทัด repository นี้ถูกใช้โดยวิศวกรทุกคนในจำนวนสองหมื่นห้าพันคน ครอบคลุมทุกผลิตภัณฑ์ของ Google รวมถึง Google Search, Google Maps, Google Docs, Google Calendar, Gmail และ YouTube 12 †
ผลลัพธ์ที่มีค่าอย่างหนึ่งคือวิศวกรสามารถใช้ประโยชน์จากความเชี่ยวชาญที่หลากหลายของทุกคนในองค์กร Rachel Potvin ผู้จัดการฝ่ายวิศวกรรมของ Google ที่ดูแล Developer Infrastructure group บอกกับ Wired ว่าวิศวกรทุกคนของ Google สามารถเข้าถึง "คลัง library มากมาย" เพราะ "เกือบทุกอย่างถูกสร้างไว้แล้ว" 14
ยิ่งไปกว่านั้น Eran Messeri วิศวกรใน Google Developer Infrastructure group อธิบายว่าข้อดีอย่างหนึ่งของการใช้ repository เดียวคือช่วยให้ผู้ใช้เข้าถึงโค้ดทั้งหมดในรูปแบบที่ทันสมัยที่สุดได้ง่าย โดยไม่ต้องมีการประสานงาน 15
เราใส่ลงใน shared source code repository ไม่เพียงแค่ source code แต่ยังรวมถึง artifact อื่นๆ ที่เข้ารหัสความรู้และการเรียนรู้ ได้แก่:
• มาตรฐานการกำหนดค่าสำหรับ library, infrastructure และสภาพแวดล้อมของเรา (Chef, Puppet หรือ Ansible scripts)
• เครื่องมือ deployment
• มาตรฐานและเครื่องมือการทดสอบ รวมถึงความปลอดภัย
• เครื่องมือ deployment pipeline
• เครื่องมือ monitoring และ analysis
• บทเรียนและมาตรฐาน
การเข้ารหัสความรู้และแบ่งปันผ่าน repository นี้เป็นหนึ่งในกลไกที่ทรงพลังที่สุดที่เรามีสำหรับการเผยแพร่ความรู้ Randy Shoup กล่าวว่า
กลไกที่ทรงพลังที่สุดในการป้องกันความล้มเหลวที่ Google คือ single code repository เมื่อมีใครเช็คอินอะไรก็ตามเข้าไปใน repo จะส่งผลให้เกิด build ใหม่ ซึ่งจะใช้เวอร์ชันล่าสุดของทุกอย่างเสมอ ทุกอย่างถูก build จาก source code แทนที่จะ dynamic link ที่ runtime—จะมี library เพียงเวอร์ชันเดียวที่เป็นเวอร์ชันปัจจุบันที่ใช้งานอยู่ ซึ่งจะถูก static link ระหว่างกระบวนการ build 16
Tom Limoncelli เป็นผู้เขียนร่วมของ The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems และอดีต site reliability engineer ที่ Google ในหนังสือของเขา เขากล่าวว่าคุณค่าของการมี repository เดียวสำหรับทั้งองค์กรนั้นทรงพลังมากจนยากที่จะอธิบาย
คุณสามารถเขียน tool ได้ครั้งเดียวและให้มันใช้ได้กับทุกโปรเจกต์ คุณมีความรู้ที่แม่นยำ 100% ว่าใครบ้างที่ depend บน library ใด ดังนั้นคุณสามารถ refactor มันและมั่นใจได้ 100% ว่าใครจะได้รับผลกระทบและใครที่ต้องทดสอบหาความเสียหาย ฉันอาจจะยกตัวอย่างได้อีกเป็นร้อยตัวอย่าง ฉันไม่สามารถอธิบายเป็นคำพูดได้ว่าข้อได้เปรียบทางการแข่งขันนี้ใหญ่แค่ไหนสำหรับ Google 17
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
งานวิจัยแสดงให้เห็นว่าแนวปฏิบัติที่ดีเกี่ยวกับ code ส่งผลต่อประสิทธิภาพระดับสูง Rachel Potvin จาก Google ซึ่งมีความเชี่ยวชาญด้านการสร้างระบบและการนำทีมพัฒนา เป็นที่ปรึกษาให้กับรายงาน State of DevOps Report ปี 2019 ของ DORA ซึ่งระบุว่า code maintainability เป็นโครงสร้างสำคัญที่ช่วยให้ทีมทำ continuous delivery ได้สำเร็จ โครงสร้างใหม่นี้ ซึ่งอิงจากประโยชน์ที่ Potvin เห็นจาก infrastructure ที่มีให้ที่ Google ช่วยให้ทีมคิดเกี่ยวกับการจัดโครงสร้างงานและโค้ดของพวกเขา 18
ตามรายงานระบุว่า
ทีมที่จัดการ code maintainability ได้ดีจะมีระบบและเครื่องมือที่ทำให้นักพัฒนาเปลี่ยนโค้ดที่ดูแลโดยทีมอื่นได้ง่าย ค้นหาตัวอย่างใน codebase นำโค้ดของคนอื่นกลับมาใช้ใหม่ รวมถึงเพิ่ม อัปเกรด และย้ายไปใช้ dependency เวอร์ชันใหม่โดยไม่ทำให้โค้ดเสียหาย การมีระบบและเครื่องมือเหล่านี้ไม่เพียงแต่ช่วยให้ CD ดีขึ้น แต่ยังช่วยลด technical debt ซึ่งช่วยเพิ่ม productivity 19
ที่ Google ทุก library (เช่น libc, OpenSSL รวมถึง library ที่พัฒนาภายใน เช่น Java threading libraries) จะมี owner ที่รับผิดชอบในการทำให้แน่ใจว่า library ไม่เพียงแต่ compile ได้ แต่ยังผ่านการทดสอบของทุกโปรเจกต์ที่ depend บน library นั้น เช่นเดียวกับบรรณารักษ์ในโลกจริง owner คนนั้นยังรับผิดชอบในการย้ายแต่ละโปรเจกต์จากเวอร์ชันหนึ่งไปยังเวอร์ชันถัดไป
ลองพิจารณาตัวอย่างจริงขององค์กรที่รัน Java Struts framework library ถึงแปดสิบเอ็ดเวอร์ชันใน production—เกือบทุกเวอร์ชันยกเว้นเวอร์ชันเดียวมีช่องโหว่ด้านความปลอดภัยที่ร้ายแรง และการดูแลรักษาทุกเวอร์ชันเหล่านี้ ซึ่งแต่ละเวอร์ชันมีลักษณะเฉพาะและปัญหาของตัวเอง สร้างภาระในการดำเนินงานและความเครียดอย่างมาก ยิ่งไปกว่านั้น ความหลากหลายนี้ทำให้การอัปเกรดเวอร์ชันมีความเสี่ยงและไม่ปลอดภัย ซึ่งยิ่งทำให้นักพัฒนาไม่กล้าอัปเกรด และวงจรนี้ก็ดำเนินต่อไปเรื่อยๆ single source repository แก้ปัญหาส่วนนี้ได้ รวมถึงการมี automated tests ที่ช่วยให้ทีมสามารถย้ายไปใช้เวอร์ชันใหม่ได้อย่างปลอดภัยและมั่นใจ
หากเราไม่สามารถ build ทุกอย่างจาก source tree เดียวได้ เราก็ต้องหาวิธีอื่นในการรักษาเวอร์ชันที่ดีของ library และ dependencies ของมัน ตัวอย่างเช่น เราอาจมี repository ทั่วทั้งองค์กร เช่น Nexus, Artifactory หรือ Debian หรือ RPM repository ซึ่งเราจะต้องอัปเดตเมื่อมีช่องโหว่ที่ทราบ ทั้งใน repository เหล่านี้และในระบบ production
สิ่งสำคัญคือต้องแน่ใจว่า dependencies ถูกดึงมาจากภายใน source control repository หรือ package repository ขององค์กรเท่านั้น เพื่อป้องกันการโจมตีผ่าน "ซัพพลายเชนซอฟต์แวร์" ที่อาจบุกรุกระบบขององค์กร
Spread Knowledge by Using Automated Tests as Documentation and Communities of Practice (แพร่กระจายความรู้ด้วยการใช้ Automated Tests เป็นเอกสารประกอบและ Communities of Practice)
เมื่อเรามี shared libraries ที่ถูกใช้ทั่วทั้งองค์กร เราควรเปิดให้มีการเผยแพร่ความเชี่ยวชาญและการปรับปรุงอย่างรวดเร็ว การทำให้แน่ใจว่าแต่ละ library มี automated testing จำนวนมากรวมอยู่ด้วย หมายความว่า library เหล่านี้จะกลายเป็นเอกสารอธิบายตนเอง (self-documenting) และแสดงให้วิศวกรคนอื่นเห็นวิธีใช้งาน
ประโยชน์นี้จะเกิดขึ้นเกือบจะอัตโนมัติหากเรามีแนวปฏิบัติ test-driven development (TDD) ซึ่ง automated tests จะถูกเขียนก่อนที่เราจะเขียนโค้ด ระเบียบวินัยนี้จะเปลี่ยน test suite ของเราให้เป็นข้อกำหนดของระบบที่มีชีวิตและทันสมัยอยู่เสมอ วิศวกรที่ต้องการทำความเข้าใจวิธีใช้ระบบสามารถดู test suite เพื่อหาตัวอย่างการทำงานจริงของ API ของระบบ
ตามอุดมคติ แต่ละ library ควรมี owner หรือทีมเดียวที่ดูแล ซึ่งเป็นที่รวมความรู้และความเชี่ยวชาญสำหรับ library นั้น ยิ่งไปกว่านั้น เราควรอนุญาตให้ใช้เพียงเวอร์ชันเดียวใน production เพื่อให้แน่ใจว่าสิ่งที่อยู่ใน production ใช้ความรู้ส่วนรวมที่ดีที่สุดขององค์กร
ในโมเดลนี้ owner ของ library ยังรับผิดชอบในการย้ายแต่ละกลุ่มที่ใช้ repository จากเวอร์ชันหนึ่งไปยังเวอร์ชันถัดไปอย่างปลอดภัย ซึ่งต้องอาศัยการตรวจจับ regression error อย่างรวดเร็วผ่าน automated testing ที่ครอบคลุมและการ continuous integration สำหรับทุกระบบที่ใช้ library นั้น
เพื่อเผยแพร่ความรู้ให้เร็วขึ้น เรายังสามารถสร้าง discussion groups หรือ chat rooms สำหรับแต่ละ library หรือ service เพื่อให้ผู้ที่มีคำถามสามารถรับคำตอบจากผู้ใช้อื่น ซึ่งมักจะตอบได้เร็วกว่านักพัฒนา
การใช้เครื่องมือสื่อสารประเภทนี้แทนที่จะมีความรู้ความเชี่ยวชาญที่กระจัดกระจายอยู่เป็นหย่อมๆ ทั่วองค์กร จะช่วยอำนวยความสะดวกในการแลกเปลี่ยนความรู้และประสบการณ์ ทำให้แน่ใจว่าพนักงานสามารถช่วยเหลือกันในเรื่องปัญหาและรูปแบบใหม่ๆ
Design for Operations through Codified Non-Functional Requirements (ออกแบบเพื่อ Operations ผ่าน Non-Functional Requirements ที่ถูกทำให้เป็นรหัส)
เมื่อ Development ติดตามงานของตนไปยังปลายน้ำและมีส่วนร่วมในการแก้ไข incidents ใน production แอปพลิเคชันจะถูกออกแบบให้เหมาะสมกับ Operations มากขึ้นเรื่อยๆ ยิ่งไปกว่านั้น เมื่อเราเริ่มออกแบบโค้ดและแอปพลิเคชันอย่างตั้งใจเพื่อรองรับ flow ที่รวดเร็วและความสามารถในการ deploy เรามักจะระบุชุดของ non-functional requirements ที่เราจะผสานรวมเข้ากับบริการ production ทั้งหมดของเรา
การนำ non-functional requirements เหล่านี้ไปปฏิบัติจะทำให้บริการของเรา deploy และรันใน production ได้ง่าย ซึ่งเราสามารถตรวจจับและแก้ไขปัญหาได้อย่างรวดเร็ว และแน่ใจว่าระบบยังทำงานได้อย่างเหมาะสมเมื่อ component ล้มเหลว ตัวอย่างของ non-functional requirements ได้แก่ การทำให้แน่ใจว่าเรามี:
• production telemetry ที่เพียงพอในแอปพลิเคชันและสภาพแวดล้อมของเรา
• ความสามารถในการติดตาม dependencies อย่างแม่นยำ
• บริการที่มีความยืดหยุ่นและเสื่อมสภาพอย่างสง่างาม (degrade gracefully)
• ความเข้ากันได้ไปข้างหน้าและย้อนหลังระหว่างเวอร์ชัน
• ความสามารถในการ archive ข้อมูลเพื่อจัดการขนาดของชุดข้อมูล production
• ความสามารถในการค้นหาและทำความเข้าใจ log messages ระหว่าง services ได้ง่าย
• ความสามารถในการติดตาม requests จากผู้ใช้ผ่านหลาย services
• การกำหนดค่า runtime ที่เรียบง่ายและรวมศูนย์โดยใช้ feature flags เป็นต้น
การทำให้ non-functional requirements ประเภทนี้เป็นรหัส จะทำให้บริการใหม่และที่มีอยู่ทั้งหมดของเราใช้ประโยชน์จากความรู้และประสบการณ์ส่วนรวมขององค์กรได้ง่ายขึ้น สิ่งเหล่านี้เป็นความรับผิดชอบของทีมที่สร้างบริการ
Build Reusable Operations User Stories into Development (สร้าง Operations User Stories ที่ใช้ซ้ำได้เข้าไปใน Development)
เมื่องาน Operations ที่ไม่สามารถทำ automation หรือ self-service ได้อย่างสมบูรณ์ เป้าหมายของเราคือทำให้งานที่เกิดขึ้นซ้ำๆ นี้ทำซ้ำได้และแน่นอนที่สุด เราทำสิ่งนี้โดยการกำหนดมาตรฐานของงานที่ต้องการ ทำ automation ให้มากที่สุด และบันทึกงานของเราเพื่อให้ทีมผลิตภัณฑ์สามารถวางแผนและจัดสรรทรัพยากรสำหรับกิจกรรมนี้ได้ดีขึ้น
แทนที่จะสร้าง servers ด้วยตนเองแล้วนำเข้าสู่ production ตาม checklist แบบ manual เราควรทำ automation งานนี้ให้มากที่สุดเท่าที่จะทำได้ รวมถึงการจัดการคอนฟิกหลังการติดตั้ง ในกรณีที่บางขั้นตอนไม่สามารถทำ automation ได้ (เช่น การติดตั้ง server ด้วยตนเองและให้อีกทีมเดินสาย) เราควรกำหนดการส่งมอบงานระหว่างทีมให้ชัดเจนที่สุดเพื่อลด lead time และข้อผิดพลาด การทำเช่นนี้จะช่วยให้เราวางแผนและจัดตารางขั้นตอนเหล่านี้ได้ดีขึ้นในอนาคต
ตัวอย่างเช่น เราสามารถใช้เครื่องมือเช่น Terraform เพื่อ automate การ provision และจัดการคอนฟิกของ cloud infrastructure การเปลี่ยนแปลงเฉพาะหน้าหรืองานโปรเจกต์สามารถบันทึกในระบบ ticket เช่น JIRA หรือ ServiceNow โดยการเปลี่ยนแปลงคอนฟิก infrastructure จะถูกบันทึกใน version control และเชื่อมโยงกับงาน tickets จากนั้นนำไปใช้กับระบบของเราโดยอัตโนมัติ (paradigm ที่เรียกว่า infrastructure-as-code หรือ GitOps)
ตามอุดมคติ สำหรับงาน Ops ที่เกิดขึ้นซ้ำทั้งหมด เราควรรู้สิ่งต่อไปนี้: ต้องทำงานอะไร ต้องใช้ใครทำงาน มีขั้นตอนอะไรบ้างในการทำให้เสร็จ และอื่นๆ ตัวอย่างเช่น "เรารู้ว่า high-availability rollout ต้องใช้สิบสี่ขั้นตอน ต้องใช้ทีมงานสี่ทีม และห้าครั้งล่าสุดที่เราทำใช้เวลาเฉลี่ยสามวัน"
เช่นเดียวกับที่เราสร้าง user stories ใน Development และใส่เข้าไปใน backlog แล้วดึงเข้ามาทำงาน เราสามารถสร้าง "Ops user stories" ที่กำหนดไว้อย่างดี ซึ่งแสดงถึงกิจกรรมการทำงานที่สามารถใช้ซ้ำได้ในทุกโปรเจกต์ของเรา (เช่น deployment, capacity, security ฯลฯ) การสร้าง Ops user stories ที่กำหนดไว้อย่างดีนี้ จะเปิดเผยงาน IT Operations ที่ทำซ้ำได้ในลักษณะที่แสดงควบคู่ไปกับงาน Development ทำให้สามารถวางแผนได้ดีขึ้นและได้ผลลัพธ์ที่ทำซ้ำได้มากขึ้น
Ensure Technology Choices Help Achieve Organizational Goals (ทำให้แน่ใจว่าการเลือกเทคโนโลยีช่วยบรรลุเป้าหมายขององค์กร)
เมื่อเป้าหมายหนึ่งของเราคือการเพิ่ม productivity ของนักพัฒนาให้สูงสุด และเรามี service-oriented architectures ทีม service ขนาดเล็กสามารถสร้างและรัน service ของตนในภาษาหรือ framework ใดก็ได้ที่ตอบสนองความต้องการเฉพาะของตนได้ดีที่สุด ในบางกรณี นี่คือสิ่งที่ช่วยให้เราบรรลุเป้าหมายขององค์กรได้ดีที่สุด
อย่างไรก็ตาม มีสถานการณ์ที่ตรงกันข้ามเกิดขึ้น เช่น เมื่อความเชี่ยวชาญสำหรับ service ที่สำคัญมีอยู่ในทีมเดียวเท่านั้น และมีเพียงทีมนั้นเท่านั้นที่สามารถเปลี่ยนแปลงหรือแก้ไขปัญหาได้ ทำให้เกิด bottleneck กล่าวอีกนัยหนึ่ง เราอาจ optimize เพื่อ productivity ของทีม แต่ไม่ได้ตั้งใจขัดขวางการบรรลุเป้าหมายขององค์กร
สิ่งนี้มักเกิดขึ้นเมื่อเรามีกลุ่ม Operations ที่เน้นหน้าที่การงานซึ่งรับผิดชอบด้านใดด้านหนึ่งของการสนับสนุน service ในสถานการณ์เหล่านี้ เพื่อให้แน่ใจว่าเราเปิดใช้งานทักษะเชิงลึกในเทคโนโลยีเฉพาะ เราต้องแน่ใจว่า Operations สามารถมีอิทธิพลต่อ component ที่ใช้ใน production หรือให้ความสามารถในการไม่ต้องรับผิดชอบแพลตฟอร์มที่ไม่ได้รับการสนับสนุน
หากเราไม่มีรายการเทคโนโลยีที่ Operations จะสนับสนุน ซึ่งสร้างโดย Development และ Operations ร่วมกัน เราควรตรวจสอบ infrastructure และ services ใน production อย่างเป็นระบบ รวมถึง dependencies ทั้งหมดที่ได้รับการสนับสนุนในปัจจุบัน เพื่อค้นหาสิ่งใดที่สร้าง failure demand และ unplanned work ในสัดส่วนที่ไม่สมดุล
เป้าหมายของเราคือการระบุเทคโนโลยีที่:
• ขัดขวางหรือทำให้ flow ของงานช้าลง
• สร้าง unplanned work ในระดับสูงอย่างไม่สมส่วน
• สร้างคำขอรับการสนับสนุนจำนวนมากอย่างไม่สมส่วน
• ไม่สอดคล้องกับผลลัพธ์ทางสถาปัตยกรรมที่เราต้องการมากที่สุด (เช่น throughput, stability, security, reliability, business continuity)
การกำจัด infrastructure และ platform ที่เป็นปัญหาออกจากเทคโนโลยีที่ Ops สนับสนุน จะช่วยให้ทุกคนมุ่งเน้นไปที่ infrastructure ที่ช่วยบรรลุเป้าหมายระดับโลกขององค์กรได้ดีที่สุด
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
เป้าหมายคือการสร้าง infrastructure platforms ที่ผู้ใช้ (รวมถึงทีมพัฒนา) สามารถใช้บริการ operations แบบ self-service ได้โดยไม่ต้องยื่น ticket หรือส่งอีเมล นี่คือความสามารถสำคัญที่เปิดใช้งานโดย modern cloud infrastructure—มันเป็นหนึ่งในห้าคุณลักษณะสำคัญของ cloud computing ที่กำหนดโดย National Institute of Standards and Technology (NIST) ของรัฐบาลกลางสหรัฐฯ: 20
• On-demand self service: ผู้บริโภคสามารถ provision ทรัพยากรคอมพิวเตอร์ตามต้องการได้โดยอัตโนมัติ โดยไม่ต้องปฏิสัมพันธ์กับมนุษย์จากผู้ให้บริการ
• Broad network access: ความสามารถสามารถเข้าถึงได้ผ่านแพลตฟอร์มที่หลากหลาย เช่น โทรศัพท์มือถือ แท็บเล็ต แล็ปท็อป และ workstation
• Resource pooling: ทรัพยากรของผู้ให้บริการถูกรวมในโมเดล multi-tenant โดยทรัพยากรทางกายภาพและเสมือนถูกจัดสรรแบบไดนามิกตามต้องการ ลูกค้าอาจระบุตำแหน่งที่ระดับนามธรรมที่สูงขึ้น เช่น ประเทศ รัฐ หรือศูนย์ข้อมูล
• Rapid elasticity: ความสามารถสามารถถูก provision และปล่อยอย่างยืดหยุ่นเพื่อขยายออกหรือเข้าได้อย่างรวดเร็วตามต้องการ ดูเหมือนไม่มีขีดจำกัดและสามารถจัดสรรในปริมาณเท่าใดก็ได้ตลอดเวลา
• Measured service: ระบบ cloud จะควบคุม เพิ่มประสิทธิภาพ และรายงานการใช้ทรัพยากรโดยอัตโนมัติตามประเภทของบริการ เช่น พื้นที่จัดเก็บ การประมวลผล แบนด์วิธ และบัญชีผู้ใช้ที่ใช้งานอยู่
เป็นไปได้ที่จะประสบความสำเร็จในการสร้าง infrastructure platforms ด้วยโมเดล private, public, และ hybrid—โดยมีเงื่อนไขว่าคุณต้องปรับปรุงกระบวนการและแนวปฏิบัติของ datacenter แบบดั้งเดิมให้ทันสมัย เพื่อให้สามารถตอบสนองคุณลักษณะสำคัญทั้งห้าประการนี้ หากแพลตฟอร์มเทคโนโลยีของคุณไม่สนับสนุนคุณลักษณะเหล่านี้ ควรให้ความสำคัญกับการแทนที่ด้วยแพลตฟอร์มที่รองรับ หรือปรับปรุงแพลตฟอร์มที่มีอยู่ให้ได้ผลลัพธ์ทางสถาปัตยกรรมเหล่านี้มากที่สุด
รายงาน State of DevOps Report ปี 2019 ของ DORA พบว่ามีเพียง 29% ของผู้ตอบแบบสำรวจที่กล่าวว่าพวกเขาใช้ cloud infrastructure ที่เห็นด้วยหรือเห็นด้วยอย่างยิ่งว่าพวกเขาตรงตามคุณลักษณะสำคัญทั้งห้าประการของ cloud computing ตามที่ NIST กำหนด และการใช้ประโยชน์จากทั้งห้าคุณลักษณะของ cloud computing มีความสำคัญ ผู้มีประสิทธิภาพสูงมีแนวโน้มที่จะตรงตามคุณลักษณะ cloud ที่จำเป็นทั้งหมดมากกว่าผู้มีประสิทธิภาพต่ำถึงยี่สิบสี่เท่า 21
สิ่งนี้แสดงให้เห็นสองประการ ประการแรก ความไม่สอดคล้องกันระหว่างทีมที่อาจบอกว่าอยู่บน cloud แต่กลับไม่ได้รับประโยชน์—ต้องดำเนินการตามคุณลักษณะที่อธิบายไว้ข้างต้นจึงจะประสบความสำเร็จ ประการที่สอง ผลกระทบของความสามารถทางเทคนิคและสถาปัตยกรรมต่อประสิทธิภาพการส่งมอบซอฟต์แวร์ โดยการดำเนินการที่ดี ทีมระดับสูงเห็นประสิทธิภาพที่สำคัญทั้งในด้านความเร็วและความเสถียรเมื่อเทียบกับทีมที่มีประสิทธิภาพต่ำ
CASE STUDY (กรณีศึกษา)
Standardizing a New Technology Stack at Etsy (2010) (การสร้างมาตรฐาน Technology Stack ใหม่ที่ Etsy)
ในหลายองค์กร’ที่นำ DevOps มาใช้ เรื่องราวทั่วไปที่นักพัฒนาเล่าคือ "Ops ไม่ยอมให้สิ่งที่เราต้องการ เราจึงสร้างและสนับสนุนมันเอง" อย่างไรก็ตาม ในช่วงแรกของการเปลี่ยนแปลงที่ Etsy ผู้นำด้านเทคโนโลยีกลับใช้แนวทางตรงกันข้าม โดยลดจำนวนเทคโนโลยีที่ได้รับการสนับสนุนใน production ลงอย่างมาก
ในปี 2010 หลังจากฤดูวันหยุดช่วงพีคที่เกือบเป็นหายนะ ทีม Etsy ตัดสินใจลดจำนวนเทคโนโลยีที่ใช้ใน production ลงอย่างมหาศาล โดยเลือกเพียงไม่กี่อย่างที่ทั้งองค์กรสามารถสนับสนุนได้เต็มที่ และกำจัดส่วนที่เหลือ ‡
เป้าหมายของพวกเขาคือการสร้างมาตรฐานและลด infrastructure และ configurations ที่ได้รับการสนับสนุนอย่างจงใจ หนึ่งในการตัดสินใจแรกๆ คือการย้ายแพลตฟอร์มทั้งหมดของ Etsy ไปใช้ PHP และ MySQL นี่เป็นการตัดสินใจเชิงปรัชญาเป็นหลักมากกว่าการตัดสินใจทางเทคโนโลยี—พวกเขาต้องการให้ทั้ง Dev และ Ops สามารถเข้าใจ technology stack ทั้งหมด เพื่อให้ทุกคนมีส่วนร่วมในแพลตฟอร์มเดียว และเพื่อให้ทุกคนสามารถอ่าน เขียนใหม่ และแก้ไขโค้ดของกันและกัน
ตลอดหลายปีต่อมา Michael Rembetsy ซึ่งเป็น Director of Operations ของ Etsy ในขณะนั้น เล่าว่า "เราเลิกใช้เทคโนโลยีที่ยอดเยี่ยมบางอย่าง โดยนำพวกมันออกจาก production ทั้งหมด" รวมถึง lighttpd, Postgres, MongoDB, Scala, CoffeeScript, Python และอื่นๆ อีกมากมาย 23
ในทำนองเดียวกัน Dan McKinley นักพัฒนาในทีม feature ที่นำ MongoDB เข้ามาใช้ใน Etsy ในปี 2010 เขียนในบล็อกของเขาว่าประโยชน์ทั้งหมดของการมี database แบบ schema-less ถูกหักล้างด้วยปัญหาด้านการดำเนินงานทั้งหมดที่ทีมต้องแก้ไข ซึ่งรวมถึงปัญหาที่เกี่ยวกับ logging, graphing, monitoring, production telemetry, และการสำรองข้อมูลและกู้คืน รวมถึงปัญหาอื่นๆ อีกมากมายที่นักพัฒนาโดยทั่วไปไม่ต้องกังวล ผลลัพธ์คือการยกเลิก MongoDB และย้าย service ใหม่ไปใช้ MySQL database infrastructure ที่ได้รับการสนับสนุนอยู่แล้ว 24
กรณีศึกษาจาก Etsy นี้แสดงให้เห็นว่า การกำจัด infrastructure และ platform ที่เป็นปัญหาออกไป องค์กรสามารถเปลี่ยนโฟกัสไปที่สถาปัตยกรรมที่สอดคล้องและช่วยให้บรรลุเป้าหมายของตนได้ดีที่สุด
CASE STUDY: NEW TO THE SECOND EDITION (กรณีศึกษา: เพิ่มใหม่ในฉบับพิมพ์ครั้งที่สอง)
Crowdsourcing Technology Governance at Target (2018) (การกำกับดูแลเทคโนโลยีแบบ Crowdsourcing ที่ Target)
หนึ่งในการค้นพบสำคัญจากรายงาน State of DevOps Report คือทีมทำงานได้เร็วขึ้นเมื่อเราไม่ควบคุมวิธีการทำงานและการดำเนินงานของพวกเขา หรือเทคโนโลยีที่พวกเขาใช้ 25 ในอดีต การเลือกเทคโนโลยีเป็นกลไกบังคับใช้เพื่อจำกัดความหลากหลายในองค์กร สิ่งนี้นำไปสู่การปฏิบัติตามที่เห็นได้ชัดในการตอบสนองความต้องการด้านสถาปัตยกรรม ความปลอดภัย และสถาปัตยกรรมทางธุรกิจ แต่ gateways การอนุมัติจากส่วนกลาง และการแยกส่วน ส่งผลให้มี automation น้อยลง จำกัด automation และดำเนิน "กระบวนการและเครื่องมือก่อน" ต่อไป ก่อนผลลัพธ์
แต่ในปี 2015 Target เริ่มโปรแกรมใหม่: recommend_tech ซึ่งใช้ crowdsourcing ในการเลือกเทคโนโลยี มันเริ่มต้นด้วย template พื้นฐานในหน้าเดียวสำหรับเทคโนโลยีทั้งหมดตามโดเมน โดยให้ขอบเขต (local เทียบกับ enterprise) และอายุครึ่งชีวิต (half-life) ที่ผู้เชี่ยวชาญภายในของ Target’s เห็นว่าเหมาะสมกับการจัดวางแต่ละประเภท 26
ระหว่างการนำเสนอในงาน DevOps Enterprise Summit 2018 Dan Cundiff, Principal Engineer, Levi Geinert, Director of Engineering, และ Lucas Rettif, Principal Product Owner อธิบายว่าพวกเขาต้องการเคลื่อนที่เร็วขึ้นโดยเปลี่ยนจากการกำกับดูแล (governance) เป็นการให้คำแนะนำ (guidance) เมื่อพูดถึงเทคโนโลยี: libraries, frameworks, tools ฯลฯ คำแนะนำนี้จะให้แนวทางที่ทีมรู้สึกสบายใจที่จะดำเนินการภายใน ขณะเดียวกันก็ลดความเสียดทานของกระบวนการกำกับดูแลที่เข้มงวด 27
พวกเขาพบว่ากุญแจสำคัญในการให้คำแนะนำแทนการกำกับดูแลคือต้องเข้าถึงได้ (ทุกคนสามารถมีส่วนร่วม), โปร่งใส (ทุกคนควรเห็น), ยืดหยุ่น (เปลี่ยนแปลงง่าย), และเป็นวัฒนธรรม (ขับเคลื่อนโดยชุมชน) ในวิธีที่ง่ายที่สุดเท่าที่จะเป็นไปได้ ท้ายที่สุดแล้ว คำแนะนำควรมีไว้เพื่อเสริมพลังให้วิศวกร ไม่ใช่จำกัดพวกเขา 28
ก่อนหน้านี้ Target มีสิ่งที่พวกเขาเรียกว่า architectural review board (ARB), § ซึ่งเป็นกลุ่มกลางที่ประชุมเป็นประจำเพื่อตัดสินใจเรื่องเครื่องมือสำหรับทุกทีมผลิตภัณฑ์ สิ่งนี้ไม่มีประสิทธิภาพและไม่ได้ผล
เพื่อปรับปรุง Dan Cundiff และเพื่อนร่วมงาน Jason Walker สร้าง repo ใน GitHub ที่มีรายการทางเลือกเทคโนโลยีง่ายๆ: เครื่องมือทำงานร่วมกัน, application frameworks, caching, datastores ฯลฯ พวกเขาตั้งชื่อมันว่า recommended_tech แต่ละเทคโนโลยีถูกระบุเป็น recommended , limited use , หรือ do not use แต่ละไฟล์แสดงว่าเหตุใดเทคโนโลยีนั้นถึงแนะนำหรือไม่, วิธีใช้งาน ฯลฯ นอกจากนี้ ประวัติเต็มที่แสดงว่าการตัดสินใจเกิดขึ้นอย่างไรก็มีอยู่ใน repo 29 บริบทของการตัดสินใจ—และที่สำคัญที่สุด—การติดตามการอภิปราย ให้คำตอบ "ทำไม" มากขึ้นแก่ชุมชนวิศวกรรม ดังที่กล่าวไว้ข้างต้น "อายุครึ่งชีวิต" ของการจัดวางแต่ละประเภทเป็นจุดหมายเชิงทิศทางให้ทีมเข้าใจถึงความเป็นไปได้ของการเปลี่ยนแปลงภายในโดเมน
รายการนี้ไม่ได้ถูกส่งต่อไปยังวิศวกรโดยไม่มีข้อมูลนำเข้า ทุกคนที่ Target สามารถเปิด pull request ในหมวดหมู่เทคโนโลยีใดก็ได้และแนะนำการเปลี่ยนแปลง เทคโนโลยีใหม่ ฯลฯ ทุกคนสามารถแสดงความคิดเห็นและอภิปรายถึงประโยชน์หรือความเสี่ยงต่างๆ ของเทคโนโลยีนั้น และเมื่อมันถูก merge ก็เท่านั้นเอง การเลือกเทคโนโลยีถูกแนะนำอย่างยิ่งและถืออย่างหลวมๆ จนกว่ารูปแบบใหม่จะเกิดขึ้น 30
เนื่องจากการเปลี่ยนแปลงเป็นแบบ local และง่ายสำหรับทีมในการปรับเปลี่ยน การย้อนกลับจึงทำได้ง่ายและมีความยืดหยุ่นสูง ตัวอย่างเช่น การเปลี่ยนจาก Python ไปเป็น Golang สำหรับ API ของผลิตภัณฑ์หนึ่งๆ ถือว่ายืดหยุ่นสูงและย้อนกลับได้ง่าย ในทางกลับกัน การเปลี่ยนผู้ให้บริการ cloud หรือการรื้อถอนศูนย์ข้อมูลนั้นเป็นเรื่องที่ยืดหยุ่นต่ำและมีรัศมีผลกระทบที่กว้างมาก
สำหรับการเปลี่ยนแปลงที่มี "ต้นทุนสูง" CIO จะถูกนำเข้ามาในกระบวนการ วิศวกรคนใดก็ได้สามารถนำเสนอไอเดียของตนตรงต่อ CIO และกลุ่มผู้นำอาวุโส ท้ายที่สุดแล้ว วิธีการ recommend_tech คือการเสริมพลังให้วิศวกรทุกระดับมีความมุ่งมั่นในงานของตนด้วยวิธีที่ง่ายที่สุดเท่าที่จะเป็นไปได้ 31
โซลูชันที่เรียบง่ายนี้แสดงให้เห็นว่าการขจัดอุปสรรคและ bottlenecks สามารถเสริมพลังให้ทีมงาน ในขณะเดียวกันก็ทำให้แน่ใจว่าพวกเขาดำเนินการภายในแนวทางที่ได้รับการอนุมัติ
Conclusion (บทสรุป)
เทคนิคที่อธิบายในบทนี้ทำให้ทุกการเรียนรู้ใหม่ถูกผนวกเข้ากับความรู้ส่วนรวมขององค์กร ทวีคูณผลกระทบของมัน เราทำสิ่งนี้โดยการสื่อสารความรู้ใหม่อย่างแข็งขันและกว้างขวาง ผ่าน chat rooms และเทคโนโลยีเช่น architecture as code, shared source code repositories, การกำหนดมาตรฐานเทคโนโลยี และอื่นๆ การทำเช่นนี้เรายกระดับมาตรฐานการปฏิบัติของไม่เพียงแค่ Dev และ Ops แต่ของทั้งองค์กร เพื่อให้ทุกคนที่ทำงานได้รับประโยชน์จากประสบการณ์สะสมของทั้งองค์กร