DevOps คือใคร?

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

เรายังคงมองหาเพื่อนร่วมงานอยู่ เพราะเบื้องหลังป้าย DevOps มีวิศวกรประเภทต่างๆ จำนวนมากซ่อนอยู่

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

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

แล้ววิศวกร DevOps คือใคร?

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

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

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

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

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

วิศวกรก่อสร้าง/วิศวกรปล่อย

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

Ops แตกต่างกันมาก

เราเดินหน้าต่อไปและอีกครั้งในการมีความรับผิดชอบที่หลากหลาย และการขาดแคลนบุคลากรที่มีคุณสมบัติเหมาะสมผลักดันเราไปสู่ความเชี่ยวชาญเฉพาะทางที่เข้มงวด เช่น เห็ดหลังฝนตก ปฏิบัติการต่างๆ ปรากฏขึ้น:

• TechOps - ผู้ดูแลระบบ enikey หรือที่รู้จักในชื่อ HelpDesk Engineer
• LiveOps - ผู้ดูแลระบบที่รับผิดชอบสภาพแวดล้อมการใช้งานจริงเป็นหลัก
• CloudOps - ผู้ดูแลระบบที่เชี่ยวชาญด้านคลาวด์สาธารณะ Azure, AWS, GCP ฯลฯ
• PlatOps/InfraOps/SysOps - ผู้ดูแลระบบโครงสร้างพื้นฐาน
• NetOps - ผู้ดูแลระบบเครือข่าย
• SecOps - ผู้ดูแลระบบที่เชี่ยวชาญด้านความปลอดภัยของข้อมูล - การปฏิบัติตาม PCI, การปฏิบัติตาม CIS, การแพตช์ ฯลฯ

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

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

สิ่งนี้เป็นจริงในบริษัทของคุณหรือไม่? - ฉันสงสัย. ในกรณีส่วนใหญ่ จะเป็นฝ่าย IT หรือ R&D

การขาดเงินทุนและความสามารถในการมีอิทธิพลต่อกิจกรรมอย่างน้อยหนึ่งในสามด้านนี้จะเปลี่ยนน้ำหนักของปัญหาไปสู่จุดที่การเปลี่ยนแปลงเหล่านี้นำไปใช้ได้ง่ายกว่า เช่น การใช้ข้อจำกัดทางเทคนิคในการเผยแพร่ที่เกี่ยวข้องกับรหัส "สกปรก" ตามแบบคงที่ ระบบวิเคราะห์ นั่นคือ เมื่อ PMO กำหนดเส้นตายที่เข้มงวดสำหรับการเปิดตัวฟังก์ชันการทำงาน R&D ไม่สามารถสร้างผลลัพธ์คุณภาพสูงได้ภายในกำหนดเวลาเหล่านี้ และผลิตออกมาอย่างดีที่สุดเท่าที่จะทำได้ โดยปล่อยให้การปรับโครงสร้างใหม่ในภายหลัง DevOps ที่เกี่ยวข้องกับ IT จะบล็อกการเปิดตัวด้วยวิธีทางเทคนิค . การขาดอำนาจในการเปลี่ยนแปลงสถานการณ์ในกรณีของพนักงานที่รับผิดชอบ นำไปสู่การแสดงความรับผิดชอบมากเกินไปต่อสิ่งที่พวกเขาไม่สามารถโน้มน้าวได้ โดยเฉพาะอย่างยิ่งหากพนักงานเหล่านี้เข้าใจและเห็นข้อผิดพลาด และวิธีแก้ไข - "ความสุขในความไม่รู้" และเป็นผลให้เกิดความเหนื่อยหน่ายและการสูญเสียพนักงานเหล่านี้

ตลาดทรัพยากร DevOps

มาดูตำแหน่งงานว่างสำหรับตำแหน่ง DevOps จากบริษัทต่างๆ กัน

เราพร้อมที่จะพบกับคุณหากคุณ:

1. คุณเป็นเจ้าของ Zabbix และรู้ว่า Prometheus คืออะไร
2. อิปเทเบิล;
3. นักศึกษาปริญญาเอก BASH;
4. ศาสตราจารย์แอนซิเบิล;
5. กูรูลินุกซ์;
6. รู้วิธีใช้การดีบักและค้นหาปัญหาแอปพลิเคชันร่วมกับนักพัฒนา (php/java/python)
7. การกำหนดเส้นทางไม่ได้ทำให้คุณวิตกกังวล
8. ให้ความสำคัญกับความปลอดภัยของระบบเป็นอย่างมาก
9. สำรองข้อมูล "ทุกสิ่ง" และยังกู้คืน "ทุกสิ่ง" นี้สำเร็จอีกด้วย
10. คุณรู้วิธีการกำหนดค่าระบบเพื่อให้ได้ประโยชน์สูงสุดจากขั้นต่ำ
11. ตั้งค่าการจำลองแบบก่อนเข้านอนบน Postgres และ MySQL
12. การตั้งค่าและปรับ CI/CD เป็นสิ่งจำเป็นสำหรับคุณ เช่น อาหารเช้า/กลางวัน/เย็น
13. มีประสบการณ์กับ AWS;
14. พร้อมพัฒนาร่วมกับบริษัท

ดังนั้น:

• ตั้งแต่ 1 ถึง 6 - ผู้ดูแลระบบ
• 7 - การดูแลเครือข่ายเล็กน้อยซึ่งเหมาะกับผู้ดูแลระบบระดับกลางด้วย
• 8 - การรักษาความปลอดภัยเล็กน้อยซึ่งจำเป็นสำหรับผู้ดูแลระบบระดับกลาง
• 9-11 – ผู้ดูแลระบบระดับกลาง
• 12 — ขึ้นอยู่กับงานที่ได้รับมอบหมาย ไม่ว่าจะเป็น Middle System Administrator หรือ Build Engineer
• 13 - การจำลองเสมือน - ผู้ดูแลระบบระดับกลางหรือที่เรียกว่า CloudOps ซึ่งเป็นความรู้ขั้นสูงเกี่ยวกับบริการของไซต์โฮสติ้งเฉพาะ เพื่อการใช้เงินทุนอย่างมีประสิทธิภาพและลดภาระในการบำรุงรักษา

เมื่อสรุปตำแหน่งที่ว่างนี้ เราสามารถพูดได้ว่าผู้ดูแลระบบระดับกลาง/อาวุโสก็เพียงพอแล้วสำหรับคนๆ นี้

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

ลองพิจารณาตำแหน่งว่างอื่น:

1. มีประสบการณ์ในการสร้างระบบรับน้ำหนักสูง
2. มีความรู้ดีเยี่ยมเกี่ยวกับ Linux OS, ซอฟต์แวร์ระบบทั่วไป และ web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK)
3. มีประสบการณ์กับระบบเวอร์ช่วลไลเซชั่น (KVM, VMWare, LXC/Docker)
4. ความเชี่ยวชาญในภาษาสคริปต์
5. ความเข้าใจหลักการทำงานของเครือข่ายโปรโตคอลเครือข่าย
6. ความเข้าใจหลักการของการสร้างระบบที่ทนทานต่อความเสียหาย
7. ความเป็นอิสระและความคิดริเริ่ม

ลองดูที่:

• 1 – ผู้ดูแลระบบอาวุโส
• 2 - ขึ้นอยู่กับความหมายที่ใส่ลงในสแต็กนี้ - ผู้ดูแลระบบระดับกลาง/อาวุโส
• 3 - ประสบการณ์การทำงาน ซึ่งรวมถึง อาจหมายถึง - “คลัสเตอร์ไม่ได้เพิ่ม แต่สร้างและจัดการเครื่องเสมือน มีโฮสต์ Docker หนึ่งโฮสต์ ไม่สามารถเข้าถึงคอนเทนเนอร์ได้” - ผู้ดูแลระบบระดับกลาง
• 4 - ผู้ดูแลระบบรุ่นเยาว์ - ใช่ ผู้ดูแลระบบที่ไม่รู้วิธีเขียนสคริปต์อัตโนมัติขั้นพื้นฐาน โดยไม่คำนึงถึงภาษา ไม่ใช่ผู้ดูแลระบบ - อินิคีย์
• 5 - ผู้ดูแลระบบระดับกลาง
• 6 – ผู้ดูแลระบบอาวุโส

สรุป - ผู้ดูแลระบบระดับกลาง/อาวุโส

อีกอันหนึ่ง:

1. ประสบการณ์ Devops;
2. มีประสบการณ์ในการใช้ผลิตภัณฑ์ตั้งแต่หนึ่งรายการขึ้นไปเพื่อสร้างกระบวนการ CI/CD Gitlab CI จะเป็นข้อได้เปรียบ
3. การทำงานกับคอนเทนเนอร์และการจำลองเสมือน หากคุณใช้นักเทียบท่าก็ดี แต่ถ้าคุณใช้ k8s เยี่ยมมาก!
4. ประสบการณ์การทำงานเป็นทีมที่คล่องตัว
5. ความรู้เกี่ยวกับภาษาการเขียนโปรแกรมใด ๆ

มาดูกัน:

• 1 - อืม... พวกเขาหมายถึงอะไร? =) เป็นไปได้มากว่าพวกเขาไม่รู้ว่ามีอะไรซ่อนอยู่ข้างหลังมัน
• 2 - วิศวกรสร้าง
• 3 - ผู้ดูแลระบบระดับกลาง
• 4 - Soft Skill เราจะไม่พิจารณาในตอนนี้ แม้ว่า Agile จะเป็นอีกสิ่งหนึ่งที่ตีความไปในทางที่สะดวกก็ตาม
• 5 - ละเอียดเกินไป - อาจเป็นภาษาสคริปต์หรือภาษาที่คอมไพล์แล้ว ฉันสงสัยว่าการเขียนในภาษา Pascal และ Basic ที่โรงเรียนจะเหมาะกับพวกเขาหรือไม่? =)

ฉันอยากจะฝากหมายเหตุเกี่ยวกับประเด็นที่ 3 เพื่อทำความเข้าใจว่าทำไมผู้ดูแลระบบจึงครอบคลุมประเด็นนี้ Kubernetes เป็นเพียงการเรียบเรียง ซึ่งเป็นเครื่องมือที่รวบรวมคำสั่งโดยตรงไปยังไดรเวอร์เครือข่ายและโฮสต์การจำลองเสมือน/การแยกส่วนด้วยคำสั่งสองสามคำสั่ง และช่วยให้คุณสามารถสื่อสารกับคำสั่งเหล่านี้เป็นนามธรรมได้ แค่นั้นเอง ตัวอย่างเช่น เรามาสร้าง 'build framework' Make กันดีกว่า ซึ่งฉันไม่ถือว่าเป็น framework เลย ใช่ ฉันรู้เกี่ยวกับแฟชั่นของการผลัก Make ทุกที่ที่จำเป็นและไม่จำเป็น เช่น การห่อ Maven ใน Make จริงจังไหม?
โดยพื้นฐานแล้ว Make เป็นเพียงตัวปิดทับเชลล์ ซึ่งทำให้คำสั่งสภาพแวดล้อมการคอมไพล์ การลิงก์ และการคอมไพล์ง่ายขึ้น เช่นเดียวกับ k8s

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

มาสรุปอีกครั้ง - ผู้ดูแลระบบระดับกลาง/อาวุโสก็เพียงพอแล้วสำหรับพวกเขา

น้ำหนักเท่าไหร่ครับเป็นกรัม

ช่วงของเงินเดือนที่เสนอสำหรับตำแหน่งงานว่างที่ระบุคือ 90-200
ตอนนี้ฉันอยากจะเปรียบเทียบระหว่างผลตอบแทนทางการเงินของผู้ดูแลระบบและวิศวกร DevOps

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

ประสบการณ์:

1. มากถึง 3 ปี - จูเนียร์
2. อายุไม่เกิน 6 ปี – กลาง
3. มากกว่า 6 – ผู้อาวุโส

ไซต์ค้นหาพนักงานเสนอ:
ผู้ดูแลระบบ:

1. จูเนียร์ - 2 ปี - 50 ถู
2. กลาง - 5 ปี - 70 ถู
3. ผู้อาวุโส - 11 ปี - 100 ถู

วิศวกร DevOps:

1. จูเนียร์ - 2 ปี - 100 ถู
2. กลาง - 3 ปี - 160 ถู
3. ผู้อาวุโส - 6 ปี - 220 ถู

จากประสบการณ์ของ “DevOps” ประสบการณ์ถูกใช้ซึ่งอย่างน้อยก็ส่งผลต่อ SDLC

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

กระบวนการฝึกอบรมวิศวกร DevOps ยังจำกัดอยู่เพียงชุดงาน ยูทิลิตี้เฉพาะ และไม่ได้ให้ความเข้าใจทั่วไปเกี่ยวกับกระบวนการและการขึ้นต่อกันของกระบวนการเหล่านั้น เป็นเรื่องดีอย่างแน่นอนเมื่อบุคคลสามารถติดตั้งใช้งาน AWS EKS โดยใช้ Terraform ร่วมกับผู้ช่วย Fluentd ในคลัสเตอร์นี้และสแต็ก AWS ELK สำหรับระบบการบันทึกได้ภายใน 10 นาที โดยใช้เพียงคำสั่งเดียวในคอนโซล แต่ถ้าเขาไม่เข้าใจ หลักการประมวลผลบันทึกและสิ่งที่จำเป็นสำหรับถ้าคุณไม่รู้วิธีรวบรวมตัวชี้วัดและติดตามความเสื่อมโทรมของบริการ มันจะยังคงเป็น enikey คนเดิมที่รู้วิธีใช้ยูทิลิตี้บางอย่าง

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

แล้วพวกเขาเป็นใคร? DevOps หรือผู้ดูแลระบบโลภ? =)

จะอยู่ต่อไปได้อย่างไร?

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

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

ที่มา: will.com