Skills
Load and reliability
k6 · Locust · Gatling · JMeter · load profiles (open and closed model, coordinated omission) · capacity planning · soak / stress / spike / breakpoint · failover and RTO/RPO · chaos experiments (hypothesis → injection → rollback) · tc netem · stress-ng · SLI/SLO, error budget, burn rate
Infrastructure and CI
Kubernetes · Helm · Docker · Linux · GitLab CI · GitHub Actions · AWS · GCP · Azure · provisioning through Bash and cloud CLIs
Observability
Grafana · Victoria Metrics · Prometheus stack · ELK — from standing up the cluster to investigating incidents and degradations
Languages
Python (Locust scenarios, the chaos agent, report analysis) · Go · Bash · TypeScript · SQL (PostgreSQL)
AI / LLM
Anthropic SDK · OpenAI SDK · Ollama · ChromaDB · RAG · MCP · Claude Code
Where the line is
I keep what I did in production separate from what I know through my own lab. In a reliability interview the first question is "walk me through one concrete experiment", so the list below is written as it is.
- Chaos Mesh and Litmus — known through the lab and the course, not applied in production. At work the chaos was done by hand: kubectl delete and drain, killing a process, iptables, stress-ng.
- tc netem and Toxiproxy — in the lab. iptables DROP — at work.
- Locust and Gatling — scenarios written in the lab; on paid projects the main tool is k6, JMeter before that.
- No formal SLI/SLO practice: I worked with customer SLAs as thresholds. Error budget and burn rate I computed in my own calculators.
- Postmortems written as write-ups of failed tests and incidents, not to a blameless template.