รู้จัก 3 ศัพท์ด้าน Site Reliability Engineering: SLI, SLA, SLO

Google ได้ออกมาเล่าถึง 3 คำศัพท์พื้นฐานทางด้าน Site Reliability Engineering (SRE) เพื่อปูพื้นให้กับเหล่าผู้ที่สนใจเข้าร่วมงาน Google Cloud Next ’18 ที่จะจัดขึ้นในสัปดาห์หน้า ทางทีมงาน TechTalkThai เห็นว่าเนื้อหาเป็นประโยชน์ดี จึงนำมาสรุปเป็นภาษาไทยให้ทุกท่านได้อ่านกันดังนี้ครับ

 

Stack Driver for Google Cloud Plattform Credit: Google

 

1. Service-Level Objective (SLO)

Google นั้นมองว่าในทุกๆ ความสำเร็จของเทคโนโลยีนั้น จะต้องเกิดจากการที่เทคโนโลยีดังกล่าวมีความทนทานมากเพียงพอที่จะทำหน้าที่ตามที่ต้องการได้ และ SLO ก็คือการกำหนดเป้าหมายด้านความทนทานของระบบ (Availability) โดยใช้ค่าเชิงตัวเลขเพื่อให้สามารถชี้วัดได้ และตัวเลขดังกล่าวนี้จะต้องถูกนำไปใช้พิจารณาในการตัดสินใจใดๆ ในเชิงสถาปัตยกรรมระบบ ว่าการออกแบบนั้นๆ จะมีค่าความทนทานในระดับที่ต้องการได้หรือเปล่า

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

การกำหนด Planned Downtime ที่ชัดเจนก็เป็นอีกหนึ่งแนวทางที่ Google นำมาใช้อยู่เสมอ และทำให้ Google มีเวลาในการจัดการกับบริการต่างๆ ที่ใช้งานทรัพยากรบน Server อย่างไม่เหมาะสม รวมถึงยังได้มีโอกาสในการปรับปรุงให้บริการของตนเองมีความทนทานในระดับที่ต้องการได้อยู่ตลอดด้วย

 

2. Service-Level Agreement (SLA)

ที่ Google มีการแยก SLO ออกจาก SLA อย่างชัดเจน โดย SLA นี้จะเสมือนเป็นบทลงโทษหากทีมผู้ดูแลระบบไม่สามารถทำให้ระบบมีความทนทานตาม SLA ที่แจ้งให้ลูกค้าทราบได้ เช่น การจ่ายค่าปรับให้กับลูกค้าเพื่อบริการหยุดทำงานนานเกินกว่าที่กำหนดเอาไว้ใน SLA เป็นต้น ดังนั้นค่า SLA นี้อาจไม่ได้เข้มงวดเท่าค่าที่กำหนดใน SLO เพื่อให้ทีมงานมีช่องว่างในการแก้ไขปัญหาได้ทันหากระบบเกิดปัญหาขึ้นมาจริงๆ เช่น หากกำหนด SLA ของระบบให้แก่ลูกค้าเอาไว้ที่ 99.9% ในแต่ละเดือน ค่า SLO ที่ใช้กันภายในก็อาจอยู่ที่ 99.95% เป็นต้น

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

 

3. Service-Level Indicator (SLI)

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

 

ทั้งนี้ Google เองก็ได้มีเขียนหนังสือด้าน Site Reliability Engineering เอาไว้ด้วย ผู้ที่สนใจสามารถซื้ออ่านได้ที่ http://shop.oreilly.com/product/0636920041528.do และ https://www.amazon.com/_/dp/149192912X?tag=oreilly20-20 ครับ

 

ที่มา: https://cloudplatform.googleblog.com/2018/07/sre-fundamentals-slis-slas-and-slos.html




About techtalkthai

ทีมงาน TechTalkThai เป็นกลุ่มบุคคลที่ทำงานในสาย Enterprise IT ที่มีความเชี่ยวชาญทางด้าน Network, Security, Server, Storage, Operating System และ Virtualization มารวมตัวกันเพื่ออัพเดตข่าวสารทางด้าน Enterprise IT ให้แก่ชาว IT ในไทยโดยเฉพาะ

Check Also

8 Startup กระแสใหม่ด้าน Network

คำว่า Transformation ทำให้ภาคอุตสหกรรมด้านเครือข่ายต้องย้ายตัวเองจากผู้เล่นในด้านฮาร์ดแวร์ไปสู่ซอฟต์แวร์แทน ดังนั้นพอทุกอย่างเป็นคำว่า Agile ส่งผลให้การพัฒนาต่างๆ เป็นไปได้อย่างรวดเร็วทำให้บริษัท Startup เกิดใหม่รายเล็กๆ ก็สามารถเข้าสู่ตลาดด้านนี้ได้ง่ายขึ้น วันนี้เราจึงขอนำเสนอบทความจาก NetworkComputing ที่จะพาเราไปชมกับ 8 บริษัท …

SAP แพตช์ช่องโหว่ด้านความมั่นคงปลอดภัยประจำเดือนสิงหาคม

เมื่อวันอังคารที่ผ่านมา SAP เจ้าของผลิตภัณฑ์ ERP รายใหญ่ได้ออกแพตช์อุตช่องโหว่ด้านความมั่นคงปลอดภัยกว่า 27 รายการ อย่างไรก็ตามในแพตช์ชุดนี้ไม่มีช่องโหว่ระดับร้ายแรง