วิศวกรรมความน่าเชื่อถือของไซต์

วิศวกรรมความน่าเชื่อถือของไซต์ ( SRE ) เป็นสาขาหนึ่งในด้านวิศวกรรมซอฟต์แวร์และ การสนับสนุน โครงสร้างพื้นฐานด้านไอทีที่ตรวจสอบและปรับปรุงความพร้อมใช้งานและประสิทธิภาพของระบบซอฟต์แวร์ที่ใช้งานอยู่และบริการซอฟต์แวร์ขนาดใหญ่ (ซึ่งคาดว่าจะให้เวลาตอบสนองที่เชื่อถือได้ในเหตุการณ์ต่างๆ เช่น การติดตั้งซอฟต์แวร์ใหม่ ความล้มเหลวของฮาร์ดแวร์ และการโจมตีทางไซเบอร์) ^{[ 1 ]}โดยทั่วไปจะเน้นที่ระบบอัตโนมัติและโครงสร้างพื้นฐานในรูปแบบโค้ด SRE ใช้องค์ประกอบของวิศวกรรมซอฟต์แวร์โครงสร้างพื้นฐานด้านไอทีการพัฒนาเว็บและการดำเนินงาน^{[ 2 ]}เพื่อช่วยในเรื่องความน่าเชื่อถือ มีความคล้ายคลึงกับDevOpsเนื่องจากทั้งสองมีเป้าหมายเพื่อปรับปรุงความน่าเชื่อถือและความพร้อมใช้งานของระบบซอฟต์แวร์ที่ใช้งานอยู่

วิศวกรรมความน่าเชื่อถือ ของไซต์ (Site Reliability Engineering) มีต้นกำเนิดที่Googleโดย Benjamin Treynor Sloss ^{[ 3 ] [ 4 ]}ผู้ก่อตั้งทีม SRE ในปี 2546 ^{[ 5 ]}แนวคิดนี้ได้ขยายตัวใน อุตสาหกรรม การพัฒนาซอฟต์แวร์ส่งผลให้บริษัทต่างๆ จ้างวิศวกรความน่าเชื่อถือ ของไซต์ ^{[ 6 ]}ภายในเดือนมีนาคม 2559 Google มีวิศวกรความน่าเชื่อถือของไซต์มากกว่า 1,000 คน^{[ 7 ]}ทีม SRE เฉพาะกิจเป็นเรื่องปกติในบริษัทพัฒนาเว็บ ขนาดใหญ่ ^{[ 8 ] ในบริษัทขนาดกลางและขนาดเล็ก ทีม DevOps บางครั้ง ก็}ทำ SRE ด้วยเช่นกัน^{[ 6 ] องค์กรที่}นำแนวคิดนี้ไปใช้ได้แก่Airbnb , Dropbox , IBM [ ^{9 ]} LinkedIn ^{[ 10 ]} Netflix [ ^{7 ]}และWikimedia ^{[ 11} ]

วิศวกรความน่าเชื่อถือของระบบ (SRE) มีหน้าที่รับผิดชอบในด้านความพร้อมใช้งานของ ระบบ ความหน่วงประสิทธิภาพประสิทธิผลการจัดการการเปลี่ยนแปลงการตรวจสอบการตอบสนองต่อเหตุฉุกเฉินและการวางแผนกำลังการผลิต [ ^{12 ] SRE}มักมีพื้นฐานด้านวิศวกรรมซอฟต์แวร์วิศวกรรมระบบและ/หรือ การ บริหารระบบ^{[ 13 ]}จุดเน้นของ SRE ได้แก่การทำงานอัตโนมัติการออกแบบระบบและการปรับปรุง ความยืดหยุ่น ของระบบ^{[ 13 ]}

SRE ถือเป็นการนำ DevOps ไปใช้ในรูปแบบเฉพาะ^{[ 14 ]}โดยมุ่งเน้นที่การสร้างระบบที่เชื่อถือได้โดยเฉพาะ ในขณะที่ DevOps ครอบคลุมขอบเขตการดำเนินงานที่กว้างกว่า^{[ 15 ] [ 16 ] [ 17 ]}แม้จะมีจุดเน้นที่แตกต่างกัน แต่บางบริษัทก็ได้เปลี่ยนชื่อทีมปฏิบัติการของตนเป็นทีม SRE ^{[ 6 ]}

คำจำกัดความทั่วไปของการปฏิบัติรวมถึง (แต่ไม่จำกัดเพียง): ^{[ 2 ] [ 18 ]}

• การนำระบบอัตโนมัติมาใช้ในงานที่ซ้ำซากเพื่อลดต้นทุน
• กำหนดเป้าหมายด้านความน่าเชื่อถือเพื่อป้องกันการทำงานที่ไม่สิ้นสุด
• การออกแบบระบบโดยมีเป้าหมายเพื่อลดความเสี่ยงต่อความพร้อมใช้งาน ความหน่วง และประสิทธิภาพ
• ความสามารถในการสังเกตการณ์คือ ความสามารถในการตั้งคำถามใดๆ เกี่ยวกับระบบโดยไม่ต้องรู้ล่วงหน้าว่าจะถามอะไร^{[ 19 ]}

คำจำกัดความทั่วไปของหลักการเหล่านี้ ได้แก่ (แต่ไม่จำกัดเพียงเท่านี้):

• การจัดการแรงงานคือ การนำหลักการข้อแรกที่กล่าวไว้ข้างต้นไปปฏิบัติใช้
• การกำหนดและวัดเป้าหมายด้านความน่าเชื่อถือ ได้แก่SLI , SLOและงบประมาณข้อผิดพลาด
• การออกแบบระบบขนาดใหญ่ที่ไม่เป็นนามธรรม ( NALSD ) โดยเน้นที่ความน่าเชื่อถือ
• การออกแบบและการนำระบบตรวจสอบการทำงานไปใช้จริง
• การกำหนด การทดสอบ และการดำเนินการกระบวนการจัดการเหตุการณ์
• การวางแผนกำลังการผลิต
• การจัดการการเปลี่ยนแปลงและการเผยแพร่ รวมถึงCI/ CD
• วิศวกรรมความโกลาหล

ทีม SRE ทำงานร่วมกับแผนกอื่น ๆ ภายในองค์กรเพื่อชี้นำการนำหลักการที่กล่าวถึงไปใช้ ด้านล่างนี้คือภาพรวมของแนวปฏิบัติทั่วไป: ^{[ 20 ]}

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

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

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

ทีม SRE ที่ทุ่มเทให้กับผลิตภัณฑ์หรือแอปพลิเคชันเฉพาะนั้นเป็นเรื่องปกติในองค์กรขนาดใหญ่^{[ 21 ]}ทีมเหล่านี้มีหน้าที่รับผิดชอบในการรับรองความน่าเชื่อถือ ความสามารถในการขยายขนาด และประสิทธิภาพของบริการหลัก ในบริษัทขนาดใหญ่ มักจะมีทีม SRE หลายทีม โดยแต่ละทีมมุ่งเน้นไปที่ผลิตภัณฑ์หรือแอปพลิเคชันที่แตกต่างกัน เพื่อให้มั่นใจว่าแต่ละส่วนได้รับการดูแลเป็นพิเศษเพื่อให้บรรลุเป้าหมายด้านประสิทธิภาพและความพร้อมใช้งาน

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

ทีมที่ปรึกษาด้าน SRE มีความเชี่ยวชาญในการให้คำแนะนำแก่องค์กรเกี่ยวกับการนำหลักการและแนวปฏิบัติของ SRE ไปใช้ โดยทั่วไปแล้ว ทีมเหล่านี้ประกอบด้วย SRE ที่มีประสบการณ์และมีประวัติการทำงานในโครงการต่างๆ มากมาย พวกเขาให้ข้อมูลเชิงลึกและคำแนะนำสำหรับความต้องการเฉพาะขององค์กร เมื่อทำงานโดยตรงกับลูกค้า SRE เหล่านี้มักถูกเรียกว่า ' วิศวกรความน่าเชื่อถือของลูกค้า ' (Customer Reliability Engineers)

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

ตั้งแต่ปี 2014 องค์กร USENIXได้จัดงาน ประชุม SREcon ประจำปี ซึ่งรวบรวมวิศวกรความน่าเชื่อถือของไซต์จากหลากหลายอุตสาหกรรม การประชุมนี้เป็นเวทีสำหรับผู้เชี่ยวชาญในการแบ่งปันความรู้ สำรวจแนวทางปฏิบัติที่มีประสิทธิภาพ และหารือเกี่ยวกับแนวโน้มในด้านวิศวกรรมความน่าเชื่อถือของไซต์^{[ 22 ]}

• Limoncelli, Tom; Chalup, Strata R.; Hogan, Christina J. (กันยายน 2014). การปฏิบัติงานด้านการบริหารระบบคลาวด์: แนวทางปฏิบัติ DevOps และ SRE สำหรับบริการเว็บเล่ม 2. Upper Saddle River, NJ: Addison-Wesley . ISBN 978-0133478549. OCLC  891786231 .
• เบเยอร์, ​​เบ็ตซี; โจนส์, คริส; เพทอฟฟ์, เจนนิเฟอร์; เมอร์ฟี, ไนออล ริชาร์ด, บรรณาธิการ (2016). วิศวกรรมความน่าเชื่อถือของไซต์: Google ดำเนินการระบบการผลิตอย่างไร . สำนักพิมพ์ O'Reilly . ISBN 978-1491929124.
• Blank-Edelman, David N., บรรณาธิการ (2018). การแสวงหา SRE: บทสนทนาเกี่ยวกับการดำเนินงานระบบการผลิตในระดับใหญ่ (ฉบับที่ 1). เซบาสโตโพล, แคลิฟอร์เนีย: O'Reilly. ISBN 978-1491978863. OCLC  1052565720 .
• เบเยอร์, ​​เบ็ตซี; เมอร์ฟี, ไนออล; คาวาฮาระ, เคนต์; เรนซิน, เดวิด; ธอร์น, สตีเฟน (2018). คู่มือการปฏิบัติงานด้านความน่าเชื่อถือของเว็บไซต์: วิธีการปฏิบัติในการนำ SRE ไปใช้ . สำนักพิมพ์ O'Reilly. ISBN 978-1492029502.
• เวลช์, แนท (2018). Real-World SRE: คู่มือการเอาตัวรอดสำหรับการรับมือกับระบบขัดข้องและเพิ่มเวลาการทำงานให้สูงสุด . Packt . ISBN 978-1788628884.
• Adkins, Heather; Beyer, Betsy; Blankinship, Paul; Lewandowski, Piotr; Oprea, Ana; Stubblefield, Adam (2020). การสร้างระบบที่ปลอดภัยและเชื่อถือได้: แนวปฏิบัติที่ดีที่สุดสำหรับการออกแบบ การนำไปใช้ และการบำรุงรักษาระบบ . O'Reilly. ISBN 978-1-4920-8312-2. OCLC  1129470292 .
• Rosenthal, Jones, Casey, Nora (2020). วิศวกรรมความโกลาหล: ความยืดหยุ่นของระบบในทางปฏิบัติ . O'Reilly. ISBN 978-1492043867.{{cite book}}: CS1 maint: multiple names: authors list (link)

• รายชื่อแหล่งข้อมูลด้านวิศวกรรมความน่าเชื่อถือของระบบที่ยอดเยี่ยม
• รายการทรัพยากรSRE ของพวกเขาเป็นอย่างไร
• SRE Weeklyจดหมายข่าวรายสัปดาห์ที่เกี่ยวกับ SRE
• หน้าเว็บSRE ของ Google สำหรับเรียนรู้เพิ่มเติมเกี่ยวกับ SRE ใน Google
• ศูนย์การเรียนรู้ความน่าเชื่อถือของ Komodor K8s พร้อมแหล่งข้อมูลสำหรับ SRE ที่ทำงานกับ Kubernetes