Infrastructure & Platform Engineering

SRIVAN
TECHNOLOGIES

The layer most people only notice when it breaks.

Kubernetes and OpenShift clusters, the pipelines that deliver to them, and the observability that tells you what they are actually doing.

21Issues published
154Topics covered
362Commands documented
93Pages in the open
Capabilities

FOUR AREAS, IN DEPTH

Each is something I have written at length about — not a keyword on a list.

01

Kubernetes & OpenShift

Cluster architecture, workload design, scheduling and placement, autoscaling that actually responds, and upgrades that do not become outages.

02

Observability & SRE

Prometheus, Grafana, log aggregation and tracing, assembled so the signals answer questions. Plus the practice around them — service levels, alerting, incident handling.

03

CI/CD & GitOps

Delivery pipelines and declarative reconciliation — ArgoCD and Flux, progressive delivery, security gates in the pipeline rather than in a document nobody reads.

04

Linux Infrastructure

Performance and capacity, systemd, kernel and sysctl tuning, namespaces and cgroups, and troubleshooting that ends with a specific cause.

Featured work

PLATFORM OPS

Field notes from production, not slideware.

A free, open technical newsletter on Kubernetes, SRE and platform engineering. No paywall, no sign-in, no tracking — a tree of static pages generated from a handful of data files, with the source public.

It exists because the explanation I wanted usually did not. Writing the thing you had to work out yourself is the most reliable way to find out whether you actually understood it.

KubernetesOpenShift ObservabilityService Mesh CI/CDLinux
21Issues published
93Pages
154Topics covered
362Commands documented
How I work

THREE THINGS THAT DECIDE THE OUTCOME

01 — Evidence first

Read what the system says before theorising about it. Most infrastructure problems announce themselves plainly in an event, a log line or an exit code. The difficulty is knowing where to look.

02 — Measure, do not assume

A change that was not measured before and after is a change you hope worked. That applies to performance, to capacity, and to the claim that something has been fixed.

03 — Leave it legible

The person debugging this at 3am may be you, a year from now, with no memory of why. Configuration that explains itself beats configuration that is merely clever.

HAVE A PROBLEM IN THIS LAYER?

Specifics get a better answer than introductions — say what is actually happening and I will tell you what I would look at first.