SLAs, SLOs, และ SLIs คืออะไร?
ช่วงนี้วันลาของออฟฟิศเหลือ เลยอยากลาพักซักวันสองวัน แบบไปนั่งทำอะไรใหม่ๆ หรือเรียนรู้อะไรใหม่ๆ ดูบ้าง แล้วบังเอิญไปเจอว่าคอร์สใน Coursera มีคอร์สเกี่ยวกับ Google Cloud ให้เรียนฟรีจนสิ้นปีนี้เลยจัดซักหน่อย
มีหลายคอร์สมากที่น่าสนใจและเซฟเอาไว้ แต่ว่าคอร์สแรกที่ผมเรียนคือ Site Reliability Engineering: Measuring and Managing Reliability
ตอนนี้เรียนจบไป Week 1 แล้วรู้สึกว่าน่าสนใจดี พวก concept ที่เราเคยได้ยินต่างๆ ไม่ว่าจะเป็น SLA, SLO, หรือ SLI ที่พอจะคุ้นๆ หูกันบ้าง ได้มีโอาสมารื้อปัดฝุ่น และก็เข้าใจในการนำไปใช้จริงที่ practical มากขึ้น เลยเขียนจดเอาไว้ใน blog นี้มาแชร์กับทุกคน
SLA, SLO, SLI มีไว้ทำไม?
จากภาพข้างบนจะเห็นว่าในมุมของ Developers เค้าต้องการส่งมอบ Features ต่างๆ ให้กับผู้ใช้งานได้เร็วและทันเวลา แต่ในขณะเดียวกันคนที่ดูและด้าน Operations ของระบบก็อยากให้ระบบมีความเสถียร
จะเห็นว่าสองอย่างนี้ขัดกันอยู่
ในมุมมอง Developers เค้าต้องส่งมอบ features ไปให้ผู้ใช้ได้ทันเวลา เพื่อจะได้ตอบโจทย์ใช้งานของผู้ใช้และสร้างรายได้ให้กับองค์กร
แต่ในมุมมอง Operations เค้าต้องการให้ส่งมอบของเหล่านี้ให้ช้า เพราะการ deploy ของไปเยอะๆ หรือเร็วๆ อาจจะมีความเสี่ยงที่จะเกิด bugs หรือทำให้ระบบไม่สามารถทำงานตามเดิมได้
แนวคิด DevOps เลยเกิดขึ้นมาเพื่อทำลายกำแพง (Silo) อันนี้ ซึ่งจะมีทีมที่เรียกว่า SRE (Site Reliability Engineers) ที่นำแนวคิด DevOps นี้มาเพื่อทลายกำแพงและรักษาสมดุลของทั้งความเร็วและความเสถียรนี้ขึ้น โดยเอาสิ่งที่เรียกว่า SLO และ SLI นี่แหละเข้ามาใช้ภายในองค์กร (แต่ SLA เอาไว้ใช้อีกจุดประสงค์นึงนะ)
ถ้างั้น SLA, SLO, และ SLI คืออะไร เรามาดูต่อกัน
SLAs (Service Level Agreements) คืออะไร
SLA ย่อมาจาก Service Level Agreement หมายถึงข้อตกลงที่เราตกลงร่วมกับลูกค้าที่มาใช้บริการ service หรือ software ของเรา เป็นข้อตกลงที่ทำให้ลูกค้าหรือผู้ใช้งานได้เชื่อมั่นที่จะใช้งานของของเรา
โดยทั่วไปข้อตกลงนี้ มักมีระบุว่า ถ้าเราไม่สามารถให้บริการได้ตามที่เราตกลงเอาไว้ จะมีผลบางอย่างตามมา เช่น คืนเงิน (refund), หรือคืนเป็นเครดิตเพื่อเอาไปใช้ชดเชย, หรืออะไรก็ตามตามที่ตกลงกันไว้
สมมติเช่นเราได้กำหนด SLA ไว้ว่า บริการของเราจะใช้งานได้ 99% success rate ในช่วง 4 สัปดาห์ (หรือ 28 วัน) ถ้าเกิดการในความเป็นจริงเกิด success rate ไม่ถึง 99% เช่นเหลือ 97% จะต้องมีการชดเชยตามมาให้กับลูกค้า
อีกตัวอย่างนึงที่น่าสนใจลองนึกภาพถ้าเราเป็นผู้ให้บริการ Streaming เจ้านึง แล้ว duration time นับจาก time to first byte (TTFB) ของ API วิ่งไปถึง 30 seconds ก็ดูน่าจะทำให้ผู้ใช้บริการหงุดหงิดแล้วใช่ไหมครับ ในที่นี้ถ้าเรามั่นใจว่าระบบเราดีมาก จะตั้ง SLA เอาไว้ที่ 1 second ก็ได้เพื่อให้การันตีกับผู้ใช้ได้ว่าเราไม่มีทางตอบช้ากว่านั้นแน่ๆ (หรืออาจจะน้อยกว่านั้นก็ได้นะครับ)
ฟังดูแล้วน่ากลัวใช่ไหมครับถ้าต้องมีการชดเชยให้ผู้ใช้ ใครจะอยากมี SLA เอาไว้กัน 55
แต่ในความเป็นจริงผู้ให้บริการขนาดใหญ่ที่มีทรัพยากรในการทำให้ความน่าเชื่อถือ (Reliability) มีความน่าเชื่อถือที่สูง จะมีการกำหนด SLA เอาไว้กับลูกค้า เพื่อให้ลูกค้าเชื่อมั่นและอยากใช้บริการ โดยไม่กังวลว่าถ้าเกิดข้อผิดพลาดอะไรขึ้นมาแล้วจะไม่ได้รับการชดเชยอะไรกลับไป
โดยหลักๆ SLA คือสิ่งที่สื่อสารไปภายนอกองค์กรเพื่อเรียกความมั่นใจ
แต่ใจความแท้จริงเรื่อง Reliability ของ DevOps จะอยู่ที่ SLO และ SLI ที่จะพูดถึงถัดไปครับ
SLOs (Service Level Objective) คืออะไร
Service Level Objective คือเป้าหมายภายในที่ทั้งทางฝั่ง Development Teams และ SRE / Operation Teams ตั้งเป้าเอาไว้ว่าจะพยายามรักษาสมดุลเพื่อให้อยู่ในระดับที่รับได้
เป้าหมายนี้มีเอาไว้สื่อสารภายใน และไม่มีผลกระทบตามมาถ้าผลออกมาแย่กว่าเป้านี้
ฟังดูชื่นใจขึ้นเยอะใช่ไหมครับ คาดว่าใครอ่านถึงตรงนี้ ต้องอยากมีแค่ SLO มากกว่า SLA แน่นอน 55
เพียงแต่ว่าเป้านี้คือสิ่งทั้ง Development Teams และ SRE Teams ต้องช่วยกันรักษาสมดุลไม่ให้ตก และมีการ review ทุก 3–6 เดือน ว่าค่าที่เราตั้งนั้นเหมาะสมไหม
แน่นอนครับ แปลว่าค่านี้สามารถปรับได้ตลอดเวลา และอาจมีการปรับเป็นพิเศษสำหรับบางช่วง เช่น Black Friday ที่อาจจะมีการใช้งานหนัก เป็นต้น
การกำหนดค่านี้ต้องเป็นการคุยกันระหว่าง Developers และ SREs โดยหาจุดสมดุลว่าค่าไหนคือค่าที่เหมาะสมโดยเอาผู้ใช้เป็นหลัก แต่มีเงื่อนไขว่า SLO ต้องสูงกว่า (Stronger) กับค่าของ SLA เสมอ เพราะถ้าแตะ SLA แปลว่าวิกฤติแล้วล่ะ เพราะต้องชดเชยให้กับผู้ใช้ เราควรรักษามาตรฐานให้ดีกว่านั้นคือไม่เกิน SLO
ในที่นี้ตัวอย่างข้างบนคือเราเอาผู้ใช้เป็นที่ตั้ง ถ้า Duration Time มากกว่า 200 เมื่อไหร่อาจจะทำให้การใช้งานติดขัด และผู้ใช้งานอาจจะไม่ Happy กับบริการของเราได้
ตามภาพถ้าเราตั้ง SLO เอาไว้ที่ว่า 200ms ก็เป็นข้อตกลงที่ทั้ง Development Teams และ SRE Teams พยายามพยุงไม่ให้มันเกิน โดยต้องรักษาสมดุลระหว่างความเร็วในการส่งมอบ Features และความเสถียรของระบบในกรณีที่เราจะต้อง Take actions อะไรบางอย่าง (เช่นจาก Error Alerts, Bugs, Defects,etc)
ตรงนี้ทุกคนน่าจะเป็นภาพคร่าวๆ แล้วว่า SLO คืออะไร แต่ทีนี้มีตัวชี้วัดอะไรบ้างล่ะ ที่เราสามารถเอามาใช้วัดได้ นอกจากตัวอย่างที่ยกใจ ตัวชี้วัดนั้นเรียกว่า SLI
SLIs (Service Level Indicators) คืออะไร
ความหมายตามชื่อเลยครับ คือเป็นตัวชี้วัดเพื่อวัดระดับสำหรับค่าของ SLO และ SLA ที่เราได้พูดถึงไปก่อนหน้านี้
ถ้าตามตัวอย่างก่อนหน้า ก็คือเราเลือกใช้ duration time จาก TTFB เป็นตัวชี้วัด (Indicator) นั่นเองครับ
ทีนี้มันเป็นสิ่งเดียวหรอ ที่ใช้ชี้วัดได้?
เปล่าเลย มันสามารถใช้อะไรได้อีกมากมาย โดยหลักการคือให้คำนึกถึงว่าตัวชี้วัดอะไรที่จะสามารถชี้วัดได้ว่าลูกค้าหรือผู้ใช้จะ Happy กับการใช้งานระบบของเรา
แต่ว่าตัวชี้วัดในที่นี้ก็อย่าลืมว่าต้องมีรายละเอียดสองอย่างด้วยคือ
- Time frame คือกรอบเวลาของค่าที่จะชี้วัด
- Percentile ที่จะใช้ในวัด
มาถึงตรงนี้อาจจะเริ่มมึนละว่าอะไรคือ Percentile หว่า 55 ผมยกตัวอย่างเป็นกราฟข้างล่างน่าจะเห็นภาพสุด
เช่นถ้าเราบอกว่า เราตั้ง SLO เอาไว้ว่า
Duration Time นับจาก TTFB ไม่เกิน 200ms ที่ P99 ในช่วง 4 สัปดาห์ (หรือ 28 วัน) คือ SLO ของเรา
นั่นแหละว่า เวลานับจาก Server ได้รับ byte แรกมา เราจะต้อง process และตอบกลับภายใน 200 milliseconds โดยร้อยละ 99 ในช่วง 28 วันนี้
ถ้าต่ำกว่านี้ คือเกิน SLO เราแล้ว เราต้องหยุด ship features ก่อน และแก้ปัญหาเพื่อให้ค่าของ Indicator เรายังคงไม่เกิน SLO ที่เรากำหนดไว้
แต่ในกรณีนี้ที่ยังไม่เกิน SLO ของเรา เราจะยังสามารถ ship features ต่อไปได้
ตรงนี้ลองนึกภาพถ้าเรามีตัวชี้วัด (Indicator) เป็น Success Rate เอาไว้ 99% แล้วถ้าเกิดมี Error Rate ยังไม่เกิน 1% เราอาจจะยังไม่ต้องรีบ take actions ไปแก้ bugs หรือ issues ตรงนั้นก็ได้
ตรงนี้จะสามารถช่วยให้ Development Teams ได้โฟกัสอยู่กับตัว features ที่กำลังทำอยู่โดยไม่โดน distracted จาก error alerts ที่มีอยู่ว่าต้องรีบแก้ทันที
แต่ในทางกลับกัน ถ้า Error Rate มันมากกว่า > 1% แล้วเราต้องรีบหยุดมาช่วยซ่อมตรงนี้กันก่อน
กลับมาที่ภาพ Percentile อีกครั้ง ตรงนี้ การเลือก Percentile เป็นสิ่งที่ต้องควรระวัง เช่น ถ้าเราเลือกที่ P99 อาจจะต้องดูว่าหลัง P99 มีความถี่ที่เยอะแค่ไหน
นึกภาพถ้าเราเป็นเว็บ Streaming ที่มีคนใช้งาน 100 ล้านคน แล้วแม้ว่าคนที่เกิน P99 จากกราฟจะดูมีความถี่ที่น้อย แต่นั่นอาจจะหมายถึงคนหลายแสนหรือล้านที่พบปัญหา (Long tail graph)
ซึ่งเหตุการณ์แบบนี้มักเกิดขึ้นในช่วงที่มี events ต่างๆ เช่น Black Friday แล้วทำให้มี Outlier ดึงกราฟให้เกิดเป็นกราฟ Long tail ขึ้นมา
ดังนั้น ในบางกรณีแบบนี้อาจมีการยกระดับ SLO จาก P99 มาเป็น P99.9 หรือ P99.99 เพื่อให้ผู้ใช้ส่วนใหญ่ยังสามารถใช้งานได้ดีอยู่
หลังจากมี SLO แล้วเรามาทำ Error Budget ต่อ
Error Budget คือตัวเลขที่สวนทางกันกับ SLO ที่เราเอาไว้ เช่นถ้าเรากำหนด SLO เอาไว้ว่า…
Success Rate ในช่วงเวลา 28 วัน ที่ P99 ต้องไม่ต่ำกว่า 95%
แปลว่าในที่นี้เรามี Error Budget อยู่ 5% ในช่วง 28 วัน ถ้ายังมี Error Budget เหลือ เราจะยังสามารถ ship features ต่อไปได้ เพราะยังมี room ที่รองรับความเสี่ยงของ error ที่จะเกิดขึ้นจากการ ship features หรือ changes เหล่านั้นได้
แต่เมื่อใดก็ตามที่เราใช้เกิน Error Budget เกินโควต้าที่เรามีแล้ว ในช่วง Time Frame นั้นจะไม่มีการ ship features ใหม่เพื่อเพิ่มโอกาสในการเกิด Error Rate ที่เยอะขึ้นไปกว่านั้นแล้ว
ทีมจะโฟกัสที่การ maintain ให้ระบบมีความเสถียรก่อน
แต่ทั้งนี้ทั้งนั้น พวกนี้ก็มีข้อยกเว้นอยู่ที่ตกลงกัน เช่นถ้าเรามี Feature ที่ต้องรีบ ship ให้ได้เพราะสำคัญมาก ตรงนี้เราอาจจะคุยกับคนที่เป็น management หรือ decision makers เพื่อขอเหมือนเป็นโควต้าพิเศษเพื่อ ship feature นั้นๆ ได้ แต่ก็ต้องอยู่ในกรอบที่ไม่เกิน SLA อยู่นะ
เท่านี้เราก็จะรู้แล้วว่า ณ เวลานั้นๆ เราควรจะต้องโฟกัสกับการทำอะไร และมีความเสี่ยงแค่ไหนในแง่ Reliability
Conclusion
จะเห็นว่าการมีของ SLOs, SLIs, และ Error Budget จะมาช่วยให้เราสามารถรักษาสมดุลระหว่าง Development และ Stability ได้เป็นอย่างดี เพราะมีตัวเลขชี้วัดที่สามารถบอกได้ว่า ณ เวลานี้ควร ship features ใหม่ไหม? ควรต้องแก้ errors รึเปล่าหรือให้โฟกัสที่ features ก่อนดี? หรือเราควรหยุดแล้วมาโฟกัสที่เรื่องความเสถียรก่อนดี?
สิ่งเหล่านี้จะช่วยให้ระบบการทำงานเราเป็นรูปธรรมมากขึ้น มีตัวเลขที่ชี้วัดได้ และแก้ปัญหา Silo ระหว่าง Developers กับ Operations ได้ เพราะทั้งสองฝ่ายต้องร่วมมือกันรักษาค่าของ SLOs ให้ยังมีคุณภาพ
ตรงนี้เท่าที่เคยอ่าน บางที่เหมือนจะมี Incentive ให้ด้วยนะ ถ้าเราสามารถรักษาระดับ SLOs เอาไว้ได้ เพราะจะทำให้ Developers และ Operations เองคิดถึงผู้ใช้งานมากขึ้น แล้วได้ผลตอบแทนจากการทำให้ผู้ใช้ Happy เพราะ SLOs ตั้งมาจากจุดที่ผู้ใช้จะ Happy กับการใช้งานนั่นเอง
หวังว่าบทความนี้จะเป็นประโยชน์กับทุกๆ คนนะครับ ^ ^
ช่วงนี้ผม Social Detox หน่อย ปิด Facebook และ Instagram ไป แต่ถ้าสนใจ ติดตามผมได้ใน Linkedin และ Twitter นะครับ 😆
- Linkedin — https://www.linkedin.com/in/notsu/
- Twitter — https://twitter.com/notsu
ปล. ตอนนี้ที่ Senestia เปิดรับหลายตำแหน่งอยู่น้า ใครสนใจหลังไมค์มาได้นะครับ 🚀
