Charity Majors @mipsytipsy CTO @honeycombio, ex-Parse, Facebook, Linden Lab; cowrote Database Reliability Engineering; loves whiskey, rainbows. I test in production and so do you. ๐ŸŒˆ๐Ÿ–ค Jul. 03, 2019 1 min read

... the truest sign of a healthy team and healthy system is this: you mostly use your observability tooling for

๐Ÿ”ฎ business
๐Ÿ”ญ product
๐Ÿ”Ž 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. โ€ฆ

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.