We have 2 (50% distributed) scrum teams, that have been doing scrum for just over a year. Since almost the whole time, the teams' painful point is environments instability, from all perspectives: smoke tests failing and need to be looked at, things break and need to invest time into fixing them, things are deployed from other teams (we work in a global project) that broke our code and so on. All these are not the teams' problems, though they intermittently impede our teams. Otherwise, the teams state that are very happy and constantly improve.
So, despite our velocity been estimated correctly (say 50), and if everything goes well we can deliver that, we are often called to fix our environments, do investigation, do root cause analysis etc. Therefore we end up not delivering successful sprints. We cannot gauge this downtime since sometimes takes up 1 person - 1 hour, sometimes 4 persons - 2 days to investigate and fix. This is completely random.
This problem keeps being raised in retrospectives, the management is aware, and the response is that "we are aware of these and agreement has been made to improve on such and such...", and that "we are moving towards improving the whole process by doing X,Y,Z". In discussions between the scrum master and the development manager, the development manager almost refuses that these problems are the reason why the team is not delivering successful sprints, and that given good coordination, the team should still be delivering anything that they committed to. Committing to less might mean that the team is delivering everything and runs out of things to do in the sprint, whereas over-committing might end up not delivering everything. Also, under-committing has been proved to raise the manager's eyebrow as "the team must always have things to do", and "under-committing" is not the solution.
What do you think are possibles fixes to this process so that the team can effectively commit and deliver within this environment?