Job Readiness

WRONG:
• Used Docker, Kubernetes, Terraform, Jenkins, AWS

RIGHT:
• Reduced deployment time from 45 minutes to 8 minutes by migrating from
  manual deployments to a containerized CI/CD pipeline (Docker, GitHub Actions, EKS)

• Decreased infrastructure costs by 35% ($12k/month) by right-sizing EC2 instances
  using CloudWatch metrics and implementing auto-scaling policies

• Improved mean time to recovery from 2 hours to 18 minutes by building
  centralized observability with Prometheus, Grafana, and structured logging

[Action verb] + [what you did] + [how you did it] + [measurable result]

"Automated database backup verification, eliminating 3 hours/week of manual work
and catching 2 silent backup failures before they became incidents"

[Name] | [LinkedIn] | [GitHub] | [Location]

SUMMARY (2-3 lines)
DevOps/Platform engineer with X years of experience building CI/CD pipelines
and cloud infrastructure. Focus on reliability, automation, and developer experience.

EXPERIENCE
  Company Name — Job Title (dates)
  • Impact bullet 1
  • Impact bullet 2
  • Impact bullet 3

SKILLS
  Cloud: AWS (EC2, EKS, RDS, S3, IAM), Azure
  Containers: Docker, Kubernetes, Helm
  IaC: Terraform, CloudFormation
  CI/CD: GitHub Actions, Azure Pipelines, ArgoCD
  Observability: Prometheus, Grafana, OpenTelemetry
  Languages: Bash, Python, Go (basic)

1. Home Lab Infra (Terraform + Kubernetes)
   - Terraform modules for AWS infrastructure
   - K8s cluster with Helm charts for your apps
   - CI/CD pipeline to deploy on git push
   - README explaining architecture

2. Automated Blog/Portfolio CI/CD
   - Your own blog (this one!) deployed with a pipeline
   - Show: GitHub Actions, Docker, deployment

3. Observability Stack
   - docker-compose with Prometheus + Grafana + sample app
   - Pre-built dashboards with useful alerts

4. Incident Response Toolkit
   - Bash/Python scripts for common diagnostics
   - Document your runbook template

# Hi, I'm [Name]

DevOps engineer focused on reliability and automation.

## What I'm working on
- Building a multi-region Kubernetes setup with GitOps (Argo CD)
- Learning SRE practices through hands-on labs

## Tech Stack
Docker · Kubernetes · Terraform · AWS · GitHub Actions · Prometheus

## Recent Projects
- [infra-homelab](link) — Full AWS infrastructure with Terraform
- [devops-notes](link) — My learning notes (this site!)

S: Our checkout service was throwing 500 errors at 2am, affecting 20% of users.
T: I was on-call and responsible for restoring service.
A: I checked deployment history (recent deploy 30min earlier), reviewed error logs
   (saw null pointer on payment config), identified missing env var, rolled back deployment.
R: Service restored in 18 minutes. Wrote postmortem, added env var validation to CI/CD.

1. CLARIFY — "Before I dive in, can I ask a few questions?"
   - What does the user/customer actually experience?
   - When did this start? Any recent changes?
   - What environment (dev/staging/prod)?

2. GATHER DATA — don't guess, look at evidence
   - Metrics (is there an alert? what does the graph show?)
   - Logs (recent errors in logs?)
   - Recent changes (deployment, config change, infra change?)

3. HYPOTHESIZE — form a hypothesis before testing
   - "Based on this error message, I think it could be X because..."
   - "I'd first check Y because it's the most likely cause"

4. TEST ONE THING AT A TIME — systematic, not random
   - If you change two things at once, you don't know which fixed it

5. COMMUNICATE — narrate what you're doing and why
   - "I'm checking the service logs first because the error suggests..."

1. Check if the service is running (kubectl get pods, ps aux)
2. Check if the port is listening (ss -tlnp | grep :8080)
3. Check the service logs (kubectl logs, journalctl)
4. Check upstream dependencies (database, cache, downstream services)
5. Check load balancer health checks
6. Check recent deployments

1. df -h — which filesystem?
2. df -i — could be inode exhaustion
3. du -sh /* — find large directories
4. Find large files: find / -type f -size +500M
5. Common culprits: /var/log, Docker images, core dumps, tmp files
6. Quick fix: truncate large logs, clean docker, clear tmp
7. Long-term: log rotation, monitoring alert, increase disk

1. Clarify requirements
   - Scale: how many users? requests/sec? data size?
   - Availability requirements? (99.9%? 99.99%?)
   - Read-heavy or write-heavy?

2. Estimate scale
   - 1M users, 10% daily active, 10 requests each = 1M req/day = ~12 req/sec
   - 1TB of data, growing 1% daily

3. High-level design
   - Draw the components (LB, app servers, DB, cache, CDN)
   - Show data flow

4. Deep dive
   - Interviewer will pick a component to go deeper on

5. Identify failure points and mitigations

Load Balancer → App Servers → Cache → Database
                     ↓
               Message Queue → Worker Servers
                     ↓
                Object Storage (S3)

Requirements:
- 100M URLs shortened per day
- Redirect latency < 10ms
- Links don't expire (or have configurable TTL)

Scale:
- 100M writes/day = 1,150/sec
- Reads likely 10-100x writes = 11,500-115,000 req/sec

Design:
[Client] → [CDN] → [Load Balancer] → [App Servers] → [Redis Cache]
                                              ↓
                                          [Database]

Short URL generation: base62 encode a counter or random ID
Redirect: look up in Redis cache first → DB if not cached
Database: simple key-value (short_code → original_url, metadata)
Cache: hot URLs cached in Redis with 24h TTL

Scale considerations:
- App servers: stateless, scale horizontally
- Redis: cluster mode for high availability
- Database: read replicas for redirect lookups
- Global: deploy in multiple regions, use Route53 latency-based routing