SRE and platform engineering meet at the stalled release

The release has stopped halfway through. In this hypothetical incident, the platform engineer can investigate the controller that stopped it. The application engineer knows something just as important: whether the old version can read data the new version has already written. Restoring the controller and rolling back the application are different jobs. Neither answer is a substitute for the other.

This is where the distinction between site reliability engineering, or SRE, and platform engineering becomes useful. Platform engineering makes shared development work easier to do consistently. SRE helps services meet users' expectations without an ever-growing burden of manual care. Their work overlaps, but a stalled release needs more than a debate about whose title covers it. It needs someone to take each question.

The shared platform still has customers of its own

A developer wants to deploy a service without assembling the entire release process again. A platform team might provide that workflow, a starting template for new services, a way to obtain infrastructure or an integration for managing identities. These are internal products: other developers rely on them to get their work done.

The reliability question reaches through that convenience to the people using the finished service. Does the application deliver what they need, and what does it take to keep it doing so? Reliability engineers may help design the answer, write software or take substantial operational responsibility. Platform engineers may write software, run infrastructure and take on-call shifts too. The tools and the pager do not, by themselves, divide the disciplines.

Our deployment platform needs to be reliable for its developer customers. The application using it still has behavior that its own team must understand. In a small organization, the same people may do both jobs; elsewhere, SRE involvement may range from advice to extensive operations work. Combining the people is perfectly possible. Leaving their commitments unspoken is where the trouble begins.

For instance, someone has to agree how reliable the application needs to be. A service level objective, or SLO, states a reliability target, but choosing that target means agreeing what customer impact is acceptable and what the team can sustain. Google's guidance on implementing SLOs makes that agreement a shared responsibility. An SRE cannot settle it alone, and a common platform template cannot know every application's tolerance.

The controller and the data need different answers

Back at the stopped release, fixing the controller will not tell us whether rollback is safe for the data. Checking data compatibility will not restart the controller. Those investigations can move together, with a coordinator keeping them aimed at restoring the customer's service.

The incident commander is the person keeping the response aligned. They need to reach the people who can act, not acquire every production permission themselves. Coordinating the recovery does not transfer ownership of every component. It gives the separate investigations a common picture of what customers need next.

A useful handoff makes the next question concrete. Suppose the application owner can show that deployment stopped before application startup and attaches the controller error. The platform owner can accept investigation of that stage. Meanwhile, the application owner checks whether rollback can safely read the current data, and the incident lead tracks the effect on customers.

The ticket may have reached the platform queue before any of that happens. A queue can hold a question indefinitely; it cannot answer on behalf of the person who has not seen it. Keep the investigation moving until the receiving team accepts it, and agree where to turn if that owner cannot be reached. The transfer is useful when someone takes up the work, not merely when its address changes.

The next team will inherit today's default

Now imagine several applications repeatedly choosing a timeout that makes the same failure worse. Each repair helps the current application. The shared default remains ready to offer the same choice to the next developer.

That recurring problem gives reliability work a route into the platform product. Show which workflow is affected and how the default contributes to the failure. Include the work of moving existing users to a better choice. Changing a default for new applications and changing the behavior of applications already using it are not the same amount of work.

The obligations can travel in the other direction as well. A platform deployment guard may depend on every application supplying a meaningful health check. A shared way of recording telemetry can make investigations easier while adding integration work and storage costs. Bring the affected teams into that design while those obligations can still be changed and funded, rather than surprising them at launch.

It helps to watch both willingness to use the platform and the reliability of the work it supports. A convenient platform can attract plenty of developers while failing too often. A carefully written control can be so awkward that teams find an unsupported way around it. Neither adoption nor a good-looking policy, considered alone, tells you whether the shared product is helping.

Find the missing permission while nobody is waiting

A ticket that recently bounced between teams can make a useful rehearsal. Follow it from the first page: who receives it, who can pause deployment, who restores the platform, and who checks the customer's journey afterward? Try the relevant permissions as well as the contact names. Discovering that the named owner cannot perform the next check is much cheaper here than during another stalled release.

Explicit acceptance should not hold up urgent mitigation. Teams can authorize appropriate, bounded actions in advance and record emergency transfers, so continuity does not depend on reaching one particular person. If rehearsal leaves an unresolved cross-team risk, put it in the risk registry with an owner and review date. That gives planning a chance to address it before another incident supplies the reminder.

The question moves when someone takes it up

Follow the handoff in words

The application owner identifies the failed stage and brings the platform-related records. The platform owner explicitly accepts investigation of that stage. The accepted workstream has a named owner, a next check and an escalation route. Throughout the transfer, the incident lead coordinates customer impact and shared priorities. These are the four roles and relationships shown; accepting one investigation does not transfer every application decision.

Our stopped release now has two questions being worked on: what stopped the controller, and whether the application can go back without misreading its data. The incident lead keeps those answers connected to recovery. SRE and platform engineering have not become the same discipline. The people doing the work simply know which part they have taken on, and the customer no longer has to wait for the organization chart to explain itself.