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. 🌈🖤 Jun. 18, 2019 3 min read

now, if you haven't been paying attention, we have racked up quite a library of useful material over the past year at @honeycombio. 🐝

our first white paper is the best answer you're gonna find anywhere to the question: ✨what is observability?✨  https://www.honeycomb.io/resources/guide-achieving-observability/ 

our second white paper or ebook was called "observability for developers", and it focused on instrumentation: how to gather data at the right level of granularity to achieve the o11y goal of 'ask any question, without having to ship new code'.

 https://www.honeycomb.io/resources/guide-observability-for-developers/ 

we then shipped a guide on tracing. we believe the events you are already gathering to debug your systems should be *plenty*, without having to store all that data (& pay for storing that data) in a completely new silo.

 https://www.honeycomb.io/resources/always-bee-tracing/ 

if you were at @o11ycon last year, you know we broke out into a bunch of small expert groups to share knowledge and best practices around observability. the findings of that skill share are gathered for posterity here:

 https://www.honeycomb.io/resources/o11ycon-2018-discussion-findings/ 

oh. whoops. the tracing link above is to our tracing *webinar*. this is the guide to tracing with honeycomb-style events (or opentracing events):

 https://www.honeycomb.io/resources/distributed-tracing/ 

we then published a guide for business decision-makers to help them see why observability is a key cornerstone for cutting down on technical debt, improving MTTR, managing systems with fewer humans, devoting more time to creative labor, etc.

 https://www.honeycomb.io/wp-content/uploads/2019/02/Why-Your-Business-Needs-Observability.pdf 

next we published an intro to best practices with sampling. we as an industry have lost these muscles, and we *must* regain them if we are going to run systems at scale.

aka "if you pay your logging vendor too much, start here" 👉  https://www.honeycomb.io/wp-content/uploads/2019/05/the_new_rules_of_sampling_-_typeset_final.pdf 

speaking of which, how much *should* you be spending on observability? my rule of thumb has always been, o11y should total 10-30% of your infra spend. but if you want to know what the professionals say, we've got a whitepaper for that too.

 https://www.honeycomb.io/resources/calculating-costs-for-observability/ 

we got a lot of questions about how (or if) someone should use us if they already have various tools. so we wrote up a paper on where we fit in the general landscape, and what we coexist nicely with or replace.

 https://www.honeycomb.io/wp-content/uploads/2019/06/Building_Your_Observability_Practice_with_Tools_that_Co-exist.pdf 

some of these are signup gated, some are not; echo complaints >> /dev/null.

the amazing, unstoppable force behind these guides is primarily the magnificent @djpiebob, who came to honeycomb after a decade at splunk.

she walked in the door, and poof -- ✨professionalism✨

but honeycomb has never been just about building another dev tool or ops tool. we're on a mission ... to humanize the profession of software development.

we believe that tools change lives. we believe that data changes lives.

we believe that people genuinely want to do the right thing, and usually WILL do the right thing if they know what that is and have the power to do so.

our profession has grown inhumane as we have grown increasingly disconnected from our users.

it is unacceptable for 40% of our software engineering cycles to get drowned under in tech debt.

it is unacceptable for on call to be life-impacting, sleep cycle destroying drudgery. it is *equally* unacceptable to ask another team to suffer on your behalf.

observability has long been a missing link in the quest for humane, sustainable careers in tech.

without observability, you can't consistently align your engineering incentives with user experience, nor can you consistently make progress. you'll just be guessing.

but it's not enough on its own, either. you have to shiift the focus from the individual performer to the group, identify unique pathologies and craft custom solutions to grow your team ever closer to functional and happy.

which brings us to our latest, the "maturity model".

this paper condenses a lot of what @lizthegrey and i know about building humane, high performing teams and aligning the incentives of engineers and users, and how these goals intersect with observability.

we'd love your feedback 💛🐝🖤
 https://www.honeycomb.io/wp-content/uploads/2019/06/Framework-for-an-Observability-Maturity-Model.pdf 

... and now i've got my replacement pinned tweet. 👆woot!


You can follow @mipsytipsy.



Bookmark

____
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.