OpsLevel has a feature where it allows you to define what “tier” each of your services are.
This feature has started some good conversations and encouraged many of our alpha users to ask themselves: “What tier are our services, anyway? And what’s in a tier, really?”
A service’s “tier” is an indicator of how mission-critical the service is and how tolerant your business is to the service’s downtime. The higher the tier, the more critical it is that the service remains available.
Why should an organization define availability tiers for their services?
- First and foremost, it can be tied explicitly to the magnitude of the incident response for if/when that service goes down. For instance, if you have a Tier-1 service, you could have its outages trigger major incidents with multiple responders and a coordinated response.
- Secondly, there’s a lot of power in having service tiers explicitly defined with a common nomenclature: you can’t have have implicit/unspoken disagreements on a service’s availability needs if it has a clearly-defined tier. To make things even simpler, you could even have standardized SLOs per tier.
- Finally, if your service tiers are explicit, it’s a lot easier to suss out dependency problems: there’s clearly a problem if your Tier-1 service has a hard dependency on another Tier-3 service.
You can now define all of your service tiers directly in OpsLevel.
In OpsLevel, we’ve always supported tiers as something you could set for your service. But the exact definition of a tier - and its corresponding business impact - usually differs between organizations. We now let you actually capture whatever works for you and your organization.
You can set the definitions for Service Tiers in the Account Settings page:
We’ve started by giving you some reasonable defaults, but please go ahead and customize them for your business. If you don’t have any formal tiers set up yet, this might prompt some interesting conversations with your team.
Bonus: you can also now define your services’ lifecycle stages in OpsLevel too!
A service’s “lifecycle stage” relates to what phase it is in its development. For example, when you first start building a new service and when the features it supports aren’t yet in the hands of any of your customers, you might call the service “pre-alpha” or a “prototype”. As things progress and as more and more customers are using the service, it might go through phases like “alpha” and “beta” until it’s generally available to all customers. Later down the road, after many years of features and maintenance and laughter and tears, you may decide to sunset your service as a result of changing business requirements. These are all different stages in the lifecycle of most services and usually have a direct correlation to how operationally mature a given service is expected to be.
You can now configure your services in OpsLevel accordingly. Again, we’ve set you up with some reasonable defaults in Account Settings, but please go ahead and customize their definitions for your business:
Both Service Tiers and Lifecycles are going to be instrumental in our upcoming Checks and Checklists features. Stay tuned for more from Team OpsLevel!
Feedback welcome
As always, if you have any feedback about any of our new features, please email us at info@opslevel.com.