DevOps คือใคร และเมื่อใดจึงไม่จำเป็น?

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

บางคนระบุ DevOps ไว้ในเรซูเม่ของพวกเขา แม้ว่าพวกเขาจะไม่ได้รู้หรือเข้าใจสาระสำคัญของคำนี้เสมอไปก็ตาม บางคนคิดว่าหลังจากศึกษา Ansible, GitLab, Jenkins, Terraform และอื่นๆ ที่คล้ายกัน (รายการสามารถต่อยอดได้ตามที่คุณต้องการ) คุณจะกลายเป็น "ผู้อุทิศตน" ทันที แน่นอนว่านี่ไม่เป็นความจริง

ในช่วงไม่กี่ปีที่ผ่านมา ฉันมีส่วนร่วมในการนำ DevOps ไปใช้งานในบริษัทต่างๆ เป็นหลัก ก่อนหน้านั้นเขาทำงานมามากกว่า 20 ปีในตำแหน่งตั้งแต่ผู้ดูแลระบบไปจนถึงผู้อำนวยการฝ่ายไอที ปัจจุบันเป็นหัวหน้าวิศวกร DevOps ที่ Playgendary

DevOps คือใคร

ความคิดในการเขียนบทความเกิดขึ้นหลังจากมีคำถามอีกข้อหนึ่ง: “ใครคือ DevOps” ยังไม่มีคำที่แน่ชัดว่าคืออะไรหรือเป็นใคร คำตอบบางส่วนมีอยู่ในนี้แล้ว วีดีโอ. ขั้นแรก ฉันจะเน้นประเด็นหลักจากนั้นฉันจะแบ่งปันข้อสังเกตและความคิดของฉัน

DevOps ไม่ใช่ผู้เชี่ยวชาญที่สามารถจ้างได้ ไม่ใช่ชุดสาธารณูปโภค และไม่ใช่แผนกของนักพัฒนาที่มีวิศวกร

DevOps เป็นปรัชญาและวิธีการ

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

ด้วยการถือกำเนิดของ DevOps โครงสร้างและบทบาทของผู้เชี่ยวชาญยังคงเหมือนเดิม (มีนักพัฒนา มีวิศวกร) แต่กฎของการโต้ตอบมีการเปลี่ยนแปลง ขอบเขตระหว่างแผนกต่างๆ เบลอแล้ว

เป้าหมายของ DevOps สามารถอธิบายได้เป็นสามประเด็น:

• ซอฟต์แวร์จะต้องได้รับการอัพเดตอย่างสม่ำเสมอ
• ซอฟต์แวร์จะต้องดำเนินการอย่างรวดเร็ว
• ควรปรับใช้ซอฟต์แวร์อย่างสะดวกและใช้เวลาอันสั้น

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

และนี่เป็นเพียงส่วนหนึ่งของเครื่องมือ DevOps เท่านั้น

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

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

มีตัวอย่างที่ชัดเจน ชายหนุ่มคนหนึ่งมาสัมภาษณ์ด้วยคำพูดที่ชาญฉลาดมากมายในเรซูเม่ของเขา ในงานสามงานสุดท้ายของเขา เขามีประสบการณ์ 5-6 เดือน ฉันออกจากบริษัทสตาร์ทอัพสองแห่งเพราะพวกเขา “ไม่ประสบความสำเร็จ” แต่เกี่ยวกับบริษัทที่สาม เขาบอกว่าไม่มีใครเข้าใจเขาที่นั่น นักพัฒนาเขียนโค้ดบน Windows และผู้อำนวยการบังคับให้โค้ดนี้ "รวม" ใน Docker ปกติและรวมเข้ากับไปป์ไลน์ CI/CD ผู้ชายคนนี้พูดในแง่ลบมากมายเกี่ยวกับสถานที่ทำงานปัจจุบันของเขาและเพื่อนร่วมงานของเขา - ฉันแค่อยากจะตอบว่า: "คุณจะไม่ขายช้าง"

จากนั้นฉันก็ถามคำถามที่สูงในรายการของฉันสำหรับผู้สมัครทุกคน

— DevOps มีความหมายต่อคุณเป็นการส่วนตัวอย่างไร?
- โดยทั่วไปหรือฉันจะรับรู้ได้อย่างไร?

ฉันสนใจความคิดเห็นส่วนตัวของเขา เขารู้ทฤษฎีและที่มาของคำนี้ แต่เขาไม่เห็นด้วยอย่างยิ่งกับทฤษฎีเหล่านี้ เขาเชื่อว่า DevOps เป็นตำแหน่งงาน นี่คือต้นตอของปัญหาของเขา ตลอดจนผู้เชี่ยวชาญคนอื่นๆ ที่มีความคิดเห็นแบบเดียวกัน

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

วิธีการและปรัชญา DevOps

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

วิธีการ DevOps เป็นเพียงวิธีการในการบรรลุเป้าหมายเท่านั้น

ตอนนี้เกี่ยวกับปรัชญา DevOps คืออะไร และนี่อาจเป็นคำถามที่ยากที่สุด

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

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

โดยใช้ประสบการณ์ของตัวเอง ฉันพยายามสร้าง "หลักสมมุติ" บางประการของปรัชญานี้ให้เป็นทางการ ผลลัพธ์จะเป็นดังนี้:

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

ฉันคิดว่า "สมมุติฐาน" ของฉันเป็นหัวข้อแยกต่างหากสำหรับการสนทนา แต่ตอนนี้มีบางอย่างที่ต้องต่อยอด

DevOps ทำอะไรได้บ้าง

คำสำคัญที่นี่คือการสื่อสาร มีการสื่อสารมากมาย ซึ่งผู้ริเริ่มควรเป็นวิศวกร DevOps คนเดียวกันทุกประการ ทำไมเป็นอย่างนั้น? เพราะนี่คือปรัชญาและวิธีการ และเป็นเพียงความรู้ด้านวิศวกรรมเท่านั้น

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

ในรัสเซีย DevOps ยังเป็นหัวข้อที่อายุน้อยมาก แต่ก็เป็นหัวข้อที่กำลังมาแรงอยู่แล้ว เท่าที่ฉันรู้ ในมอสโกเพียงแห่งเดียว การขาดแคลนผู้เชี่ยวชาญดังกล่าวในปี 2019 มีมากกว่า 1000 คน และคำว่า Kubernetes สำหรับนายจ้างก็แทบจะเหมือนผ้าขี้ริ้วสีแดงสำหรับวัว ผู้ที่ใช้เครื่องมือนี้พร้อมที่จะใช้งานแม้ในที่ที่ไม่จำเป็นและได้ผลกำไรเชิงเศรษฐกิจ ผู้จ้างงานไม่เข้าใจเสมอไปในกรณีใดว่าอะไรเหมาะสมกว่าในการใช้งาน และด้วยการปรับใช้ที่เหมาะสม การบำรุงรักษาคลัสเตอร์ Kubernetes มีค่าใช้จ่ายมากกว่าการติดตั้งใช้งานแอปพลิเคชันโดยใช้โครงร่างคลัสเตอร์ทั่วไปถึง 2-3 เท่า ใช้มันในที่ที่คุณต้องการจริงๆ

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

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

นอกจากนี้ วิศวกร DevOps ยังจำเป็นต้องใช้ทรัพยากรด้านการดูแลระบบเป็นครั้งคราว ตัวอย่างเช่น เพื่อเอาชนะ "การต้านทานต่อสิ่งแวดล้อม" - เมื่อทีมไม่พร้อมที่จะยอมรับเครื่องมือและวิธีการ DevOps

นักพัฒนาควรเขียนโค้ดและการทดสอบเท่านั้น ในการทำเช่นนี้ เขาไม่จำเป็นต้องใช้แล็ปท็อปที่ทรงพลังเป็นพิเศษเพื่อใช้ในการปรับใช้และสนับสนุนโครงสร้างพื้นฐานของโครงการทั้งหมดภายในเครื่อง ตัวอย่างเช่น นักพัฒนาส่วนหน้าจะเก็บองค์ประกอบทั้งหมดของแอปพลิเคชันไว้บนแล็ปท็อปของเขา รวมถึงฐานข้อมูล, โปรแกรมจำลอง S3 (minio) เป็นต้น นั่นคือเขาใช้เวลาส่วนใหญ่ในการบำรุงรักษาโครงสร้างพื้นฐานในท้องถิ่นและต่อสู้กับปัญหาทั้งหมดของวิธีแก้ปัญหาดังกล่าวโดยลำพัง แทนที่จะพัฒนาโค้ดส่วนหน้า คนแบบนี้สามารถต้านทานการเปลี่ยนแปลงใดๆ ได้อย่างมาก

แต่มีทีมจำนวนหนึ่งที่ยินดีแนะนำเครื่องมือและวิธีการใหม่ๆ และมีส่วนร่วมอย่างกระตือรือร้นในกระบวนการนี้ แม้ว่าในกรณีนี้ การสื่อสารระหว่างวิศวกร DevOps และทีมก็ไม่ได้ถูกยกเลิก

เมื่อไม่จำเป็นต้องใช้ DevOps

มีบางสถานการณ์ที่ไม่จำเป็นต้องใช้ DevOps นี่คือข้อเท็จจริง - จำเป็นต้องเข้าใจและยอมรับ

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

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

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

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

• Devอุ๊ปส์
• DevOpsConf
• โหลดสูง++
• แฟลต
• โซลูชันคลาวด์ MailRu

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

หากบริษัทของคุณขายปลาในร้านค้าเล็ก ๆ และผลิตภัณฑ์ไอทีเพียงสอง 1C: การกำหนดค่าระดับองค์กร (การบัญชีและ UNF) ก็แทบจะไม่สมเหตุสมผลเลยที่จะพูดถึง DevOps

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

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

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

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

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

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

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

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

เกมใดๆ ที่มีอยู่ต้องขอบคุณเงินทุน: ทั้งทางตรงและทางอ้อมจากผู้เล่น ที่ Playgendary เราพัฒนาเกมมือถือฟรีโดยมีผู้คนมากกว่า 200 คนที่เกี่ยวข้องโดยตรงกับการสร้างสรรค์เกมเหล่านั้น เราจะใช้ DevOps ได้อย่างไร?

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

ขณะนี้เรากำลังใช้ Jenkins เป็นเครื่องมือไปป์ไลน์ CI/CD เพื่อดำเนินการไปป์ไลน์การประกอบทั้งหมดด้วย Unity และการปรับใช้งานในภายหลังใน App Store และ Play Market เพิ่มเติมจากชุดเครื่องมือแบบคลาสสิก:

• อาสนะ - สำหรับการจัดการโครงการ บูรณาการกับเจนกินส์ได้รับการกำหนดค่าแล้ว
• Google Meet - สำหรับการประชุมทางวิดีโอ
• Slack - สำหรับการสื่อสารและการแจ้งเตือนต่างๆ รวมถึงการแจ้งเตือนจาก Jenkins
• Atlassian Confluence - สำหรับเอกสารและงานกลุ่ม

แผนเร่งด่วนของเราประกอบด้วยการแนะนำการวิเคราะห์โค้ดแบบคงที่โดยใช้ SonarQube และการดำเนินการทดสอบ UI อัตโนมัติโดยใช้ Selenium ในขั้นตอนการบูรณาการอย่างต่อเนื่อง

แทนการสรุป

ฉันอยากจะทิ้งท้ายด้วยความคิดต่อไปนี้: ในการเป็นวิศวกร DevOps ที่มีคุณสมบัติสูง การเรียนรู้วิธีสื่อสารสดกับผู้คนเป็นสิ่งสำคัญ

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

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

ที่มา: will.com