ฉันจะจ้าง DevOps ที่ดีเหมาะสมกับ บริษัท ของฉันได้อย่างไร

ผู้พัฒนาที่ดีควรสอดคล้องกับกฎที่ 11 ของการทดสอบ Joel :

ผู้สมัครใหม่เขียนรหัสในระหว่างการสัมภาษณ์หรือไม่?

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

คำถามย่อย: ฉันเชื่อว่าพนักงาน devops ที่ดีสามารถกำหนดค่าห่วงโซ่การสร้างครั้งเดียวและควรทำงานตั้งแต่นั้นมา ฉันสามารถคาดหวังให้เขาหรือเธอเป็นนักพัฒนาใน บริษัท (DEVops) ได้หรือไม่? เนื่องจาก DevOps เป็นงานที่ค่อนข้าง "ใหม่" อาจจะดีกว่าหรือที่ บริษัท ขนาดเล็กจะแบ่งปันพนักงาน devops หรือจ้างเขาหรือเธอเป็นอิสระเมื่อใดก็ตามที่คุณต้องการเขาหรือเธอ?

ความสับสนของฉันเกี่ยวกับคำที่มาจากข้อเสนองานเช่นนี้แม้ที่นี่ใน stackexchange (= ลิงค์ที่หน้าจอด้านบนถูกนำมาจาก)

ฉันพบบทความที่เป็นประโยชน์ แต่เป็นไปได้ที่คุณอาจต้องการอ่านหากคุณสะดุดกับคำถามนี้: https://hackernoon.com/devoops-some-common-common-anti-patterns-1850ac2f5074

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

ไม่จำเป็นต้องแยกแยะระหว่างการสร้างและการวิ่งและตามเวอร์เนอร์โวเกิลก็ดีกว่านั้น:

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

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

การเปลี่ยนแปลงนี้เป็นไปตามความสำคัญที่เพิ่มขึ้นของวิธีการรวมและส่งมอบอย่างต่อเนื่อง โปรดทราบว่าความคิดเหล่านี้เก่ากว่าระเบียบแบบแผนของ“ ความว่องไว” อย่างเป็นทางการแล้วบางแนวคิดได้นำเสนอในรายงานของคณะกรรมการวิทยาศาสตร์ของนาโต้เกี่ยวกับวิศวกรรมซอฟต์แวร์ที่ตีพิมพ์ในปี 1968!

ในขณะที่สามารถมองข้ามถ้อยคำได้คำอธิบายสั้น ๆ ของข้อเสนอ DevOps (เว็บไซต์นี้) กล่าวถึง "วิศวกรซอฟต์แวร์":

ไซต์ถาม - ตอบเบต้าสำหรับวิศวกรซอฟต์แวร์ที่ทำงานเกี่ยวกับการทดสอบอัตโนมัติการส่งมอบอย่างต่อเนื่องการรวมบริการและการตรวจสอบและการสร้างโครงสร้างพื้นฐาน SDLC

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

เมื่อมีความเสี่ยงที่จะลงคะแนนเสียงนอกหัวข้อหรือแม้แต่บาปฉันจะบอกคุณว่า "อย่าฟังนักเล่นพิลึกบอกคุณว่า DevOps ไม่ใช่บทบาท"

คุณอยู่ในเส้นทางที่ถูกต้อง ควรเหมาะสมกับ บริษัท ของคุณ นั่นคือสิ่งที่สำคัญเมื่อทำการจ้างงาน

หากคุณต้องการ DevOps เพื่อทำงานเหมือน DevOps ให้ผลลัพธ์เช่น DevOps มันคือ DevOps

• อย่าให้ใครมาห้ามปรามคุณเป็นอย่างอื่น
• โฆษณาต่อไป
• ให้สัมภาษณ์อยู่ดี
• จ้างต่อไป

ในขณะนั้นค้นหาข้อมูลเพิ่มเติมเกี่ยวกับ DevOps วิธีที่แนวคิดสามารถเข้ากับ บริษัท ของคุณได้อย่างไร

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

คุณต้องการพนักงานหรือไม่ หรือนักแปลอิสระ? แจ็คของการค้าทั้งหมดหรือไม่ มีเพียงคุณเท่านั้นที่รู้จัก บริษัท ของคุณ

สร้างวัฒนธรรมที่เป็นเอกลักษณ์ของคุณซึ่งแปลความหมายของ DevOps ของคุณ

"การจ้าง DevOps" จะยากเพราะ DevOps ไม่ใช่บทบาท หากคุณสามารถหาวิศวกรที่มีการพัฒนาซอฟต์แวร์และทักษะด้านวิศวกรรมคุณก็อยู่ในแนวทางที่ถูกต้อง ..

อย่างไรก็ตาม ,

กระบวนการจ้างงานของคุณจะซับซ้อนโดยปัจจัยบางประการ:

1. วิศวกรความน่าเชื่อถือของไซต์ (คำศัพท์ของ Google สำหรับผู้ดูแลระบบ / วิศวกรที่มีทักษะการเข้ารหัส) นั้นหายาก
2. ทักษะที่หายากมีราคาแพง
3. ทักษะที่หายากคือ ... หายาก

ข่าวดีก็คือคุณอาจไม่ต้องการ SRE ที่ผ่านการรับรองอย่างสมบูรณ์

กรณีการใช้งานของคุณอย่างที่เคยเป็นอยู่คือการว่าจ้างวิศวกรเพื่อสร้างโครงสร้างพื้นฐาน (AWS) และการปรับใช้แบบอัตโนมัติ (Jenkins) ทักษะเหล่านั้นไม่ใช่สิ่งที่หายาก แต่คุณอาจมีความท้าทายในการค้นหาบุคคลเพียงคนเดียว

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

มีความเป็นไปได้สองอย่าง:

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

2. คุณรู้ว่าสิ่งที่คุณต้องการและเพียงแค่มองหาคนที่จะใช้วิสัยทัศน์นี้สำหรับคุณ

หากคุณต้องการใครสักคนที่จะช่วยให้คุณทราบว่าประเด็นใดที่คุณต้องให้ความสนใจมี บริษัท ที่เรียกว่าDORA (DevOps Research and Assessment) ซึ่งเป็น บริษัท ที่ก่อตั้งโดยดร. Nicole Forsgren, Jez Humble และ Gene Kim Nicole ดำเนินการสำรวจState of DevOpsเป็นเวลาหลายปีและได้เก็บสถิติโดยละเอียดของอุตสาหกรรมมาหลายปี Jez Humble เป็นกูรูด้านการจัดส่งแบบต่อเนื่องและเขียนหนังสือเล่มนี้อย่างแท้จริง ยีนคิมเป็นผู้เขียนThe Phoenix โครงการและสุดท้ายทั้งสองเป็นผู้เขียนร่วมของDevOps คู่มือ DORA ให้การประเมินบริษัท ของคุณและช่วยคุณตอบคำถามเหล่านั้น

หากคุณมีความคิดที่ดีที่คุณต้องไปและต้องการใครสักคนที่จะช่วยให้คุณไปถึงที่นั่นการรับ บริษัท จัดหางานอาจไม่ใช่ความคิดที่ดีในตอนนี้ ฉันอยากจะแนะนำให้ไปที่ DevOps Enterprise DOES Conferenceหรือ Local DevOpsDays Conferenceและพูดคุยกับผู้คนในโถงทางเดิน ค้นหาคำแนะนำและอาจเปิดบูธทำโปสเตอร์เกี่ยวกับการจ้างงาน

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

ฉันมองหาสิ่งต่าง ๆ ในคนที่ฉันจ้างมาในพื้นที่นี้

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

ฉันยังไม่พบผู้สมัครที่สมบูรณ์แบบดังนั้นมันจึงเป็นการแลกเปลี่ยนบางประเภทอยู่เสมอ ในโลกปัจจุบันฉันมองผ่าน 65+ เรซูเม่ที่มีคุณสมบัติ "ก่อนกำหนด" ในฐานะผู้สมัครจากเอเจนซี่และฝ่ายทรัพยากรบุคคลทิ้ง 50 หรือมากกว่านั้นโดยไม่ผ่านข้อกำหนดขั้นต่ำของฉันบนกระดาษสัมภาษณ์ 15+ และจ้าง 3 กระบวนการนี้ ส่วนที่ดีกว่าของ 9 เดือน

นอกเหนือจากคำถามอื่น ๆ ที่ฉันเชื่อว่าคำตอบต่อไปนี้ยังขาดหายไป - ฉันต้องการที่จะสรุปสิ่งที่ฉันได้เรียนรู้มาในระดับต่ำต้อยเป็นส่วนใหญ่:

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

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

DevOps เปิดเผยถึงความจำเป็นในการเปลี่ยนแปลงและการเปลี่ยนแปลงนั้นจำเป็นต้องมีความรับผิดชอบ

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