An application outage occurs. What happens next?
Immediately, the support team begins investigating—reviewing logs, metrics, and any signals that might point to the cause. They reach out to the network team for clarity since there was a change.
The network team responds that a recent change was made at the network layer and based on their validation, everything appeared to be operating normally, with traffic flowing through the load balancer as expected.
As time passes, the customers continue to experience the impact, while both internal teams continue their investigations. Eventually, deeper analysis reveals that the network change actually created the service interruption.
In situations like this, one team is focused on restoring service as quickly as possible, while another is validating recent changes based on their own system context. Both are working with the information available to them at the time.
The challenge is that, in complex environments, understanding is often distributed across multiple teams and systems. When incidents occur, the effort to identify root cause can become slower when context isn’t easily shared across those boundaries.
Evidence-Based Discovery
Most organizations face the same pressures. Operating expenses go under budget cuts, with relentless year-over-year cost optimization. Capital expenditure gets approved, as that’s where new business value is created. This creates tension: reduce operating costs while maintaining reliability.
The typical answer is to throw more people at it, by adding another shift or hiring more specialists. But that just scales costs with complexity while treating symptoms and not the cause of the core problem.
To circumvent these issues, our work begins by conducting discovery and assessment sessions with organizations, then auditing and analyzing their issues to understand how the business runs daily. This gives us facts and real evidence to work with.
Findings may reveal that traffic started dropping before customers noted their concerns, configuration changes happened right before services degraded, or alert fatigue buried the real signals. Teams weren’t talking to each other even though they manage the same systems. Once patterns are surfaced, we build a value hypothesis showing what organizations are currently spending on reactive operations, the toil we can eliminate, and what the transformation will look like.
User Experience Over Metrics
Most monitoring focuses on cause-based metrics such as CPU usage, memory consumption, and network errors. But the problem is, by the time these metrics spike, customers are already feeling the impact.
By pushing symptom-based monitoring instead, real user experiences can be tracked: climbing request latency, dropped transaction rate success, and slow-loading pages. These symptoms appear before infrastructure alerts fire, giving teams time to respond before the outage hits customers.
Then we connect symptom monitoring to change tracking. Traffic suddenly decreases? Something’s wrong, because normal conditions don’t produce that pattern. The system correlates with recent deployments, configuration updates, and infrastructure changes, so teams immediately see what could have caused the problem instead of spending hours blaming each other.
Trust as Technical Infrastructure
Site reliability engineering introduced blameless postmortems. Most companies claim they do this. But practically, they’re rarely implemented. Leadership support is required. Organizations need to understand that teams will make mistakes. Then the question becomes: what did we learn and how do we make sure it doesn’t happen again?
After that, guardrails come into play to ensure the problem doesn’t repeat. How do we test and validate changes across teams so the network can certify their changes won’t impact applications? These require technical solutions that connect systems.
With the original network change example, the network team believed their change was safe and validated it on their end, while the service team investigated once alerts fired. Both teams acted reasonably with the information they had, but the problem lived in the gap between them. When engineers trust that honesty accelerates resolutions rather than inviting consequences, collaboration replaces finger-pointing.
The Cost-Value Equation
Conscious choices need to be made for automation versus agentic approaches. A $10 problem doesn’t need to be solved with $100 worth of automation or AI.
Simple, repetitive tasks get traditional automation: restart failed services, rotate logs, and scale based on load. These follow clear rules. Complex diagnostics get agentic AI: correlating symptoms across multiple systems, identifying root causes when data is incomplete, and recommending fixes based on similar past incidents. These need reasoning and context.
We tested this ourselves. As an AI-native company, we deployed services in our own cloud, simulated incidents, and trained models on operational patterns to reveal which problems AI solves effectively and which require different approaches.
Built for Production Speed
Platform operations is different from platform engineering or data teams. Those teams work in sprints; they plan features, test in stages, and have time to think through problems.
With platform operations, everything is in production and urgent. Incidents don’t arrive on a schedule and decisions are made in seconds, not minutes.
Engineers need systems that work at that pace and can surface the right information immediately, suggest likely causes based on what’s happening right now, execute validated fixes without needing manual steps, and learn from each incident to do better next time. Systems need to be built to accelerate engineering judgment; AI can handle data correlation and pattern matching, while engineers can manage complex decisions and reliability strategy.
The Universal Transformation Model
Every customer is unique. Banking has different constraints than telecom or retail, with internal processes, compliance requirements, and technical stacks. But if you look at the holistic picture across industries, the transformation model stays consistent:
- Eliminate silos
- Integrate systems so they talk to each other
- If you make a mistake, learn from it
- Build guardrails so mistakes don’t repeat
- Introduce automation that identifies problems proactively, don’t wait for things to break
Each of these outcomes show that the model is working: incident detection time drops, mean time to resolution (MTTR) improves, and alert fatigue decreases. Engineers spend less time firefighting and more time on improvements, so organizations feel the benefits: operating costs go down while reliability goes up.
Where Technical Capability Meets Organizational Commitment
That network outage I described at the beginning can now be solved. Integrated tools would have immediately connected the configuration change to the service impact. Blameless culture would have had teams collaborating instead of protecting themselves. Symptom monitoring would have caught the degradation before customers even noticed, and automated guardrails would have validated the network change against service requirements before anyone deployed it.
These capabilities exist today. The technical pieces work. What’s missing is implementation, both the connected systems and the organizational culture to use them effectively.
Organizations that commit to this will reduce costs and improve reliability simultaneously. Those that keep solving problems the old way will watch costs climb as systems get more complex. Modern platform operations can’t be solved with disconnected tools and siloed teams, it requires technical excellence and organizational maturity working together.
About the Author
Suresh Ramasamy is a seasoned IT service delivery professional with 18+ years of industry experience, recognized for his aptitude in information technology solutions and for building innovative business operations programs. Currently Director of Platform Operations at Ascendion, he functions as practice lead for Cloud SRE/CRE teams and champions delivery management for infrastructure and cloud operations, alongside people and business management, and P&L responsibilities across multiple services.
His expertise spans on-prem and public cloud environments, OpenStack, VMware private cloud, CaaS (Container as a Service), software-defined storage, network operations, and more. He partners with senior leadership and cross-functional teams, drives governance and reporting, supports SLA compliance, and leads security and vulnerability remediation.
