SLI, SLO, SLA difference

4-minute read
SRE • SLI • SLO • SLA • DevOps

Hand-picked summary from different sources about service layer attributes: SLI, SLO, SLA.

New information may be added over time.

Interconnection of attributes:

SLIs drive SLOs which inform SLAs

  • SLAs – help teams set boundaries and error budgets.
  • SLOs – help prioritize work.
  • SLIs – tell SREs when they need to freeze all launches to save an endangered error budget—and when they can loosen up the reins.

SLI (service layer indicators)

Indicators or metrics over time. Which inform about the health of a service.

  • Not every trackable metric should be an SLI
    • Tracking performance on 10 components for each of 10 SLOs can get unwieldy very quickly. Instead, strategically choose which metrics actually matter to your core SLOs and put your energy into tracking those effectively.

Examples

  • 95th percentile latency of homepage requests over past 5 minutes < 300ms

SLO (service layer objectives)

Service level objectives which agreed upon bounds for how often those SLIs must be met.

  • SLO best practices
    • Less is more
      • Not every metric is vital to client success, which means not every metric should be an SLO. Commit to as few SLOs as possible and focus on the ones that matter most to customers.

Examples

  • 95th percentile homepage SLI will succeed 99.9% over trailing year.

SLA (service layer agreement)

Business level agreements, which define the service availability for a customer, and the penalties for failing to deliver that availability.

SLAs help teams set boundaries and error budgets.

  • The difference between SLAs and KPIs
    • An SLA is an agreement between you and your customer that defines how your relationship will work in the future. Key performance indicators (KPIs) are the metrics chosen to gauge how well a team performed against agreed standards.
  • Is SLA need for free users?
    • Companies providing a service to users for free are unlikely to want or need an SLA for those free users.
  • The challenge of SLAs
    • Challenge: SLA generally written by people who aren’t in the tech trenches themselves—often make promises that are difficult for teams to measure, don’t always align with current and ever-evolving business priorities, and don’t account for nuance
    • Resolution: Tech should be involved in the creation of SLAs. The more IT and DevOps collaborate with legal and business development to develop SLAs that address real-world scenarios, the more SLAs will start to reflect key realities, such as clients delaying their own issue resolution.
  • SLAs are notoriously difficult to measure, report on, and meet.
    • Tracking SLAs is difficult, and changing them is even harder
      • To see how they’re performing against SLA, many IT managers have to extract a ton of raw data, write custom queries, and build elaborate Excel formulas and reports.
      • Plus, the SLAs often have to be custom or hard-coded into many service desks, meaning it can take days of development effort to change them.
    • SLAs don’t always align with business priorities – SLAs seldom seem to change or evolve at the same pace the business does.
    • There is little flexibility in reporting.
  • SLA best practices
    • Create an SLA that stops tracking time to resolution while you’re waiting for a customer to reply
    • Remember the agent experience
    • Break up large, complex SLAs
    • Set different performance goals based on ticket priority levels
    • Keep some SLAs running 24/7, and restrict others to normal business hours
    • Craft SLAs around customer expectations
      • Every part of your customer agreement should be crafted around what matters to the customer. On the back end, an incident may mean addressing 10 different components. But in the client’s view, all that matters is that the system functions as expected.
      • Your SLAs and SLOs should reflect this reality. Don’t overcomplicate things by drilling down to a granular level and making individual promises for each of those 10 components. Keep your promises confined to the high-level, user-facing functionality. This will keep clients happier and less confused and simplify the lives of IT pros responsible for making good on your SLA promises.
    • Use plain language in SLAs
      • Clients won’t always ask for clarification, so if your SLA language is complicated, you’re probably setting yourself up for some painful misunderstandings down the line. The simpler your language, the less likely client conflict is in your future.
Examples of SLA
  • Uptime, responsiveness, and responsibilities.
  • Service credits if 95th percentile homepage SLI succeeds less than 99.5% over trailing year.
Variants of penalties
  • financial penalties
  • service credits
  • license extensions

Users

SLI, SLO, SLA users

Sources: