“You see, but you do not observe,” says Sherlock Holmes to Watson in “A Scandal in Bohemia.” Sherlock Holmes is an observational super hero. He studies human nature, correctly predicts what people will do under duress and can tell someone’s occupation from their clothing, haircut and posture. What you might not know about Sherlock Holmes is that Arthur Conan Doyle based him on a real person, Dr. Joseph Bell, a forensic scientist Doyle studied under in his youth. Improving your powers of observation isn’t fictional, it’s actually very attainable.

But if you read a few Sherlock Holmes stories, you’ll notice a pattern. Yes, Sherlock observes more than the average person and makes more insightful connections because of it. But, his challenge in nearly every story is not to figure out what happened, but why.

If you plonked Sherlock Holmes into a modern SRE team, he’d easily be able to deduce what’s happening on the inside of the system by observing the outputs of the system, and he’d be quick to answer any question with…

Elementary, my dear CTO.

The trouble is, the rest of us are not Sherlock Holmes. We’re merely Watsons. We see, but we cannot possibly monitor all logs, all metrics, and observe every event within our increasingly complex infrastructures in real time. But, there is a way to improve our abilities to connect the whats to the whys - minus the Sherlockian “mind palace.”

Observation & Observability

As software becomes exponentially more complex, we’re seeing a convergence of microservices, polyglot persistence, and increasingly agile, but complicated little systems. If one tiny part goes awry, finding the proverbial monkey wrench in the works can take valuable time. To successfully deliver and run a product or service that uses these modern architectural patterns, you need observability.

Observability is a measure of how well internal states of a system can be inferred from its external outputs.

Monitoring methods and tools have evolved to handle increasingly distributed and complex systems, but while it’s easier now to observe code and test results to extrapolate behavior, all bets are off once your code hits the real world. Improving observability will allow you to gather context from your systems so your team can investigate problems when they arise.

But you still need to put on your deerstalker hat to quickly understand how the affected system relates to the other systems, and what caused it to suddenly misbehave.

Solve the Mystery Faster with Better Tools

Arthur Conan Doyle was paid by the word - which means Sherlock’s mysteries take a long time to solve. But it’s in your best interest to solve your mysteries as quickly and efficiently as possible.

This is where a tool like Fluxroll comes in.

Fluxroll allows you to more efficiently use the tools you already have, and gives you the additional information you need to find the root cause.

Now you can track all code changes and configuration changes automatically, and maintain a topological graph that lets you quickly see what’s been affected and isolate the few changes that could be the culprit.

With our Git integration with all major providers, you can also see the actual code change with the click of a button.

You’ll never have to spend hours trying to figure out which branch was deployed again.

And, Fluxroll also maintains a list of stakeholders for each component, so you’re not left wondering who to contact in case of emergency.

Engineering teams using Fluxroll have dramatically reduced their mean time to resolution.

Give your team Sherlockian powers with Fluxroll

Improving observability not only makes your systems better, it makes your team better, because the more you know, the more you can adjust and improve. Software development is never “finished,” and being able to see - and observe - what is happening once your code enters the world will help you build better solutions.

Complex systems should not be a mystery - not when you have the right tools.