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

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

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

ความคิดแรกของฉันคือ "ทำไมเขาเป็นคนเดียวที่ทำ ops ในทีม dev โดยเฉพาะอย่างยิ่งเมื่อเขาทำงานกับระบบอัตโนมัติมากมาย" ฉันคิดว่ามีโอกาสที่จะจัดการกับอาการหมาป่าโลน โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการพัฒนาโครงสร้างพื้นฐาน - รหัสให้กรอบที่ดีสำหรับการแบ่งปันภาระ คน Ops ควรเป็นผู้เชี่ยวชาญในการกำหนดและกำหนดความต้องการโครงสร้างพื้นฐานสำหรับแอปพลิเคชัน แต่พวกเขาควรจะสามารถสร้างแพลตฟอร์มเพื่อให้บทบาท dev ทำมากที่สุดเท่าที่จะเป็นไปได้

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

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

ฉันคิดว่าข้อบกพร่องแรกอยู่ในประโยคนี้:

เขารายงานไปยังผู้จัดการฝ่ายพัฒนา แต่ทำงานใกล้ชิดกับผู้จัดการโครงสร้างพื้นฐานมากขึ้น

DevOps เป็นการเปลี่ยนแปลงทางวัฒนธรรมโดยมีเป้าหมายเพื่อกำจัดไซโล ถ้าไซโลยังคงอยู่วิศวกรนี้ก็จะเรียกชื่อเขาว่าอะไรก็ตาม วิศวกรที่ทำการพัฒนาด้านปฏิบัติการผู้เชี่ยวชาญด้านระบบอัตโนมัติผู้พัฒนาโครงสร้างพื้นฐานอัตโนมัติ - แต่วิศวกรคนนี้ไม่ใช่วิศวกร DevOps
ในความเป็นจริง"DevOps Engineer" ไม่ใช่บทบาทที่แท้จริงมันเป็น 'chapeau' มากกว่าที่จะสามารถครอบคลุมนักพัฒนาผู้ดูแลระบบผู้ทดสอบระบบ QA และสถาปนิกที่ทำงานในทีมทั่วไป

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

อย่างที่คุณอธิบายมันวิศวกรคนนี้เป็นคนเดียวที่ทำ Ops ในทีม Dev นั่นไม่ได้ทำให้เขาเป็น "วิศวกร DevOps" (อะไรก็ตามที่มีความหมายในองค์กรของเขา) เขากำลังทำงานอย่างโดดเดี่ยวเพราะงานนั้นถูกเสนอเป็น "DevOps Engineer" แต่ดูเหมือนว่าคนอื่น ๆ ในทีมของเขาไม่ต้องการทำงานในการปฏิบัติงาน

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

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

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

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

รับความมุ่งมั่นการจัดการ

เมื่ออยู่ในสถานที่สิ่งต่างๆกลายเป็นเรื่องง่ายสำหรับวิศวกร DevOps โดยเฉพาะอย่างยิ่งเมื่อมีการต่อต้าน (จากทุกฝ่าย) เข้ามาในเกม เชื่อใจฉันจะมีการต่อต้านเช่นนี้ซึ่งท้าทายเช่น:

• ทำไมเราต้องเปลี่ยน? ฉันต้องการทำสิ่งที่ฉันทำมาตลอดหลายปีที่ X แล้ว!
• ฉันไม่ต้องการที่จะสูญเสียพลัง (ทางเทคนิค) ที่ฉันมีและทำตามขั้นตอนเวิร์กโฟลว์ทุกประเภทเพื่อรับการแก้ไขอย่างบ้าคลั่งในการผลิตซึ่งควรใช้เวลา 5 นาทีแทนที่จะเป็น 5 ชั่วโมง (หรือหลายวัน ... )
• ... (ฉันสามารถเพิ่มกระสุนอีกโหลได้ที่นี่ ... )

เมื่อใดก็ตามที่ความท้าทายเหล่านั้นเกิดขึ้นวิศวกร DevOps ทุกคนควรพูดว่า:

ฉันขอโทษฉันกำลังทำงานของฉัน ... ตามคำแนะนำจากผู้บริหารระดับสูง

รับงบประมาณที่จำเป็น

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

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

1. ประโยชน์ของระบบอัตโนมัติ

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

ด้วยการใช้ระบบ SCM คำสั่งโอเปอเรเตอร์หลายตัวจะเป็นไปโดยอัตโนมัติ

2. ลดต้นทุนใบอนุญาตซอฟต์แวร์

ผู้จำหน่ายซอฟต์แวร์บางรายได้ตัดสินใจเพิ่มค่าธรรมเนียมรายปีสำหรับซอฟต์แวร์ SCM (ล้าสมัย) ซึ่งฝ่ายจัดการไม่เห็นด้วย ดังนั้นพวกเขาจึงสร้างโครงการพิเศษเพื่อให้แทนที่ด้วยซอฟต์แวร์ SCM อื่น

งบประมาณของโครงการเท่ากับค่าธรรมเนียมรายปีที่ไม่ต้องการจ่าย ซึ่งรวมถึงการบินในวิศวกรจากทวีปอื่น ๆ (เช่นฉัน) เพื่อทำให้โครงการประสบความสำเร็จ

3. ลดต้นทุนการดำเนินงาน

บริษัท ประกันภัยรายใหญ่บางแห่งใช้ซอฟต์แวร์ FTP เพื่อถ่ายโอนซอฟต์แวร์แก้ไขไปยังคอมพิวเตอร์ระดับกลางประมาณ 13,000 (AS / 400s) ทั่วประเทศและสิ่งนี้เมื่อใดก็ตามที่ "แก้ไข" พร้อมใช้งาน ค่าใช้จ่ายในการโอน 1 ครั้งประมาณ 4 USD (13.000 x 4 = 52.000 USD สำหรับการโอนครั้งเดียว ... ) ซอฟต์แวร์ประกอบด้วยส่วนประกอบ 120,000 ชิ้นที่พัฒนา / ดูแลโดยนักพัฒนาประมาณ 150 คน ทำคณิตศาสตร์เกี่ยวกับความน่าจะเป็นที่นักพัฒนา 1 คนทำผิดพลาด 1 ครั้ง (เล็กน้อย) ในองค์ประกอบ 120.000 ใด ๆ เหล่านี้ซึ่งทำให้เกิดการผลิตและจำเป็นต้องมีการแก้ไขด่วนซึ่งจะมีค่าใช้จ่ายอีก 52.000 USD (สำหรับการโอน!)

ด้วยการใช้ระบบ SCM ที่เพียงพอ (ด้วยสภาพแวดล้อมการทดสอบที่มีการจัดการการอนุมัติ ฯลฯ ) ทำให้ บริษัท นี้ประสบความสำเร็จในการลดต้นทุนที่สำคัญ ลองคิดดูว่าถ้าระบบ SCM สามารถป้องกันความต้องการการโอนย้ายการแก้ไขด่วนได้เพียง 20 ครั้งก็ส่งผลให้ลดค่าใช้จ่ายลง 52.000 x 20 = 1.040.000 USD (เป็นงบประมาณในการใช้ระบบ SCM พวกเขาต้องการเพียงเศษเสี้ยว ของจำนวนเงินนั้นเพื่อให้งานเสร็จ)

4. ลดต้นทุนการไม่พร้อมใช้งาน

หากกรณีข้างต้นไม่น่าเชื่อถือเพียงพอให้ลองนึกถึงระบบของ บริษัท บัตรเครดิตรายใหญ่ที่ไม่มีอยู่ทั่วโลก ฉันได้รับการบอกว่า 1 วินาทีของความไม่พร้อมใช้งานมีค่าใช้จ่าย 1.000.000 USD

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

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

(ผมคิดว่าปัญหาของเขาเป็นส่วนใหญ่กับลังเลdevsไม่อื่น ๆ ของเขาOpsเพื่อนร่วมงานที่ดูเหมือนจะทำดำเนินงานคลาสสิกส่วนใหญ่.)

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

สิ่งหนึ่งที่ไม่ควรเกิดขึ้นก็คือผู้ชาย DevOps ทำระบบอัตโนมัติของเขาและทุกคนพยายามอย่างหนักเพื่อหลีกเลี่ยงระบบอัตโนมัติดังกล่าว (เช่นผ่านท่อ CI / CD และทำสิ่งต่างๆด้วยตนเองในสภาพแวดล้อมหนึ่ง) IMO นี้เป็นสิ่งสำคัญที่ต้องหยุด ทางออกหนึ่งสำหรับสิ่งนั้นคือการผลักดันอย่างหนักสำหรับวิธีการเลี้ยงสัตว์ที่ไม่ใช่สัตว์เลี้ยงนั่นคือการทำลาย VMs หรือภาชนะบรรจุซ้ายและขวาอย่างไม่ลดละทันทีที่คุณทำได้และหมุนใหม่อย่างต่อเนื่อง

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

ประการที่สาม "คนที่แต่งตัวประหลาดคนหนึ่ง" ของหลักสูตรต้องระวังว่าเขาไม่ได้ทำภารกิจประจำวันให้เพื่อนร่วมงานของเขา (เช่นการสร้าง Dockerfile หลังจาก Dockerfile สำหรับสิ่งประดิษฐ์ของพวกเขา ... )

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

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

และในที่สุดถ้าหลังจากหลายปีและหลายปีของการทำงานหนักไม่มีเพื่อนร่วมงานมองเห็นได้ดีขึ้นก็เป็นไปได้ที่จะมองหาลู่ทางอื่น ๆ (ไม่ว่าจะภายในหรือภายนอก บริษัท ) การมีประสบการณ์ DevOps ทั้งหมดภายใต้เข็มขัดของเขาเป็นฐานที่ดีเยี่ยมสำหรับการหางานทำวันนี้ ...

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

คำตอบนี้เป็นเพียงมุมมองที่เป็นเอกลักษณ์ของฉันจากประสบการณ์และอาจไม่บ่งบอกถึงบรรทัดฐานหรือวิธีปฏิบัติที่ดีที่สุด ...

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

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

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

มันเป็นไปได้เพื่อนร่วมงานของคุณอาจจะตระหนักหรือยังไม่ได้ตระหนักว่าเขาหรือเธอไม่ชอบการเป็นวิศวกร DevOps

ค่อนข้างพูดแนวคิดของ devops เป็นของใหม่และยังคงกำหนดตัวเองในความคิดของฉัน ขณะนี้ฉันทำหน้าที่เป็นวิศวกรผู้ฝึกหัดจนสำเร็จ สำหรับฉันนี่หมายความว่าฉันอำนวยความสะดวกและพัฒนาเครื่องมือและกระบวนการที่ใช้โดยทั้งทีมงาน dev และ ops ของเราที่จะให้พวกเขามุ่งเน้นไปที่ผลิตภัณฑ์ที่สร้างรายได้ให้กับ บริษัท ทีม ops และ dev พัฒนาเซิร์ฟเวอร์ของตัวเองและตามความจำเป็น ฉันแค่ขอ CI สำหรับผลิตภัณฑ์ของเราให้แน่ใจว่ากระบวนการของเราเหมาะสมและค้นหาว่ากระบวนการใดที่สามารถปรับปรุง / อัตโนมัติ ฉันได้พบกับแผนกทั้งหมดของเราตั้งแต่ฝ่ายขายจนถึงคลังสินค้าไปจนถึงนักพัฒนาและฝ่ายปฏิบัติการ (QA และผู้จัดการการวางจำหน่าย) เพื่อดูว่าพวกเขาทำอะไรอยู่และฉันจะปรับปรุงกระบวนการของพวกเขาได้อย่างไร

สำหรับฉัน DevOps หมายถึงการพัฒนาและการดำเนินงานของระบบซอฟต์แวร์กลายเป็นความรับผิดชอบของหนึ่งทีมแทนที่จะเป็นทีม dev และ ops แยกกัน นี่คือถนนสองทาง ทีมที่ดีที่สุดประกอบด้วยบุคคล " T-Shaped " ซึ่งเป็นผู้เชี่ยวชาญในสาขาเดียวและคุ้นเคยกับสาขาที่เกี่ยวข้องหลายแห่ง

• สมาชิกในทีมที่มีประสบการณ์ Ops คาดว่าจะทำในสิ่งที่พวกเขาทำได้ดีที่สุด (เช่น Ops) เพื่อสอนพื้นฐานของสิ่งที่พวกเขาทำดีที่สุด (เช่น Ops) ให้กับผู้อื่นและเพื่อเรียนรู้และทำงานในสาขาที่เกี่ยวข้อง (เช่นภารกิจ Dev)
• สมาชิกในทีมที่มีประสบการณ์ Dev นั้นคาดว่าจะทำสิ่งที่ดีที่สุด (เช่น Dev) เพื่อสอนพื้นฐานของสิ่งที่พวกเขาทำดีที่สุด (เช่น Dev) ให้กับผู้อื่นและเรียนรู้และทำงานในสาขาที่เกี่ยวข้อง (เช่นภารกิจ Ops)

ดังนั้นเพื่อให้วิศวกร DevOps รู้สึกเหมือนหมาป่าโดดเดี่ยวน้อยลงเชิญเขาให้สอนนักพัฒนาเกี่ยวกับวิธีการใช้งานระบบในขณะที่ยอมรับว่าเขาเป็นผู้เชี่ยวชาญในการออกแบบโครงสร้างพื้นฐาน

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

คาดว่า Devs จะทำภารกิจ Ops ประจำวันบางอย่างทั้งเพื่อสร้างความซ้ำซ้อนในทีมและเพื่อกระจายงาน "น่าเบื่อหน่าย" อย่างเป็นธรรม

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

จะทำอะไรได้บ้างเพื่อช่วยให้วิศวกร DevOps รู้สึกเหมือนหมาป่าโดดเดี่ยวน้อยลง

เพื่อถ่าย - สิ่งที่วิศวกร DevOps สามารถทำได้ตัวเอง / ตัวเองจะรู้สึกน้อยเช่นหมาป่าโดดเดี่ยว?

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

ดังนั้น - อย่ารู้สึกเหมือนเป็นหมาป่าโดดเดี่ยว มีส่วนร่วมในชุมชน DevOps เช่นนี้ที่นี่หรือกลุ่มเครื่องมือเฉพาะและ GitHub - อย่างน้อยที่สุดความรู้สึกนั้นก็คือคุณไม่ใช่หมาป่าโดดเดี่ยวเพียงตัวเดียว ;-)