TL;DR
While DevOps is not orthogonal to Scrum, Devops and Scrum are not synonyms. In addition, there is no "DevOps" role in Scrum. Everyone but the Product Owner and Scrum Master (let's see if I we can start normalizing the term "Scrum Referee" instead!) is simply a Developer.
The fact that infrastructure and operations work is part of Sprint Planning should be embraced. It is the job of the Scrum Master to coach, educate, and facilitate this collaboration, not to find ways for the team to avoid it.
Analysis and Recommendations
This leads to issues where frontend devs are not happy because they have to estimate "server stuff" and Infra/Ops are not happy because they have to estimate "refactor JS service XY" during Sprint Planning.
Good. This is exactly as it should be. Scrum is based on empirical design and just-in-time planning, while frameworks that use Scrum (e.g. SAFe) call what you're doing architectural runway. In either case, it is the responsibility of the whole Scrum Team to call out dependencies and plan for them during Sprint Planning.
Whether or not your team is T-shaped or I-shaped, how do the Developers plan to test and deploy work if no one on the team is thinking about "server stuff?" How will your Developers with infrastructure or ops skills successfully contribute if no one on the team is taking responsibility for upgrading the Node.js Kubernetes pods when needed?
While it may not be possible in your organization to have T-shaped people with cross-functional skills assigned to your team, and while they may not currently see the value in each other's work, the reality is that it's your job to facilitate the collaboration between them and to ensure that the whole Scrum Team (including the Product Owner and the Developers) treat infrastructure and operations work as part of the Definition of Done for each user story. In turn, doing that requires that infrastructure and operations tasks need to be included in Product Backlog Refinement, in Sprint Planning, baked into estimates, and completable within the same Sprint as the rest of the potentially-shippable increment.
The fact that you have people on both sides of this issue saying it's someone else's problem means you have created a JBOP group (Just a Bunch of People℠, riffing off of the JBOD non-RAID appellation) rather than a cohesive team committed to delivering a single coherent increment as required by the Scrum framework, which explicitly states:
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Taking Ownership of the Problem
Part of your job as Scrum Master is to help your team understand how the framework is supposed to work, and to assist them in removing friction points and silos within the team when they aren't yet ready to do it themselves. Embracing silos or allowing the team to toss things over the wall to other people rather than taking ownership as a team to deliver the Sprint Goal is simply not an option.
The Scrum Team collectively owns their own process and must be empowered to inspect-and-adapt their processes within the framework as needed. Currently, they clearly need assistance in fixing those processes, and may not feel empowered to develop or apply new processes. The is great grist for the mill for the team's Sprint Retrospectives, and supporting this effort is a core expectation for the role of Scrum Master.
Senior Leadership's Role
On the other hand, if the underlying problem is that your organization is broken, then the Scrum Team (and especially the Scrum Master) is responsible for communicating these problems upwards within the organization and collaborating with organizational leaders outside the team to fix it. However, if the organizational culture is too toxic or broken to be fixed, then that is the responsibility of senior leadership since they establish the tone at the top.
Basically, if senior leadership deliberately breaks or fails to properly support the Scrum framework despite the Scrum Team's best efforts, then the responsibility ultimately rests with that leadership team. If leadership breaks the company culture or its processes, then they get to keep both halves. Q.E.D.
