OpsLevel serves as our primary tool to manage the owners for different repositories and services. I use OpsLevel to map the different services' owners, making it our source for keeping all the owners for those repos and services. Recently, we have integrated OpsLevel with Jira, allowing the same OpsLevel name to be mapped to the different Jira name of that respective team. This integration is excellent for infrastructure mapping and finding out who the owner is and assigning Jira tickets directly to the teams.
Centralized ownership mapping has streamlined ticket assignment but still needs better alias handling
What is our primary use case?
What is most valuable?
OpsLevel offers the best feature through its ownership mapping of different places. For example, we have an OpsLevel file, a YAML file that we have in GitHub, which maps the same team name in OpsLevel, Jira, GitHub, and different AWS services, becoming our main source for finding the right owner. OpsLevel allows us to categorize different sub-teams within the team and find the right owners for assignment. Additionally, it provides alias names for the teams and services so that we can map teams with slightly different names but belonging to the same services.
OpsLevel has positively impacted our organization by solving our problem of finding ownership and the workflows we need. We can assign tickets to different owners of different repos using OpsLevel, which has helped our company tremendously because ownership was one of the major problems we faced.
We work on a lot of vulnerability tickets assigned based on the services owned by different teams. Now that we have these owners, it has become very simple to automate the process of assigning those Jira tickets of vulnerabilities directly to the teams that own the service. During organization-level incidents, the Mean Time to Resolution (MTTR) to find out who owns a particular service has become way faster, helping us reduce the time to resolve those incidents.
What needs improvement?
OpsLevel could improve by working on how to reduce duplication and making it simpler for people. For example, while aliases help define different names for the same service or team, they can create space for duplication. There may need to be a smarter way to reduce duplication and ensure unique names for services and teams alike.
I chose a rating of seven because I think there is still a lot of room for improvement. Another reason is that we are using automation to log into OpsLevel and get the right team, but sometimes it becomes a hassle to code. Having API access with a token or something similar would be beneficial.
Regarding OpsLevel's AI capabilities, I think it has potential in governance and security. OpsLevel integrates AI to automate service discovery and documentation, but I believe it could explore more to become IDE compatible and make it simpler for us to access all that API data rather than creating extensive coding.
I think the accuracy and reliability of OpsLevel's output are important. Currently, as we adopt more AI, I cannot specifically talk about the accuracy, but I would like to have faith in OpsLevel because we have been using it a lot, and I trust its accuracy and reliability.
For how long have I used the solution?
I have been using OpsLevel for the last two years.
What do I think about the stability of the solution?
OpsLevel is stable.
What do I think about the scalability of the solution?
OpsLevel's scalability is pretty good; we use it for almost every individual service, and I have not encountered any scalability issues yet.
How are customer service and support?
I have not reached out for customer support, but I would rate it as not very great at this moment.
Which solution did I use previously and why did I switch?
Before OpsLevel, we used Terminus in parallel and also utilized an Excel sheet for ownership, but I think Terminus is complementary rather than competitive, making OpsLevel our primary resource for ownership.
How was the initial setup?
OpsLevel was quite simple to adopt because we only needed to add an OpsLevel file, which directly integrates all those repositories or services after the sync, making it straightforward.
I found the integration process with our existing tools and systems really simple, except for one caveat, which was the naming convention. We use different conventions in Jira, OpsLevel, and elsewhere, so having a universal naming convention where we use the same terminology in Jira would have been much better.
What about the implementation team?
OpsLevel supports collaboration between different teams in our organization because my team owns OpsLevel, and other people can add an OpsLevel file in their YAML. We are admins but allow other teams to manage their own ownership in OpsLevel, and if we find any discrepancies, we can update it as admins.
What was our ROI?
I cannot specify how much money was saved, but I can say that OpsLevel has saved a tremendous amount of time. Finding owners manually and adding them to an Excel sheet and accessing via scripts would take longer; with OpsLevel, it is done with a click.
Which other solutions did I evaluate?
OpsLevel helps with monitoring or improving service quality by solving our problem of ownership. On a scale from one to ten, I would say ownership has improved significantly in a year because we had many unassigned tickets that people used to manually assign to different teams, and OpsLevel has tremendously solved this issue, reducing the time needed to resolve those tickets.
What other advice do I have?
OpsLevel receives a rating of seven from me on a scale from one to ten.
I think the learning curve for new users of OpsLevel is straightforward and simple. I do not think anyone needs too much training, but writing an OpsLevel YAML file would be an simple way to learn OpsLevel.
We update or modify information in OpsLevel infrequently, generally less than once a year.
I would advise others looking into using OpsLevel to know that it is used by all industries and is doing a good job for us, so they should check it out and consider pursuing it.
