Sheg Adelakun

Led governance and rollout of an automated workload rightsizing platform across a multi-cluster EKS fleet. Authored the deployment safety policy (CPU floor enforcement by environment tier), built the fleet-wide analysis identifying a seven-figure annual savings opportunity, and ran the readiness review that separated deploy-ready services from at-risk ones.

• Kubernetes
• FinOps
• EKS

Monthly observability spend climbed — a five-figure log-cost spike was the trigger — but billing only exposed cluster-level aggregation, making attribution hard. I led the cost analysis and reduction plan: identify the top log producers, audit metric cardinality for unbounded labels, and sequence quick wins (log-level fixes, sampling non-critical logs, dropping unused metrics) ahead of architectural changes like tiered retention by service criticality. Recognizing that one production cluster dominated spend let the plan capture most of the opportunity without waiting on perfect per-service tagging.

• FinOps
• Grafana Cloud
• Cardinality

Authored the System Security Plan and STRIDE threat model for a controller with write access to production Kubernetes clusters. Carried it through six independent review bodies — AppSec, SRE, CloudOps, Quality Engineering, Architecture, and Performance — including formal risk acceptance for vendor-constrained threats.

• Security
• Threat Modeling
• Governance

Allowlisting an IP on the load-balancer ACL was a manual ticket process. I built a Python automation around the existing Terraform repository that validates IP and CIDR syntax, detects duplicates and CIDR overlaps against the live config, injects the entry into the correct block, and routes through the existing pipeline so approval and review are preserved rather than bypassed by a direct API write. It uses locking to avoid races. I deliberately rejected a heavier design that would have orchestrated everything in a serverless function, letting the pipeline do the heavy lifting instead — the simpler system is the one operators can reason about.

• GitOps
• Terraform
• Python
• Automation

Console-managed dashboards and folders drifted, were not version-controlled, and could be deleted without trace. I built and operate a modular Terraform system that manages observability by team: a central orchestration layer loading per-team dashboard definitions automatically, plus a module that provisions teams, folders, and least-privilege folder permissions. It manages roughly ninety-five dashboards across fifteen teams under version control with per-team folder isolation — the platform the rest of the governance work sits on.

• Terraform
• Grafana
• IaC
• Governance

Assessed application readiness for ARM64 adoption across containerized cloud workloads, classifying services by migration risk, identifying toolchain and binary-compatibility blockers, and quantifying the infrastructure cost-efficiency opportunity.

• ARM64
• Migration
• Cost Efficiency

Site-to-site VPN monitoring was built on a BGP metric, but BGP was enabled on only one of ten tunnels — the rest used static routes — so the alerting silently covered ten percent of connections while appearing complete; the dark tunnels carried production database and customer-site traffic. Acting on a network engineer's discovery rather than defending the original design, I pivoted from the routing-protocol metric to a traffic-based one on the gateway resource, which covers every tunnel regardless of protocol. I built per-connection alerts across both regions, retired the obsolete BGP alerts, and rebuilt the dashboard with human-readable site names. Coverage went from one tunnel to all ten.

• Monitoring
• Networking
• Grafana

Designed and shipped a Grafana alerting suite through a GitOps pipeline, built PromQL against live production metric schemas, and diagnosed metric-pipeline gaps — missing ServiceMonitors and scrape coverage — that were blocking operational dashboards. Related work included synthetic monitoring across a dozen critical payment services with a live operational dashboard, and quorum-and-witness monitoring for a high-availability database cluster on a previously blind, revenue-critical failure path, with correct priority-based routing.

• Grafana
• Prometheus
• PromQL
• GitOps

A major cloud-provider outage hit both directly and through third parties on the same provider, and it took hours to identify the upstream as the root cause because vendor status was checked by hand during incidents. I authored the epic and split it across the team, inventorying and classifying thirty-plus external dependencies — cloud, payment, identity, and ops providers — by criticality. The design was tiered: subscription-based ingestion into the ticketing system for vendors that support it, synthetic and blackbox checks for those that do not, plus dependency mapping so an upstream alert states which internal services it affects. It was designed for sub-five-minute detection.

• Reliability
• Dependency Mapping
• Synthetic Monitoring

An unreviewed infrastructure-as-code run reorganizing monitoring folders deleted production alert rules as a side effect, and a revenue-critical service went down with no one paged for roughly twelve hours — the heartbeat alert that should have caught it no longer existed. I reconstructed the timeline, root-caused the folder-to-alert coupling, and ran the manual restoration critical-path first. I then led the prevention program: PR-time validation that detects destructive changes to alert resources in the plan, lifecycle guards on critical rules, state separation so monitoring is not coupled to general infrastructure, automated alert backups, and required review on monitoring changes. Console-managed alerts and dashboards were migrated into version control so they can no longer be changed silently.

• Incident Response
• Terraform
• Grafana
• Governance

Alerts defaulted to low priority and relied on a human to manually open an incident before any paging workflow began, so an alert that fired but went untriaged escalated to no one. I designed a time-based bridge: an unacknowledged critical alert auto-creates the incident after a fifteen-minute window, handing off to the existing escalation automation. The design resolved an architectural ambiguity about which system owns escalation timing, consolidating it into one layer rather than two competing ones.

• Alerting
• Escalation
• On-Call

Incident response was resolving symptoms — a restart here, a reboot there — without anyone owning the recurrence. I stood up a structured problem-management practice on top of the incident process: root-cause analysis with corrective actions, formal known-error documentation for issues with no immediate fix, and consolidation of clusters of related recurring incidents into single tracked problem records so action items did not scatter across dozens of tickets. The practice fed a recurring report to leadership, making the pattern of recurrence visible rather than absorbed silently by on-call.

• Problem Management
• RCA
• ITIL
• Reliability

Monitoring coverage across the platform was uneven and there was no shared way to talk about how mature any given service was. I built a five-level monitoring maturity model, scored every service against it, and used it to drive a prioritization decision made jointly with partner teams: services with direct financial impact if they failed were advanced first, while lower-impact services moved up the scale on a longer horizon. The model became the framing for a read-out to the CTO and for a recurring progress report to leadership, turning scattered monitoring work into a legible roadmap with a direction and a finish line.

• Strategy
• Maturity Model
• Stakeholder Communication