Why Cloud-Native Site Reliability Engineering Is Becoming a Mainframe Skill
As transaction paths become more complex, Scott Petry of PwC US stresses the increasing importance of automation, observability, incident management and more
As enterprise environments expand across z/OS, AWS, APIs and distributed services, mainframe teams need to apply reliability practices typically associated with cloud-based operations.
Site reliability engineering (SRE), which emerged from large-scale cloud operations, is becoming increasingly important for mainframe teams as the complexity of transaction paths is growing.
When a customer opens a mobile app and submits a payment, the request often passes through an API gateway on AWS, a Kubernetes-based microservice, a cloud database and an IBM z/OS system of record. If the transaction fails, who owns the incident?
“The reliability boundary now extends well beyond the mainframe itself,” Scott Petry, principal, Cloud Engineering, Data & Analytics at PwC US, tells TechChannel. “Reliability must now be managed across the full hybrid environment, not within the boundaries of a single platform.”
SRE uses software engineering to improve reliability through automation, observability, incident management and measurable service-level objectives (SLOs). In AWS environments, SRE teams typically focus on distributed systems, automated recovery and end-to-end service health. An engineer would typically monitor performance metric and detect anomalous behavior in enterprise software. But as enterprise transactions now span z/OS, APIs and cloud services, those principles are becoming relevant to mainframe operations.
“In that environment, it is not enough for each platform to appear healthy independently. The practical measure of reliability is whether the entire transaction completes successfully from end to end,” Petry says.
Why Monitoring Is No Longer Enough
Traditional monitoring focused on the health of infrastructure, from CPU utilization to memory consumption, storage capacity and basic availability metrics. Those indicators remain important, but they do not explain why a transaction failed.
“The key shift is from measuring the health of individual systems to measuring the reliability of the business service they collectively support,” Petry says. That requires observability focusing on transaction flow, service dependencies, latency and the user experience across the application path. A payment request that moves from a mobile app to AWS and to a z/OS system can still fail even while the end-to-end system is functioning as designed at each individual layer.
So how do you troubleshoot a transaction that touches multiple platforms?
“The first requirement is end-to-end visibility,” Petry says. “Teams need to be able to follow a transaction across every system it touches, from APIs and cloud services through to the mainframe system of record.”
Troubleshooting in hybrid environments depends on cross-platform telemetry that can correlate metrics, logs and traces across APIs, cloud services, databases and mainframe applications. Amazon CloudWatch can help with this, enabling teams to consolidate data from AWS and third-party sources in a single location and use a range of analytics tools to generate actionable insights.
“Distributed tracing with a shared correlation ID allows operations teams to connect telemetry across platforms and identify where latency, errors or failures occurred. That reduces the time spent comparing separate logs and coordinating among cloud, application and mainframe teams,” Petry says.
Unified observability is also key. “If each team can see only its own platform, troubleshooting becomes a process of elimination,” Petry explains. “A consolidated view of the full transaction path makes it much easier to isolate the root cause and understand the customer or business impact.”
SRE teams can use AWS Management and Governance services—such as AWS Service Catalog, AWS Systems Manager and AWS Proton—to manage AWS and on-premises computing resources and deploy distributed applications without compromising system reliability.
Which SRE Principles Apply to Mainframe Operations?
While the principles of site reliability engineering are often associated with cloud-native platforms, many of them translate to mainframe operations.
SLOs define measurable reliability targets, error budgets establish how much disruption is acceptable before teams need to take corrective action, and structured incident response helps organizations learn from system failures. Automation is used wherever possible to reduce manual intervention and improve operational consistency.
“The core objective of SRE is to improve reliability through measurement, automation and continuous improvement, and those principles are highly relevant to mainframe operations,” Petry notes.
In a z/OS environment, they can be applied to batch completion windows, transaction throughput, response times, availability targets and workflows such as job scheduling, recovery procedures and system provisioning. Mainframe teams have long managed reliability through capacity planning and change control.
“The opportunity is to extend those practices across the full transaction path,” Petry adds. “That includes defining service-level objectives that span cloud and mainframe environments, correlating telemetry across platforms, automating repeatable operational tasks and using incident data to reduce recurring manual work.”
“Incident response, automation, capacity planning and observability translate most naturally because mainframe teams have practiced disciplined versions of them for years.”
The primary challenge is connecting those established practices in enterprise systems with cloud-native tools and bridging telemetry across the hybrid environment.
Not every SRE principle transfers directly. “Service-level objectives also translate well, but they should be defined around the end-to-end business transaction rather than measured platform by platform,” Petry explains. “The SLO that matters most is the one that reflects whether the customer-facing service completed successfully.”
Error budgets in particular require more adaptation. “Accepting a defined amount of unreliability in exchange for faster innovation can be difficult to apply to core systems of record, where the tolerance for failed critical transactions may be close to zero,” Petry says. “In practice, error budgets are often more useful for surrounding cloud services, customer-facing applications and release pipelines than for the mainframe system of record itself.”
How SRE Is Reshaping Mainframe Operational Roles
Mainframe operations teams are increasingly being asked to manage hybrid systems that extend beyond the boundaries of z/OS, requiring engineers to obtain new skills in APIs, Kubernetes fundamentals, cloud networking, observability platforms and automation scripting.
As outages of customer-facing systems can involve cloud services, APIs, databases and mainframe applications simultaneously, reliability engineering is becoming a collaboration between mainframe specialists and cloud, application and platform teams.
But there are often organizational obstacles to achieving end-to-end reliability. Fragmented systems with separate dashboards, alerting systems and ownership can make it difficult to diagnose problems across multiple environments and slow down incident response.
AI platforms can correlate events across systems, detect anomalies, suggest likely root causes and accelerate incident analysis, but only when they are fed with high-quality telemetry data. This requires organizations to break down silos so that reliable inputs and cross-platform coordination support a unified observability stack.
As distributed business services span hybrid on-premises and cloud environments, the skill set required to operate reliable systems supporting critical transactions is changing. The link between observability and SRE is strengthening, with SRE principles providing a practical framework.