Welcome back to part two of our takeaways from ContainerDays in Hamburg! Following up on our initial reflections on cloud sovereignty, open-source security, and Kelsey Hightower’s Q&A, Lucian and I wanted to share our key notes on Site Reliability Engineering (SRE), Disaster Recovery (DR), and what it actually takes to build mature, lean platform engineering organizations.
AI-Driven Incident Response in SRE
Artificial intelligence is making huge inroads into operational tooling, but the consensus across SRE sessions was clear: AI should accelerate human understanding, not replace human judgment.
- Scope AI to read, not act: Giving AI broad read access across your telemetry and observability stack allows it to correlate signals across systems quickly during diagnosis. Reading is where AI adds maximum value with minimal operational risk.
- Split postmortem duties: Let AI assemble the objective, factual timeline of events while human engineers write the “why” and extract the broader lessons. Granting AI read access to your postmortem archive allows it to flag potential recurring incidents and remind teams what was learned during prior outages.
- Get the fundamentals right first: Service Level Objectives (SLOs), alert design, and runbook automation must stand on their own. AI is an enhancement layer on top of a working reliability practice, not a substitute for building one.
- Grade autonomy by severity: For high-severity incidents, AI should investigate and advise while humans retain sole authority to decide and act. As incident severity drops, AI can safely operate more agentically to trigger resolution actions on its own.
Ultimately, AI dramatically shortens the time it takes to comprehend an incident. Humans keep authority over production changes, with that boundary loosening only as the potential blast radius shrinks.
Disaster Recovery: Preparation Over Panic
The Disaster Recovery panel delivered a grounding message: DR is primarily organizational work completed long before an outage ever occurs.
- Answer organizational questions before the incident: Who makes up the DR team? Do they know each other and their specific roles? Have they run joint simulations? Is there a clear starting runbook? An active incident is the worst possible time to figure out team dynamics.
- Train on-call engineers to debug, not just follow runbooks: Runbooks only cover the failure modes you anticipated. When an alert strays off-script—which is when things matter most—engineers need real debugging fluency with your toolchain. That requires investment in training, not just documentation.
- Derive RPO and RTO from simulations, not wishful thinking: Real recovery costs in time and data loss can only be measured through simulated failure. Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) picked on paper rarely survive contact with reality.
- Balance recovery cost against downtime cost: A tighter RTO costs real money, but so does downtime. Establish error budgets and SLOs where cost, performance, and reliability reach a pragmatic tradeoff—and involve executive management early so investment boundaries are clear.
- Diagnose before acting: When a crisis hits, assemble the team and diagnose the failure completely before taking corrective action. Knee-jerk fixes applied without comprehension almost always make outages worse.
Disaster recovery comes down to discipline: the technology matters far less than whether your people, operational targets, and budgets were aligned in advance. And above all else: DO NOT PANIC!
Platform Engineering: Building Mature and Lean Systems
Building internal developer platforms was one of the central themes of the conference, with discussions focusing on how to make platform efforts measurable and sustainable.
Mature Platform Engineering
While the CNCF Platform Engineering Maturity Model provides a solid generic baseline, it should be adapted to your company’s reality rather than adopted blindly.
- Prioritize measurement early: Measurement is the most overlooked pillar. Teams regularly ship platform features without defining how they will measure success or usage.
- Talk to consumers and measure outcomes: Interview the developers who will use the platform and uncover what they actually struggle with. Define the smallest possible scope and ask “how do we measure this?” before writing code. Forcing the measurement question up front shifts focus from “what component are we shipping?” to “what problem are we solving?”
- Keep maturity models simple and context-specific: Avoid off-the-shelf complexity. A simple, self-reported questionnaire that teams fill out to track capability adoption often works best.
- Target improvements per team: Questionnaire results show where each team stands today and highlight the concrete next step toward target maturity—per team, rather than as an organizational average.
Lean Platforms Panel
A mature platform process naturally leads to a lean platform architecture, preventing the platform team from becoming a feature factory.
- Listen to consumer problem statements: When a team presents a clear, well-articulated need, build for it. When they can’t state the problem, building anyway is how platforms accumulate unused bloat.
- Ask “what problem are you trying to solve?” first: Evaluating whether a user can formulate their underlying problem is critical. Helping developers articulate their challenge is often more valuable than shipping code against a guess.
- Audit and delete regularly: Platforms naturally accumulate legacy services over time. Regularly audit capability usage and remove what isn’t earning its keep—deletion is a platform feature, not a failure.
Lean platforms stay effective by applying discipline at both ends: nothing gets built without a clear problem statement, and nothing stays built once it stops delivering value.
ContainerDays once again proved to be a fantastic anchor event for the platform engineering community. Beyond the technical sessions, the overarching takeaway from our time in Hamburg was that technology is only half the equation—whether you are responding to incidents, designing DR strategies, or building platforms, success hinges on human clarity, intentional design, and strong team alignment.
Lucian and I left Hamburg energized for what’s ahead, and we’re already looking forward to next year’s edition!
