On my side, working in a small team of 5, we just leave one person out of the sprint to work on support requests, bug fixes and if time allow improvements. Large handling of technical debt (ex: transitioning from VueJS 2 to 3, good luck expressing this as a "product increment" in a sprint goal and good luck if you don't tackle it ... ) are part of sprint work.
Overtime, I realized that Scrum is a framework, not a fixed set of rules, and as per Agile, the goal is to maximize business value. So if we are swamped by support requests and our systems are not operating properly, it's the role of the person on "support duty" to warn the rest of the team and ask for help. Sure it may impact some velocity metrics and we may not hit our sprint goal that week, but why would that matter? There is no point writing more code and building more features if what we have is not working properly and not satisfying to users.
The main issue i have seen with this system is that the developer on support duty may not have the right skills to perform all the work that is needed. Scrum relies on the assumption that anyone can do anything, and that's definitely a flaw when working on a larger codebase with a mixed of frontend, backend and devops with more junior developers. It does force us to train everybody and learn to delegate so that everybody can be exposed to all parts of the system but this takes many months / years.
We also learnt to define smaller Scrum goals. It's better to achieve a small goal and then decide what to do next than to always feel like we are running behind. The sequence of "two weeks" sprints is often seen as a "fixed" schedule with deadline to hold at all costs, but that's stupid. The core idea of Agile is to follow an incremental approach following the path of max business value delivery, and periodically reflect about how things are going. If the amount of support requests and operational issues is such that there is no more resources available for new feature development, then it's time to prioritize tackling some technical debt and improve monitoring and automation to prevent the most common issues