SaaS SLI vs SLO vs SLA: examples और error budget समझें
SLI, SLO और SLA का फर्क जानें, customer-focused reliability target चुनें, error budget निकालें और perfect uptime का वादा किए बिना नतीजे review करें।
इस मार्गदर्शिका में
SLI, SLO, SLA और error budget का क्या अर्थ है?
SLI किसी service property का परिभाषित माप है, जैसे सफल valid requests का हिस्सा। SLO उस माप के लिए तय लक्ष्य या सीमा है, किसी निश्चित अवधि में। SLA customer के साथ service commitment और उसके चूकने पर होने वाली कार्रवाई का agreement है। Error budget बताता है कि SLO की अवधि में कितनी unreliability की गुंजाइश है। Google SRE इन शब्दों को अलग रखता है, क्योंकि हर शब्द अलग measurement या decision से जुड़ता है।
SLI: तय करें कि customer experience में क्या मापना है
ऐसा measurable signal चुनें जो customer outcome के पास हो: सफल core requests, पूरी हुई transaction, स्वीकार्य response time या टिकाऊ data write। परिभाषित करें कि कौन-सी request गिनी जाएगी, failure कैसे पहचानी जाएगी और missing telemetry का क्या होगा। Server uptime probe उपयोगी है, लेकिन वह यह न दिखाए कि customer का काम पूरा हुआ या नहीं।
SLO: लक्ष्य और measurement window साथ तय करें
Indicator, target और window तीनों लिखें। उदाहरण: “हर rolling 30-day window में कम से कम 99.9% eligible document-save requests सफल हों।” Report करने से पहले eligible requests, status codes, exclusions और data source परिभाषित करें। Denominator या अवधि बदलने से percentage भी बदल सकता है।
SLA: बाहरी commitment को contract की तरह review करें
Public या signed service-level agreement में measurement rules, exclusions, सूचना देने के तरीके और service credits जैसे remedies हो सकते हैं। इसके legal और financial असर हो सकते हैं। अपने agreement में cloud provider का uptime number डालने से पहले product dependencies, monitoring, support क्षमता और contract wording जाँचें।
| Customer journey | SLI definition / eligible events | SLO target और अवधि | Data source | Budget कम हो तो फैसला |
|---|---|---|---|---|
| Core save या transaction | ||||
| Sign-in या API workflow | ||||
| Data durability या export |
SaaS product के लिए SLO कैसे चुनें?
उस customer journey से शुरू करें जिस पर लोग निर्भर हैं
पूछें कि product से मुख्य value पाने के लिए user का कौन-सा काम पूरा होना चाहिए; फिर उसकी service boundary और मापने योग्य failure तय करें। Background report में देरी और असफल payment या खोया write अलग असर रखते हैं। कुछ ऐसे targets चुनें जो engineering या product का फैसला बदल सकते हों।
ऐसा denominator और window लें जिसे team समझा सके
Eligible requests, successful outcomes, latency threshold, regions और measurement window को सरल भाषा में परिभाषित करें। जाँचें कि data source हर event को लगातार एक ही तरह देखता है और retries गलती से एक user action को कई बार नहीं गिनते। Exclusions सीमित और लिखित रखें; असुविधाजनक failure को बाद में हटाएँ नहीं।
Customer जरूरत और देखी गई reliability के आधार पर target तय करें
Customer expectations, service का असली व्यवहार, dependencies और अधिक reliability की लागत देखें। हर service के लिए 100% लक्ष्य व्यावहारिक योजना नहीं है: इससे trade-offs छिप सकते हैं या ऐसी reliability पर खर्च हो सकता है जो user outcome बेहतर नहीं करती। लोकप्रिय percentage को product के अर्थ की जाँच किए बिना न अपनाएँ।
Team error budget का उपयोग कैसे करे?
Budget को SLO से निकालें, किसी नारे से नहीं
Request-based objective में allowed unsuccessful share, तय eligible requests और window के भीतर target का पूरक हिस्सा है। यदि लक्ष्य 99.9% eligible requests सफल होना है, तो उसी अवधि में उन requests का 0.1% error budget है। Time-based availability SLI का अर्थ अलग है; SLI सचमुच समय आधारित न हो तो percentage को downtime minutes में न बदलें।
Release और reliability फैसलों के लिए budget burn देखें
Budget अपेक्षा से तेज खर्च हो रहा हो तो प्रभावित journey और हाल के बदलाव जाँचें। Team risky releases धीमे कर सकती है, reliability work पर ध्यान दे सकती है या mitigation सुधार सकती है। पहले से उचित response पर सहमति लें; एक छोटा error अपने-आप सभी काम रोकने का कारण नहीं है।
Product और operations के साथ नतीजे review करें
SLI, objective, अवधि, customer impact, मुख्य कारण और actions साथ दिखाएँ। Product उपयोग, architecture या customer जरूरत बदलने पर target फिर देखें। Objective फैसला लेने का साधन है, marketing badge, guarantee या contractual SLA review का विकल्प नहीं।
SaaS reliability objectives पर सवाल
क्या SLO और SLA एक ही हैं?
नहीं। SLO, SLI से मापा गया internal या product reliability target है। SLA customer के साथ agreement है जिसमें remedies और दूसरी obligations हो सकती हैं। SLA में SLO का reference हो सकता है, लेकिन दोनों शब्दों को interchangeable न मानें।
क्या 99.9% SLO का मतलब downtime की तय अवधि है?
तभी जब SLI और उसकी अवधि availability को समय के रूप में मापते हैं। Request-success SLI eligible requests की सफलता का हिस्सा देखता है; उसका error budget requests का हिस्सा होता है, outage minutes नहीं। Indicator और window हमेशा बताएँ।
Startup को कितने SLO चाहिए?
कोई सार्वभौमिक संख्या नहीं है। कुछ customer journeys से शुरू करें जहाँ reliability से product या operations का वास्तविक फैसला बदलता है। नया target तभी जोड़ें जब team उसे परिभाषित, माप और नतीजे पर कार्रवाई कर सके।
क्या अपने SLO को uptime कहकर advertise कर सकते हैं?
ऐसी wording चुनें जो वास्तविक measurement से मेल खाए और बताए कि यह target है या contractual commitment। Public या signed promise छापने से पहले legal तथा product owners से measurement exclusions और remedies review कराएँ।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; project-team editorial review pending · स्रोत जाँचे गए .