ITIL, DevOps และ SRE ทำงานร่วมกันสำหรับองค์กรของคุณอย่างไร
เผยแพร่แล้ว: 2020-03-02เมื่อมีคนถามว่าองค์กรของคุณเป็น "ร้านค้า" ประเภทใด คุณสามารถตอบได้อย่างมั่นใจว่าเป็น ITIL, DevOps หรือ SRE
บางทีบางคนอาจทำได้ แต่ถ้าคุณเป็นองค์กรขนาดใหญ่ คำตอบน่าจะเป็นการผสมผสานระหว่างรูปแบบการทำงานเหล่านี้ โดยเฉพาะอย่างยิ่งเนื่องจาก SRE ได้กลายเป็นส่วนสำคัญของการนำ DevOps ไปใช้งาน ITIL สามารถทำงานควบคู่ไปกับหลักการ DevOps และ SRE ได้อย่างมีประสิทธิภาพ แม้ว่าในแวบแรกดูเหมือนว่าจะเป็นสายพันธุ์ที่แตกต่างกัน
เคล็ดลับคือทำให้แน่ใจว่าไม่ว่ารูปแบบการดำเนินงานหรือ toolchain ขององค์กรของคุณจะต่างกันอย่างไร จะมีการแชร์การมองเห็น การสื่อสาร และการทำงานร่วมกันระหว่างทีม วิธีนี้จะช่วยให้ทีมที่แตกต่างกันของคุณอยู่ในแนวเดียวกันในขณะที่ใช้แนวทางปฏิบัติที่ดีที่สุดจากแต่ละวิธี
ITIL คืออะไร? ถ้าคุณไม่คุ้นเคย…
ITIL ย่อมาจาก ห้องสมุดโครงสร้างพื้นฐานด้านเทคโนโลยีสารสนเทศ และเป็นวิธีการที่พัฒนาขึ้นเพื่อสร้างแหล่งเดียวของแนวทางปฏิบัติที่ดีที่สุดสำหรับเทคโนโลยีสารสนเทศ ตามที่ Sarah K. White และ Lynn Greiner:
“ITIL ได้รับการพัฒนาโดย Central Computer and Telecommunications Agency (CCTA) ของรัฐบาลอังกฤษในช่วงทศวรรษ 1980 โดยครั้งแรกที่ประกอบด้วยหนังสือมากกว่า 30 เล่ม พัฒนาและเผยแพร่เมื่อเวลาผ่านไป ซึ่งได้ประมวลแนวปฏิบัติที่ดีที่สุดในเทคโนโลยีสารสนเทศที่สะสมมาจากหลายแหล่ง (รวมถึงผู้ขายที่ดีที่สุด) ปฏิบัติ) ทั่วโลก”
ITIL ได้รับการอัปเดตเป็นเวอร์ชันที่สี่แล้ว และวิธีการย่อเป็นหนังสือเก้าเล่ม ในขณะที่หนังสือเหล่านี้สะท้อนถึงยุคเทคโนโลยีที่ทันสมัย อุดมคติเหล่านี้รวมถึง "กระบวนการอัตโนมัติ การปรับปรุงการจัดการบริการ และการบูรณาการแผนกไอทีเข้ากับธุรกิจ" ITIL เป็นวิธีการแบบจากบนลงล่างมาก มีโครงสร้างสูง และขับเคลื่อนด้วยกระบวนการ และยังคงเป็นหนึ่งในเฟรมเวิร์กไอทีที่นำมาใช้มากที่สุดในปัจจุบัน
แนวทางปฏิบัติที่สำคัญบางประการของ ITIL ได้แก่ แคตตาล็อกบริการและการออกแบบ การตรวจสอบและการจัดการเหตุการณ์ การจัดการเหตุการณ์และปัญหา การจัดการรุ่น การจัดการการกำหนดค่า และอื่นๆ แนวทางปฏิบัติทั้งหมดนี้มีขึ้นโดยไม่คำนึงถึงรูปแบบการดำเนินงาน แต่อาจแสดงออกแตกต่างกันในบริบทของความต้องการด้านสถาปัตยกรรมและเวิร์กโฟลว์ที่แตกต่างกัน แนวทางปฏิบัติเหล่านี้มักมีประโยชน์แม้กระทั่งสำหรับองค์กรที่ระบุว่าเป็นร้านค้า DevOps หรือ SRE
ความสัมพันธ์ระหว่าง ITIL และ ITSM คืออะไร?
ITSM หรือการจัดการความปลอดภัยเทคโนโลยีสารสนเทศเป็นกระบวนการสำหรับวิธีที่บริษัทจัดการบริการด้านไอที กระบวนการนี้เน้นที่ลูกค้าเป็นหลัก และโดยทั่วไปประกอบด้วย 5 ขั้นตอน:
- กลยุทธ์การบริการ
- การออกแบบบริการ
- การเปลี่ยนแปลงการบริการ
- การให้บริการ
- ปรับปรุงบริการอย่างต่อเนื่อง
ITIL เป็นกรอบสำหรับการนำแนวทางปฏิบัติของ ITSM ไปใช้ เฟรมเวิร์กนี้มีความเป็นกลางในองค์กร จึงสามารถนำไปใช้กับธุรกิจเกือบทั้งหมด แม้ว่าลูกค้าที่ฝ่ายไอทีมุ่งเน้นจะเป็นลูกค้าภายในเท่านั้นก็ตาม เนื่องจากมีการเชื่อมโยงอย่างใกล้ชิดจึงไม่น่าแปลกใจที่ ITIL และ ITSM จะสอดคล้องกับหลายประเด็น
ตาม itiltraining.com:
“มีความสำคัญอย่างมากในการปรับปรุงอย่างต่อเนื่อง ซึ่งเกี่ยวข้องกับการวัดและปรับปรุงกระบวนการ บริการด้านไอที และโครงสร้างพื้นฐานด้านไอทีอย่างสม่ำเสมอ การทำเช่นนี้จะช่วยเพิ่มประสิทธิภาพ ประสิทธิผล และความคุ้มค่าสูงสุด”
ITIL ทำงานอย่างไรกับ DevOps
เมื่อคุณปฏิบัติตามกระบวนการ ITIL คุณมุ่งเน้นที่การปรับ IT ให้สอดคล้องกับเป้าหมายทางธุรกิจขององค์กรของคุณ สิ่งนี้เข้ากันได้ดีกับปรัชญา DevOps ในการทำลายระบบไซโลทั่วทั้งองค์กร นอกจากนี้ คุณสามารถขจัดปัญหาคอขวดในการสื่อสารได้ ซึ่งจะทำให้ทีมจัดส่งคุณลักษณะที่ลูกค้าต้องการได้เร็วขึ้นและปฏิบัติตามโมเดล CAMS (วัฒนธรรม ระบบอัตโนมัติ การวัดผล การแบ่งปัน) อย่างใกล้ชิดยิ่งขึ้น แต่สิ่งนี้มีลักษณะอย่างไรเมื่อนำไปใช้กับองค์กร
ใช้ตอนไหน?
องค์กรของคุณอาจใช้ ITIL และ DevOps ในสถานการณ์ต่างๆ เพื่อหาโซลูชันที่มีประสิทธิภาพมากที่สุดสำหรับสถานการณ์ต่างๆ ตัวอย่างเช่น อาจเหมาะสมที่จะใช้ประโยชน์จากแนวทางปฏิบัติที่ดีที่สุดของ DevOps ระหว่างทีมพัฒนาและทีมปฏิบัติการ ซึ่งจำเป็นต้องปรับให้สอดคล้องกันในเวิร์กโฟลว์ การพุชโค้ด ระบบอัตโนมัติ และการตรวจสอบ
อย่างไรก็ตาม เมื่อสื่อสารระหว่างส่วนต่างๆ ขององค์กรที่อาจทำงานด้วยความเร็วต่างกัน กล่าวคือ การขายและไอที แนวทางปฏิบัติของ ITIL อาจมีประโยชน์ กราฟด้านล่างนี้เป็นเพียงตัวอย่างเล็กๆ น้อยๆ เกี่ยวกับวิธีการนำวิธีการทั้งสองไปใช้ในสถานการณ์ที่แตกต่างกัน:

ความสอดคล้องระหว่างไอทีกับส่วนที่เหลือขององค์กรของคุณ
ผลลัพธ์ของการใช้แนวทางปฏิบัติที่ดีที่สุดของ ITIL และ DevOps ผสมผสานกันคือการปรับให้เข้ากับเป้าหมายทั่วทั้งองค์กรได้ดีขึ้น เมื่อฝ่ายไอทีและส่วนอื่นๆ ขององค์กรทำหน้าที่เป็นหน่วยงานอิสระโดยสิ้นเชิง ฝ่ายหนึ่งมักจะรู้สึกว่าทำงานหนักเกินไปและไม่ได้รับการสนับสนุน ใน “The Phoenix Project” นวนิยายที่กล่าวถึงการต่อสู้ดิ้นรนขององค์กรสมมติกับการรวมไอที เรื่องนี้กลายเป็นความขัดแย้งหลัก
ในหนังสือเล่มนี้ ฝ่ายไอทีมีหน้าที่รับผิดชอบบางส่วนในการวิจัยและพัฒนาและการริเริ่มการขายที่ประสบความสำเร็จ R&D ต้องการข้อมูลที่ถูกต้องและการรายงานสินค้าคงคลังเพื่อเติมเต็มสินค้าคงคลังและออกสู่ตลาดด้วยผลิตภัณฑ์ใหม่ในเวลาที่เหมาะสม ฝ่ายขายจำเป็นต้องมีระบบ CRM โทรศัพท์/ข้อความเสียง และระบบ MRP ที่มีประสิทธิภาพ มิฉะนั้น พวกเขาไปโดยไม่มีความสามารถในการเพิ่มหรือเปลี่ยนแปลงคำสั่งซื้อของลูกค้า และไม่มีวิธีจัดการสุขภาพของลูกค้า
หากไม่มีการสื่อสารข้ามสายงาน ก็ไม่มีทางวางแผนสำหรับการเปลี่ยนแปลงที่จำเป็นเหล่านี้ ในทางกลับกัน แผนกต่างๆ เรียกร้องซึ่งกันและกันอย่างไม่สมเหตุสมผล ลูกบอลถูกทิ้งบ่อยครั้ง และรายได้ของบริษัทก็ลดลง
ความขัดแย้งนี้ได้รับการแก้ไขเมื่อฝ่ายไอทีประสานงานและสื่อสารกับส่วนที่เหลือขององค์กร และหัวหน้าแผนกอื่นๆ ได้ให้การสนับสนุนระดับสูงสำหรับการริเริ่มด้านไอที โดยการพังทลายของไซโลและการทำงานร่วมกัน ปัญหาเหล่านี้ได้รับการแก้ไขมากมาย
บางครั้ง จังหวะเวลาของการริเริ่มด้านไอทีและการริเริ่มทางธุรกิจอาจดูเหมือนไม่ตรงกัน อย่างไรก็ตาม ด้วยการใช้แนวทางปฏิบัติที่ดีที่สุดของ ITIL และ DevOps องค์กรต่างๆ สามารถสร้างไทม์ไลน์ที่สอดคล้องกันได้ ด้านล่างเป็นกราฟที่แสดงให้เห็นว่ากระบวนการเหล่านี้สามารถทำงานพร้อมกันได้อย่างไรเพื่อตอบสนองทั้งองค์กร

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

หลักเจ็ดของ ITIL 4
ด้านล่างนี้เป็นหลักการทั้งเจ็ดของ ITIL 4 มาพูดคุยกันในรายละเอียดเพิ่มเติม
1. เริ่มต้นจากที่ที่คุณอยู่
การนำแนวทางปฏิบัติที่ดีที่สุดของ SRE มาใช้ไม่ได้มีขนาดเดียว และทุกคนต้องเริ่มจากที่ใดที่หนึ่ง ทำตามขั้นตอนแรกและนำไปใช้และทำซ้ำไปเรื่อยๆ เป็นสิ่งสำคัญที่สุด
2. ทำให้มันง่ายและใช้งานได้จริง
ในบทของหนังสือ Google SRE เรื่องความเรียบง่าย ระบุว่า:
“ไม่เหมือนกับทุกสิ่งในชีวิต 'ความน่าเบื่อ' เป็นคุณลักษณะเชิงบวกเมื่อพูดถึงซอฟต์แวร์! เราไม่ต้องการให้โปรแกรมของเราเป็นไปตามธรรมชาติและน่าสนใจ เราต้องการให้พวกเขาปฏิบัติตามสคริปต์และบรรลุเป้าหมายทางธุรกิจที่คาดการณ์ได้”
ความเรียบง่ายทั้งในซอฟต์แวร์และการดำเนินธุรกิจช่วยเพิ่มความคล่องตัวในการสื่อสาร เพิ่มความเร็ว และช่วยให้มั่นใจได้ว่าไม่มีการลดทอนความน่าเชื่อถือ น้อยมาก
3. เพิ่มประสิทธิภาพและทำให้เป็นอัตโนมัติ
เป้าหมายอย่างหนึ่งของ SRE คือการทำให้กระบวนการที่ทำงานหนักเป็นอัตโนมัติ และเพิ่มเวลาว่างให้กับนักพัฒนาในการมุ่งเน้นที่นวัตกรรมแทนการทำงานที่ไม่ได้วางแผนไว้ วิธีนี้ช่วยเพิ่มประสิทธิภาพเวิร์กโฟลว์และช่วยให้คุณลักษณะใหม่จัดส่งได้เร็วขึ้น
4. ความคืบหน้าซ้ำ ๆ กับข้อเสนอแนะ
SREs ตั้งค่าการแจ้งเตือนสำหรับตัวชี้วัดที่สำคัญที่สุดและเน้นผู้ใช้เป็นศูนย์กลาง เมตริก การแจ้งเตือน และ SLO ที่เชื่อมโยงทั้งหมดได้รับการทำซ้ำเพื่อตอบสนองความต้องการของลูกค้า
5. ทำงานร่วมกันและส่งเสริมการมองเห็น
SRE เป็นความร่วมมือทางวัฒนธรรม มุ่งเน้นไปที่วัฒนธรรมการทำงานที่ไร้ตำหนิซึ่งให้ความสำคัญกับการเรียนรู้จากความล้มเหลว และเชื่อมั่นว่าสมาชิกในทีมแต่ละคนทำในสิ่งที่เขาหรือเธอคิดว่าดีที่สุดสำหรับองค์กร
6. เน้นคุณค่า
หากไม่มีลูกค้า ซอฟต์แวร์ก็ไม่มีค่า มูลค่าทางธุรกิจถูกสร้างขึ้นเมื่อลูกค้าต้องการและได้รับสิ่งที่ต้องการจากผลิตภัณฑ์ แนวทางปฏิบัติที่ดีที่สุดของ SRE ทำให้มั่นใจได้ว่าผลิตภัณฑ์มีความน่าเชื่อถือเพียงพอที่จะมอบคุณค่าให้กับลูกค้า ดังนั้นจึงเป็นการมอบคุณค่าให้กับองค์กร
7. คิดและทำงานแบบองค์รวม
โดยการทำลายระบบไซโลและมุ่งเน้นไปที่ความสามารถในการปรับขนาดและความน่าเชื่อถือในระดับองค์รวม SRE สามารถให้ประโยชน์ที่สำคัญในการทำให้องค์กรเติบโตเต็มที่ ความสำเร็จทั่วทั้งธุรกิจอยู่ในมือของสมาชิกในทีมทุกคน และ SRE ทำงานเพื่อให้แน่ใจว่าผลิตภัณฑ์ ระบบ และขั้นตอนของบริษัทมีความยืดหยุ่นเพียงพอที่จะไม่เพียงแค่เป็นไปตามมาตรฐานแต่เกินมาตรฐานลูกค้า
การจัดการการเปลี่ยนแปลงที่ยืดหยุ่นและรวดเร็ว
หนึ่งในแนวทางปฏิบัติที่ดีที่สุดของ ITIL คือการประสานงานการจัดการการเปลี่ยนแปลงที่ดูแลโดยคณะกรรมการอนุมัติการเปลี่ยนแปลง (CAB) อย่างไรก็ตาม ตามที่ระบุไว้โดยพันธมิตรที่ Mindbridge Kaimar Karu:
“การให้ CAB ตรวจสอบคำขอเปลี่ยนแปลงทุกครั้งนั้นไม่มีประสิทธิภาพ และไม่ใช่เรื่องปกติทั่วไป โดยเฉพาะอย่างยิ่งเมื่อค่าใช้จ่ายของ CAB สามารถทำงานได้หลายหมื่นครั้งต่อชั่วโมงในบางองค์กร อย่างไรก็ตาม การให้ CAB ตรวจสอบคำขอเปลี่ยนแปลงความเสี่ยงที่ไม่ทราบสาเหตุ เมื่อจำเป็นต้องปรึกษากับส่วนต่างๆ ของธุรกิจเนื่องจากอาจได้รับผลกระทบ เป็นเรื่องที่สมเหตุสมผลมาก”
SRE สามารถช่วยในเรื่องนี้ได้ และหลักการสำคัญของ SRE ช่วยอำนวยความสะดวกในการจัดการการเปลี่ยนแปลงที่ยืดหยุ่นและรวดเร็วยิ่งขึ้น การปฏิบัติทางโทรศัพท์ช่วยให้ทีมมีความรับผิดชอบมากขึ้นตลอดเวลาสำหรับโค้ดในการผลิต การย้อนกลับสามารถทำได้โดยอัตโนมัติโดยเป็นส่วนหนึ่งของการแก้ไขอย่างรวดเร็ว ชันสูตรพลิกศพของเหตุการณ์ช่วยอำนวยความสะดวกในการเรียนรู้เชิงลึกที่สำคัญ เช่น SLO ช่วยให้ทีมสามารถปรับตัวในสิ่งที่สำคัญและตัดผ่านความซับซ้อนที่ระเบิดได้ของการจัดการบริการที่ทันสมัย
นอกจากนี้ งบประมาณข้อผิดพลาดจะสร้างแนวทางสำหรับทีมพัฒนาว่าเมื่อใดที่สามารถส่งคุณลักษณะใหม่ได้อย่างปลอดภัย หากงบประมาณผิดพลาดมีที่ว่างเพียงพอ การเปลี่ยนแปลงจะได้รับการอนุมัติ แต่ถ้างบประมาณข้อผิดพลาดหมดลงหรือใกล้หมดลง การเปลี่ยนแปลงจะถูกเลื่อนออกไปจนกว่าจะถึงหน้าต่างถัดไป
ความยืดหยุ่นที่เพิ่มขึ้นนี้ยังได้รับแรงบันดาลใจจากแนวคิดความเป็นผู้นำของ SRE แทนที่จะใช้ปรัชญาการควบคุมและสั่งการ SRE ตระหนักถึงความจำเป็นในความยืดหยุ่นในสภาพแวดล้อมที่เปลี่ยนแปลงตลอดเวลาและมุ่งเน้นไปที่บริบทเหนือการควบคุม ซึ่งหมายความว่าหากต้องจัดส่งคุณสมบัติที่มีความสำคัญต่อธุรกิจ ฟีเจอร์นั้นจะถูกจัดส่ง
ดรีมทีม ITIL, DevOps และ SRE
แม้ว่าบางองค์กรจะดำเนินการตามบริบทของวิธีการเหล่านี้เพียงอย่างเดียว แต่หลายๆ องค์กรพบว่าการผสมผสานของทั้งสามวิธีนี้เป็นวิธีที่มีประสิทธิภาพมากที่สุดในการปรับเป้าหมายทางธุรกิจและไอทีเพื่อสร้างบริการที่ปลอดภัยและเชื่อถือได้ ด้านล่างเป็นกราฟแสดงจุดแข็งของแต่ละวิธี แม้ว่าอาจใช้หลักการเดียวกันและพยายามบรรลุผลแบบเดียวกัน แต่จริงๆ แล้ววิธีการนั้นแตกต่างกันและเสริมกันอย่างมาก
ITIL | DevOps | SRE | |
ปรัชญาและวัฒนธรรม | ปรับ IT ให้เข้ากับความต้องการทางธุรกิจเพื่อสร้างความสัมพันธ์แบบพึ่งพาอาศัยกัน สั่งการและควบคุมและขับเคลื่อนกระบวนการเพื่อลดความเสี่ยง | ปรับปรุงการทำงานเป็นทีมและกำจัดไซโล มุ่งสร้างแนวร่วมและลดไซโลระหว่างการพัฒนาและการดำเนินงาน มักจะมุ่งเน้นไปที่การช่วยเหลือทีมในการปรับปรุงความเร็วและคุณภาพของการปรับใช้ | หมดปัญหางานหนัก ออกแบบให้ใช้งานได้จริง ถือว่าการดำเนินงานเป็นปัญหาซอฟต์แวร์เพื่อเพิ่มประสิทธิภาพสูงสุด เหมาะอย่างยิ่งเพื่อรองรับบริการแบบกระจายในขนาดที่ต้องการความน่าเชื่อถือสูง |
แนวทางปฏิบัติและเครื่องมือที่สำคัญ | วางแผนกำลังการผลิต แคตตาล็อกบริการ/CMDB การจัดการปัญหา เปลี่ยนผู้บริหาร/คณะที่ปรึกษา | วางแผนกำลังการผลิต โทรอยู่ ไมโครเซอร์วิส CI/CD อินฟาเรดเป็นรหัส การตรวจสอบและการบันทึก การสื่อสารและความร่วมมือ | จับคู่แนวทางปฏิบัติที่สำคัญของ DevOps ควบคู่ไปกับ: การเปิดตัวแบบก้าวหน้า SLO และงบประมาณข้อผิดพลาด การสังเกต วิศวกรรมโกลาหล |
การทำงานเป็นทีม | โมเดลดั้งเดิมของกระบวนการรวมศูนย์และการมองเห็น โดยปกติงานจะเข้าคิว ('น้ำตก') เหตุการณ์ที่ส่งผ่านทีม NOC ส่วนกลาง | นักพัฒนาและผู้ปฏิบัติงานร่วมกันใช้กระบวนการและเครื่องมือเดียวกันมากขึ้นตลอดวงจรชีวิตบริการทั้งหมด โดยทั่วไปแล้ว นี่หมายความว่า devs ดำเนินการตามสิ่งที่พวกเขาสร้างขึ้น แต่อาจมีส่วนร่วมกับ ops สำหรับการสนับสนุน L2 | SRE มักจะทำหน้าที่เป็นที่ปรึกษาเพื่อสร้างแนวทางปฏิบัติที่เน้นความน่าเชื่อถือ วิศวกรซอฟต์แวร์และบทบาทของ SRE มาบรรจบกัน โดยสอดคล้องตามกระบวนการและผลลัพธ์ที่ใช้ร่วมกัน |
มาตรการสำคัญ | ความพร้อมใช้งาน # เหตุการณ์ # การส่งต่อ ฯลฯ | ความพร้อมใช้งาน ความถี่ในการใช้งาน ฯลฯ | SLO เช่นเดียวกับความพร้อมใช้งาน ความถี่ในการปรับใช้ ฯลฯ งบประมาณผิดพลาด |
บทสรุป
โดยการระบุแนวทางปฏิบัติที่เหมาะสมที่สุดสำหรับทีมของคุณ และด้วยการลองผิดลองถูก คุณจะพบกับชุดค่าผสมที่รับประกันว่าองค์กรของคุณจะทำงานได้อย่างมีประสิทธิภาพสูงสุด
เนื้อหาเพิ่มเติม: เรียนรู้ต่อไป ค้นพบว่าบริษัทของคุณจะได้รับประโยชน์จากวัฒนธรรมที่ไร้ที่ติได้อย่างไร