#o11y

With the Christmas holidays happening, things slowed down enough to sit and catch up on some reading – which included reading Cloud Observability in Action by Michael Hausenblas from Manning. You could ask – why would I read a book about a domain you’ve written about (Logging In Action with Fluentd) and have an active book in development (Fluent Bit with Kubernetes)? The truth is, it’s good to…

I think that if the mental model one is using is like the New View on Systems Safety, then the connections between the disciplines in TOAD (Testing, Observability And Devops 🐸) naturally become obvious as you work more and more with software systems.

Conversely for people rooted in the traditional / Cartesian view of software systems, it’s pretty much impossible to explain. (edited)

For instance

If I think that the history of a software is composed of discrete, finite frames of time that can be reconstructed after the fact then good fucking luck explaining to me why I need an observability framework that lets me respond quickly to unknowns.

Because if I think history is composed of discrete, comprehensible frames that can be reconstructed after the fact, then I have a lot to learn from the system out of that history — your observability and prediction techniques are nice but not necessary.

However

If I don’t accept that history is composed of discrete comprehensible events, then I have very little to learn from history and then the o11y framework and the culture of resiliency makes sense This is btw what is obliquely being gotten at in the Clay Shirkey quote:

Process is an embedded reaction to prior stupidity.

It means people with a lot of process are people with the old / Cartesian view of system safety. They have a lot of process because they think they can predict what sort of events will be important in the future.

Since formal process is reactive, it follows that in order to have a lot of formal process, we have to have a lot of events we can predict with great specificity.