Computers can detect dips and spikes, but only humans can ascribe meaning.
I don't think I posted this yet -- @FisherDanyel wrote a dead-on piece summarizing the reasons our industry's embrace of "AIOps" is such a muddle. https://thenewstack.io/observability-and-the-misleading-promise-of-aiops/ …
OH "I stand by my claim that as long as Gartner insists on defining AI as “the magic technology that will make high cardinality problems go away”, that we get to define the ranking function in BubbleUp as AI." ... yeah. 😖
Look...I'm not trying to pick on anyone or be a jerk. I get it, marketing terms exist to simplify and sell, they don't have to be technically precise or meaningful.
It's just that the closer I look at the use cases, the more it appears to annihilate good operations engineering.
Managing fleets at scale requires a lot of critical thinking about signal and noise. Your ability to debug depends on your ability to prune and sample and emit meaningful telemetry.
AIOps is like... "or you could just not? throw it all in the soup and we'll fix it in post."
I'm actually relatively sympathetic to the arguments for AIOps, and I believe that someday something like this will be both reasonable and useful.
But when I look at the *actual examples* touted today, all I see are complicated answers to problems that shouldn't exist.
Like the one I've heard over and over about tens of thousands of nodes all emailing their disk space usage, and how AIOps saves a human from having to read them all. 😳
Shouldn't exist. The solution is to get rid of the spew, not do more elaborate things with it.
It bothers me how many value propositions seem to boil down to assuring tech execs that their engineers won't need to understand their own systems.
AIOps goes the extra mile in then guaranteeing they won't be able to do so.
Honeycomb's value prop and philosophy have always been the exact mirror image, fwiw.
At the end of the day, we believe that someone, somewhere is going to have to understand your systems. That's who we build for. Those people are our customers.
And furthermore, since software is built and run by teams, we aim to bring everyone up to the level of your best debugger in each part of the system, by sharing history and context.
We believe that tools can democratize understanding and expertise.
Someone asked last week, hesitantly, if it would be too grandiose to say that our real product is that we build better engineers.
Grandiose it may be 🙃 but it is absolutely not wrong.
How do you build a better engineer? You immerse them in reality (production) with the tools to swiftly inspect and explore the effects of their actions.
You give challenging, interesting work and peers to learn from, you minimize the bullshit and ship frequently.
I really don't think we spend nearly enough time thinking and talking about the sociotechnical systems that contribute to not only great engineering, but great *engineers*.
What stands between so many decent engineers and greatness is their near illiteracy with prod.
If your instincts for writing code were honed in staging or on your laptop, you simply cannot be thought of as a mature engineer. (You may be close though! 💕)
So yeah, um. AIOps. lol.
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.