At this client my work had two fronts. One was a project with a beginning, middle and end: shutting down an entire financial product line. The other was day-to-day work, making sure product teams weren't left waiting on the platform.
Shutting down without breaking things
The company decided to discontinue a product line. Left behind were more than a dozen microservices, each with a database, secrets, pipelines and infrastructure in sandbox and production, plus dozens of repositories. Some were already archived, but nobody was sure what was still running.
Shutting down a financial system is delicate. Deleting something still in use takes production down, and deleting without a backup can mean losing data that has to be kept. So before deleting anything, I wrote a decommissioning playbook and applied it service by service, always in the same order: remove the metrics exporter, remove the infrastructure from Terraform and the Helm releases, find the service's database through Vault, delete the secrets and references in Vault and Jenkins, drop the sandbox and production databases and, finally, archive the repositories.
Before removing each service or VM, there was a backup and a snapshot. Each step was recorded with evidence on the service's card, in sandbox and in production. And I documented how to find which database each service used from its secrets in Vault, knowledge that wasn't written down anywhere.
In the end, every service was shut down traceably: for each one, it's possible to prove what was removed, when and with which backup. The company now maintains and pays for less infrastructure, with fewer exposed secrets, and the playbook is ready for future shutdowns.
Unblocking the people who ship
Day to day, product teams depended on the platform for almost everything that wasn't code. I handled dozens of requests from different teams. On secrets, that meant integration credentials in Vault, dynamic database credentials and KMS-encrypted keys. On CI/CD, build and deploy failures in Jenkins, Helm and SonarQube, including a quality gate block in the middle of a delivery week. On access and networking, SSO, VPN, internal DNS, security groups, API gateway routes and S3 and EKS permissions.
So repeated requests would stop depending on me, I wrote a troubleshooting guide for the most common types and recorded a piece of technical debt: API gateway settings created by hand in staging that needed to move into infrastructure as code.
"The partner is slow"
Calls to an external partner sometimes took more than three seconds, and the partner insisted it always answered in under 500 ms. Instead of arguing about who was right, I measured. I wrote a script that, from inside the cluster, repeated the call and split out the time for DNS, TCP connect, TLS handshake and response.
DNS and TCP were always fast. In 4 out of 10 calls, the roughly three-second delay happened exactly in the TLS handshake. The conversation moved away from "it's the network" and "it's the partner" and got a specific place to investigate.
Why developers couldn't see their pods
Engineers couldn't see pod CPU and memory usage in any environment. I went layer by layer. The user mapping in the cluster was right. The Kubernetes read role already included the metrics. SSO login assumed the right role in AWS. What was missing was the SSO role registered in the EKS cluster's access entries. I added the entry, and engineers could see usage without asking the platform team.
What I take from it
In legacy systems, the danger isn't in what you know exists, it's in what nobody remembers is still running. A playbook with evidence turns a risky task into an auditable process. And when two parties disagree, whether about latency or about permissions, breaking the problem into steps usually ends the argument and shows where to look.