If there is any one thing teams new to Agile need to learn, it is that Scrum is just one choice among many. And nowhere near as universally useful as people seem to believe.
HOWEVER; The counterpoint would be if you are doing new product work and your priorities are changing faster than a week or two you have either an exceptional situation or this should be a canary that you have something really wrong with your priority directions.
In the latter case scrum is being a useful tool in bringing this to your attention.
1. Pre-customer development
2. Contract development shops where you bill by the sprint
I’ve never seen good outcomes in a live product environment.
Usually the answer is Kanban for smaller teams or Scaled Agile for larger teams IMO…but the situation the OP is dealing with looks like they are prioritizing preventative work to stop these support tickets from having to come in in the first place.
Prevention measures for unplanned work are critical.
I STRONGLY disagree with this, conceptually, logically and in practice. Scaled agile approaches make you plan your sprints way further in advance and account for emerging (or sustainment) work with the use of reserving a percentage of capacity. This works about as well as riding out a run of bad luck at the casino while you wait for the odds to balance out. Scaling "up" the existing practices to a department or company level will not help an interrupt-driven team. Scaled agile doesn't work for pure development teams; i'ts even less likely to work for an SRE team.
It gets the plan in front of everybody so you can discuss the tradeoffs and risks too. There's an entire open session as part of it called R.O.A.M. where risks to the ability to deliver the plan are discussed, not just with the tech people but with the business folks too.
That portion of PI planning is where you call out things that could break the plan. Emerging (or sustainment) work is one of those risks and you have to call it out, then once it's called out you have to discuss what the organization is going to do to prevent it. Capacity isn't going to just spring forth out of nowhere, so what are we pushing off if there's more of it than expected? Do we need to prioritize preventative work to make sure we don't have problems? Do we need some type of infrastructure, monitoring system or automation in our devops process?
Everywhere I've been, the PI Planning process has led to less "we have to do this now" and more "we need to see if this can be included in the next PI", which creates significantly less disruptions to the development team focus. The only remaining interruptions should be production issues (preventable) or significant market shifts (rare).
It doesn't work when people try to adhere to that plan so rigidly that it becomes a waterfall system.
IMO the biggest issue with Scaled Agile always comes down to leadership IMO. It's not supposed to be rigid. It's supposed to be adapted to your organization and put the plans in the hands of the developers.
The horror stories about SAFe that I've seen on here usually end up with me asking a few followup questions and those questions make it clear that something was terribly wrong. One guy on here told me they did PI Planning for 2 full weeks, which is abject insanity.
What we used to do (while growing the SRE team from ~8 to 30) was having dedicated teams on specific projects. Each had their own scheduling system as they saw fit. AND a weekly rotating support duty which took precedence: teams had to allocate someone from their own capacity to this duty.
The importance was to adequately rotate everyone, to pair a senior and a junior in the support team, and to be available to them to debrief, or to reallocate high priority/criticity tasks to more expert members, if required.
Also, if the support queue was empty, they could do maintenance/exploratory work, but NOT their own team project work.