Cutting MTTR of Incidents at Clarivate using Lightrun Developer Observability

Introduction

ExLibris is a company that provides various digital solutions and products for libraries around the world. We have thousands of customers worldwide. I’m a software engineer at ExLibris, and I work in a team that develops one of these products. Other than developing new features, a significant part of my job involves solving bugs.

Given that we have an enormous number of customers with varying scales and several versions—one for each month—we maintain many SQA environments that simulate production environments. The variance between these SQA environments can lead to situations where a bug can be reproduced in only one SQA environment and not in another. If you manage to reproduce a bug in your local environment, then you’re very fortunate. I imagine most developers can relate to this situation in their daily work.

I work mainly with Java and a mix of front-end languages and tools, using IntelliJ as my go-to IDE. Lightrun integrates seamlessly with it, making the experience smooth and user-friendly. We push to production about once a month.

My Experience with Lightrun

Before starting to work with Lightrun, wherever there was an issue or inconsistency between production and our varying SQA environments, the troubleshooting flow was lengthy and inefficient. It was like finding a needle in a haystack. We then brought into our tool stack the Lightrun developer observability platform that helped us make a huge change in the way we solve issues and trim down MTTR.

A recent example of how I benefited from Lightrun was  when a specific rest API call failed with 500 status code in one of our environments. To identify what was causing this to happen, I used the Lightrun Snapshotand placed it in the endpoint of the failed request. I quickly was able from within the IntelliJ IDE and the Lightrun plugin to figure out that the problem was in between sending the call and receiving it rather than in the endpoint itself. With that insight, I was able to work with my engineering team and solve this issue quickly.

Bottom line from my experience is that instead of banging your head against the wall trying to understand vague server logs, you can use Lightrun. Simply connect to the agent in the specific SQA environment/s where the bug is reproduced, navigate to the suspicious code, and create logs or even snapshots that will give you a complete picture of all the variables. Trigger the code execution, and voilà—you have much more information than the server logs could provide, bringing you several steps closer to addressing the bug. Not to mention the time saved, the increase in productivity, and the faster resolution of complex bugs.

Conclusion

In the growing complexity of software development, we ought to think outside the box and not chain ourselves to legacy and often inefficient methods while there are much more innovative approaches out there that can clearly make the whole difference between spending days and even weeks on a task instead of minutes. Think about the time that you gain back and what you can accomplish with it.

This post was originally published on LinkedIn by Haviva Elimelech from ExLibris (Part of Clarivate).