Role
DevOps and platform engineering
How many people have to do something for a change to reach production? If it is more than two, a deployment is an event rather than an activity - and that is why it happens rarely.
Intro call
Four questions we would start with
How many people touch one deployment to production?
The more hands, the less often you deploy, and the less often you deploy, the larger and riskier each change becomes.
How quickly do you find out about a problem in production?
If it is from a user, the monitoring is measuring something other than what actually breaks.
How do you know the test environment matches production?
If it is by assumption, then some production bugs cannot be reproduced anywhere else.
What do you not do, even though you know it has to be done?
Usually: you do not tidy the configuration and you do not review infrastructure costs. Always because nothing is on fire.
We take over the repetitive work, you keep the decisions about the platform
Environment configuration, deployment runs, collecting context during an incident and summarising costs can be taken off the desk. Decisions about the platform standard and about the response to an incident stay with the engineer.
- A deployment stops being an event. - A repeatable run with a rollback makes more frequent, smaller changes safer than rare, large ones.
- An incident starts with context. - What changed in the last hours, what else reacted, which services are related - before anyone starts searching.
- The standard is visible and a departure is named. - A team may do it differently, but then it is known where and why, instead of being discovered during an outage.
Scope
What can be taken off a platform team
Twenty example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your stack.
Environments and their configuration
- Environment configuration described and reproducible
- A comparison of the test environment with production
- A signal when configuration drifts
- A register of departures from the standard (decision: the engineer)
Deployments
- A repeatable deployment run with a rollback step where one is possible
- Pre-deployment checks as a condition of starting
- A register of deployments with the scope of changes
- A signal when a deployment departs from the run (assessment: the engineer)
Monitoring and alerts
- A review of alerts for usefulness
- Pointing out alerts with a high share of false hits (judgement on usefulness: the engineer)
- Linking an alert to a service and an owner
- A signal when a service has no monitoring
Incidents
- Context with the report: recent changes and related services
- The signals from the same time window collected together
- The incident chronology recorded as it happens
- A draft post-incident analysis (content: the engineer)
Infrastructure costs
- Cost assigned to services and teams
- Pointing out resources that are not used
- Cost changes against the previous period
- Material for a decision to change the configuration (decision: the engineer)
A day's work
Today
- Environment configuration lives its own life and drifts quietly
- A deployment needs several people present and a good day
- During an incident you start by establishing what changed recently
- Alerts arrive in numbers that consume the team's attention
- You reconstruct the incident chronology afterwards, from memory
- You look at infrastructure costs when the invoice arrives
With AI assistance
- Configuration drift between environments is flagged
- The deployment has a repeatable run, and for irreversible changes, stages
- An incident starts with the list of recent changes and related services
- Alerts that never led to an action are pointed out
- The incident chronology records itself as it happens
- Cost is assigned to services and teams as you go
- Deployment frequency
smaller changes more often, instead of large ones rarely
a deployment does not require gathering several people
- Time to restore after an incident
a shorter road to the cause
the context and the recent changes sit with the report
- Environments that match
fewer bugs that cannot be reproduced outside production
configuration drift is flagged
- Infrastructure cost
it is visible what costs money and whose it is
cost assigned to services and teams
We start with deployments, because their frequency affects everything else.
- Step 1
A repeatable deployment run
With a rollback step and pre-start checks. For irreversible changes - schema migrations above all - rollback does not exist and we do not pretend otherwise; there you work in stages and fix forward, and the run has to account for that.
- Step 2
Environments that match
A configuration comparison and a drift signal.
- Step 3
Context during an incident
Recent changes, related services, the chronology recorded as it happens.
- Step 4
Alerts and costs
A review of alert usefulness and the assignment of costs. Last, because it needs data from several periods.
Common questions
Questions that come up at the first meeting
How is this different from a systems administrator?
The administrator maintains what already runs - servers, backups, updates. Here the subject is the environments software is built in and the road a change takes to production. The roles are often combined in smaller companies, but the problems they solve are completely different.
Can the platform team be smaller after this?
Platform teams are usually a bottleneck, not a surplus - every product team queues for one or two people. Taking over repetitive deployments and the gathering of context during incidents does not shrink the team, it shortens that queue. That is in fact the first thing product teams notice.
Does this fall under the AI Act?
Working on infrastructure is not a high-risk use. The only point needing care is that data about deployments and incidents serves to improve the platform rather than to assess teams or the people who shipped a change.
Still have a question that is not here? Book a call
Next step
How many times did you deploy to production last month?
We will show you what platform work looks like when a deployment stops being an event and an incident starts with context.