... the truest sign of a healthy team and healthy system is this: you mostly use your observability tooling for
🔎 other higher order use cases.
Not incident response, not even bugs. But that doesn't mean you stop using it. Quite the opposite.
Teams that have clawed their way out of reactive mode tend to use observability tooling *even more*.
🌟 for understanding user behavior
🌟 making informed decisions
🌟 resolving conflicts like gentlefolk
🌟 retrofitting in advance of known scaling cliffs
Observability tooling is a hard prerequisite or terrific assist for efforts like
🌟 improving your deployment pipeline, running multiple builds at once
🌟any sort of controlled injection of chaos
🌟 load testing, identifying said scaling cliffs
🌟 satisfying one's curiosity
... I could go on. ☺️ Basically, your appetite for good observability is likely to *grow* after you've extricated yourself from the mess of firefighting.
But you'll use it differently. Not just for understanding your systems,
but for answering complex business questions, running experiments, and validating hypotheses about your users 🌤in conjunction with🌤 your systems.
This was the core insight of the model @lizthegrey and I have been working on. https://www.honeycomb.io/blog/toward-a-maturity-model-for-observability/ …
You can follow @mipsytipsy.
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.
Enjoy Threader? Sign up.
Threader is an independent project created by only two developers. The site gets 500,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Running this space is expensive and time consuming. If you find Threader useful, please consider supporting us to make it a sustainable project.