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 ขั้นตอน:

  1. กลยุทธ์การบริการ
  2. การออกแบบบริการ
  3. การเปลี่ยนแปลงการบริการ
  4. การให้บริการ
  5. ปรับปรุงบริการอย่างต่อเนื่อง

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

ตาม itiltraining.com:

“มีความสำคัญอย่างมากในการปรับปรุงอย่างต่อเนื่อง ซึ่งเกี่ยวข้องกับการวัดและปรับปรุงกระบวนการ บริการด้านไอที และโครงสร้างพื้นฐานด้านไอทีอย่างสม่ำเสมอ การทำเช่นนี้จะช่วยเพิ่มประสิทธิภาพ ประสิทธิผล และความคุ้มค่าสูงสุด”

ITIL ทำงานอย่างไรกับ DevOps

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

ใช้ตอนไหน?

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

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

กราฟ ITIL และ DevOps

ความสอดคล้องระหว่างไอทีกับส่วนที่เหลือขององค์กรของคุณ

ผลลัพธ์ของการใช้แนวทางปฏิบัติที่ดีที่สุดของ ITIL และ DevOps ผสมผสานกันคือการปรับให้เข้ากับเป้าหมายทั่วทั้งองค์กรได้ดีขึ้น เมื่อฝ่ายไอทีและส่วนอื่นๆ ขององค์กรทำหน้าที่เป็นหน่วยงานอิสระโดยสิ้นเชิง ฝ่ายหนึ่งมักจะรู้สึกว่าทำงานหนักเกินไปและไม่ได้รับการสนับสนุน ใน “The Phoenix Project” นวนิยายที่กล่าวถึงการต่อสู้ดิ้นรนขององค์กรสมมติกับการรวมไอที เรื่องนี้กลายเป็นความขัดแย้งหลัก

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

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

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

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

แนวทางปฏิบัติที่ดีที่สุดของ 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 เช่นเดียวกับความพร้อมใช้งาน ความถี่ในการปรับใช้ ฯลฯ

งบประมาณผิดพลาด

บทสรุป

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

เนื้อหาเพิ่มเติม: เรียนรู้ต่อไป ค้นพบว่าบริษัทของคุณจะได้รับประโยชน์จากวัฒนธรรมที่ไร้ที่ติได้อย่างไร