มันยากไหมที่จะเข้าใจประเด็นหลักเมื่อพูดถึง DevOps? เราได้รวบรวมการเปรียบเทียบที่ชัดเจน สูตรที่โดดเด่น และคำแนะนำจากผู้เชี่ยวชาญที่จะช่วยให้แม้แต่ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็สามารถเข้าใจประเด็นได้ ในตอนท้าย โบนัสคือ DevOps ของพนักงาน Red Hat
คำว่า DevOps มีต้นกำเนิดเมื่อ 10 ปีที่แล้วและเปลี่ยนจากแฮชแท็ก Twitter ไปสู่การเคลื่อนไหวทางวัฒนธรรมที่ทรงพลังในโลกไอที ซึ่งเป็นปรัชญาที่แท้จริงที่ส่งเสริมให้นักพัฒนาทำสิ่งต่าง ๆ ให้เสร็จเร็วขึ้น ทดลอง และทำซ้ำไปข้างหน้า DevOps มีความเชื่อมโยงกับแนวคิดเรื่องการเปลี่ยนแปลงทางดิจิทัลอย่างแยกไม่ออก แต่บ่อยครั้งที่เกิดขึ้นกับคำศัพท์ด้านไอที ในช่วงสิบปีที่ผ่านมา DevOps ได้รับคำจำกัดความ การตีความ และความเข้าใจผิดมากมายเกี่ยวกับตัวมันเอง
ดังนั้นคุณมักจะได้ยินคำถามเกี่ยวกับ DevOps บ่อยๆ เช่น agile เหมือนกันหรือไม่? หรือนี่เป็นวิธีการพิเศษบางอย่าง? หรือเป็นเพียงคำพ้องความหมายอื่นของคำว่า "ความร่วมมือ"?
DevOps มีแนวคิดที่แตกต่างกันมากมาย (การส่งมอบอย่างต่อเนื่อง การบูรณาการอย่างต่อเนื่อง ระบบอัตโนมัติ ฯลฯ) ดังนั้นการกลั่นกรองสิ่งที่สำคัญอาจเป็นเรื่องที่ท้าทาย โดยเฉพาะอย่างยิ่งเมื่อคุณหลงใหลในเรื่องนี้ อย่างไรก็ตาม ทักษะนี้มีประโยชน์มาก ไม่ว่าคุณจะพยายามถ่ายทอดความคิดของคุณไปยังผู้บังคับบัญชา หรือเพียงบอกคนในครอบครัวหรือเพื่อนของคุณเกี่ยวกับงานของคุณก็ตาม ดังนั้น ให้เราทิ้งความแตกต่างทางคำศัพท์ของ DevOps ไว้ก่อนและมุ่งเน้นไปที่ภาพรวม
DevOps คืออะไร: 6 คำจำกัดความและความคล้ายคลึง
เราขอให้ผู้เชี่ยวชาญอธิบายสาระสำคัญของ DevOps อย่างเรียบง่ายและสั้นที่สุดเท่าที่จะเป็นไปได้ เพื่อให้ผู้อ่านที่มีความรู้ด้านเทคนิคทุกระดับเห็นคุณค่าของสิ่งนี้อย่างชัดเจน จากผลลัพธ์ของการสนทนาเหล่านี้ เราได้เลือกการเปรียบเทียบและสูตรที่โดดเด่นที่สุดซึ่งจะช่วยให้คุณสร้างเรื่องราวเกี่ยวกับ DevOps ได้
1. DevOps คือการเคลื่อนไหวทางวัฒนธรรม
“DevOps เป็นการเคลื่อนไหวทางวัฒนธรรมที่ทั้งสองฝ่าย (นักพัฒนาซอฟต์แวร์และผู้เชี่ยวชาญด้านการดำเนินงานระบบไอที) ตระหนักดีว่าซอฟต์แวร์ไม่ได้ก่อให้เกิดประโยชน์ที่แท้จริงจนกว่าจะมีคนเริ่มใช้งาน: ลูกค้า ลูกค้า พนักงาน ไม่ใช่ประเด็น” Eveline Oehrlich นักวิจัยอาวุโสกล่าว นักวิเคราะห์จากสถาบัน DevOps “ดังนั้น ทั้งสองฝ่ายร่วมกันรับประกันการส่งมอบซอฟต์แวร์ที่รวดเร็วและมีคุณภาพสูง”
2. DevOps เป็นเรื่องเกี่ยวกับการเพิ่มศักยภาพให้กับนักพัฒนา
“DevOps ช่วยให้นักพัฒนาเป็นเจ้าของแอปพลิเคชัน เรียกใช้ และจัดการการส่งมอบตั้งแต่ต้นจนจบ”
“โดยทั่วไปแล้ว DevOps ได้รับการพูดถึงว่าเป็นหนทางในการเร่งการส่งมอบแอปพลิเคชันไปสู่การผลิตโดยการสร้างและใช้กระบวนการอัตโนมัติ” Jai Schniepp ผู้อำนวยการแพลตฟอร์ม DevOps ของบริษัทประกันภัย Liberty Mutual กล่าว “แต่สำหรับฉันมันเป็นเรื่องพื้นฐานมากกว่ามาก” DevOps ช่วยให้นักพัฒนาเป็นเจ้าของแอปพลิเคชันหรือซอฟต์แวร์เฉพาะ เรียกใช้ และจัดการการส่งมอบตั้งแต่ต้นจนจบ DevOps ขจัดความสับสนด้านความรับผิดชอบและแนะนำทุกคนที่เกี่ยวข้องในการสร้างโครงสร้างพื้นฐานที่ขับเคลื่อนโดยนักพัฒนาโดยอัตโนมัติ”
3. DevOps เป็นเรื่องเกี่ยวกับการทำงานร่วมกันในการสร้างและส่งมอบแอปพลิเคชัน
“พูดง่ายๆ ก็คือ DevOps เป็นแนวทางในการผลิตและส่งมอบซอฟต์แวร์ที่ทุกคนทำงานร่วมกัน” Gur Staf ประธานและหัวหน้าฝ่ายระบบธุรกิจดิจิทัลอัตโนมัติของ BMC กล่าว
4. DevOps เป็นไปป์ไลน์
“การประกอบสายพานลำเลียงจะทำได้ก็ต่อเมื่อชิ้นส่วนทั้งหมดประกอบเข้าด้วยกัน”
“ฉันจะเปรียบเทียบ DevOps กับสายการประกอบรถยนต์” Gur Staff กล่าวต่อ – แนวคิดคือการออกแบบและผลิตชิ้นส่วนทั้งหมดล่วงหน้าเพื่อให้สามารถประกอบได้โดยไม่ต้องปรับแต่งทีละชิ้น การประกอบสายพานลำเลียงจะทำได้ก็ต่อเมื่อชิ้นส่วนทั้งหมดประกอบเข้าด้วยกัน ผู้ออกแบบและสร้างเครื่องยนต์ต้องพิจารณาว่าจะติดตั้งเข้ากับตัวถังหรือโครงอย่างไร คนทำเบรกต้องคิดถึงเรื่องล้อและอื่นๆ สิ่งเดียวกันควรเป็นจริงกับซอฟต์แวร์
นักพัฒนาที่สร้างตรรกะทางธุรกิจหรืออินเทอร์เฟซผู้ใช้ต้องคิดถึงฐานข้อมูลที่จัดเก็บข้อมูลลูกค้า มาตรการรักษาความปลอดภัยเพื่อปกป้องข้อมูลผู้ใช้ และวิธีทำงานทั้งหมดนี้เมื่อบริการเริ่มให้บริการแก่ผู้ชมจำนวนมากหรืออาจถึงหลายล้านดอลลาร์ ”
“การให้ผู้คนร่วมมือกันและคิดถึงส่วนของงานที่คนอื่นทำอยู่ แทนที่จะมุ่งความสนใจไปที่งานของตนเองเพียงอย่างเดียวถือเป็นอุปสรรคใหญ่ที่สุดในการเอาชนะ หากคุณสามารถทำเช่นนี้ คุณจะมีโอกาสที่ดีเยี่ยมในการเปลี่ยนแปลงทางดิจิทัล” Gur Staff กล่าวเสริม
5. DevOps คือการผสมผสานที่ลงตัวระหว่างบุคลากร กระบวนการ และระบบอัตโนมัติ
Jayne Groll กรรมการบริหารของ DevOps Institute เสนอการเปรียบเทียบที่ดีในการอธิบาย DevOps ในคำพูดของเธอ “DevOps เปรียบเสมือนสูตรอาหารที่มีส่วนผสมหลักสามประเภท ได้แก่ คน กระบวนการ และระบบอัตโนมัติ ส่วนผสมส่วนใหญ่เหล่านี้สามารถนำมาจากพื้นที่และแหล่งที่มาอื่นๆ: Lean, Agile, SRE, CI/CD, ITIL, ความเป็นผู้นำ, วัฒนธรรม, เครื่องมือ ความลับของ DevOps ก็เหมือนกับสูตรดีๆ อื่นๆ คือการได้สัดส่วนที่เหมาะสมและผสมส่วนผสมเหล่านี้เพื่อเพิ่มความเร็วและประสิทธิภาพในการสร้างและเผยแพร่แอปพลิเคชัน”
6. DevOps เกิดขึ้นเมื่อโปรแกรมเมอร์ทำงานเหมือนทีม Formula 1
“การแข่งขันไม่ได้ถูกวางแผนตั้งแต่ต้นจนจบ แต่ตรงกันข้าม วางแผนตั้งแต่ต้นจนจบ”
“เมื่อฉันพูดถึงสิ่งที่คาดหวังจากโครงการริเริ่ม DevOps ฉันคิดว่าทีมแข่งรถ NASCAR หรือ Formula 1 เป็นตัวอย่าง” Chris Short ผู้จัดการอาวุโสฝ่ายการตลาดแพลตฟอร์มคลาวด์ที่ Red Hat และผู้จัดพิมพ์จดหมายข่าว DevOps'ish กล่าว – ผู้นำของทีมมีเป้าหมายเดียว: ยึดตำแหน่งที่สูงที่สุดเท่าที่จะเป็นไปได้เมื่อสิ้นสุดการแข่งขัน โดยคำนึงถึงทรัพยากรที่มีให้กับทีมและความท้าทายที่เกิดขึ้น ในกรณีนี้ การแข่งขันไม่ได้วางแผนไว้ตั้งแต่ต้นจนจบ แต่ตรงกันข้ามตั้งแต่เส้นชัยจนถึงต้นทาง ประการแรก มีการกำหนดเป้าหมายที่ทะเยอทะยาน จากนั้นจึงกำหนดวิธีที่จะบรรลุเป้าหมาย จากนั้นพวกเขาก็ถูกแบ่งออกเป็นงานย่อยและมอบหมายให้กับสมาชิกในทีม”
“ทีมงานใช้เวลาทั้งสัปดาห์ก่อนการแข่งขันเพื่อหยุดเข้าพิตให้สมบูรณ์แบบ เขาฝึกความแข็งแกร่งและคาร์ดิโอเพื่อรักษารูปร่างให้พร้อมสำหรับวันแข่งขันอันแสนทรหด ฝึกการทำงานร่วมกันเพื่อแก้ไขปัญหาที่อาจเกิดขึ้นระหว่างการแข่งขัน ในทำนองเดียวกันทีมพัฒนาควรฝึกทักษะในการออกเวอร์ชันใหม่บ่อยๆ หากคุณมีทักษะดังกล่าวและระบบรักษาความปลอดภัยที่ใช้งานได้ดี การเปิดตัวเวอร์ชันใหม่สู่การใช้งานจริงก็เกิดขึ้นบ่อยขึ้นเช่นกัน ในโลกทัศน์นี้ ความเร็วที่เพิ่มขึ้นหมายถึงความปลอดภัยที่เพิ่มขึ้น” Short กล่าว
“มันไม่เกี่ยวกับการทำ 'สิ่งที่ถูกต้อง'” ชอร์ตกล่าวเสริม “แต่เป็นการกำจัดสิ่งต่าง ๆ ที่ขัดขวางผลลัพธ์ที่ต้องการให้มากที่สุดเท่าที่จะเป็นไปได้ ทำงานร่วมกันและปรับเปลี่ยนตามคำติชมที่คุณได้รับแบบเรียลไทม์ เตรียมพร้อมสำหรับความผิดปกติและทำงานเพื่อปรับปรุงคุณภาพเพื่อลดผลกระทบต่อความก้าวหน้าไปสู่เป้าหมายของคุณ นี่คือสิ่งที่รอเราอยู่ในโลกแห่ง DevOps”
วิธีปรับขนาด DevOps: 10 เคล็ดลับจากผู้เชี่ยวชาญ
เพียงแต่ว่า DevOps และ DevOps จำนวนมากมีความแตกต่างกันโดยสิ้นเชิง เราจะบอกวิธีเอาชนะอุปสรรคระหว่างทางตั้งแต่ตัวแรกถึงตัวที่สอง
สำหรับหลายๆ องค์กร การเดินทางสู่ DevOps เริ่มต้นอย่างง่ายดายและเป็นสุข ทีมเล็กๆ ที่หลงใหลได้ถูกสร้างขึ้น กระบวนการเก่าจะถูกแทนที่ด้วยทีมใหม่ และความสำเร็จแรกๆ กำลังจะเกิดขึ้นอีกไม่นาน
อนิจจา นี่เป็นเพียงภาพลวงตาลวงตาของความก้าวหน้า Ben Grinnell กรรมการผู้จัดการและหัวหน้าฝ่ายดิจิทัลของบริษัทที่ปรึกษา North Highland กล่าว ชัยชนะในช่วงแรกๆ ถือเป็นกำลังใจอย่างแน่นอน แต่ไม่ได้ช่วยให้บรรลุเป้าหมายสูงสุดของการนำ DevOps ไปใช้ทั่วทั้งองค์กรอย่างกว้างขวาง
เห็นได้ง่ายว่าผลลัพธ์คือวัฒนธรรมแห่งการแบ่งแยกระหว่าง “เรา” และ “พวกเขา”
“บ่อยครั้งที่องค์กรต่างๆ เปิดตัวโครงการบุกเบิกเหล่านี้โดยคิดว่าพวกเขาจะปูทางไปสู่ DevOps กระแสหลัก โดยไม่คำนึงว่าคนอื่นๆ จะสามารถหรือเต็มใจที่จะเดินตามเส้นทางนั้นหรือไม่” Ben Grinnell อธิบาย – ทีมสำหรับการดำเนินโครงการดังกล่าวมักจะได้รับคัดเลือกจาก “Varangians” ที่มีความมั่นใจในตนเอง ซึ่งเคยทำสิ่งที่คล้ายกันในที่อื่นแล้ว แต่ยังใหม่สำหรับองค์กรของคุณ ในขณะเดียวกัน พวกเขาได้รับการสนับสนุนให้ฝ่าฝืนและทำลายกฎเกณฑ์ที่ยังคงผูกมัดต่อคนอื่นๆ เห็นได้ง่ายว่าผลลัพธ์ที่ได้คือวัฒนธรรมของ “เรา” และ “พวกเขา” ที่ขัดขวางการถ่ายทอดความรู้และทักษะ”
“และปัญหาทางวัฒนธรรมนี้เป็นเพียงหนึ่งในเหตุผลที่ทำให้ DevOps ขยายขนาดได้ยาก ทีม DevOps กำลังเผชิญกับความท้าทายทางเทคนิคที่เพิ่มขึ้น ซึ่งเป็นปกติของบริษัทไอทีที่เติบโตอย่างรวดเร็วที่เติบโตอย่างรวดเร็ว” Steve Newman ผู้ก่อตั้งและประธานของ Scalyr กล่าว
“ในโลกยุคใหม่ การบริการเปลี่ยนแปลงทันทีที่มีความต้องการเกิดขึ้น การปรับใช้และปรับใช้ฟีเจอร์ใหม่ๆ อย่างต่อเนื่องถือเป็นเรื่องดี แต่การประสานงานกระบวนการนี้และขจัดปัญหาที่เกิดขึ้นนั้นเป็นเรื่องที่น่าปวดหัวจริงๆ Steve Newman กล่าวเสริม – ในองค์กรที่เติบโตอย่างรวดเร็ว วิศวกรในทีมข้ามสายงานต้องดิ้นรนเพื่อรักษาการมองเห็นการเปลี่ยนแปลงและผลกระทบแบบเรียงซ้อนระดับการพึ่งพาที่มันสร้างขึ้น ยิ่งไปกว่านั้น วิศวกรจะไม่มีความสุขเมื่อพวกเขาถูกลิดรอนโอกาสนี้ และด้วยเหตุนี้ พวกเขาจึงเข้าใจแก่นแท้ของปัญหาที่เกิดขึ้นได้ยากขึ้น”
จะเอาชนะความท้าทายเหล่านี้ที่อธิบายไว้ข้างต้นและก้าวไปสู่การใช้ DevOps จำนวนมากในองค์กรขนาดใหญ่ได้อย่างไร ผู้เชี่ยวชาญเรียกร้องให้มีความอดทน แม้ว่าเป้าหมายสูงสุดของคุณคือการเร่งวงจรการพัฒนาซอฟต์แวร์และกระบวนการทางธุรกิจของคุณให้เร็วขึ้น
1. จำไว้ว่าการเปลี่ยนแปลงวัฒนธรรมต้องใช้เวลา
Jayne Groll กรรมการบริหาร สถาบัน DevOps: “ในความคิดของฉัน การขยายตัวของ DevOps ควรเพิ่มขึ้นและทำซ้ำได้พอๆ กับการพัฒนาแบบ Agile (และคำนึงถึงวัฒนธรรมอย่างเท่าเทียมกัน) Agile และ DevOps เน้นย้ำถึงทีมขนาดเล็ก แต่เมื่อทีมเหล่านี้มีจำนวนเพิ่มมากขึ้นและการบูรณาการกัน เราก็มีคนจำนวนมากขึ้นที่นำแนวทางการทำงานใหม่ๆ มาใช้ และผลที่ตามมาก็คือการเปลี่ยนแปลงทางวัฒนธรรมครั้งใหญ่”
2. ใช้เวลาในการวางแผนและเลือกแพลตฟอร์มให้เพียงพอ
Eran Kinsbruner หัวหน้าผู้เผยแพร่ศาสนาด้านเทคนิคของ Perfecto: “เพื่อให้สามารถปรับขนาดได้ ทีม DevOps จะต้องเรียนรู้ที่จะผสมผสานกระบวนการ เครื่องมือ และทักษะแบบดั้งเดิม จากนั้นค่อย ๆ ดูแลและทำให้ DevOps แต่ละขั้นตอนมีความเสถียร ทุกอย่างเริ่มต้นด้วยการวางแผนอย่างรอบคอบเกี่ยวกับเรื่องราวของผู้ใช้และกระแสคุณค่า ตามด้วยการเขียนซอฟต์แวร์และการควบคุมเวอร์ชันโดยใช้การพัฒนาแบบ Trunk หรือวิธีการอื่นๆ ที่เหมาะสมที่สุดสำหรับการแตกแขนงและการรวมโค้ด”
“จากนั้นก็มาถึงขั้นตอนการบูรณาการและการทดสอบ ซึ่งจำเป็นต้องมีแพลตฟอร์มที่ปรับขนาดได้สำหรับระบบอัตโนมัติอยู่แล้ว นี่คือจุดสำคัญสำหรับทีม DevOps ในการเลือกแพลตฟอร์มที่เหมาะสมที่เหมาะสมกับระดับทักษะและเป้าหมายสุดท้ายของโครงการ
ระยะต่อไปคือการปรับใช้กับการผลิต และควรดำเนินการอัตโนมัติเต็มรูปแบบโดยใช้เครื่องมือและคอนเทนเนอร์ในการเตรียมการ สิ่งสำคัญคือต้องมีสภาพแวดล้อมเสมือนจริงในทุกขั้นตอนของ DevOps (โปรแกรมจำลองการผลิต สภาพแวดล้อม QA และสภาพแวดล้อมการผลิตจริง) และใช้เฉพาะข้อมูลล่าสุดสำหรับการทดสอบเพื่อให้ได้ข้อสรุปที่เกี่ยวข้องเสมอ การวิเคราะห์จะต้องชาญฉลาดและสามารถประมวลผลข้อมูลขนาดใหญ่พร้อมข้อเสนอแนะที่รวดเร็วและดำเนินการได้”
3. นำความผิดออกจากความรับผิดชอบ
กอร์ดอน ฮาฟฟ์ ผู้เผยแพร่ศาสนา RedHat: “การสร้างระบบและบรรยากาศที่เอื้ออำนวยและสนับสนุนการทดลองทำให้เกิดสิ่งที่เรียกว่าความล้มเหลวที่ประสบความสำเร็จในการพัฒนาซอฟต์แวร์แบบคล่องตัว นี่ไม่ได้หมายความว่าไม่มีใครรับผิดชอบต่อความล้มเหลว ในความเป็นจริง การระบุผู้ที่รับผิดชอบจะง่ายยิ่งขึ้น เนื่องจาก “การมีความรับผิดชอบ” ไม่ได้หมายความว่า “ก่อให้เกิดอุบัติเหตุ” อีกต่อไป นั่นคือสาระสำคัญของความรับผิดชอบเปลี่ยนแปลงไปในเชิงคุณภาพ ปัจจัยสี่ประการที่มีความสำคัญ ได้แก่ ขอบเขตของการหยุดชะงัก แนวทาง กระบวนการผลิต และสิ่งจูงใจ” (คุณสามารถอ่านเพิ่มเติมเกี่ยวกับปัจจัยเหล่านี้ได้ในบทความของ Gordon Huff เรื่อง “บทเรียน DevOps: การทดลองที่เป็นประโยชน์ 4 ด้าน”)
4. เคลียร์เส้นทางข้างหน้า
Ben Grinnell กรรมการผู้จัดการและหัวหน้าฝ่ายดิจิทัลที่ที่ปรึกษา North Highland: “เพื่อให้บรรลุเป้าหมาย ผมขอแนะนำให้เปิดตัวโปรแกรม “การเคลียร์เส้นทาง” ร่วมกับโครงการบุกเบิก เป้าหมายของโครงการนี้คือการทำความสะอาดขยะที่ผู้บุกเบิก DevOps ทิ้งไว้ เช่น กฎที่ล้าสมัยและสิ่งต่างๆ เช่นนั้น เพื่อให้เส้นทางข้างหน้ายังคงชัดเจน”
“ให้การสนับสนุนและแรงผลักดันแก่องค์กรแก่ผู้คนผ่านการสื่อสารที่เหนือกว่ากลุ่มบุกเบิกโดยการเฉลิมฉลองความสำเร็จของวิธีการทำงานใหม่อย่างกว้างขวาง ฝึกสอนผู้ที่มีส่วนร่วมในโครงการ DevOps คลื่นลูกถัดไป และกังวลเกี่ยวกับการใช้ DevOps เป็นครั้งแรก และจำไว้ว่าคนเหล่านี้แตกต่างจากผู้บุกเบิกมาก”
5. เครื่องมือที่เป็นประชาธิปไตย
Steve Newman ผู้ก่อตั้งและประธาน Scalyr: “เครื่องมือไม่ควรถูกซ่อนไม่ให้คนอื่นเห็น และเครื่องมือเหล่านั้นควรเรียนรู้ได้ง่ายสำหรับทุกคนที่ยินดีสละเวลา หากความสามารถในการสืบค้นบันทึกถูกจำกัดไว้เพียงสามคนที่ "ได้รับการรับรอง" เพื่อใช้เครื่องมือ คุณจะมีคนสูงสุดสามคนที่พร้อมสำหรับจัดการกับปัญหาเสมอ แม้ว่าคุณจะมีสภาพแวดล้อมการประมวลผลขนาดใหญ่มากก็ตาม กล่าวอีกนัยหนึ่ง มีปัญหาคอขวดที่นี่ซึ่งอาจนำไปสู่ผลลัพธ์ที่ร้ายแรง (ทางธุรกิจ)”
6. สร้างเงื่อนไขที่เหมาะสมสำหรับการทำงานเป็นทีม
Tom Clark หัวหน้าฝ่าย Common Platform ที่ ITV: “คุณสามารถทำอะไรก็ได้ แต่ไม่ใช่ทุกอย่างในคราวเดียว ดังนั้นให้ตั้งเป้าหมายที่ยิ่งใหญ่ เริ่มต้นจากจุดเล็กๆ และก้าวไปข้างหน้าอย่างรวดเร็ว เมื่อเวลาผ่านไป คุณจะมีชื่อเสียงในการทำสิ่งต่างๆ ให้สำเร็จ ดังนั้นคนอื่นๆ ก็จะอยากใช้วิธีการของคุณเช่นกัน และไม่ต้องกังวลกับการสร้างทีมที่มีประสิทธิภาพสูง แต่ควรจัดเตรียมสภาพการทำงานที่เหมาะสมและมีประสิทธิภาพให้กับผู้คนแทน”
7. อย่าลืมเกี่ยวกับกฎของคอนเวย์และกระดานคัมบัง
Logan Daigle ผู้อำนวยการฝ่ายจัดส่งซอฟต์แวร์และกลยุทธ์ DevOps ที่ CollabNetVersionOne: “สิ่งสำคัญคือต้องเข้าใจผลที่ตามมาของกฎของคอนเวย์ ในการถอดความแบบหลวม ๆ ของฉัน กฎหมายนี้ระบุว่าผลิตภัณฑ์ที่เราสร้างและกระบวนการที่เราใช้ในการทำเช่นนั้น รวมถึง DevOps กลายเป็นโครงสร้างในลักษณะเดียวกับองค์กรของเรา”
“หากมีการไซโลจำนวนมากในองค์กร และการควบคุมมีการเปลี่ยนแปลงหลายครั้งเมื่อวางแผน สร้าง และปล่อยซอฟต์แวร์ ผลกระทบของการปรับขยายจะเป็นศูนย์หรือเกิดขึ้นไม่นาน หากองค์กรสร้างทีมงานข้ามสายงานเกี่ยวกับผลิตภัณฑ์ที่ได้รับทุนสนับสนุนจากตลาด โอกาสแห่งความสำเร็จก็จะเพิ่มขึ้นอย่างมาก”
“สิ่งสำคัญอีกประการหนึ่งของการขยายขนาดคือการแสดงงานที่กำลังดำเนินการทั้งหมด (WIP, งานระหว่างดำเนินการ) บนกระดานคัมบัง เมื่อองค์กรมีสถานที่ที่ผู้คนสามารถเห็นสิ่งเหล่านี้ได้ จะส่งเสริมการทำงานร่วมกันอย่างมาก ซึ่งมีผลกระทบเชิงบวกต่อการปรับขนาด”
8. มองหารอยแผลเป็นเก่า
Manuel Pais ที่ปรึกษา DevOps และผู้ร่วมเขียน Team Topologies: “การใช้แนวทางปฏิบัติ DevOps นอกเหนือจาก Dev และ Ops และการพยายามนำไปใช้กับฟังก์ชันอื่นๆ แทบจะไม่ใช่แนวทางที่ดีที่สุด สิ่งนี้จะมีผลกระทบบางอย่างอย่างแน่นอน (เช่น โดยการควบคุมด้วยตนเองโดยอัตโนมัติ) แต่จะบรรลุผลสำเร็จได้อีกมากหากเราเริ่มต้นด้วยการทำความเข้าใจกระบวนการจัดส่งและข้อเสนอแนะ”
“หากมีรอยแผลเป็นเก่าในระบบไอทีขององค์กร - ขั้นตอนและกลไกการจัดการที่ดำเนินการอันเป็นผลมาจากเหตุการณ์ในอดีต แต่สูญเสียความเกี่ยวข้อง (เนื่องจากการเปลี่ยนแปลงในผลิตภัณฑ์ เทคโนโลยี หรือกระบวนการ) - สิ่งเหล่านี้จำเป็นต้องถูกลบออกอย่างแน่นอน หรือทำให้ราบรื่น แทนที่จะทำให้กระบวนการที่ไม่มีประสิทธิภาพหรือไม่จำเป็นเป็นอัตโนมัติ”
9. อย่าผสมพันธุ์ตัวเลือก DevOps
Anthony Edwards ผู้อำนวยการฝ่ายปฏิบัติการของ Eggplant: “DevOps เป็นคำที่คลุมเครือมาก ดังนั้นแต่ละทีมจึงลงเอยด้วย DevOps เวอร์ชันของตัวเอง และไม่มีอะไรจะเลวร้ายไปกว่านั้นเมื่อองค์กรมี DevOps กว่า 20 แบบที่เข้ากันไม่ได้ดีนัก เป็นไปไม่ได้ที่ทีมพัฒนาทั้งสามทีมจะมีส่วนต่อประสานพิเศษระหว่างการพัฒนาและการจัดการผลิตภัณฑ์เป็นของตัวเอง ผลิตภัณฑ์ไม่ควรมีความคาดหวังเฉพาะของตนเองในการจัดการผลตอบรับเมื่อถ่ายโอนไปยังเครื่องจำลองการผลิต มิฉะนั้นคุณจะไม่สามารถปรับขนาด DevOps ได้”
10. เผยแพร่คุณค่าทางธุรกิจของ DevOps
Steve Newman ผู้ก่อตั้งและประธาน Scalyr: “ทำงานเพื่อรับรู้ถึงคุณค่าของ DevOps เรียนรู้และอย่าลังเลที่จะพูดคุยเกี่ยวกับประโยชน์ของสิ่งที่คุณทำ DevOps เป็นตัวช่วยประหยัดเวลาและเงินได้อย่างเหลือเชื่อ (แค่คิดว่า: หยุดทำงานน้อยลง, ใช้เวลาเฉลี่ยในการกู้คืนสั้นลง) และทีม DevOps จะต้องเน้น (และสั่งสอน) อย่างไม่รู้จักเหน็ดเหนื่อยถึงความสำคัญของความคิดริเริ่มเหล่านี้ต่อความสำเร็จทางธุรกิจ ด้วยวิธีนี้คุณสามารถขยายวงกว้างของผู้สมัครพรรคพวกและเพิ่มอิทธิพลของ DevOps ในองค์กรได้”
โบนัส
На DevOps ของเราจะมาถึงในวันที่ 13 กันยายน ใช่แล้ว Red Hat ในฐานะผู้ผลิตซอฟต์แวร์ มีทีม DevOps และแนวปฏิบัติเป็นของตัวเอง
Mark Birger วิศวกรของเราผู้พัฒนาบริการอัตโนมัติภายในสำหรับกลุ่มอื่นๆ ทั่วทั้งองค์กร จะบอกเล่าเรื่องราวของเขาเองเป็นภาษารัสเซียล้วนๆ - วิธีที่ทีม Red Hat DevOps ย้ายแอปพลิเคชันจากสภาพแวดล้อมเสมือน Hat Virtualization ที่จัดการโดย Ansible ไปเป็นรูปแบบคอนเทนเนอร์เต็มรูปแบบบน แพลตฟอร์ม OpenShift
แต่นั่นไม่ใช่ทั้งหมด:
เมื่อองค์กรย้ายปริมาณงานไปยังคอนเทนเนอร์แล้ว วิธีการตรวจสอบแอปพลิเคชันแบบเดิมอาจไม่ทำงาน ในการพูดคุยครั้งที่สอง เราจะอธิบายแรงจูงใจในการเปลี่ยนแปลงวิธีการบันทึกและแสดงให้เห็นถึงความต่อเนื่องของเส้นทางที่นำเราไปสู่วิธีการตัดไม้และการตรวจสอบที่ทันสมัย
ที่มา: will.com