เหตุใดผู้ดูแลระบบจึงควรเป็นวิศวกร DevOps

เหตุใดผู้ดูแลระบบจึงควรเป็นวิศวกร DevOps

ไม่มีเวลาใดที่จะดีไปกว่าการเรียนรู้ในชีวิตมากกว่าวันนี้


นี่คือปี 2019 และ DevOps มีความเกี่ยวข้องมากขึ้นกว่าที่เคย ว่ากันว่ายุคของผู้ดูแลระบบหมดไปแล้วเหมือนกับยุคของเมนเฟรม แต่นี่เป็นเรื่องจริงเหรอ?
เช่นเดียวกับที่เกิดขึ้นบ่อยครั้งในแวดวงไอที ​​สถานการณ์ก็เปลี่ยนไป วิธีการ DevOps เกิดขึ้นแล้ว แต่ไม่สามารถดำรงอยู่ได้หากไม่มีบุคคลที่มีทักษะผู้ดูแลระบบ กล่าวคือ หากไม่มี Ops

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

เหตุใดผู้ดูแลระบบจึงควรเป็นวิศวกร DevOps

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

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

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

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

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

นอกจากการเปลี่ยนวิธีคิดแล้ว คุณยังต้องเรียนรู้วิธีรักษาโครงสร้างพื้นฐานและรับประกันการทำงานที่เสถียร ความน่าเชื่อถือ และความพร้อมใช้งานสำหรับการบูรณาการและการส่งมอบแอปพลิเคชัน บริการ และซอฟต์แวร์อย่างต่อเนื่อง

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

ดังนั้น หากคุณต้องการเรียนรู้ระบบอัตโนมัติ คุณจะต้องเชี่ยวชาญการเขียนโปรแกรมอย่างน้อยสักหน่อย แม้ว่าคุณจะไม่ใช่ Developer เพราะในขั้นตอนนี้ของการพัฒนาของคุณ ระบบโครงสร้างพื้นฐานอัตโนมัติ ใน DevOps ต้องใช้ทักษะนี้

จะทำอย่างไร? เพื่อให้ยังคงเป็นที่ต้องการในฐานะผู้เชี่ยวชาญ คุณจะต้องได้รับทักษะที่เกี่ยวข้อง - เชี่ยวชาญภาษาการเขียนโปรแกรมอย่างน้อยหนึ่งภาษา เช่น Python สิ่งนี้อาจดูยากสำหรับผู้ที่ทำงานด้านการบริหารอย่างมืออาชีพ เนื่องจากเขาคุ้นเคยกับการคิดว่ามีเพียงนักพัฒนาโปรแกรมเท่านั้น ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญ แต่มีความรู้เกี่ยวกับภาษาการเขียนโปรแกรมภาษาใดภาษาหนึ่ง (อาจเป็น Python, Bash หรือแม้แต่ PowerShell) ย่อมได้เปรียบอย่างแน่นอน

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

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

แต่ข้อความนี้เป็นจริงแค่ไหน?

ผู้ดูแลระบบ: นักรบหนึ่งคนในสนาม

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

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

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

เขายังรับผิดชอบในการอัปเกรดฮาร์ดแวร์ การตรวจสอบและวิเคราะห์บันทึก การตรวจสอบความปลอดภัย การแพตช์เซิร์ฟเวอร์ การแก้ไขปัญหา การวิเคราะห์สาเหตุหลัก และระบบอัตโนมัติ—โดยทั่วไปจะผ่านสคริปต์ PowerShell, Python หรือ Bash ตัวอย่างหนึ่งของการใช้งาน สถานการณ์ คือการจัดการบัญชีผู้ใช้และบัญชีกลุ่ม การสร้างบัญชีผู้ใช้และการกำหนดสิทธิ์เป็นงานที่น่าเบื่ออย่างยิ่งเมื่อผู้ใช้ปรากฏและหายไปเกือบทุกวัน การทำงานอัตโนมัติผ่านสคริปต์ช่วยให้มีเวลามากขึ้นสำหรับงานโครงสร้างพื้นฐานที่สำคัญ เช่น การอัพเกรดสวิตช์และเซิร์ฟเวอร์ และโครงการอื่นๆ ที่ส่งผลต่อความสามารถในการทำกำไรของบริษัทที่ผู้ดูแลระบบทำงานอยู่ (แม้ว่าจะเป็นที่ยอมรับกันโดยทั่วไปว่าแผนกไอทีไม่ได้สร้างรายได้โดยตรง)

หน้าที่ของผู้ดูแลระบบคือไม่เสียเวลาและประหยัดเงินของบริษัทในทางที่เป็นไปได้ บางครั้งผู้ดูแลระบบทำงานเป็นสมาชิกของทีมขนาดใหญ่ เช่น ผู้ดูแลระบบ Linux, Windows, ฐานข้อมูล, พื้นที่เก็บข้อมูล และอื่นๆ ตารางการทำงานก็แตกต่างกันไป ตัวอย่างเช่น การเปลี่ยนแปลงในเขตเวลาหนึ่งเมื่อสิ้นสุดวันจะโอนกรณีไปยังกะถัดไปในเขตเวลาอื่น เพื่อให้กระบวนการไม่หยุด (ตามดวงอาทิตย์) หรือพนักงานมีวันทำงานปกติตั้งแต่ 9 น. ถึง 5 น. หรือทำงานในศูนย์ข้อมูลตลอด XNUMX ชั่วโมงทุกวัน

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

DevOps: การพัฒนาและการบำรุงรักษาเป็นหนึ่งเดียว

DevOps เป็นปรัชญาประเภทหนึ่งสำหรับกระบวนการพัฒนาและบำรุงรักษา แนวทางในโลกไอทีนี้ได้กลายเป็นนวัตกรรมอย่างแท้จริง

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

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

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

หัวข้อของระบบอัตโนมัติมีความเกี่ยวข้องมากขึ้น ทั้งผู้ดูแลระบบและผู้เชี่ยวชาญ DevOps สนใจที่จะปรับขนาดอย่างรวดเร็ว ลดข้อผิดพลาด และค้นหาและแก้ไขข้อผิดพลาดที่มีอยู่ได้อย่างรวดเร็ว ดังนั้นระบบอัตโนมัติจึงเป็นแนวคิดที่ทั้งสองส่วนมาบรรจบกัน ผู้ดูแลระบบมีหน้าที่รับผิดชอบบริการคลาวด์ เช่น AWS, Azure และ Google Cloud Platform พวกเขาจะต้องเข้าใจหลักการของการบูรณาการและการส่งมอบอย่างต่อเนื่อง และวิธีการใช้เครื่องมือเช่น เจนกิ้นส์.

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

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

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

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

หากคุณเป็นผู้ดูแลระบบ คุณต้องศึกษา Git ให้ดีขึ้น ทำความเข้าใจวิธีสร้างการควบคุมเวอร์ชัน และจดจำคำสั่งทั่วไป: สถานะ git, git commit -m, git add, git pull, git push, git rebase, สาขา git, git diff และคนอื่น ๆ. มีหลักสูตรและหนังสือออนไลน์มากมายที่สามารถช่วยให้คุณเรียนรู้หัวข้อนี้ตั้งแต่เริ่มต้นและเป็นมืออาชีพที่มีทักษะเฉพาะด้าน นอกจากนี้ยังมีสิ่งมหัศจรรย์ แผ่นโกงด้วยคำสั่ง Gitดังนั้นคุณจึงไม่จำเป็นต้องอัดมันทั้งหมด แต่ยิ่งคุณใช้ Git มากเท่าไร มันก็จะง่ายขึ้นเท่านั้น

ข้อสรุป

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

ที่มา: will.com

เพิ่มความคิดเห็น