แม้ว่าวิธีการของ DevOps จะอยู่กับเรามาระยะหนึ่งแล้ว แต่ก็ยังคงเป็นศูนย์กลางของการสนทนาที่เข้มข้น บริษัท ต่างๆต้องการ แต่ไม่แน่ใจว่าจะดำเนินการอย่างไร
DevOps มีอยู่ทั่วไป . และแม้ว่าจะเป็นเทรนด์ที่น่าสนใจ แต่ก็ควรเข้ากับผลิตภัณฑ์ไม่ใช่ในทางอื่น
แต่บางคนไม่เห็นเป็นอย่างนั้น ฉันมักจะถูกถามคำถามเช่น“ คุณคิดว่าเราควรเริ่มใช้ Docker หรือไม่ก็เข้าสู่ Kubernetes โดยตรง” คำถามดังกล่าวไม่มีความหมายโดยไม่รู้ด้วยซ้ำว่าผลิตภัณฑ์นั้นเกี่ยวกับอะไร
คำศัพท์ที่แปลกใหม่ทั้งหมด - คลาวด์ ผู้ว่าการ , คอนเทนเนอร์, การจัดการการกำหนดค่า, โครงสร้างพื้นฐานตามรหัส - สัญญาว่าจะปรับปรุงบางอย่าง แต่พวกเขาจะ DevOps เช่นเดียวกับกล้องโทรทรรศน์สำหรับดาราศาสตร์ อาจมีประโยชน์ แต่ไม่จำเป็น
หลัก ๆ แล้ว DevOps มีเป้าหมายเพื่อปิดช่องว่างระหว่างสิ่งที่ลูกค้าสั่งและสิ่งที่ทีมพัฒนาส่งมอบให้ มีการให้ความสำคัญกับรอบการเปิดตัวที่สั้นวิธีการออกแบบซ้ำ ๆ และการทำงานอัตโนมัติของขั้นตอนซ้ำ ๆ คุณคิดว่าอะไรสำคัญที่สุดในการนำสิ่งเหล่านั้นมาสู่ความเป็นจริง
หากคุณพูดว่า“ การสื่อสารที่ดีเยี่ยม” คุณคิดถูกแล้ว เครื่องมือทั้งหมดดี แต่จะคุ้มค่ากับเงินที่ลงทุนไปเมื่อปรับปรุงการสื่อสารเท่านั้น
แง่มุมหนึ่งของการสื่อสารคือการรู้ว่าอะไรคือสิ่งที่จำเป็นเพื่อให้งานสำเร็จลุล่วง และงานไม่ได้หมายความว่า“ รหัสถูกผูกมัดกับที่เก็บ” ลองคิดดูว่า“ ลูกค้าเห็นการเปลี่ยนแปลงในการผลิตและยอมรับมัน”
ทันทีที่กำหนดขั้นตอนแรกนี้และทุกคนรู้ว่าจะต้องเกิดอะไรขึ้นนั่นคือเวลาที่ดีที่สุดในการจดบันทึก ที่ไหน? ฉันเป็นผู้สนับสนุนอย่างมากในการดูแลรักษา README.md แต่ละคนในทีมสามารถมองเข้าไปข้างในและรู้สถานะของโปรเจ็กต์ได้ตลอดเวลาและเป็นเรื่องธรรมดาสำหรับผู้มาใหม่ในโปรเจ็กต์
ระบบอัตโนมัติขั้นตอนต่อไปหลังจากเขียน README เป็นทางเลือก แม้ว่าจะเป็นผลพลอยได้ตามธรรมชาติของการจัดทำเอกสารกระบวนการ และใช่ระบบอัตโนมัติเป็นสิ่งที่มักจะนึกถึงเมื่อคิดถึง DevOps
รอสักครู่…การทำงานอัตโนมัติเป็นทางเลือกเมื่อพูดถึง DevOps? DevOps เป็นแผนกของบุคคลที่ทำให้ใช้งานได้หรือไม่
s corp หรือ c corp llc
สิ่งที่คนทั่วไปมักเข้าใจภายใต้คำว่า 'วิศวกร DevOps' คือวิศวกรด้านความน่าเชื่อถือของซอฟต์แวร์วิศวกรแพลตฟอร์มหรือวิศวกรระบบปฏิบัติการอัตโนมัติ ทั้งหมดนี้เป็นบทบาทที่ถูกต้องที่ช่วยให้ฝึก DevOps ได้ แต่การใช้คำว่า 'วิศวกร DevOps' โดยรวมอาจจะคลุมเครือเล็กน้อย
ลองมาดู DevOps กันอย่างละเอียด
ก่อนอื่นให้ฉันแสดงให้คุณเห็นว่า DevOps ไม่ใช่อะไร:
เมื่อทราบสิ่งนี้คุณจึงทราบแล้วว่าคุณไม่สามารถ“ จ้างวิศวกร DevOps” หรือ“ สร้างทีม DevOps” ใน บริษัท เพื่อให้แน่ใจว่าคุณจะได้รับการพิสูจน์ในอนาคต DevOps นั้นคล้ายกับการพัฒนา Agile คุณจะจ้างนักพัฒนา Agile เช่นนี้ เหรอ? อาจจะไม่. ไม่ว่าคุณจะพัฒนาผลิตภัณฑ์ด้วยวิธี Agile หรือคุณไม่ทำ
แล้ว DevOps สามารถอธิบายได้อย่างไร? มันเป็นวิธีการ หรืออาจจะเป็น วัฒนธรรม . บางทีอาจเป็นวิญญาณ การทำผลิตภัณฑ์ตามหลักการ DevOps หมายความว่าทุกคนไม่ว่าจะเป็นนักพัฒนาวิศวกรฝ่ายปฏิบัติการหรือผู้จัดการผลิตภัณฑ์จะมีวิสัยทัศน์ร่วมกันดูแลผลิตภัณฑ์ผ่านการสื่อสาร ในระดับที่น้อยกว่าก็หมายความว่าทุกคนใช้เครื่องมือเดียวกัน เครื่องมือเหล่านี้ไม่ได้มีไว้เพื่อช่วยเหลือคนกลุ่มใดกลุ่มหนึ่ง พวกเขามีจุดมุ่งหมายเพื่อผลักดันผลิตภัณฑ์ไปข้างหน้า
การไปกับแนวคิดนี้ต้องมีการเปลี่ยนความคิดอย่างจริงจังซึ่งเป็นอุปสรรคสำคัญ ทำไมถึงเป็นเช่นนั้น? เป็นเพราะผู้คนต้องก้าวออกจากเขตความสะดวกสบายและเริ่มทำงานร่วมกับผู้คนที่มีความสามารถแตกต่างกัน จู่ๆนักพัฒนาจำเป็นต้องเรียนรู้ว่าระบบคลาวด์ทำงานอย่างไรและเริ่มปรับใช้โค้ดของตนเอง ผู้ปฏิบัติงานจำเป็นต้องละทิ้งการตั้งค่าด้วยตนเองและเริ่มการเข้ารหัส ทุกคนต้องเรียนรู้แนวคิดใหม่ ๆ ทุกคนมี ความรับผิดชอบใหม่ .
สิ่งนี้ไม่ใช่เรื่องง่าย แต่ด้วยการสื่อสารที่ดีและมีเป้าหมายร่วมกันมันก็ทำได้ค่อนข้างดี การสื่อสารนี้เกี่ยวข้องกับการสร้างวัฒนธรรมการจัดตั้งกระบวนการที่มีน้ำหนักเบาและการดูแลรักษาเอกสารที่เหมาะสม
การปรับแต่งประสิทธิภาพ sql คืออะไร
คุณอาจไม่เคยคิดแบบนั้น แต่เครื่องมือส่วนใหญ่ที่เกี่ยวข้องกับ DevOps คือ เครื่องมือจัดทำเอกสาร :
Dockerfile s เอกสารนั้นเกี่ยวกับวิธีการสร้างและกำหนดค่าไมโครเซอร์วิสที่กำหนดแนวคิดที่แปลกใหม่เหล่านี้ทำโดยพื้นฐานแล้ว: ช่วยให้สมาชิกในทีมสื่อสารได้ดีขึ้นโดยการจัดทำเอกสารกระบวนการ จากนั้นกระบวนการเหล่านี้สามารถรันได้ด้วยตนเองหรือเป็นแบบอัตโนมัติ สิ่งสำคัญคือผู้มีส่วนได้ส่วนเสียทุกคนในโครงการสามารถติดตามพวกเขาได้
การจัดทำเอกสารกระบวนการของคุณเป็นรหัสมีข้อดีอย่างหนึ่งที่เหนือกว่าคู่มือการใช้งานทั่วไป รหัสสามารถตรวจสอบได้และทำงานอย่างคาดเดาได้ เนื่องจากอินพุตเดียวกันจะสร้างเอาต์พุตเดียวกัน
ด้วยคำแนะนำที่เป็นลายลักษณ์อักษรคุณจะตีความได้มากเท่าที่มีผู้อ่าน หากคุณเขียนเอกสารที่คลุมเครือหรือคลุมเครือบุคคลที่อ่านเอกสารนั้นจะกรอกข้อมูลลงในช่องว่าง ประเด็นคือคุณไม่สามารถควบคุมสิ่งที่เข้าไปในช่องว่างได้
รหัสง่ายกว่ามาก หากไม่มีขั้นตอนที่เป็นรูปธรรมโปรแกรมจะหยุดทำงาน ขั้นตอนที่เป็นรูปธรรมเหล่านี้เป็นสิ่งสำคัญอย่างหนึ่งของการสื่อสาร DevOps
ในหนังสือ โครงการฟีนิกซ์ เราเห็นปัญหาของผู้จัดการที่เพิ่งได้รับการเลื่อนตำแหน่งซึ่งได้รับมอบหมายให้ปรับใช้โครงการใหญ่ เนื่องจากไม่มีใครรู้ว่าเกิดอะไรขึ้นทุกคนต่างต่อสู้กับไฟโดยไม่มีความคืบหน้ามากนัก คำบรรยายของหนังสือระบุว่าเป็นเรื่องของ DevOps ฉันเห็นด้วยกับที่
แต่สิ่งที่น่าสนใจก็คือตลอดทั้งเล่มไม่มีการแนะนำเครื่องมือใหม่แม้แต่ชิ้นเดียว คุณสามารถบรรลุสถานะ DevOps ได้โดยการปรับปรุงการสื่อสารเพียงอย่างเดียวหรือไม่? ตัวละครเอกของหนังสือเล่มนี้ก็มีความหวังเช่นกัน!
แม้ว่าแนวทางของตัวละครเอกอาจถูกมองว่าเป็น 'โรงเรียนเก่า' (ใช้การ์ดกระดาษจริงแทนระบบติดตามข้อผิดพลาดที่เหมาะสม) แต่สิ่งต่างๆก็เริ่มเปลี่ยนไปในทางที่ดีขึ้นเมื่อทุกฝ่ายที่เกี่ยวข้องเริ่มคุยกัน
คุณอาจคิดว่าเป็นไปได้ที่จะปรับปรุงการทำงานร่วมกันระหว่างการพัฒนาและการดำเนินงานโดยการสร้างอินเทอร์เฟซที่ดีขึ้นระหว่างกันเช่นข้อตกลงระดับบริการหรือเหตุการณ์ค้างส่ง แต่สิ่งที่ตรงกันข้ามคือความจริง ด้วยการทำลายอินเทอร์เฟซและแนะนำการเอาใจใส่และสาเหตุทั่วไปคุณจะมีทีมที่ทำงานไปสู่เป้าหมายร่วมกัน
ตามหลักการแล้วแต่ละผลิตภัณฑ์ควรมีเพียงทีมเดียว: ทีมผลิตภัณฑ์
ครั้งหนึ่งฉันเคยอยู่ในทีมพัฒนาที่ไม่มีเป้าหมายร่วมกับทีมอื่น ทีมพัฒนาต้องการผลักดันการเปลี่ยนแปลงให้มากที่สุด ทีมตรวจสอบได้รับมอบหมายให้ป้องกันการนำข้อบกพร่อง พวกเขามีผู้จัดการที่แตกต่างกันและได้รับการประเมินเป็นรายบุคคล
ผลลัพธ์? การพัฒนาและการตรวจสอบความถูกต้องเล่นปิงปองกับรายงานข้อบกพร่อง เมื่อการตรวจสอบความถูกต้องพบการทดสอบที่ไม่ผ่านการพัฒนาจึงสนใจที่จะค้นหาข้อบกพร่องในโค้ดทดสอบมากกว่าการพยายามทำให้โค้ดของตนเองปราศจากข้อบกพร่อง
แน่นอนว่ารอบการเปิดตัวจะเพิ่มขึ้นเนื่องจากมีค่าใช้จ่ายจำนวนมากในการกรอกรายงานรายงานโต้แย้งและอื่น ๆ อย่างเหมาะสม สิ่งที่ดูเหมือนจะไม่เข้าใจมากที่สุดคือในแง่ของผลิตภัณฑ์ทั้งสองทีมควรมีเป้าหมายร่วมกันและทำงานร่วมกันเพื่อบรรลุเป้าหมาย แต่การขาดความร่วมมือที่เหมาะสมและความคิดเกี่ยวกับไซโลทำให้ยากที่จะสังเกตเห็น
แนวคิดการผลิตแบบลีนที่เป็นแรงบันดาลใจให้ The Manifesto for Agile Software Development ( ซึ่งจะแนะนำให้เรารู้จักกับ DevOps ) เกี่ยวกับการต่อสู้กับขยะ โดยสิ้นเปลืองเราหมายถึงทุกสิ่งที่ไม่เกี่ยวข้องโดยตรงกับสิ่งที่ลูกค้าสั่ง งานระหว่างทำที่หมักหมมเป็นความสูญเปล่า ทุกขั้นตอนของกระบวนการที่ไม่ได้นำไปสู่การปลดปล่อยอย่างชัดเจนคือความสูญเปล่า
แต่ของเสียสามารถมองเห็นได้จากระดับสูงเท่านั้น ในขอบเขตของทีมเดียวขั้นตอนบางอย่างอาจดูเหมือนจำเป็น อย่างไรก็ตามจากมุมมองของผลิตภัณฑ์อาจไม่มีประโยชน์
หากต้องการทราบว่าความพยายามใดที่สูญเปล่าคุณต้องเข้าร่วมกองกำลังและพิจารณาวงจรชีวิตของผลิตภัณฑ์ที่จัดส่ง คุณต้องคิดจากมุมมองของลูกค้าด้วย คุณลักษณะนี้เป็นสิ่งที่ลูกค้าต้องการหรือไม่? หากไม่เป็นเช่นนั้นคุณสามารถข้ามไปได้เช่นกัน กระบวนการของคุณง่ายและเรียบง่ายหรือไม่? มองลึกลงไปโดยเฉพาะอย่างยิ่งเกี่ยวกับผู้ที่ข้ามขอบเขตของทีม
คุณต้องการให้แน่ใจว่าการพัฒนาผลิตภัณฑ์มีประสิทธิภาพเท่าที่จะเป็นไปได้หรือไม่? เชิญบุคคลภายนอกมาดูวิธีการทำงานของคุณ บุคคลที่ไม่ได้เป็นส่วนหนึ่งของทีมของคุณจะสามารถถามคำถามเชิงลึกและมองเห็นประเด็นใหม่เพื่อการปรับปรุง
CALMS เป็นคำอธิบายที่ถูกต้องมากว่าควรฝึก DevOps อย่างไร:
สังเกตว่ามีลักษณะคล้ายแซนวิช ค่ากลางทั้งสามเป็นค่าทางเทคนิคมากกว่าในขณะที่ค่าภายนอกเกี่ยวข้องกับทักษะที่อ่อนนุ่ม แต่พื้นฐานของวัฒนธรรมทั้งหมดคือการสื่อสาร: เราแลกเปลี่ยนคุณค่าและความเชื่อของเรากับสมาชิกในทีมคนอื่น ๆ จนกว่าเราจะได้ข้อตกลงร่วมกันว่าสิ่งต่างๆควรปฏิบัติอย่างไร
ตัวอย่าง angularjs สำหรับผู้เริ่มต้น
เช่นเดียวกันกับการแบ่งปัน การแบ่งปันสิ่งพื้นฐานเช่นอาหารไม่จำเป็นต้องมีการสื่อสาร อย่างไรก็ตามท่าทางนั้นยังสามารถมองได้ว่าเป็นการสื่อสาร “ ฉันห่วงใยคุณดังนั้นฉันจึงแบ่งปันกับคุณ” เราไม่ต้องการ จำกัด ขอบเขตเฉพาะการสื่อสารด้วยวาจาเท่านั้น
อย่างไรก็ตามการแบ่งปันแนวคิดและเครื่องมือต้องมีการสื่อสาร เราควรแบ่งปันอย่างไร เราจะวางไว้ที่ไหน? สิ่งเหล่านี้มีประโยชน์สำหรับทุกคนในทีมหรือสำหรับกลุ่มเล็ก ๆ เท่านั้น?
หากคุณมุ่งเน้นเฉพาะด้านเทคนิคเพิ่มเติมเช่นระบบอัตโนมัติแบบลีนและการวัดผลคุณจะพลาดจุดสำคัญของ DevOps มีอะไรดีในการมีสคริปต์การปรับใช้งานอัตโนมัติที่ไม่มีใครเคยใช้ข้างผู้เขียน หากสคริปต์ช่วยเธอได้สักพักก็อาจจะมีเหตุผล แต่ลองนึกดูว่าจะประหยัดเวลาได้มากแค่ไหนถ้าทุกคนแชร์สคริปต์นี้ นี่พูดบางอย่างเกี่ยวกับการต่อสู้กับขยะ!
หากคุณมุ่งเน้นเฉพาะด้านเทคนิคเพิ่มเติมเช่นระบบอัตโนมัติแบบลีนและการวัดผลคุณจะพลาดจุดสำคัญของ DevOps ทวีตบางคนกล่าวว่า DevOps ทำให้การดำเนินงานใกล้เคียงกับการพัฒนามากขึ้น นี่เป็นความจริง แต่ไม่ใช่ความจริงทั้งหมด เมื่อทำถูกต้อง DevOps จะนำทุกหน่วยเข้ามาใกล้ ช่วยให้ธุรกิจและลูกค้าเห็นว่าการพัฒนากำลังทำอะไรอยู่เกือบแบบเรียลไทม์
ข้อเสนอแนะที่สั้นกว่านี้เป็นประโยชน์ต่อผู้มีส่วนได้ส่วนเสียทั้งหมด โดยทั่วไปงานจะมองเห็นได้ชัดเจนขึ้นและนักพัฒนาก็สามารถดูได้อย่างง่ายดายว่าลูกค้าใช้โค้ดที่พวกเขาสร้างขึ้นอย่างไร ด้วยการปรับใช้แบบเดิมคุณสามารถรอได้หลายเดือนก่อนที่จะมีคนสังเกตเห็นข้อบกพร่องหรือข้อกำหนดที่ไม่ได้รับ ด้วยการปรับใช้งานอย่างต่อเนื่องทุกคนสามารถตอบสนองต่อปัญหาที่เกิดขึ้นได้ นักพัฒนาปฏิบัติการธุรกิจและลูกค้าสามารถนั่งในห้องเดียวและปรับเปลี่ยนแอปพลิเคชันการทำงานตามความต้องการในปัจจุบัน
หลักการออกแบบตัวอย่างต่างๆ
แน่นอนว่าต้องมีเครื่องมือทั้งหมดที่จะทำให้เป็นไปได้
แต่ไม่มีเครื่องมือใดที่จะทดแทนการสื่อสารที่ดีและการเอาใจใส่ภายใน บริษัท ได้ ครั้งหนึ่งฉันเคยสังเกตผลิตภัณฑ์ที่กระบวนการสร้างเป็นของทีมหนึ่งในขณะที่อีกทีมหนึ่งรหัสที่ให้มา
ปัญหาเกี่ยวกับระบบสร้างเป็นเรื่องปกติ นักพัฒนาไม่แน่ใจว่าจะใช้อย่างไร มันขึ้นอยู่กับเครื่องมือมาตรฐาน แต่พวกเขาได้รับการปรับแต่งเพื่อจุดที่เอกสารทั้งหมดที่มีอยู่บนเว็บพิสูจน์แล้วว่าไม่มีประโยชน์
ทุกคนต้องการให้สถานการณ์ดีขึ้น แต่ทั้งสองทีมไม่มีความเข้าใจกัน นั่นหมายความว่าทั้งสองฝ่ายแนะนำเครื่องมือใหม่โดยไม่ได้ปรึกษากับอีกฝ่าย นี่เป็นเพียงการขยายช่องว่างให้กว้างขึ้นแทนที่จะปิดลง
หากคุณต้องการเริ่มการเปลี่ยนแปลง DevOps ภายในองค์กรของคุณให้เริ่มต้นด้วยการปรับปรุงวิธีการสื่อสารของคุณ อย่าคิดแค่วิธีแก้ปัญหา: ระดมความคิดด้วยใจที่เปิดกว้าง อันดับแรก . จากนั้นคุณอาจพบว่าเช่นการสนับสนุนเครื่องมือไม่เพียงพอกับความต้องการของคุณ นั่นคือช่วงเวลาที่คุณสามารถพิจารณาปรับแต่งเครื่องมือปัจจุบันของคุณหรือแนะนำเครื่องมือใหม่ ๆ มิฉะนั้นคุณอาจจะเพิ่มปัญหาเดิมเข้าไป
ในบทนำฉันได้พูดถึงคำถามที่ลูกค้ามักถามฉันว่า“ ฉันควรไปกับ Docker หรือควรข้ามไปที่ Kubernetes โดยตรง” หลังจากอ่านบทความนี้คุณจะเห็นว่าคำถามดังกล่าวได้รับคำตอบที่ดีที่สุดหลังจากเตรียมงานเสร็จแล้วโดยใช้ความคิดของ DevOps
หากคุณรู้ว่าทีมผลิตภัณฑ์ของคุณเข้าใจถึงประโยชน์ของ DevOps สำหรับตัวเองและสำหรับลูกค้าทีมงานและลูกค้าสามารถเริ่มต้นได้ด้วยการตั้งความคาดหวัง จากนั้นวิศวกรจะสามารถหารูปแบบการพัฒนาและการปรับใช้ สุดท้ายคุณสามารถกำหนดได้ว่าต้องการเครื่องมือใด
เมื่อบันทึกข้อกำหนดทั้งหมดแล้วตัวเลือกเทคโนโลยีจะง่ายกว่ามาก
ฉันเป็นผู้สนับสนุนเครื่องมืออัตโนมัติ DevOps ที่ยอดเยี่ยมทั้งหมดที่ทำให้งานของเราง่ายขึ้นและจัดการได้มากขึ้น แต่งานประจำวันของเราคือการทำงานร่วมกับ คน . เรามาลงทุนเวลาเพื่อปรับปรุงแนวทางปฏิบัติที่ดีที่สุดของ DevOps ในแง่มุมนี้แทนการได้รับใบรับรองเทคโนโลยีอื่น
ทีม DevOps ผสมผสานการพัฒนาและการดำเนินการเพื่อส่งมอบการเพิ่มซอฟต์แวร์ด้วยวิธีที่รวดเร็วและมีประสิทธิภาพมากขึ้นกว่าที่เคยทำได้
ความรับผิดชอบของทีม DevOps รวมถึงบทบาทที่ครอบคลุมหลายส่วน ได้แก่ วิศวกร QA วิศวกรแพลตฟอร์มระบบคลาวด์วิศวกรความน่าเชื่อถือของไซต์วิศวกรระบบอัตโนมัตินักออกแบบผลิตภัณฑ์นักพัฒนาผลิตภัณฑ์เจ้าของผลิตภัณฑ์และสถาปนิกซอฟต์แวร์ล้วนเป็นส่วนหนึ่งของมัน
หลักการของ DevOps คือการหลีกเลี่ยงของเสียการกระทำที่เน้นลูกค้าเป็นศูนย์กลางความรับผิดชอบแบบ end-to-end ทีมงานอิสระข้ามสายงานการปรับปรุงอย่างต่อเนื่องการสื่อสารที่ดีเยี่ยมและระบบอัตโนมัติทุกครั้งที่ทำได้
DevOps เป็นวิธีการรวบรวมผู้คนจากทีมพัฒนาและทีมปฏิบัติการโดยช่วยให้พวกเขาสื่อสารได้ดีขึ้นทั้งทางวาจาและโดยใช้กระบวนการและเครื่องมือทั่วไป
DevOps ใช้เพื่อเพิ่มศักยภาพให้กับทีม Agile ในการนำเสนอซอฟต์แวร์คุณภาพสูงที่เพิ่มขึ้น
