Defining and implementing SLI and SLO in an organization is a whole lifecycle. The first reference point is the SLA (the formal agreement between business and IT). SLAs typically have financial implications associated - you miss SLAs, you pay in some form, either reputation or monetary loss. So your SLOs have to be more conservative than the SLAs, so you get all-hands-onboard well before SLAs are impacted. SLIs or service level indicators are the actual measure or indicator. The SLI answers the question - 'What are you measuring?'. Deciding SLI in alignment with end-user definition of 'working' is important, or else you end up measuring metrics that really don't matter to the customer. For example, instead of measuring CPU or Memory utilization, measure client side performance thresholds or ability to complete transactions (availability). Basically focus on the 'user journey' and not just the 'service' (as in technical service component). Picking the right SLIs, finding the achievable SLOs and ensuring agreement across the board are key steps to defining SLI, SLOs.
A few guidelines:
- While defining Service Level Objectives, teams new to the concept typically go overboard (we need five 9s of availability! Yay!). It is wise to define aspirational SLOs separate from achievable SLOs.
- Understand dependencies before agreeing to SLOs. SLOs work only if teams managing dependencies understand and agree
to the same numbers.
The
SLODLC is a great checklist if you are going from initiation to a functioning SLI/SLO model.