SLO, SLI และงบประมาณข้อผิดพลาด

Welcome! In this lesson, we'll dive into Service Level Objectives (SLOs), Service Level Indicators (SLIs), and Error Budgets. These are crucial concepts for defining and maintaining the reliability of your services.

Understanding them helps teams communicate expectations, prioritize work, and ensure a consistent user experience.

An SLI, or Service Level Indicator, is a quantitative measure of some aspect of the service you provide. Think of it as a direct measurement of your system's performance or behavior.

SLIs tell you how well your service is doing from a user's perspective. They are the raw data points we use to evaluate reliability.

Many different metrics can serve as SLIs. Here are some of the most common ones:

• Latency: The time it takes for a service to respond to a request. (e.g., 99th percentile request latency)
• Error Rate: The proportion of requests that result in an error. (e.g., HTTP 5xx responses)
• Availability: The percentage of time a service is operational and reachable.
• Throughput: The number of requests successfully processed per unit of time.

Selecting the right SLIs is key. They should directly reflect what truly matters to your users. For an e-commerce site, for example, the latency of adding an item to a cart is more critical than the latency of an internal admin endpoint.

Focus on user-facing metrics and those that indicate business impact. A few good SLIs are better than many irrelevant ones.

An SLO, or Service Level Objective, is a target value or range for an SLI over a specific period. It's the explicit goal you set for your service's performance.

For example, an SLO might be: "99.9% of requests will have a latency of less than 300ms over a 30-day rolling window."

Good SLOs are:

• Specific: Clearly state what is being measured.
• Measurable: Based on quantifiable SLIs.
• Achievable: Realistic given your resources and system complexity.
• Relevant: Important to users and the business.
• Time-bound: Defined for a specific period (e.g., 7 days, 30 days).

SLOs help align teams on what reliability means for their service.

An Error Budget is the maximum amount of time a system can fail or be unavailable without violating its SLO. It's essentially 1 minus your SLO.

If your SLO is 99.9% availability, you have a 0.1% error budget. This budget represents the acceptable amount of 'bad' performance or downtime.

Let's calculate an error budget for a common SLO:

• SLO: 99.9% availability over 30 days.
• Total time in 30 days: 30 days * 24 hours/day * 60 minutes/hour = 43,200 minutes.
• Error Budget Percentage: 100% - 99.9% = 0.1%.
• Error Budget (minutes): 43,200 minutes * 0.001 = 43.2 minutes.

This means your service can be unavailable for up to 43.2 minutes within a 30-day period without violating the SLO.

Error budgets are powerful decision-making tools. When your error budget is healthy (plenty of 'bad time' left), teams might prioritize new features or experimental changes.

However, if the error budget is nearly depleted, it signals that reliability work (e.g., bug fixes, stability improvements) must take precedence over new feature development to avoid violating the SLO.

Great job! You've learned the core concepts of service reliability engineering:

• SLIs are the specific, measurable metrics of your service.
• SLOs are the target goals set for those SLIs.
• Error Budgets are the acceptable amount of 'unreliability' before an SLO is violated, guiding decisions between features and stability.

These tools are fundamental for building and maintaining highly reliable systems!