Bridging Gaps: ความสำคัญของการสื่อสาร DevOps

แม้ว่าวิธีการ DevOps จะอยู่กับเรามาระยะหนึ่งแล้ว แต่ก็ยังเป็นศูนย์กลางของการอภิปรายที่ร้อนแรง บริษัทต่างๆ ต้องการ แต่ไม่แน่ใจว่าจะเข้าถึงได้อย่างไร

DevOps มีอยู่ทุกที่ และถึงแม้จะเป็นเทรนด์ที่น่าสนใจ แต่ก็ควรเข้ากับผลิตภัณฑ์ ไม่ใช่ในทางกลับกัน

แต่บางคนกลับมองไม่เห็นอย่างนั้น ฉันมักถูกถามคำถามเช่น "คุณคิดว่าเราควรเริ่มใช้ Docker หรือกระโดดเข้าสู่ Kubernetes ทันที" คำถามดังกล่าวไม่มีความหมายโดยไม่ได้รู้ว่าผลิตภัณฑ์นั้นเกี่ยวกับอะไร

คำศัพท์แฟนซีเหล่านั้น—คลาวด์, Kubernetes, คอนเทนเนอร์, การจัดการการกำหนดค่า, โครงสร้างพื้นฐานตามรหัส—สัญญาการปรับปรุงบางอย่าง แต่พวกเขามีไว้สำหรับ DevOps เช่นเดียวกับกล้องโทรทรรศน์กับดาราศาสตร์ อาจมีประโยชน์ แต่ไม่จำเป็น

ที่แกนหลัก DevOps ตั้งเป้าที่จะปิดช่องว่างระหว่างสิ่งที่ลูกค้าสั่งกับสิ่งที่ทีมพัฒนามอบให้ มีการเน้นย้ำที่วงจรการเปิดตัวสั้นๆ แนวทางการออกแบบซ้ำๆ และระบบอัตโนมัติของขั้นตอนที่ซ้ำๆ คุณคิดว่าอะไรสำคัญที่สุดในการทำให้สิ่งเหล่านี้เป็นจริง

ถ้าคุณพูดว่า "การสื่อสารที่ดี" คุณพูดถูก เครื่องมือทุกอย่างเรียบร้อยดี แต่จะคุ้มกับเงินที่ลงทุนไปเมื่อปรับปรุงการสื่อสารเท่านั้น

แง่มุมหนึ่งของการสื่อสารคือการรู้ว่าอะไรจำเป็นเพื่อให้งานสำเร็จลุล่วง และงานไม่ได้หมายความว่า "รหัสถูกผูกมัดกับที่เก็บ" คิดซะว่า “ลูกค้าเห็นการเปลี่ยนแปลงในการผลิตและยอมรับมัน”

ทันทีที่มีการกำหนดขั้นตอนแรกนี้ และทุกคนรู้ว่าต้องเกิดอะไรขึ้น นั่นคือเวลาที่ดีที่สุดที่จะจดบันทึกไว้ ที่ไหน? ฉันเป็นผู้สนับสนุนรายใหญ่ในการรักษา README.md แต่ละคนในทีมสามารถมองเข้าไปข้างในและรู้สถานะของโปรเจ็กต์ได้เสมอ และนี่เป็นเรื่องปกติสำหรับผู้ที่มาใหม่ในโครงการ

การทำงานอัตโนมัติ ขั้นตอนต่อไปหลังจากเขียน README เป็นทางเลือก แม้ว่าจะเป็นผลพลอยได้ตามธรรมชาติของการบันทึกกระบวนการ และใช่ ระบบอัตโนมัติคือสิ่งที่มักจะนึกถึงเมื่อคิดถึง DevOps

รอสักครู่…ระบบอัตโนมัติเป็นทางเลือกเมื่อพูดถึง DevOps? DevOps เป็นแผนกของบุคคลที่ทำการปรับใช้ไม่ใช่หรือ

สิ่งที่ผู้คนมักเข้าใจภายใต้คำว่า "วิศวกร DevOps" คือวิศวกรความน่าเชื่อถือของซอฟต์แวร์ วิศวกรแพลตฟอร์ม หรือวิศวกรระบบอัตโนมัติในการปฏิบัติงาน สิ่งเหล่านี้ล้วนเป็นบทบาทที่ถูกต้องที่ช่วยให้ฝึก DevOps ได้ แต่การใช้คำว่า "วิศวกร DevOps" ร่วมกันอาจมีความคลุมเครือเล็กน้อย

ลองมาดูที่ DevOps กันดีกว่า

คำอธิบาย DevOps

ก่อนอื่น ให้ฉันแสดงให้คุณเห็นว่า DevOps ไม่ใช่อะไร:

1. ไม่ใช่แค่คำนำหน้าตำแหน่งงาน
2. ไม่ใช่ทีม (แต่ "Dev" และ "Ops")
3. ไม่ใช่เทคโนโลยี
4. ไม่ได้หมายความว่า “ผู้ดูแลระบบที่เขียนโค้ดได้”
5. ไม่ได้หมายถึง "ระบบอัตโนมัติ"
6. ไม่ได้หมายความว่า “ตอนนี้ไม่มีทีมปฏิบัติการ”

เมื่อทราบสิ่งนี้ ตอนนี้คุณก็ทราบแล้วว่าคุณไม่สามารถ "จ้างวิศวกร DevOps" หรือ "สร้างทีม DevOps" ในบริษัทได้ง่ายๆ เพื่อให้แน่ใจว่าคุณจะพร้อมสำหรับอนาคต DevOps นั้นคล้ายกับการพัฒนาแบบ Agile คุณจะจ้างนักพัฒนา Agile เช่นนี้ หรือไม่? อาจจะไม่. ไม่ว่าคุณจะพัฒนาผลิตภัณฑ์ในแบบ Agile หรือไม่ก็ตาม

แล้วจะอธิบาย DevOps ได้อย่างไร? มันเป็นวิธีการ หรืออาจจะเป็นวัฒนธรรม บางทีแม้แต่วิญญาณ การทำผลิตภัณฑ์ตามหลักการ DevOps หมายความว่าทุกคน ไม่ว่าจะเป็นนักพัฒนา วิศวกรฝ่ายปฏิบัติการ หรือผู้จัดการผลิตภัณฑ์ ต่างก็มีวิสัยทัศน์ร่วมกัน ดูแลรักษาผ่านการสื่อสาร ในระดับที่น้อยกว่าก็หมายความว่าทุกคนใช้เครื่องมือเดียวกัน เครื่องมือเหล่านี้ไม่ได้มีไว้สำหรับช่วยเหลือคนกลุ่มใดกลุ่มหนึ่ง มีไว้เพื่อผลักดันผลิตภัณฑ์ไปข้างหน้า

การดำเนินตามแนวคิดนี้จำเป็นต้องเปลี่ยนความคิดอย่างจริงจัง ซึ่งเป็นอุปสรรคสำคัญ ทำไมถึงเป็นอย่างนั้น? เป็นเพราะผู้คนต้องก้าวออกจากเขตสบายและเริ่มร่วมมือกับผู้คนที่มีความสามารถต่างกัน จู่ๆ นักพัฒนาก็ต้องเรียนรู้วิธีการทำงานของระบบคลาวด์และเริ่มปรับใช้โค้ดของตนเอง เจ้าหน้าที่ปฏิบัติการต้องละทิ้งการตั้งค่าด้วยตนเองและเริ่มเขียนโค้ด ทุกคนต้องเรียนรู้แนวคิดใหม่ ทุกคนมี หน้าที่ใหม่

ไม่ใช่เรื่องง่าย แต่ด้วยการสื่อสารที่ดีและมีเป้าหมายร่วมกัน เป็นเรื่องที่ทำได้ค่อนข้างมาก การสื่อสารนี้เกี่ยวข้องกับการสร้างวัฒนธรรม การตั้งค่ากระบวนการที่ไม่ซับซ้อน และการดูแลรักษาเอกสารที่เหมาะสม

DevOps Automation เป็นเอกสารประกอบ

คุณคงไม่เคยคิดแบบนั้น แต่เครื่องมือส่วนใหญ่ที่เกี่ยวข้องกับ DevOps คือ เครื่องมือเอกสาร :

• สคริปต์บิลด์ที่เขียนขึ้นเพื่อให้สามารถอ่านได้ เพื่อบันทึกกระบวนการบิลด์
• ไปป์ไลน์การรวมอย่างต่อเนื่อง บันทึกกระบวนการรวมจากการสร้างชิ้นส่วนเดียวไปจนถึงผลิตภัณฑ์ทั้งหมด
• ไปป์ไลน์การปรับใช้อย่างต่อเนื่องดำเนิน ต่อไปโดยจัดทำเอกสารวิธีการปรับใช้ผลิตภัณฑ์ที่ลูกค้าของคุณสามารถใช้ได้
• ไฟล์การจัดการการกำหนดค่า บันทึกขั้นตอนการติดตั้งและการกำหนดค่า
• ข้อมูลจำเพาะของ Infrastructure-as-code จะบันทึกโครงสร้างพื้นฐานที่จำเป็น (ที่จริงแล้วค่อนข้างเป็นทางการ!)
• คอนเทนเนอร์มาพร้อมกับ Dockerfile ของตัวเอง ซึ่งบันทึกวิธีสร้างและกำหนดค่าไมโครเซอร์วิสที่กำหนด

แนวคิดแฟนซีเหล่านี้ทำสิ่งหนึ่งโดยพื้นฐานแล้ว: ช่วยให้สมาชิกในทีมสื่อสารได้ดีขึ้นด้วยการบันทึกกระบวนการ กระบวนการเหล่านี้สามารถเรียกใช้ด้วยตนเองหรือแบบอัตโนมัติได้ สิ่งสำคัญคือผู้มีส่วนได้ส่วนเสียในโครงการทุกคนสามารถติดตามพวกเขาได้

การบันทึกกระบวนการของคุณเป็นโค้ดมีข้อดีเหนือกว่าคู่มือการใช้งานทั่วไป รหัสสามารถตรวจสอบและทำงานคาดการณ์ได้ ให้อินพุตเดียวกัน ให้เอาต์พุตเหมือนกัน

ด้วยคำแนะนำที่เป็นลายลักษณ์อักษร คุณจะตีความได้มากเท่ากับจำนวนผู้อ่าน หากคุณเขียนเอกสารที่คลุมเครือหรือคลุมเครือ คนที่อ่านจะกรอกข้อมูลในช่องว่าง ประเด็นคือ คุณไม่สามารถควบคุมสิ่งที่เข้าไปในช่องว่างได้

มันง่ายกว่ามากด้วยรหัส หากไม่มีขั้นตอนที่เป็นรูปธรรม โปรแกรมจะหยุดทำงาน ขั้นตอนที่เป็นรูปธรรมเหล่านี้เป็นส่วนสำคัญของการสื่อสาร DevOps

การสื่อสาร DevOps: วิธีเดียวที่จะเชื่อมช่องว่างระหว่างการพัฒนาและการปฏิบัติการ

ในหนังสือ The Phoenix Project เราพบเห็นปัญหาของผู้จัดการที่เพิ่งเลื่อนตำแหน่งซึ่งได้รับมอบหมายให้ปรับใช้โครงการขนาดใหญ่ เนื่องจากไม่มีใครรู้ว่าเกิดอะไรขึ้น ทุกคนกำลังต่อสู้กับไฟโดยไม่มีความคืบหน้ามากนัก คำบรรยายหนังสือระบุว่าเป็นเรื่องราวของ DevOps ฉันเห็นด้วยกับที่

แต่สิ่งที่น่าสนใจคือตลอดทั้งเล่ม ไม่มีเครื่องมือใหม่แนะนำเลย คุณสามารถบรรลุสถานะของ DevOps โดยการปรับปรุงการสื่อสารเพียงอย่างเดียวได้หรือไม่ ตัวเอกของเล่มนี้ทำได้ คุณเองก็มีหวังเช่นกัน!

แม้ว่าแนวทางของตัวเอกอาจถือเป็น "โรงเรียนเก่า" (โดยใช้การ์ดกระดาษจริงแทนระบบติดตามแมลงที่เหมาะสม) สิ่งต่างๆ เริ่มเปลี่ยนไปในทางที่ดีขึ้นเมื่อทุกฝ่ายที่เกี่ยวข้องเริ่มพูดคุยกัน

คุณอาจคิดว่าเป็นไปได้เท่านั้นที่จะปรับปรุงการทำงานร่วมกันระหว่างการพัฒนาและการปฏิบัติการโดยการสร้างส่วนต่อประสานที่ดีขึ้นระหว่างกัน เช่น ข้อตกลงระดับบริการหรืองานในมือของเหตุการณ์ แต่สิ่งที่ตรงกันข้ามคือความจริง โดยการทำลายอินเทอร์เฟซและการแนะนำความเห็นอกเห็นใจและสาเหตุทั่วไป คุณจะมีทีมที่ทำงานเพื่อเป้าหมายร่วมกัน

โครงสร้างทีม DevOps: ใครอยู่ในทีม?

ตามหลักการแล้วแต่ละผลิตภัณฑ์ควรมีเพียงหนึ่งทีมเท่านั้น นั่นคือทีมผลิตภัณฑ์

ครั้งหนึ่งฉันเคยอยู่ในทีมพัฒนาที่ไม่มีเป้าหมายร่วมกันกับทีมอื่น ทีมพัฒนาต้องการผลักดันการเปลี่ยนแปลงให้มากที่สุด ทีมตรวจสอบความถูกต้องได้รับมอบหมายให้ป้องกันไม่ให้เกิดข้อบกพร่อง พวกเขามีผู้จัดการที่แตกต่างกันและได้รับการประเมินเป็นรายบุคคล

ผลลัพธ์? การพัฒนาและการตรวจสอบการเล่นปิงปองพร้อมรายงานข้อบกพร่อง เมื่อการตรวจสอบความถูกต้องพบการทดสอบที่ไม่ผ่าน การพัฒนาสนใจที่จะค้นหาข้อบกพร่องในโค้ดทดสอบเองมากกว่าพยายามทำให้โค้ดของตนเองปราศจากข้อบกพร่อง

รอบการเปิดตัวพุ่งขึ้นแน่นอน เนื่องจากมีค่าใช้จ่ายมหาศาลในการกรอกรายงาน รายงานโต้แย้ง และอื่นๆ อย่างเหมาะสม สิ่งที่ดูเหมือนจะไม่เป็นที่รู้จักมากที่สุดคือในแง่ของผลิตภัณฑ์ ทั้งสองทีมควรมีเป้าหมายร่วมกันและทำงานร่วมกันเพื่อให้บรรลุเป้าหมาย แต่การขาดความร่วมมือที่เหมาะสมและความคิดแบบไซโลทำให้สังเกตได้ยาก

การต่อสู้กับขยะเป็นความพยายามร่วมกัน

แนวคิดในการผลิตแบบลีนซึ่งเป็นแรงบันดาลใจให้ The Manifesto สำหรับการพัฒนาซอฟต์แวร์แบบ Agile (ซึ่งแนะนำเราให้รู้จักกับ DevOps) นั้นเกี่ยวกับการต่อสู้กับการสูญเสีย เปล่าประโยชน์ เราหมายถึงทุกอย่างที่ไม่เกี่ยวข้องโดยตรงกับสิ่งที่ลูกค้าสั่ง งานระหว่างทำที่ซ้อนกันเป็นขยะ ทุกขั้นตอนของกระบวนการที่ไม่ได้นำไปสู่การปลดปล่อยอย่างชัดเจนเป็นการสูญเปล่า

แต่จะเห็นขยะในระดับสูงเท่านั้น ในขอบเขตของทีมหนึ่ง ขั้นตอนบางอย่างอาจดูเหมือนจำเป็น แม้ว่าจากมุมมองของผลิตภัณฑ์ มันอาจจะไร้ประโยชน์

หากต้องการทราบว่าความพยายามใดที่สูญเปล่า คุณต้องร่วมมือกันและพิจารณาวงจรชีวิตของผลิตภัณฑ์ที่จัดส่ง คุณต้องคิดจากมุมมองของลูกค้าด้วย คุณลักษณะนี้เป็นสิ่งที่ลูกค้าต้องการหรือไม่? ถ้าไม่คุณสามารถข้ามได้ในขณะนี้ กระบวนการของคุณเรียบง่ายและคล่องตัวหรือไม่? พิจารณาให้ลึกซึ้งยิ่งขึ้นโดยเฉพาะผู้ที่ข้ามเขตแดนของทีม

คุณต้องการให้แน่ใจว่าการพัฒนาผลิตภัณฑ์มีประสิทธิภาพเท่าที่ควรหรือไม่? เชิญบุคคลภายนอกมาดูว่าคุณทำงานอย่างไร บุคคลที่ไม่ได้เป็นส่วนหนึ่งของทีมของคุณจะสามารถถามคำถามเชิงลึกและหาจุดที่ต้องปรับปรุงใหม่ได้

หลักการ DevOps: รักษาความสงบของคุณ

CALMS เป็นคำอธิบายที่แม่นยำมากว่าควรฝึก DevOps อย่างไร:

• C วัฒนธรรม
• ระบบ อัตโนมัติ
• เหลียน
• การวัด M
• S haring

สังเกตว่ามันมีรูปร่างเหมือนแซนวิช ค่ากลางสามค่านั้นเป็นเทคนิคมากกว่า ในขณะที่ค่าภายนอกเกี่ยวข้องกับทักษะที่อ่อนนุ่ม แต่พื้นฐานของทุกวัฒนธรรมคือการสื่อสาร เราแลกเปลี่ยนค่านิยมและความเชื่อของเรากับสมาชิกในทีมคนอื่นๆ จนกว่าเราจะบรรลุข้อตกลงร่วมกันว่าสิ่งต่างๆ ควรประพฤติอย่างไร

เช่นเดียวกับการแบ่งปัน การแบ่งปันสิ่งพื้นฐานเช่นอาหารไม่จำเป็นต้องมีการสื่อสาร อย่างไรก็ตาม ท่าทางนั้นสามารถมองได้ว่าเป็นการสื่อสาร “ฉันห่วงใยคุณ ดังนั้นฉันจึงแบ่งปันกับคุณ” เราไม่ต้องการที่จะจำกัดขอบเขตของการสื่อสารด้วยวาจาเท่านั้น

การแบ่งปันแนวคิดและเครื่องมือต้องมีการสื่อสาร เราควรแบ่งปันอย่างไร? เราจะวางพวกเขาไว้ที่ไหน? มีประโยชน์สำหรับทุกคนในทีมหรือสำหรับกลุ่มเล็ก ๆ หรือไม่?

หากคุณมุ่งเน้นเฉพาะด้านเทคนิคมากขึ้น เช่น ระบบอัตโนมัติ แบบลีน และการวัด แสดงว่าคุณพลาดจุดสำคัญของ DevOps การมีสคริปต์การปรับใช้อัตโนมัติที่ไม่มีใครใช้ข้างผู้เขียนจะดีอย่างไร หากสคริปต์ช่วยเธอประหยัดเวลาก็อาจมีเหตุผล แต่ลองนึกดูว่าจะช่วยประหยัดเวลาได้มากแค่ไหนหากทุกคนแชร์สคริปต์นี้ นี้บอกอะไรบางอย่างเกี่ยวกับการต่อสู้กับขยะ!

DevOps ทำให้ธุรกิจใกล้ชิดกับการพัฒนามากขึ้น

บางคนกล่าวว่า DevOps นำการดำเนินงานมาใกล้การพัฒนามากขึ้น นี่เป็นความจริง แต่ก็ไม่ใช่ความจริงทั้งหมด เมื่อทำถูกต้อง DevOps จะทำให้ทุกหน่วยใกล้ชิดกันมากขึ้น ช่วยให้ธุรกิจและลูกค้าเห็นสิ่งที่กำลังดำเนินการอยู่ เกือบจะเป็นแบบเรียลไทม์

วงข้อเสนอแนะที่สั้นลงนี้เป็นประโยชน์ต่อผู้มีส่วนได้ส่วนเสียทั้งหมด โดยทั่วไปงานจะมองเห็นได้ชัดเจนขึ้น และนักพัฒนาก็สามารถเห็นได้ง่ายว่าลูกค้าใช้โค้ดที่พวกเขาสร้างขึ้นอย่างไร ด้วยการปรับใช้แบบดั้งเดิม คุณสามารถรอหลายเดือนก่อนที่จะมีคนสังเกตเห็นจุดบกพร่องหรือข้อกำหนดที่ไม่ได้รับ ด้วยการปรับใช้อย่างต่อเนื่อง ทุกคนสามารถตอบสนองต่อปัญหาที่เกิดขึ้นได้ นักพัฒนา ฝ่ายปฏิบัติการ ธุรกิจ และลูกค้าสามารถนั่งในห้องเดียวกันและปรับเปลี่ยนแอปพลิเคชันการทำงานได้ตามความต้องการในปัจจุบัน

เครื่องมือ DevOps ก่อน? คิดใหม่อีกครั้ง

แน่นอนว่าจำเป็นต้องมีเครื่องมือทั้งหมดเพื่อให้เป็นไปได้

แต่ไม่มีเครื่องมือใดที่สามารถทดแทนการสื่อสารที่ดีและความเห็นอกเห็นใจภายในบริษัทได้ ครั้งหนึ่งฉันเคยสังเกตผลิตภัณฑ์ที่กระบวนการสร้างเป็นเจ้าของโดยทีมหนึ่งในขณะที่อีกทีมหนึ่งเป็นเจ้าของรหัส

ปัญหาเกี่ยวกับระบบบิลด์เป็นเรื่องปกติ นักพัฒนาไม่แน่ใจว่าจะใช้มันอย่างไร มันขึ้นอยู่กับเครื่องมือมาตรฐาน แต่ได้รับการปรับแต่งเพื่อให้ทุกเอกสารที่มีอยู่บนเว็บพิสูจน์แล้วว่าไร้ประโยชน์

ทุกคนต้องการที่จะปรับปรุงสถานการณ์ แต่ไม่มีความเข้าใจระหว่างทั้งสองทีม ซึ่งหมายความว่าทั้งสองฝ่ายแนะนำเครื่องมือใหม่โดยไม่ปรึกษากับอีกฝ่าย สิ่งนี้ทำให้ช่องว่างกว้างขึ้นแทนที่จะปิด

หากคุณต้องการเริ่มการเปลี่ยนแปลง DevOps ภายในองค์กรของคุณ ให้เริ่มด้วยการปรับปรุงวิธีการสื่อสารของคุณ อย่าเพิ่งคิดหาวิธีแก้ปัญหา: ระดมสมองด้วยใจที่เปิดกว้าง ก่อน จากนั้นคุณอาจพบว่า ตัวอย่างเช่น การสนับสนุนเครื่องมือไม่เพียงพอสำหรับความต้องการของคุณ เมื่อนั้นคุณสามารถพิจารณาปรับแต่งเครื่องมือปัจจุบันของคุณหรือแนะนำเครื่องมือใหม่ ๆ ได้ ไม่เช่นนั้นคุณอาจจะเพิ่มปัญหาเดิมเข้าไป

วิธีที่เร็วที่สุดในการสร้าง DevOps? สื่อสารดีขึ้น!

ในบทนำ ฉันได้กล่าวถึงคำถามที่ลูกค้ามักถามฉันว่า "ฉันควรไปกับ Docker หรือฉันควรข้ามไปที่ Kubernetes เลย" หลังจากอ่านบทความนี้แล้ว คุณจะเห็นว่าคำถามดังกล่าวมีคำตอบที่ดีที่สุดหลังจากเตรียมงานบางอย่างด้วยแนวคิด DevOps

หากคุณรู้ว่าทีมผลิตภัณฑ์ของคุณเข้าใจถึงประโยชน์ของ DevOps สำหรับตัวเองและสำหรับลูกค้า ทีมงานและลูกค้าสามารถเริ่มต้นได้ด้วยการกำหนดความคาดหวังของพวกเขา จากนั้นวิศวกรก็สามารถหารูปแบบการพัฒนาและการใช้งานได้ สุดท้าย คุณสามารถกำหนดได้ว่าเครื่องมือใดที่จำเป็น

เมื่อข้อกำหนดทั้งหมดได้รับการจัดทำเป็นเอกสาร ตัวเลือกเทคโนโลยีจะทำได้ง่ายขึ้นมาก

ฉันเป็นผู้สนับสนุนเครื่องมืออัตโนมัติ DevOps ที่ยอดเยี่ยมทั้งหมดที่ทำให้งานของเราง่ายขึ้นและจัดการได้มากขึ้น แต่งานประจำวันของเราคือการทำงานกับ ผู้คน มาลงทุนเวลาเพื่อปรับปรุงแนวทางปฏิบัติที่ดีที่สุดของ DevOps ในด้านนี้ แทนที่จะได้รับใบรับรองเทคโนโลยีอื่น