Developers are spending too much time operating infrastructure
What we usually see
- Product engineers debugging pipelines and cloud config instead of shipping
- Routine infrastructure requests interrupt the same senior developer
- Nobody owns the platform, so everyone owns a piece of it
- Onboarding a service means learning one person’s conventions
How we approach it
Take the platform work off the product team: own the infrastructure scope, put the repeatable parts behind self-service paths, and leave developers a documented route to ship without reading Terraform.
- Platform engineering
- Golden paths
- Terraform modules
- CI/CD
Kubernetes has become difficult to maintain
What we usually see
- Pods restart for reasons nobody has traced
- Cluster and add-on upgrades are deferred because they feel risky
- Resource requests and limits were guessed once and never revisited
- Autoscaling behaves unpredictably under load
How we approach it
Establish what the cluster is actually doing, fix the failure modes that recur, get resource and scaling configuration onto a rational basis, and bring cluster and add-on upgrades into a repeatable process.
- EKS · AKS · GKE
- Helm · Kustomize
- Karpenter · HPA
- Prometheus
CI/CD is inconsistent, and releases need manual coordination
What we usually see
- Deploys need a specific person, a specific laptop, or a manual runbook
- Every service builds and deploys differently for no deliberate reason
- Rollback means redeploying an older branch and hoping
- Pipelines are slow enough that engineers batch changes
How we approach it
Converge services onto shared, versioned pipeline definitions; make pipelines fast enough to run on every change; and make rollback an ordinary, rehearsed operation rather than an incident response.
- GitHub Actions · GitLab CI
- Jenkins · Azure DevOps Pipelines
- Reusable templates
- Release automation
Infrastructure changes are still manual, and Terraform resists change
What we usually see
- Console changes have drifted from what the code describes
- One large state file makes every change feel dangerous
- Copy-pasted configuration across environments
- No one is confident running a plan against production
How we approach it
Reconcile drift, split state along sane boundaries, factor shared configuration into modules, and put changes behind a plan-and-review workflow so infrastructure changes stop being events.
- Terraform
- Modules and remote state
- Policy as code
- GitOps
Production changes are not driven from Git
What we usually see
- Cluster state has diverged from the repository and nobody knows by how much
- Changes are applied by hand during incidents and never make it back into code
- No reliable audit trail of what changed in production, or why
- Promotion between environments is a manual, error-prone ritual
How we approach it
Move to declarative, Git-driven delivery: configuration in the repository, changes proposed by pull request, reconciliation automated with Argo CD or Flux, and promotion between environments controlled rather than improvised.
- Argo CD · Flux
- Kustomize · Helm
- Declarative delivery
- Git audit trail
Production troubleshooting takes too long
What we usually see
- Intermittent failures that nobody has been able to reproduce
- Latency or networking problems that cross service boundaries
- Symptoms that appear under load and vanish under inspection
- An issue that has been open long enough to become normal
How we approach it
Work the problem systematically — narrow it with evidence from logs, metrics, traces and configuration rather than by guessing — then fix the cause and leave behind the instrumentation that would catch it next time.
- Cloud networking
- Kubernetes internals
- Log · metric · trace analysis
- Load testing
Observability is fragmented
What we usually see
- Incidents are discovered by customers first
- Dashboards exist but nobody trusts them
- Logs are collected but hard to search when it matters
- Alerts are noisy enough that people have stopped reading them
How we approach it
Instrument what actually indicates health, consolidate logs, metrics and traces where engineers will look, standardize on OpenTelemetry where portability matters, and reduce alerting to signals a human should act on.
- OpenTelemetry
- Prometheus · Grafana · Loki
- Datadog · CloudWatch · Azure Monitor
- Alert routing
Reliability is undefined, and recovery has never been tested
What we usually see
- No agreement on what "reliable enough" means for each service
- Backups are configured but restores have never been rehearsed
- Single points of failure everyone knows about and nobody owns
- On-call exists but has no design behind it
How we approach it
Define SLIs and SLOs that reflect what users feel, test recovery instead of assuming it, remove the failure points that would matter most, and give on-call runbooks worth opening at 3am.
- SLI / SLO design
- DR · RTO / RPO
- Multi-region
- Runbooks
Security controls are inconsistent across the estate
What we usually see
- IAM permissions are broader than anyone intended
- Secrets live in CI settings or environment variables
- Controls differ between accounts, subscriptions, projects and clusters
- No agreed process for patching or vulnerability remediation
How we approach it
Tighten access to what is actually needed, move secrets into a managed store, express guardrails as policy so they apply uniformly, and put scanning into the pipeline so findings arrive on the pull request.
- IAM and least privilege
- Vault · cloud secret stores
- OPA · Kyverno
- Trivy · Checkov · Snyk
Cloud costs are difficult to understand
What we usually see
- Spend grows and nobody can attribute it to a workload or team
- Tagging is inconsistent, so reporting is guesswork
- Idle or oversized resources nobody has permission to remove
- Committed-spend decisions made without usage evidence
How we approach it
Get attribution working first — tagging and account structure — then act on the evidence: right-size against real usage, remove what nothing uses, and put cost where engineers already look.
- Tagging and account structure
- Cost and usage reporting
- Right-sizing
- Autoscaling
A cloud migration or modernization needs senior ownership
What we usually see
- A migration has been planned repeatedly but never owned
- Workloads sit on infrastructure that is expensive or unsupported
- Uncertainty about which managed services fit the workload
- Cutover risk is unclear, so the decision keeps sliding
How we approach it
Assess the workload and its dependencies, choose target services deliberately, build the target environment in code, and run a rehearsed cutover with a defined rollback path — datacenter-to-cloud, cloud-to-cloud, or replatforming.
- AWS · Azure · GCP
- Terraform
- Networking and connectivity
- Cutover planning
There is no mature platform engineering function
What we usually see
- Infrastructure is a side responsibility split across several developers
- Each team solves environment and deployment problems its own way
- No shared templates, so every new service is a fresh set of decisions
- Nobody owns developer experience, so friction accumulates unchallenged
How we approach it
Stand up the platform function rather than a platform product: agree the small number of paved paths worth having, template them, put guardrails in by default, and leave a platform your team can extend.
- Internal developer platforms
- Backstage · Crossplane
- Golden paths
- Self-service environments
You need senior DevOps capability without hiring a whole organization
What we usually see
- The workload justifies real platform capability but not a full team
- A first DevOps hire would have no peer to review their decisions
- Senior platform hiring has been open for months
- Contractors have come and gone without leaving anything maintainable
How we approach it
Take ownership of a defined cloud and platform scope under an ongoing engagement, keep everything in code and documentation, and stay accountable for it — so that hiring internally later is a choice rather than a rescue.
- Managed cloud and DevOps
- Platform engineering
- Infrastructure as Code
- Runbooks
Infrastructure knowledge lives in people’s heads, not in code and runbooks
What we usually see
- One engineer is the single point of failure for the platform
- Onboarding an environment takes days of tribal knowledge
- Documentation was accurate at some point in the past
- Routine work is manual, repetitive and unwritten
How we approach it
Move the environment into code, automate what should never be manual, and keep documentation and runbooks current as part of the work rather than as a project — so handover is possible in either direction.
- Infrastructure as Code
- Runbooks
- Operational automation
- Documentation