Lack of Required Production Readiness

The Lesson

A platform should not enter SRE support until it has demonstrated that it is ready to be operated reliably in production.

Production readiness is the foundation on which a successful managed service is built. SRE is responsible for operating and maintaining platforms over the long term, but this responsibility can only be fulfilled effectively when the platform has been designed, tested and prepared for operational support.

A common failure mode is treating production readiness as a final activity immediately before handover. By this stage, delivery timelines are often fixed, delivery teams are preparing to roll off, and there is limited time available to resolve operational gaps.

Production readiness must be considered throughout the delivery lifecycle. It should be treated as a core delivery outcome alongside functional requirements, not as an activity completed immediately before operational transition.

A platform that is not production ready transfers technical debt, operational risk and additional workload directly into SRE.

---

The Problem

SRE frequently receives platforms where the application may be technically functional but has not been sufficiently prepared for long-term operation.

This occurs when delivery teams focus primarily on delivering application functionality and meeting project milestones, while operational requirements are considered later in the lifecycle.

The result is a gap between a platform being ready to deploy and a platform being ready to support as a managed service.

A production-ready platform should allow SRE to understand its behaviour, detect issues quickly, respond effectively and recover from failures within agreed expectations.

When these capabilities are missing, SRE inherits a service that requires additional remediation before it can be operated effectively.

Insufficient SRE Engagement During Delivery

One of the primary causes of production readiness issues is limited SRE involvement during the earlier stages of delivery.

When SRE only becomes involved shortly before go-live, there is limited opportunity to influence architecture, tooling decisions or operational practices.

By this stage, decisions around observability, resilience, security, deployment processes and support models have already been made.

Late involvement means SRE often identifies issues when the cost and complexity of remediation are at their highest.

Missing or Inadequate Observability

Observability is a fundamental requirement for operating any production service.

Without appropriate observability, SRE cannot effectively understand platform behaviour or quickly identify the cause of issues.

Common gaps include:

• Missing application metrics.
• Insufficient infrastructure metrics.
• Poor logging practices.
• Missing dashboards.
• Incomplete alerting.
• Alerts that are too noisy or lack operational value.
• Lack of correlation between application and infrastructure events.

A platform without adequate observability forces engineers to rely on manual investigation and assumptions during incidents.

This increases incident duration and makes proactive operational management significantly more difficult.

Inadequate Monitoring and Alerting

Monitoring and alerting should provide early warning of service degradation and operational failures.

A common issue is that platforms enter SRE support with monitoring that only covers basic infrastructure availability rather than the actual health of the service.

Examples include:

• Monitoring that confirms servers or containers are running but not whether the application is functioning.
• Alerts that trigger without clear operational action.
• Missing alerts for critical business functions.
• No defined ownership of alert responses.

Poor alerting creates two risks:

1. Important failures may not be detected quickly.
2. Engineers may spend significant time responding to irrelevant alerts.

Both reduce the effectiveness of the SRE function.

Untested Disaster Recovery and Resilience

Disaster recovery (DR) is frequently documented but not tested.

A recovery plan that has not been exercised provides limited confidence that recovery objectives can actually be achieved.

Common issues include:

• Backups not being tested.
• Recovery procedures not validated.
• Failover processes not rehearsed.
• Unknown recovery times.
• Dependencies not identified.
• Recovery ownership unclear.

This creates significant risk when contractual Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are defined without evidence that they can be achieved.

SRE cannot be accountable for recovery commitments that have not been technically validated.

Insufficient Testing

Testing is often focused on application functionality rather than operational behaviour.

A production-ready platform requires testing beyond whether features work correctly.

Important areas include:

• Performance testing.
• Load testing.
• Failure testing.
• Backup restoration testing.
• Disaster recovery testing.
• Deployment rollback testing.
• Security testing.
• Monitoring validation.
• Integration testing.

Without these tests, unknown risks are discovered after the platform is already in production.

Poor Operational Documentation

SRE requires accurate and accessible documentation to support a platform effectively.

Common documentation gaps include:

• Missing architecture diagrams.
• Outdated deployment instructions.
• Missing troubleshooting guides.
• No operational runbooks.
• Missing dependency information.
• No explanation of known limitations.

Poor documentation increases reliance on individual knowledge and slows incident response.

It also increases onboarding time when engineers are required to learn unfamiliar platforms.

Incomplete Knowledge Transfer

A successful transition into SRE requires structured knowledge transfer from delivery teams.

A common failure pattern is a short handover meeting shortly before the delivery team exits.

This does not provide enough time for SRE engineers to build operational understanding.

Effective knowledge transfer requires:

• Time to review architecture.
• Walkthroughs of deployment processes.
• Explanation of known issues.
• Review of operational procedures.
• Observation of normal operational activity.
• Opportunity to ask questions.
• Practical involvement before ownership transfers.

Without this, SRE begins supporting the platform while still learning how it works.

Security and Compliance Gaps

Security requirements are often addressed during delivery but may not be fully validated before handover.

Potential gaps include:

• Unreviewed access controls.
• Excessive permissions.
• Missing security monitoring.
• Incomplete vulnerability management.
• Missing audit information.
• Poor secret management practices.

Security is an operational responsibility. Gaps in security controls create ongoing risk once the platform enters managed service.

Lack of Operational Ownership Definition

A platform may be technically complete but still lack clarity around who owns operational responsibilities.

Examples include:

• Who approves production changes?
• Who manages application releases?
• Who owns third-party dependencies?
• Who responds to business-impacting issues?
• Who maintains operational documentation?

Without clear ownership, incidents and operational tasks can be delayed while responsibilities are determined.

Impact on SRE Operations

When production readiness requirements are not met, SRE absorbs the impact.

This results in:

• Increased operational overhead.
• More manual intervention.
• Longer incident resolution times.
• Higher incident frequency.
• Increased engineer cognitive load.
• Reduced ability to focus on proactive reliability improvements.
• Greater risk of missing service expectations.

The issue is not simply that SRE receives additional work. The issue is that SRE receives responsibility without the conditions required to successfully deliver that responsibility.

---

The Solution

Production readiness should become a formal requirement before a platform transitions into SRE ownership.

The goal is not to delay delivery unnecessarily. The goal is to identify and resolve operational risks while the delivery team still has the knowledge, resources and context required to address them.

Engage SRE Throughout the Delivery Lifecycle

SRE should be involved before the final handover stage.

Early engagement allows SRE to provide guidance on:

• Architecture decisions.
• Operational requirements.
• Observability.
• Monitoring.
• Deployment processes.
• Resilience.
• Support models.

This shifts production readiness from a late-stage assessment into an ongoing delivery activity.

Establish a Production Readiness Assessment

Every platform entering SRE should complete a formal production readiness assessment.

The assessment should evaluate areas including:

• Architecture.
• Observability.
• Monitoring and alerting.
• Security.
• Disaster recovery.
• Backup and restore.
• Performance.
• Capacity.
• Documentation.
• Operational ownership.
• Support processes.

The assessment should identify gaps, owners and remediation plans before operational responsibility transfers.

Define Production Readiness as a Delivery Acceptance Criteria

Production readiness should be included within project acceptance criteria.

A project should not be considered complete simply because the application works.

The platform should also demonstrate that it can:

• Be monitored.
• Be supported.
• Be recovered.
• Be secured.
• Be maintained.
• Be operated reliably.

This aligns delivery success with long-term service success.

Introduce a Structured Hypercare Period

A defined hypercare period should exist before full SRE ownership begins.

During this period:

• SRE has access to the platform.
• SRE participates in operational activities.
• Delivery teams remain available.
• Knowledge transfer continues.
• Outstanding operational issues are resolved.

This provides a controlled transition between delivery and operational ownership.

Maintain Clear Ownership of Remediation

Production readiness gaps should have clear ownership.

Issues identified before handover should remain with the appropriate delivery teams until they are resolved or formally accepted as operational risks.

SRE should not become the default owner of unresolved delivery shortcomings simply because the platform has reached go-live.

Validate Operational Commitments Through Testing

Operational commitments should be based on evidence.

Before agreeing service levels, teams should validate:

• Recovery capabilities.
• Performance expectations.
• Monitoring effectiveness.
• Deployment procedures.
• Incident response processes.

Testing provides confidence that the service can meet the expectations defined within contracts and service agreements.

Create Standard Production Readiness Requirements

Production readiness should be standardised across SRE engagements.

A common framework should define minimum expectations for:

• Monitoring.
• Alerting.
• Logging.
• Documentation.
• Security.
• Disaster recovery.
• Deployment processes.
• Support procedures.

While platforms may differ technically, the operational standard should remain consistent.

Improve Delivery and Commercial Alignment

Production readiness requirements should be understood by delivery and commercial teams before contracts and Statements of Work are agreed.

The required effort, timelines and responsibilities should be included during project planning.

This prevents situations where operational readiness activities are discovered late but no time or budget remains to complete them properly.

Benefits

Improving production readiness before SRE handover provides significant benefits:

• Reduced operational risk.
• Faster SRE onboarding.
• Lower incident frequency.
• Improved reliability and availability.
• Faster incident investigation and recovery.
• Reduced engineer cognitive load.
• Lower operational overhead.
• More predictable service delivery.
• Clearer accountability between delivery and operations.
• Improved customer confidence.

Production readiness is the point where delivery becomes sustainable operation.

A platform should not transition into managed service ownership based only on whether it can run. It should transition when it has demonstrated that it can be operated, supported and recovered reliably over the long term.