Sysadmin และ DevOps Engineer แตกต่างกันอย่างไร

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

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

DevOps ส่วนใหญ่ไม่ใช่บทบาท (เมื่อใช้เช่นนี้จะเป็น buzzword มากกว่าบทบาทจริง)

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

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

เวอร์ชั่นสั้น

DevOps เป็นการผสมผสานระหว่างวัฒนธรรมองค์กร, วิธีการทำงานแบบ Agile / Lean และซอฟต์แวร์อัตโนมัติที่เมื่อนำไปใช้กับการบริหารระบบและการปฏิบัติการช่วยให้ฟังก์ชั่นเหล่านี้ทำงานด้วยความคล่องตัวในระดับเดียวกับ Agile หรือ Lean Development Teams

รุ่นยาว

แนวคิดที่อยู่เบื้องหลัง DevOps นั้นมาจากชุมชนการบริหารระบบการดำเนินงานและความคล่องตัวโดยเฉพาะPatrick Deboisได้นำเสนอที่ Agile2008 ในหัวข้อ 'โครงสร้างพื้นฐานแบบ Agile' ซึ่งเขาเน้นความแตกต่างระหว่างวิธีที่สามหน้าที่ภายในองค์กร:

1. ทีมพัฒนา Agile - ทีมงานเปรียวเขียนโค้ด
2. ทีมบริหารระบบ - สร้างโครงสร้างพื้นฐานเพื่อใช้งานซอฟต์แวร์
3. ทีมปฏิบัติการ - สนับสนุนแอปพลิเคชันและโครงสร้างพื้นฐานในการผลิต / สด

ข้อเสนอของ Debois คือการรวมสามวิธีในการทำงานร่วมกันโดยเฉพาะการย้ายทีมการบริหารระบบและทีมปฏิบัติการจากแบบจำลอง Waterfallไปเป็นแบบ Agile ไปสิ้นสุดที่ Debois ติดตั้งDevOpsDays 2009 ใน Ghent เบลเยียมโดยไม่ได้ตั้งใจสร้างวลีDevOps

ความคิดของ DevOps สะท้อนกับหนังสือชุด VisibleOps: Gene Kim, George Spafford และ Kevin Behr; ที่ไปในการเขียนฟีนิกซ์โครงการและDevOps คู่มือ หนังสือทั้งสองเล่มสำรวจว่า Agile และ Lean สามารถส่งผลกระทบเชิงบวกต่อทีมผู้ดูแลระบบและทีมปฏิบัติการ

ในฐานะที่เป็นวิศวกรDevOps ที่มาจากพื้นหลังการดำเนินงานคุณจะต้องย้ายจากการสร้างและปรับใช้เซิร์ฟเวอร์และซอฟต์แวร์ด้วยตนเองเพื่อสคริปต์การติดตั้งซอฟต์แวร์ลงบนเซิร์ฟเวอร์ของคุณด้วยการกด BASH, PowerShell, Python เป็นต้นหลังจากนั้นไม่นาน เย็นสคริปต์ถูกและเริ่มที่จะสำรวจวิธีการที่มีความซับซ้อนมากขึ้นในการใช้งานโดยอัตโนมัติ

ในที่สุดคุณจะได้ตัดสินบนChef, Puppet, Ansibleหรือเครื่องมือการจัดการการกำหนดค่าอื่น ๆเพื่อช่วยจัดการสถานะของระบบของคุณ เนื่องจากทักษะของคุณในการใช้งานแอพพลิเคชั่นและการจัดการระบบที่ครบกำหนดพร้อมกับเครื่องมือของคุณคุณได้ย้ายเข้าสู่ขอบเขตของ ' Infrastructure as Code ' และใช้มันเพื่อไม่เพียง แต่ทำให้การปรับใช้ซอฟต์แวร์เป็นอัตโนมัติ เพื่อขับเคลื่อนซอฟต์แวร์ในระหว่างที่ธุรกิจเปลี่ยนมาใช้ Cloud

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

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

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

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

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

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

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

Sysadmin vs. DevOps (มุมมองส่วนตัว)

บาง บริษัท พูดถึง Dev, Ops และ Test หากบางสิ่งจำเป็นต้องทำการทดสอบพวกเขาจะพูดว่า: "การทดสอบควรทำเช่นนั้น" หากจำเป็นต้องได้รับการพัฒนา Dev จะทำเช่นนั้นและหากจำเป็นต้องปรับใช้ซอฟต์แวร์ Ops จะทำเช่นนั้น

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

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

อ้างอิง

ดูแลระบบ

ตามที่Wikipedia :

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

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

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

DevOps

ตามที่Wikipedia :

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

DevOps

DevOps Toolchain

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

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

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

จะมีเซิร์ฟเวอร์ที่คุณไม่ได้ยินเสียงในศูนย์ข้อมูล ทุกอย่างจะเป็นซอฟต์แวร์ ที่เก็บข้อมูลเครือข่ายระบบความปลอดภัยดาต้าเซ็นเตอร์; SDN, ไฟร์วอลล์, NFV, ที่เก็บข้อมูล, เซิร์ฟเวอร์, ฯลฯ Sysadmins ที่ไม่มีพื้นฐานการพัฒนาซอฟต์แวร์, ประสบการณ์ SDLC (ฉันไม่ได้หมายถึงสคริปต์ Perl, Powershell, ฯลฯ ) อาจหายไป สภาพแวดล้อมแบบกระจายปรับขนาดได้และเสมือนจริงซึ่งส่วนใหญ่เป็นระบบคลาวด์เติบโตในแนวนอนไม่ใช่แนวตั้ง

ฉันกล้าพูดว่า Sysadmins เติบโตในแนวดิ่ง DevOps (หรือ OpsDev) เติบโตในแนวนอน คุณสามารถเห็นรูปแบบเดียวกันกับการพัฒนาไมโครไซต์จาก monoliths ฉันอยากเลือกวิศวกร DevOps จากทีมซอฟต์แวร์ไม่ใช่จากทีมปฏิบัติการ / ระบบ

เพราะทีมงาน / ระบบเพียงแค่ทำงานในสิ่งที่ทีมซอฟต์แวร์สร้าง

• Sysadmins ไม่ได้สร้าง / คอมไพล์ Linux / FreeBSD / windows kernel เป็นต้นเช่นเดียวกับวิศวกรซอฟต์แวร์ที่สร้าง / คอมไพล์แอปพลิเคชัน
• Sysadmins ไม่ผ่านวงจรการพัฒนาซอฟต์แวร์ (SDLC)
• Sysadmins ไม่ได้เป็นส่วนหนึ่งของขั้นตอนการผลิต (กระบวนการ CI / CD)

• ดูแลระบบเริ่มทำงานหลังจาก CI / การส่งมอบ / การใช้งานอย่างต่อเนื่องสิ้นสุดลง

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

ดูเหมือนว่าไม่มีเซิร์ฟเวอร์ / ระบบในการจัดการไม่จำเป็นต้องดูแลระบบ

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

บางคนจากทีมซอฟต์แวร์รู้วิธีสร้างรักษาวิธีการใช้รหัส (SRE กับ DevOps / OpsDev)

ฉันสงสัยว่าทำไมเรียกว่า DevOps แต่ไม่ใช่ OpsDev มันเกี่ยวข้องกับทิศทางระหว่างสองหรือไม่?

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

เกี่ยวกับพื้นที่เก็บข้อมูลที่กำหนดโดยซอฟต์แวร์

• Software-defined storage (SDS) เป็นคำศัพท์ทางการตลาดสำหรับซอฟต์แวร์จัดเก็บข้อมูลคอมพิวเตอร์สำหรับการจัดเตรียมนโยบายและการจัดการการจัดเก็บข้อมูลโดยไม่ขึ้นอยู่กับฮาร์ดแวร์พื้นฐาน พื้นที่เก็บข้อมูลที่กำหนดโดยซอฟต์แวร์

• EMC ประกาศเปิดตัวผลิตภัณฑ์โอเพ่นซอร์สรุ่นแรก: Project CoprHD CoprHD เป็นระบบจัดเก็บและควบคุมอัตโนมัติของ Software Defined Storage และการตัดสินใจล่าสุดของ EMC ในการเปิดโอเพ่นซอร์สนั้นเป็นจุดเริ่มต้นของกลยุทธ์ของเราในการส่งมอบคุณค่าที่มากขึ้นให้กับธุรกิจทั่วโลกเมื่อเราเข้าสู่การเติบโตและการเปลี่ยนแปลง ในฐานะที่เป็นผู้นำของโลกในการจัดเก็บและการจัดการข้อมูลก็ behooves อีเอ็มซีเพื่อนำไปสู่วิธีการในการจัดเก็บที่กำหนดซอฟต์แวร์ (SDS)

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