Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leveraging AI for efficient incident response

engineering.fb.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Leveraging AI for efficient incident response

#11

Post by LASR »

We've shifted our oncall incident response over to mostly AI at this point. And it works quite well.

One of the main reasons why this works well is because we feed the models our incident playbooks and response knowledge bases.

These playbooks are very carefully written and maintained by people. The current generation of models are pretty much post-human in following them, performing reasoning and suggesting mitigations.

We tried indexing just a bunch of incident slack channels and result was not great. But with explicit documentation, it works well.

Kind of proves what we already know, garbage in, garbage out. But also, other functions, eg: PM, Design have tried automating their own workflows, but doesn't work as well.

Re: Leveraging AI for efficient incident response

#12

Post by viraptor »

benreesman wrote: post #9
ketzo wrote: post #2

This is really cool. My optimistic take on GenAI, at least with regard to software engineering, is that it seems like we're gonna have a lot of the boring / tedious parts of our jobs get a lot easier!

Claude 3.5 Sonnet still can’t cut me a diff summary based on the patch that I’m generally willing to hand in as my own work and it’s by far the best API-mediated, investor-subsidized one. Forget the diff, I don’t want my name on the natural language summary.

You mean it doesn't understand the change you've made based on the diff?

Re: Leveraging AI for efficient incident response

#13

Post by minkles »

I'm going to point out the obvious problem here: 42% RC identification is shit.

That means the first person on the call doing the triage has a 58% chance of being fed misinformation and bias which they have to distinguish from reality.

Of course you can't say anything about an ML model being bad that you are promoting for your business.

Re: Leveraging AI for efficient incident response

#14

Post by donavanm »

vjeux wrote: post #10
donavanm wrote: post #4

Im really interested in the implied restriction/focus on “code changes.” IME a very very large number of impacting incidents arent strictly tied to “a” code change, if any at all. It _feels_ like theres an implied solution to tying running version back to deployment rev, to deployment artifacts, and vcs. Boundary conditions and state changes in the distributed system were the biggest bug bear I ran in to at AWS. Then…

From my experience, the vast majority of reliability issues at Meta come from 3 areas: - Code changes - Configuration changes (this includes the equivalent of server topology changes like cloudformation, quota changes) - Experimentation rollout changes There has been issues that are external (like user behavior change for new year / world cup final, physical connection between datacenters being severed…) but they ten…

Interesting. It sounds like “all” service state management (admin config, infra, topology) is discoverable/legible for meta. I think that contrasts with AWS where there is a strong DevTools org, but many services and integrations are more of an API centric service-to-service model with distributed state which is much harder to observe. Every cloud provider I know of also has a (externally opaque) division between “native” cloud-service-built-on-cloud-infra and (typically older) “foundational” services that are much closer to “bare metal” with their own bespoke provisioning and management. Ex EC2 has great visibility inside of their placement and launch flows, but itll never look like/interop with cfn & cloudtrail that ~280 other “native” services use.

Definitely agree that the bulk Of “impact” is back to changes introduced in the SDLC. Even for major incidents infrastructure is probably down to 10-20% of causes in a good org. My view in GP is probably skewed towards major incidents impairing multiple services/regions as well. While I worked on a handful of services it was mostly edge/infra side, and I focused the last few years specifically on major incident management.

Id still be curious about internal system state and faults due to issues like deadlocked workflows, incoherent state machines, and invalid state values. But maybe its simply not that prevalent.

Re: Leveraging AI for efficient incident response

#15

Post by donavanm »

minkles wrote: post #13

I'm going to point out the obvious problem here: 42% RC identification is shit. That means the first person on the call doing the triage has a 58% chance of being fed misinformation and bias which they have to distinguish from reality. Of course you can't say anything about an ML model being bad that you are promoting for your business.

No. Youre missing the UX forest for the pedantry trees here. Ive worked on a team that did similar change detection with little to no ML magic. It matters how its presented as a hint (“top five suggested”) and not THE ANSWER. In addition its VERY common to do things like present confidence or weight to the user. And why theres a huge need for explainability.

And this is just part of the diagnosis process. The system should still be providing breadcrumbs or short cuts for the user to test the suggested hypothesis.

Which is why any responsible system like this will include feedback loops and evaluation of false positive/negative outcomes and tune for sensitivity & specificity over time.

Re: Leveraging AI for efficient incident response

#16

Post by minkles »

donavanm wrote: post #15
minkles wrote: post #13

I'm going to point out the obvious problem here: 42% RC identification is shit. That means the first person on the call doing the triage has a 58% chance of being fed misinformation and bias which they have to distinguish from reality. Of course you can't say anything about an ML model being bad that you are promoting for your business.

No. Youre missing the UX forest for the pedantry trees here. Ive worked on a team that did similar change detection with little to no ML magic. It matters how its presented as a hint (“top five suggested”) and not THE ANSWER. In addition its VERY common to do things like present confidence or weight to the user. And why theres a huge need for explainability. And this is just part of the diagnosis process. The system…

No I'm not. It's crap.

I have about 30 years experience both on hard engineering (electronics) and software engineering particularly on failure analysis and reliability engineering. Most people are lazy and get led astray with false information. This is a very dangerous thing. You need a proper conceptualisation framework like a KT problem analysis to eliminate incorrect causes and keep people thinking rationally and get your MTTR down to something reasonable.

Re: Leveraging AI for efficient incident response

#17

Post by benreesman »

viraptor wrote: post #12
benreesman wrote: post #9

Earlier quoted context omitted.

Claude 3.5 Sonnet still can’t cut me a diff summary based on the patch that I’m generally willing to hand in as my own work and it’s by far the best API-mediated, investor-subsidized one. Forget the diff, I don’t want my name on the natural language summary.

You mean it doesn't understand the change you've made based on the diff?

Even under the most generous nomenclature, no contemporary LLM understands anything.

They approximate argmax(P_sub_theta(token|prefix)).

This approximation is sometimes useful. I’ve found it to never be useful in writing code or prose about code of any difficulty. That’s my personal anecdote, but one will note that OpenAI and Anthropic still employ a great many software engineers.

Re: Leveraging AI for efficient incident response

#18

Post by jononor »

LASR wrote: post #11

We've shifted our oncall incident response over to mostly AI at this point. And it works quite well. One of the main reasons why this works well is because we feed the models our incident playbooks and response knowledge bases. These playbooks are very carefully written and maintained by people. The current generation of models are pretty much post-human in following them, performing reasoning and suggesting mitigati…

Expert systems redux? Being able to provide the expertise in form of plain written English (or another language), will at least make it much more feasible to build them up. And it can also meaningfully be consumed by a human.

If it works well for incident response, then there are many usecases that are similar - basically most kinds of diagnostics/troubleshooting of systems. At least the relatively bounded ones, where it is feasible to on have documentation on the particular system. Say debugging of a building HVAC system.

Re: Leveraging AI for efficient incident response

#20

Post by re-thc »

donavanm wrote: post #4

Im really interested in the implied restriction/focus on “code changes.” IME a very very large number of impacting incidents arent strictly tied to “a” code change, if any at all. It _feels_ like theres an implied solution to tying running version back to deployment rev, to deployment artifacts, and vcs. Boundary conditions and state changes in the distributed system were the biggest bug bear I ran in to at AWS. Then…

> IME a very very large number of impacting incidents arent strictly tied to “a” code change, if any at all

Usually this implies there are bigger problems. If something keeps breaking without any change (config / code) then it was likely always broken and just ignored.

So when companies do have most of the low hanging fruit resolved it's the changes that break things.

I've seen places where everything is duck taped together but BUT it still only breaks on code changes. Everyone learns to avoid stressing anything fragile.

Post reply on HN