/
Loading preparation module...
Initializing deterministic evaluation engine
Automated CI/CD pipelines, container orchestration with Kubernetes, Linux kernel administration, observability telemetry, and system reliability.
DevOps & Site Reliability Engineers (SRE) bridge software development and systems operations. They treat operations as a software problem, building automated deployment pipelines, managing Kubernetes container clusters, tracking error budgets, and conducting blameless post-mortems.
| Level | Title | Experience | Core Architectural Responsibility |
|---|---|---|---|
| L1 | Associate DevOps Engineer | 0-2 yrs | CI/CD pipeline maintenance, Docker containerization, and basic metric monitoring. |
| L2 | Site Reliability Engineer | 2-5 yrs | Kubernetes cluster administration, automated failover, and SLO error budget management. |
| L3 | Staff Reliability Engineer | 5-8 yrs | Distributed systems resilience, eBPF tracing, chaos engineering, and incident commander. |
| L4 | Principal Infrastructure Engineer | 8+ yrs | Platform engineering strategy, self-healing runtime systems, and global reliability. |
| Region | Entry Tier (L1) | Mid-Senior (L2/L3) | Staff/Principal (L4+) |
|---|---|---|---|
| North America | $100,000 - $130,000 | $145,000 - $205,000 | $225,000 - $350,000+ |
| Europe (EU/UK) | EUR 58,000 - 80,000 | EUR 90,000 - 135,000 | EUR 145,000 - 225,000+ |
| Asia-Pacific / India | INR 11,00,000 - 18,00,000 | INR 24,00,000 - 45,00,000 | INR 55,00,000 - 1,00,00,000+ |
Master Linux shell scripting, systemd, process isolation (namespaces & cgroups), and Docker packaging.
Construct a declarative CI/CD pipeline that runs automated linters, unit tests, vulnerability vulnerability scanning, and produces a minimal, non-root scratch/distroless container image signed with cryptographic keys.
Deploy resilient microservices on Kubernetes with auto-healing, rolling updates, and network policies.
Deploy a high-throughput microservice on Kubernetes configured with readiness/liveness probes, preStop sleep hooks, Horizontal Pod Autoscaler, and PodDisruptionBudgets. Execute load tests during a rolling update to verify 0 dropped HTTP connections.
Instrument production distributed systems with metrics, logs, and distributed traces; manage SLO error budgets.
Instrument a polyglot microservice application with OpenTelemetry collectors, Prometheus scraping, and Grafana dashboards. Implement multi-window burn-rate alert rules that notify on-call engineers before 2% of the monthly error budget burns in 1 hour.
Exit code 137 indicates the process was terminated by SIGKILL (128 + 9 = 137), almost always triggered by the Linux kernel Out-Of-Memory (OOM) killer because the container exceeded its configured cgroup memory limit. To remediate: inspect memory usage graphs, increase container resources.limits.memory, or fix memory leaks in the runtime (e.g. JVM heap sizing or unclosed database connections). In contrast, CrashLoopBackOff with exit code 1 indicates an application-level unhandled exception or crash during startup (e.g. missing environment variables, failing database connection, syntax error). To remediate: inspect kubectl logs --previous to view the stack trace prior to termination.
This occurs because pod termination and ingress/kube-proxy endpoint removal happen asynchronously in parallel. When a pod is terminated: 1) The kubelet sends SIGTERM to the container. 2) Simultaneously, the Endpoint controller removes the pod IP from the Service Endpoints list and kube-proxy updates iptables/IPVS rules across worker nodes. Because iptables rule propagation takes a few hundred milliseconds, ingress proxies continue forwarding incoming traffic to the terminating pod after the application has already stopped accepting connections. To fix: 1) Add a preStop lifecycle hook: preStop: exec: command: ["/bin/sh", "-c", "sleep 15"]. This pauses SIGTERM delivery to the application process, giving iptables rules sufficient time to withdraw the pod IP from all proxies. 2) Implement graceful shutdown in the application server to finish processing in-flight requests before exiting.
Setting resources.limits.cpu: "500m" to prevent runaway CPU usage, resulting in severe latency spikes even when node CPU utilization is below 20%.
The Linux Completely Fair Scheduler (CFS) enforces CPU limits across 100ms periods. A multi-threaded application can burst across all cores and exhaust its 50ms quota within the first 10ms of the period, remaining completely frozen for the remaining 90ms. In modern Kubernetes, best practice is to set CPU requests for scheduling and omit CPU limits or use CPU quota burst allowances.
Understanding how Linux cgroups enforce CPU bandwidth constraints is vital for preventing tail-latency degradation in containerized environments.
Under cgroups v1/v2, cpu.cfs_period_us defaults to 100,000us (100ms). If cpu.cfs_quota_us is set to 50,000us (0.5 cores), all threads combined cannot exceed 50ms of execution per 100ms period. Any excess triggers immediate thread suspension until the next period starts.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-service
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 0
template:
spec:
terminationGracePeriodSeconds: 60
containers:
- name: app
image: service:v2.4.1
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 15"]
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
memory: 1Gi