Day 2 Operations

Day 2 operations covers work after a service or resource first becomes usable. Day 0 for design, day 1 for initial launch and day 2 for later life are informal labels rather than a standard. The later period needs a deliberate operating plan.

The CNCF maturity model emphasizes the effort required after release: upgrades, improvements, support and user enablement. The balance between construction and later work depends on a capability’s complexity and lifetime; launch is not always the inexpensive part.

What is actually in it

The model’s broader operations aspect includes requests, initial releases, maintenance and eventual retirement. Within that lifecycle, day 2 focuses on keeping an already delivered capability usable and changing or retiring it safely.

Expanded into the work a team actually gets asked for, with the question each item answers:

Day 2 work	The request that arrives
Upgrades and patching	A version reaches end of support, or a CVE lands
Resizing and scaling	It was right in March and is wrong in September
Backup and recovery	Somebody needs yesterday’s data back
Configuration change	A setting chosen at creation turns out to be wrong
Ownership transfer	A team splits, merges, or the owner leaves
Support and diagnosis	It is slow, or it stopped, and the user cannot tell why
Deprecation and deletion	It is no longer needed, and removing it safely is its own project

Handover and deletion deserve explicit plans. Reorganizations can change responsibility for many resources, and deletion requires checking dependencies and retention obligations. A service catalog can help locate known dependencies, but its coverage and freshness determine what it can establish.

Provisioning and the maintenance workload

The maturity model notes that easy creation can coexist with poor usability for later management. Assess both paths before describing a capability as easy to operate.

Self-service provisioning can increase the number of resources that later need maintenance. Estimate recurring work from fleet size, lifetime, shared automation and the frequency of change. Resource count alone is not an effort measure, and shared operations need not grow proportionally with each consumer.

Customized copies of templates can make later changes harder to distribute. Codemods and repository pull requests can help, but semantic changes may require local decisions and testing. Agree who prepares, reviews and deploys migrations rather than assuming either a central campaign or each user team can handle every change alone.

Assign day 2 activities by capability contract. The provider may operate the database engine, the platform may own the service interface and escalation, and a product team may own schema changes and query behavior. Backup execution, restore approval and access policy can have different owners. Users should not inherit provider-side work they lack the authority or support to perform; neither does the platform necessarily execute every engine operation itself.

Where the load goes if nobody plans it

Unplanned day 2 work has a predictable destination, and both the platform and SRE literature describe the same trajectory from different angles.

The CNCF paper recognizes that supporting more users and varied needs can increase a platform team’s load. DORA describes a reactive infrastructure-ticket service as a source of toil and bottlenecks. Examine how much work is repeated and how much engineering time remains, rather than diagnosing the team from total demand alone.

Google’s SRE introduction explains how repeated manual operations can require more staff as services grow. Engineering that removes or automates those tasks can change the relationship between service size and human effort.

That argument applies to part of day 2, not all of it, and the distinction decides what you should try to remove. “Day 2” is a position in the lifecycle; toil is a property of a task. They overlap without being the same set.

• Day 2 work that is toil. Applying the same patch to forty instances, rotating credentials by hand, resizing on request. Manual, repetitive, automatable, and growing with the estate — the category the linear-scaling argument describes.
• Day 2 work that is engineering. Building the upgrade mechanism, designing an end-of-life path for a capability, adding the missing failure diagnostics, changing a default because the fleet taught you something. This work also happens after handover, and it is what makes the first category smaller. Treating it as overhead is how a platform ends up with a creation button and nothing else.

Moving a task to a user can shorten a queue without eliminating work. Compare hands-on time on both sides, waiting, failures and rework for the same task and service level. A one-click path may still require prolonged diagnosis or follow-up; distinguish work eliminated from work relocated.

A thinnest viable platform can use a suitable managed provider to reduce what the team directly implements and operates. Retain a clear support contract and escalation path, and staff the remaining work for the domain and customers served. Reuse depends on the provider meeting the actual requirements.

Designing for it before it arrives

Five questions to answer while a capability is still being designed, so that operating responsibilities are settled before launch.

1. How does an upgrade reach existing users? A shared implementation can reduce repeated code changes, but versioned deployments, compatibility checks and migrations still determine adoption. A referenced pipeline definition applies when the selected version is used on a later run; an image change needs a rebuild or redeploy as appropriate; runtime configuration depends on when the service reloads it. Record the rollout owner and evidence that the change took effect.
2. What can be changed after creation, and what cannot? Irreversible choices should be visible at the moment they are made, not discovered later.
3. How is it handed over? Ownership needs to be a field somebody can change, and a reorganization is the test.
4. How is it deleted? Including how a user knows it is safe. Deletion without dependency knowledge is how a shared thing disappears.
5. When it misbehaves, what can the user inspect and who helps next? DORA associates clear task feedback with a positive experience. Support volume also depends on failure rates, scope and user needs, so evaluate diagnostics through actual troubleshooting tasks.

Map both creation and production diagnosis, as DORA recommends. The maturity model likewise evaluates initial requests, maintenance and incident triage. Use these journeys to find concrete gaps in the operating plan.

Two neighboring terms, kept separate. A support lifecycle is how long a vendor maintains a release — an external clock you plan against. Day 2 operations is the work you do throughout something’s life, and a support deadline is one of the things that generates it. Data lifecycle policies, meanwhile, govern how long records are kept, which is a different subject that happens to share the word.

Budget for the agreed support lifetime, including upgrades, documentation, handover and retirement. State notice periods, migration assistance and exceptions before ending an offering. What Happens After the Click explains how that commitment affects the capabilities a platform should offer.

References

• CNCF Platform Engineering Maturity Model
• CNCF TAG App Delivery: Platforms White Paper
• Google, Site Reliability Engineering, “Introduction”
• DORA: Platform engineering