Very often the causes of an incident aren't visible in metrics because the relevant metrics aren't collected. Sometimes an incident is caused by external actors, etc...
You forgot that this whole discussion started from the question "What contexts would the AI model need for analyzing, let's say, cluster-wide incident other than the observability data that such systems anyway collect already?". If one wants to automate resolution, then it becomes necessary to feed all kinds of information into the decision engine, precisely to compensate the incompleteness of each source of information.
Bad news for you is then, no, it does not and I have a case in point at hand. Complex many-fold cascading incident(s) investigation that spans multiple data centers. I am not making these things up. As much as AI has been shown to be very good in complementing the SWEs work, the same goes for SREs and other similar roles in the field.
Yes, "entire" company codebase is a stretch as is design docs, status pages etc Helpful yes but not a hard requirement per se. In many places you won't find such level of details available and yet the incidents are still being solved
They're still being solved because there are people that hold that information in their minds. If you want to automate this, you need to feed the source code in its entirety into the decision engine.
Not sure how that relates to incident debugging?
Very often the causes of an incident aren't visible in metrics because the relevant metrics aren't collected. Sometimes an incident is caused by external actors, etc...
Yes but IME it is never possible to collect everything. It's part of the job to deduce the missing parts from what we have available.
You forgot that this whole discussion started from the question "What contexts would the AI model need for analyzing, let's say, cluster-wide incident other than the observability data that such systems anyway collect already?". If one wants to automate resolution, then it becomes necessary to feed all kinds of information into the decision engine, precisely to compensate the incompleteness of each source of information.
Yes, my point was that one does not need "all kinds of information".
Your point is wrong. An automated incident investigation tool needs "all kinds of information".
Bad news for you is then, no, it does not and I have a case in point at hand. Complex many-fold cascading incident(s) investigation that spans multiple data centers. I am not making these things up. As much as AI has been shown to be very good in complementing the SWEs work, the same goes for SREs and other similar roles in the field.
Your case I point is irrelevant. This was a hypothetical scenario, something you seem unable to comprehend.
Keep coping. And next time find some decency in your replies.
When I find some intelligence in your replies, I will.
I wonder how is it to live with that amount of toxicity and frustration? Keep it loose man, you're gonna get yourself a cancer.
Lol, I live a lot better than you.
You're not sure how the system's code relates to incident debugging for that system?
Yes, "entire" company codebase is a stretch as is design docs, status pages etc Helpful yes but not a hard requirement per se. In many places you won't find such level of details available and yet the incidents are still being solved
They're still being solved because there are people that hold that information in their minds. If you want to automate this, you need to feed the source code in its entirety into the decision engine.