Manage Engineering Initiatives with OpsLevel Checks

Engineering initiatives are a necessity when it comes to ensuring security, reliability, and keeping the lights on within an organization. These can include actions such as upgrading library versions, migrating everyone to a new metrics provider, or upgrading a framework.

For example, let’s say you’d like to run an initiative to upgrade all of your Tier 1 Ruby services to use Ruby 3.0. With OpsLevel, these initiatives can be managed using checks and checklists.

Recently, we’ve released several enhancements to checks to help simplify how engineering initiatives are run and managed. Without further ado, here’s a breakdown of what’s new.

Matching Services

Checklists allow you to customize which services your checks will be applied to by creating a customized service filter. But what if you’d like to verify which services this filter will include? With the new matching services view, you can now see which services your checklist will be applied to all in one place.

From our example of updating our Tier 1 services to use Ruby 3.0, you would start by creating a service filter within your checklist. You can then preview a list of all matching services that your checks will be ran against.

In our example, we notice that one of the matching services is Legacy Service, which we don’t want included. We can exclude that by adjusting our filter.

Our checks now won’t run against Legacy Service.

Markdown Support

OpsLevel previously supported instructions on each check to communicate to service owners why a given check is important and how to resolve it. You can now use Markdown to format check instructions with headings, lists, bold/italics/underlines, links, tables, and the myriad of other options supported by Markdown.

For example, in the screenshot below, we are able to show service owners additional context about why upgrading to Ruby 3.0 is important as well as the steps they need to take.

Check out the Markdown Cheat Sheet for more information on the Markdown syntax we support.

Check Lifecycle

Previously in OpsLevel, newly created checks were applied automatically to all matching services and contributed to the health scores of those services. That made it difficult to roll out a new check or preview the impact of a nascent check.

You can now enable or disable checks in OpsLevel. Disabled checks are still run and evaluated against matching services, but they do not contribute to those services’ health score.

This toggle allows you to control the life cycle of a check. With disabled checks, you can have others on your team review a check before taking it live. As well, you can view a report for a disabled check to see how it would affect service scores.

Check Ownership

OpsLevel is meant to track ownership of everything about your infrastructure.

In addition to tracking owners for services and repositories, you can now assign owners to checks as well.

This allows service owners to know which team to contact regarding a failing check or to get more information about that check.

If you have any questions don’t hesitate to reach out to info@opslevel.com.