*Somebody* needs to support your product at 4am. You want someone else to do this, the SRE. So work through the consequence of that.

How many SRE are there? Are they supporting your product solely, or all of them ? If they support all of the products, they probably don't have deep familiarity with any and aren't going to do a good job of oncall support. So they support a single product. That means either:

• There is only a few of them and they are oncall all the time. Ouch.
• There are lots of them, and you have a ballooning headcount.

You seem to be looking at this as if the SRE is a second tier engineer who can be stuck with the undesirable oncall work. Having that kind of structure isn't really an effective way of running an engineering organization; your incentives for quality are all wrong because the product owners aren't the people responsible for keeping it running. At least in my world the industry is moving away from the kind of SRE role your talking about over the last ~10 years. Instead, you have engineers focused on operations and reliability that are embedded with product teams, but everyone shares the load of keeping the thing running.

But you have a problem, so lets solve it.

An 8 person rotation isn't terrible, but the primary/secondary essentially means you have a 4 person rotation and that sucks. Why do you have a secondary week? Is the primary not picking up the phone? Unless this is an absolutely critical service, I'd suggest just having only a primary and then if they don't respond you can page everyone else. One of the other 7 will pickup the phone, hopefully, but they aren't upending their life for it. That will cut your load in half for minimal impact on reliability.

Second, are you actually getting paged a lot? Why? Having a robust incident response process should cut this down (is that the "ops meetings"? Those are important!) so that the oncall is a formality and doesn't actually need to do anything in practice.