... 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.
Since you’re here...
... we’re asking visitors like you to make a contribution to support this independent project. In these uncertain times, access to information is vital. Threader gets 1,000,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Your financial support will help two developers to keep working on this app. Everyone’s contribution, big or small, is so valuable. Support Threader by becoming premium or by donating on PayPal. Thank you.