You call your resident "cloud team" or "infrastructure team" for help. Unfortunately, those guys are busy having an existential crisis looking into the abyss of machines, queues, cache layers and databases that are supposedly enabling "smooth team based development".
So you get adventurous and open up XRay or Application Insights or whatever the fuck. After a few hours you realize that the erroneous response code that you thought was the culprit is there by "by design" "intentionally".
So you say fuck it and add another microservice or cache layer that "fixes" the problem and call it a day. You can hear screams of agony from the infrastructure team, but who cares.
When you leave for the day, the boss pats you on the shoulder. "Nice work today, handling that incident", he says.
Further, I think microservices can encourages devs to stay in their own little walled garden and they're quick to say "everything's working on my end, must be somebody else's problem".
Very few people, if any, have a complete understanding of the system and this is often by design which may not necessarily be a good thing. Reasoning between microservices feels harder to me than reasoning within a monolith.
I don't believe that's true in practice.
Having many services moves a lot of complexity from 1 program to "the system" as a whole. All the stuff outside the services themselves.
Who do you call when the incoming requests are failing, but each service is working fine in isolation?