I work in a team that does mostly development work, but is also responsible for existing complex systems. We've had this problem as well.
Basically, we estimate our points based on the last sprint(s) and then reserve a number of points for the expected maintenance work. Should a maintenance task occur that exceeds this significantly, like a major outage, we add it as a user story and remove an existing one that has not started yet, to keep the sprint of the same size. If a major issue pops up that is less urgent, we move it into the next sprint.
Yes, this is technically not following scrum. But the flexibility has worked well for us.
We have refined this reserved time by asking the team at every planning meeting whether they see reason to deviate from the standard reservation. We introduced this after doing an office move which took us much more time than we anticipated, leading to many stories not being finished.
However, do not just stick to how my team or any other team does it. Pick something, and just do it. There is no way to ensure that it will work well for your team. Try, and evaluate in the retrospective. If the team is unhappy, try something different and evaluate again. All teams are different, and their needs and limitations are different as well.