Hands-on DevOps is a mix of good commands, repeatable infrastructure, observability, and automated response. This article bundles practical commands, scaffolding patterns, CI/CD design, Kubernetes manifest guidance, Docker optimization techniques, Prometheus+Grafana observability, and incident runbook automation — all actionable, concise, and ready to use.
Core DevOps commands: fast reference and best practices
Short answer: memorize a small, cross-cutting set of commands for git, container tooling, orchestration and IaC — then wrap them in scripts and CI checks. For daily work, git (clone, checkout, commit, rebase, push), kubectl (apply, get, describe, logs, rollout status), docker (build, run, images, rm, prune), and terraform (init, plan, apply, fmt) are indispensable.
Beyond memorization, standardize flag usage and output formats: use kubectl -o yaml/json for machine-readable exports, docker build –progress=plain for CI logs, and terraform plan -out to capture a plan artifact. These patterns make automation predictable and debuggable across teams.
Wrap repetitive command sequences in small helper scripts or Makefile targets (e.g., make deploy, make test). Keep a curated cheat-sheet in your repo (see the DevOps commands cheat-sheet) so new hires get productive faster and on-call runbooks point to exact commands rather than freeform shell history.
Cloud infrastructure skills and Terraform scaffolding
Short answer: treat cloud infrastructure as software. Skill sets include provider-specific resource models (EC2/VMs, IAM, VPC, networking), state management, secure secrets handling, and automation patterns (modules, workspaces, remote state). The goal is reproducible environments and safe changes via pull requests and automated plan checks.
Terraform scaffolding for teams should separate concerns: a modules directory for reusable components, environment overlays for staging/production, and a CI pipeline to validate formatting (terraform fmt), linting (tflint), and plan generation. Use a remote state backend (e.g., S3 + DynamoDB lock) or managed state solutions to avoid corruption and enable collaboration.
Adopt smaller, focused modules instead of one giant monolith. Version modules through tagged releases and pin module versions in root configurations. Consider Terragrunt or automation wrappers for cross-account and multi-region orchestration. For examples and starter patterns, check the repository’s scaffolding examples: Terraform scaffolding examples.
CI/CD pipelines: design, automation, and security
Short answer: pipelines should validate code (lint/tests), build artifacts (immutable images), and deploy safely (canary/blue-green or rolling updates), while protecting secrets and enforcing policy. Treat CI as the first line of defense: rejected code never reaches production.
Design pipelines that are composable: separate build, test, and deploy stages; publish immutable artifacts (container images, bundles) to a registry with content-addressable tags; and require automated rollback mechanisms. Integrate security scans (SAST, dependency checks, container image scanning) early so fixes are cheaper.
Protect secrets by using CI-native secrets stores or a secrets manager; never echo credentials in logs. Add a manual approval gate for prod changes and require a signed commit or approved merge request. Finally, instrument pipeline runs with brief logs and artifact links to simplify incident investigation and auditability.
Kubernetes manifests, Helm, and Docker optimization
Short answer: write small, declarative manifests, prefer Helm or Kustomize for templating, and optimize Docker images with multi-stage builds and minimal base images. Keep manifests auditable and templatized for repeatability.
Manifest best practices: keep each resource focused (ConfigMap, Secret, Deployment, Service), use labels and annotations consistently, and include resource requests/limits to prevent noisy neighbors. For release strategies, implement readiness/liveness probes and use Kubernetes rollout commands (kubectl rollout status) during deployments to ensure safe transitions.
Docker optimization is about build context, layer ordering, and size. Use multi-stage Dockerfiles to separate build-time dependencies from runtime. Order RUN steps to maximize layer cache reuse and remove build artifacts before final image creation. Prefer distroless or alpine runtime images when compatible with your stack to reduce attack surface and image pull times.
Observability: Prometheus, Grafana, and incident runbook automation
Short answer: collect metrics with Prometheus, visualize with Grafana, route alerts with Alertmanager, and automate runbooks for predictable incident response. Observability is a feedback loop — measure, alert, act, and learn.
Start by instrumenting critical services with well-scoped metrics (request latency, error rates, queue depths). Use standardized metric names and labels to allow cross-service queries. Deploy node exporter and application exporters where needed, and configure Prometheus scrape intervals carefully to balance fidelity and cost.
Design alerts to be meaningful (SLO-aware) and tied directly to runbooks. Automate common mitigations (scale-up, route traffic away, restart pod) using runbook automation tools or CI/CD jobs triggered by alerts. Maintain a concise incident runbook repository with exact commands, rollback steps, and escalation paths so on-call engineers can act fast without guesswork.
Cheat-sheet: Go-to commands (quick)
- git: git clone, git checkout -b, git add -p, git commit –amend, git rebase -i, git push –force-with-lease
- kubectl: kubectl apply -f, kubectl get pods -o wide, kubectl logs -f
, kubectl describe pod, kubectl rollout status deploy/ - docker: docker build -t repo/name:tag ., docker build –target=prod, docker run -it –rm, docker images –format, docker system prune -f
- terraform: terraform init, terraform fmt, terraform validate, terraform plan -out=plan.tfplan, terraform apply plan.tfplan
- prometheus/grafana: check scrape_targets, query rate(my_metric[5m]), export dashboard snapshots for pivoting
Operational playbooks: incidents, automation, and postmortems
Short answer: an incident runbook must be precise, scripted, and tested. Automation reduces cognitive load and speeds mean time to resolution (MTTR), but always provide manual overrides and clear rollback instructions.
Structure runbooks as: trigger conditions, impact assessment, immediate mitigations (with exact commands), escalation contacts, and post-incident tasks. Keep runbooks in version control and run periodic tabletop exercises to validate them. Combining runbooks with automation tools (Rundeck jobs, GitHub Actions workflows invoked by an alert) lets you run approved mitigations with a single click.
Postmortems should be blameless, time-boxed, and focused on systemic fixes (not individual errors). Convert findings into prioritized action items and track them until verified. Feed those actions back into CI and IaC so the same issue cannot silently recur — for example, add a test that checks for missing resource limits or missing health probes.
Semantic core (keyword clusters)
| Cluster | Keywords / Phrases (examples) | Frequency / Intent |
|---|---|---|
| Primary | DevOps commands, CI/CD pipelines, Kubernetes manifests, Terraform scaffolding, Docker optimization, Prometheus Grafana monitoring, Incident runbook automation, Cloud infrastructure skills | High / Informational & Commercial |
| Secondary | infrastructure as code, IaC best practices, terraform modules, remote state backend, kubectl commands, helm charts, kustomize, multi-stage Dockerfile, image size reduction, alertmanager routing, Grafana dashboards | Medium / Informational |
| Clarifying | git workflow, canary deployments, blue-green deployment, secrets management in CI, prometheus exporters, node exporter, observability stack, runbook automation tools, rundeck, terragrunt, policy-as-code | Medium / Informational |
FAQ
Which DevOps commands should I memorize first?
Memorize git basics (clone, commit, push, rebase), kubectl essentials (apply, get, logs, rollout), docker build/run, and terraform init/plan/apply. These cover source control, containers, orchestration and IaC — the core of day-to-day troubleshooting.
How do I structure Terraform scaffolding for teams?
Use modular code, remote state with locking, separate environment overlays, CI validation for plans, and pinned module versions. Enforce policy checks in CI (e.g., Sentinel, OPA) to prevent risky changes and to keep configurations consistent across teams.
What is the minimal observability stack for production?
Prometheus for metrics, Alertmanager for alert routing, and Grafana for dashboards form a minimal, production-grade stack. Add exporters (node, blackbox) and integrate alerting with runbook automation and on-call routing for fast response.