As usual Aaron Bertrand and Kin provided excellent answers. However both answers contain a common thread. If you analyze either answer you will see that the reason why XYZ isn't working like it worked yesterday isn't because of something you/they/person X did. The reason why things changed is because the database decided to do things differently due to XYZ reasons.
A database is a living, breathing entity. Databases will make decisions, and change its mind due to a combinations of assumptions, statistics, and other heuristic tools. This is dramatically different than most application layer programming (machine learning being a notable exception).
I'm going to use some military references because I can't think of something better right now. A more general metaphor would be appreciated (no pun intended).
In most applications the programmer acts as a Drill Instructor. They tell the computer exactly what to do, in what order, and sometimes for how long. Programming a database is more like acting as a Commanding Officer. You tell it what you want it to do in at a high level, and offer some guidance where needed. The database takes on the job of figuring out the best manner to execute the plan based on current intelligence like the junior officers and non-commissioned officers.
By making this distinction clear in the other programmers minds they will hopefully begin to see that you don't have dictorial powers like they do over their environment. You are guiding the database to the solution and occasionally the database gets off track for good or bad reasons. Remind them that in the end it doesn't matter why* the database went off track, but what we can do to bring it back.
*I recognize "why" is very valuable for future prevention, learning, etc. but it seems like the OP is facing resistance from people who aren't trying to learn about or help the problem.