5 ความแตกต่างพื้นฐานระหว่าง DevOps และ SRE ที่คุณควรรู้
เผยแพร่แล้ว: 2021-02-22โลกของเทคโนโลยีสารสนเทศและการพัฒนาซอฟต์แวร์มักเชื่อมโยง DevOps กับ SRE เพื่อสื่อถึงสิ่งเดียวกัน อย่างไรก็ตาม ทั้งสองมีความแตกต่างกันอย่างมาก แม้ว่า Site Reliability Engineering (SRE) จะได้รับการตอบรับเป็นอย่างดีในช่วงไม่กี่ปีที่ผ่านมา แต่ DevOps ก็ใช้งานได้นานกว่ามาก (แม้กระทั่งก่อนที่คำว่า DevOps จะมีอยู่)
พูดง่ายๆ คือ DevOps และ SRE เป็นแนวทางปฏิบัติในการส่งมอบซอฟต์แวร์ให้เร็วขึ้น ความแตกต่างเพียงอย่างเดียวระหว่างทั้งสองอยู่ในแนวทางของพวกเขา DevOps มุ่งเน้นไปที่การลดวงจรการพัฒนาซอฟต์แวร์ และ SRE มุ่งเน้นที่การกำจัดจุดอ่อนของระบบเพื่อให้บรรลุเป้าหมายเดียวกัน
ในบทความนี้ เราจะมาดูวิธีการพื้นฐานที่ DevOps และ SRE แตกต่างกัน ก่อนที่เราจะทำอย่างนั้น เรามาเริ่มด้วยการทำความเข้าใจว่า DevOps และ SRE คืออะไร
สารบัญ
DevOps คืออะไร?
ตามคำพูดของ Gene Kim ผู้เขียน The DevOps Handbook และ The Phoenix Project
“DevOps เป็น [the] ของบรรทัดฐานทางวัฒนธรรมและแนวปฏิบัติด้านเทคโนโลยีที่ [เปิดใช้งาน] การไหลที่รวดเร็วของงานที่วางแผนไว้จากการพัฒนา ผ่านการทดสอบสู่การปฏิบัติการในขณะที่รักษาความน่าเชื่อถือ การดำเนินงาน และความปลอดภัยระดับโลก DevOps ไม่ได้เกี่ยวกับสิ่งที่คุณทำ แต่ผลลัพธ์ของคุณคืออะไร”
ดังนั้น DevOps จึงมุ่งเน้นไปที่การเปลี่ยนแปลงแนวปฏิบัติทางวัฒนธรรมภายในองค์กรเป็นหลัก เพื่อเพิ่มความเร็วในวงจรการพัฒนาซอฟต์แวร์ (SDLC) ไม่ได้กำหนดเป้าหมายไปที่บุคคล กลุ่ม หรือตำแหน่ง DevOps มีเป้าหมายเพื่อเสริมสร้างความร่วมมือระหว่างทั้งฝ่ายปฏิบัติการด้านเทคโนโลยีสารสนเทศและทีมพัฒนาซอฟต์แวร์
มันทำอะไรและทำอย่างไรไม่สำคัญ เฉพาะผลลัพธ์ของกระบวนการเท่านั้นที่จะได้รับทราบ
DevOps ใช้ชุดหลักการเพื่อเพิ่มความชัดเจนให้ทีมวิศวกรรมซอฟต์แวร์เปิดเผยต่อระบบการผลิต และทำให้ทีมปฏิบัติการด้านไอทียกระดับความคลาดเคลื่อนไปยังทีมพัฒนาได้อย่างมีประสิทธิภาพมากขึ้น อันที่จริง SRE มีบทบาทสำคัญในองค์กร DevOps โดยอำนวยความสะดวกในการทดสอบเชิงรุก ความเร็ว อนุญาตให้สังเกตได้ และปรับปรุงความน่าเชื่อถือของบริการ DevOps สนับสนุนให้ทุกองค์กรที่มี DevOps เป็นศูนย์กลางให้ดำเนินการตามหลักการทางวัฒนธรรมที่ระบุไว้ในแบบจำลอง CALMS
SRE คืออะไร?
SRE ย่อมาจาก Site Reliability Engineering เป็นคำที่ประกาศเกียรติคุณโดย Ben Treynor รองประธานอาวุโสของ Google ซึ่งมีหน้าที่ดูแลการปฏิบัติงานด้านเทคนิค
Drew Farnsworth (จาก Green Lane Design) อธิบายว่า "โดยทั่วไปแล้วฉันชอบคิดว่า SRE เป็นระบบที่การพัฒนาควบคุมการดำเนินงาน นี่คือระบบที่แบ่งสภาพแวดล้อมออกเป็นส่วนประกอบพื้นฐานที่สุดของสแต็กไอทีและเปิดตัวด้วยแนวทางปฏิบัติที่ดีที่สุดที่รวมเข้ากับฮาร์ดแวร์”
โดยพื้นฐานแล้ว ทีมงาน SREs ที่มีความเชี่ยวชาญในการพัฒนาซอฟต์แวร์มีหน้าที่รับผิดชอบในการแก้ไขปัญหาในการผลิตระบบ ในขณะที่ยังคงรักษาสมดุลระหว่างความเร็วในการจัดส่งและความน่าเชื่อถือของระบบ ในลักษณะนี้ แนวทาง SRE จะรวบรวมบุคลากรด้านการพัฒนาซอฟต์แวร์ภายใต้บทบาทปฏิบัติการ เพื่อใช้แนวทางปฏิบัติด้านวิศวกรรมที่มีโครงสร้าง เพื่อสนับสนุนนโยบายขององค์กร
พวกเขามั่นใจว่าระบบจะพร้อมใช้งานและทำงานอย่างมีประสิทธิภาพตลอดเวลาสำหรับทีมซอฟต์แวร์เพื่อพัฒนาบริการทางเทคนิคเพื่อเพิ่มความน่าเชื่อถือของระบบ เป็นความรับผิดชอบของ SREs ในการระบุจุดอ่อนใดๆ ที่อาจเกิดขึ้นก่อนที่ปัญหาใหญ่จะเกิดขึ้น
DevOps vs SRE: ความแตกต่างสูงสุดระหว่าง DevOps และ SRE
ในทางปฏิบัติ ควรมองว่า DevOps และ SRE เป็นสาขาวิชาเสริม โดยที่ SRE เป็นส่วนหนึ่งของโครงสร้าง DevOps ที่เน้นไปที่การปรับปรุงความน่าเชื่อถือของบริการทางเทคนิคให้ดียิ่งขึ้น โดยพื้นฐานแล้วไม่มีสิ่งใดเช่น DevOps กับ SRE
ดังนั้น สิ่งที่เราทำในส่วนนี้คือการประเมินความแตกต่างพื้นฐานระหว่าง DevOps และ SRE
การดำเนินการเปลี่ยนแปลง
เพื่อให้การอัปเดตเกิดขึ้นบ่อยครั้งและผู้ใช้สามารถเข้าถึงเทคโนโลยีที่ใหม่กว่าและมีความเกี่ยวข้องมากขึ้น ทั้ง DevOps และ SRE ตั้งใจที่จะก้าวอย่างรวดเร็ว อย่างไรก็ตาม DevOps จะค่อยๆ ก้าวไปข้างหน้าด้วยความระมัดระวัง ในขณะที่ SRE คำนึงถึงต้นทุนของความล้มเหลวในการดำเนินการให้เร็วขึ้น
ทั้งใช้ระบบอัตโนมัติและใช้เครื่องมือเพื่อให้บรรลุวัตถุประสงค์นี้
เกี่ยวกับความล้มเหลวตามปกติ
DevOps ยอมรับความล้มเหลวอย่างมากและมองว่าเป็นการเรียนรู้การกดขี่ ด้วยเหตุผลดังกล่าว จึงส่งเสริมวัฒนธรรมที่ไร้ที่ติโดยยอมรับว่าความล้มเหลวเป็นส่วนหนึ่งของกระบวนการและไม่ได้มุ่งเน้นที่การทำให้ระบบทนต่อข้อผิดพลาดได้ 100% ตัวอย่างนี้คือ Netflix กับ Simian Army
ในทางกลับกัน SRE สนับสนุนการชันสูตรพลิกศพอย่างไร้ที่ติ จุดประสงค์เบื้องหลังนี้คือการระบุสาเหตุของความล้มเหลว กำหนดความรับผิดชอบ และทำงานเพื่อหลีกเลี่ยงความล้มเหลวที่คล้ายกันในอนาคต จำนวนข้อผิดพลาดที่ระบบสามารถรับได้รวมอยู่ในงบประมาณข้อผิดพลาด ตัววัด SLI, SLO และ SLA กำหนดสิ่งนี้เพื่อลดต้นทุนการผลิต โดยพื้นฐานแล้ว SRE จะใช้แนวทางปฏิบัติในการติดตามและแจ้งเตือนในเชิงรุกเพื่อหลีกเลี่ยงความล้มเหลวที่อาจเกิดขึ้น
เรียนรู้ หลักสูตรการพัฒนาซอฟต์แวร์ ออนไลน์จากมหาวิทยาลัยชั้นนำของโลก รับโปรแกรม Executive PG โปรแกรมประกาศนียบัตรขั้นสูง หรือโปรแกรมปริญญาโท เพื่อติดตามอาชีพของคุณอย่างรวดเร็ว
ระบบอัตโนมัติเทียบกับนวัตกรรม
DevOps ให้ความสำคัญสูงสุดกับระบบอัตโนมัติ ในสภาพแวดล้อมที่เน้น DevOps สิ่งนี้จะแปลเป็นระบบที่เป็นอัตโนมัติมากที่สุด ส่งผลให้เกิดการเปิดตัวที่น่าเบื่อ หลังจากที่นักพัฒนาคอมมิตโค้ดแล้ว กิจกรรมส่วนใหญ่ต่อไปนี้ (ถ้าไม่ใช่ทั้งหมด) ต้องเป็นแบบอัตโนมัติ
ดังนั้น เหตุผลที่ DevOps ไล่ตาม CI/CD คือการพัฒนาระบบคุณภาพสูงด้วยความเร็วสูงขึ้น
เหตุผลของ SRE ในการติดตาม CI/CD นั้นแตกต่างกัน โดยมีเป้าหมายเพื่อลดต้นทุนของความล้มเหลว งานทั่วไป งานทั่วไป หรืองานซ้ำๆ ในการดำเนินการ เช่น การปรับใช้และการสำรองข้อมูล ถือว่าไม่น่าสนใจ ดังนั้น SREs จึงจัดสรรเวลาเฉพาะเพื่อหลีกเลี่ยงการทำงานหนัก สิ่งนี้ทำเพื่อให้พวกเขาสามารถทำงานที่น่าสนใจมากขึ้นเช่นการดำเนินการหรือสร้างสรรค์เทคโนโลยีใหม่หรือกิจกรรมที่เกี่ยวข้องกับสถาปัตยกรรม
ชำระเงิน: โครงการ DevOps สำหรับผู้เริ่มต้น
การทำลาย ไซโลขององค์กร
นักพัฒนาและเจ้าหน้าที่ดำเนินการขัดแย้งกับกระบวนการปรับใช้ แม้ว่านักพัฒนาจะได้รับประโยชน์จากฟีเจอร์ที่ถูกปรับใช้ทันทีที่มีการเข้ารหัส แต่ทีมปฏิบัติการจะเน้นไปที่การทำให้ระบบพร้อมใช้งานซึ่งขัดขวางกระบวนการปรับใช้
ทั้ง DevOps และ SRE ต่างกันในการลบไซโลในองค์กร
DevOps ตามที่อธิบายไว้ในคู่มือ DevOps จะแก้ไขปัญหานี้โดยรวมแนวทางปฏิบัติ เช่น การทำงานเป็นกลุ่มเล็กๆ และจัดการการกำหนดค่าได้ดียิ่งขึ้น
SRE ไม่เพียงแต่มุ่งหมายเพื่อเพิ่มประสิทธิภาพการไหลระหว่างทีมเท่านั้น แต่ยังช่วยระบบในการผลิตด้วย พวกเขาทำได้โดยการรวมเข้ากับทีมในฐานะที่ปรึกษาและสนับสนุนนักพัฒนาโดยแบ่งปันความรับผิดชอบในการรันระบบ นี่คือวิธีที่ SREs ทำลายไซโลในองค์กร
การวัดผลการดำเนินการที่ประสบความสำเร็จ
ตัวชี้วัด DevOps นั้นเกี่ยวกับความเร็วในการดำเนินการ ซึ่งรวมถึงความถี่ในการปรับใช้ เวลาที่ใช้ในการดำเนินการ และความถี่ที่เกิดปัญหา
ตามรายงานปี 2017 จาก Puppet และ DORA การวัดผลการใช้งานที่ประสบความสำเร็จใน DevOps ขึ้นอยู่กับสิ่งต่อไปนี้:
- ความถี่ที่การนำไปใช้งานเกิดขึ้น
- ระยะเวลาระหว่างการคอมมิตโค้ดและการนำไปใช้งาน
- ความถี่ที่การทำให้ใช้งานได้ล้มเหลว
- ใช้เวลาในการกู้คืนจากความล้มเหลวในการปรับใช้
ลูปป้อนกลับเหล่านี้มีไว้เพื่อช่วยให้ DevOps ปรับปรุงคุณภาพระบบในขณะที่อำนวยความสะดวกในการเปลี่ยนแปลงในการทดลอง
ในทางกลับกัน SRE ทำงานเพื่อปรับปรุงระบบโดยคำนึงถึงความน่าเชื่อถือ จะพิจารณาเมตริกหลักต่อไปนี้เพื่อกำหนดการใช้งานที่ประสบความสำเร็จ:
- วัตถุประสงค์ระดับการให้บริการ (SLO)
- ตัวบ่งชี้ระดับการบริการ (SLI)
- ข้อตกลงระดับการให้บริการ (SLA)
ตัวชี้วัดที่กล่าวถึงข้างต้นเป็นตัวบ่งชี้ความน่าเชื่อถือของระบบ เมตริกเหล่านี้จะกำหนดล่วงหน้าว่าการเผยแพร่การเปลี่ยนแปลงจะไปถึงการผลิตหรือไม่
ใน SRE ตัวชี้วัดความเร็วและคุณภาพเหล่านี้มีประโยชน์เมื่อสร้างงบประมาณข้อผิดพลาดและปรับปรุงความน่าเชื่อถือของระบบแทนที่จะทำงานกับคุณสมบัติใหม่
อ่าน: เงินเดือนวิศวกร DevOps ในอินเดีย
บทสรุป
Google ได้เผยแพร่ eBook เกี่ยวกับวิธีการติดตั้ง Site Reliability Engineering ในระบบที่ใช้งานจริง ซึ่ง Treynor อธิบาย SRE ว่า
“SRE คือสิ่งที่เกิดขึ้นเมื่อคุณขอให้วิศวกรซอฟต์แวร์ออกแบบทีมปฏิบัติการ”
เมื่อพูดถึงความแตกต่างของ DevOps และ SRE ทั้งหมดที่คุณต้องจำไว้ก็คือ SRE นั้นขับเคลื่อนโดยนักพัฒนามากกว่าทีมปฏิบัติการ ทั้งการบำรุงรักษาและการตรวจสอบอยู่ภายใต้การควบคุมของนักพัฒนาเป็นหลัก นั่นคือสิ่งที่ทำให้ทั้งสองสาขาวิชาแตกต่างออกไป
หากคุณสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับ DevOps ขนาดใหญ่ การพัฒนาสแต็กแบบเต็ม ลองดู โปรแกรม Executive PG ของ upGrad & IIIT-B ในด้านการพัฒนาซอฟต์แวร์- ความเชี่ยวชาญพิเศษด้านการพัฒนาแบบครบวงจร ซึ่งออกแบบมาสำหรับมืออาชีพที่ทำงานและมีการฝึกอบรมที่เข้มงวดมากกว่า 500 ชั่วโมง โครงการและการมอบหมายงานมากกว่า 9 รายการ สถานะศิษย์เก่า IIIT-B โครงการหลักที่ปฏิบัติได้จริง และความช่วยเหลือด้านงานกับบริษัทชั้นนำ
