If you see X, reach for Y

Start with the first fix in each row; most teams jump to the expensive one too early.

A GitHub Actions workflow to copy

Test on every pull request, deploy from main through a protected environment. Version tags such as @v4 are shown for readability; in a hardened repo pin each action to a full commit SHA (Actions CI, Trusted CI, Supply chain).

name: ci
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read            # least privilege for every job by default

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true  # a new push cancels the old run

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
        ports: ['5432:5432']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/postgres

  deploy:
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production   # required reviewers and secrets live here
    permissions:
      contents: read
      id-token: write         # lets the job sign in to the cloud with OIDC
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

Docker: "I want to..."

Compose v2 is a plugin, so the command is docker compose with a space; the old docker-compose binary is retired (Containers).

A Dockerfile that follows the rules

Multi-stage build, dependency files copied before source so the install layer is cached, a slim base, and a non-root user. Add a .dockerignore with node_modules, .git and .env (Containers).

FROM node:20-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM node:20-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/main.js"]

kubectl: "I want to..."

Add -n <namespace> to any command, or set it once with kubectl config set-context --current --namespace=api. Check which cluster you are on before you change anything (Kubernetes).

Terraform workflow

Plan in the pull request, apply only from CI, state stored remotely with locking. OpenTofu takes the same commands with tofu in place of terraform (IaC).

Release strategies

Separate deploying code from releasing a feature. For Mangrove's tills, which must keep selling offline, a new POS build goes to a few pilot stores first and waits a full trading day before the next ring (Safe releases, Shipping).

SLO and error-budget numbers

An error budget is 100% minus the SLO. Burn rate is how fast you spend it: a burn rate of 1 uses exactly the whole budget over the SLO window (SLOs and budgets, Burn-rate alerts).

What to watch and measure

• Four golden signals per service: latency (p50, p95, p99), traffic, errors, saturation (Observability).
• RED for request-driven services (rate, errors, duration) and USE for resources (utilisation, saturation, errors) (OpenTelemetry).
• DORA metrics for delivery: deployment frequency, lead time for changes, change failure rate, and time to restore after a failed change (Safe releases).
• Capacity: requests in progress = rate × time per request; plan for Mangrove's festival peak at about 4 times a normal day (Capacity and game days, Estimation).

Incident roles and severities

One person commands; they do not also debug. Roles can be one person each in a small team, but name them out loud (Incident command).

Status update template

[SEV1] App checkout failing for about 40% of orders. Update 3, 19:45 UTC.
Impact: customers in all cities see "payment failed"; stores are not affected.
What we know: started 19:05 after release 1.8.0 of the payments API.
What we are doing: rolling back to 1.7.4, about 10 minutes.
Next update: 20:15 UTC or sooner if this changes.
Incident lead: Nadia

Postmortem template

Blameless: ask how the system let a reasonable person make this mistake, not who made it. Publish within a week (Postmortems).

# Postmortem: checkout failures after payments API 1.8.0

Date: 2026-10-14   Severity: SEV1   Duration: 19:05 to 19:58 UTC (53 min)
Authors: Nadia, Ken      Status: actions in progress

## Summary
Two or three sentences a manager can forward.

## Impact
Orders failed, customers affected, revenue at risk, error budget used.

## Timeline (UTC)
19:05 deploy finished   19:09 burn-rate page   19:21 rollback decided ...

## Root cause and contributing factors
What happened and why the safeguards did not stop it.

## What went well / what was hard

## Actions
| Action | Type (prevent / detect / mitigate) | Owner | Due |

Git on release day

The everyday commands are in the Developer cheat sheet. These are the ones for releases and incidents (Branches and releases, Code detective).

Linux on call

The first commands to run on a sick host. journalctl and systemctl need a systemd distribution; the TechOps cheat sheet has more (Linux CLI).

Glossary

Plain definitions of the DevOps and SRE terms used across the Engineering Roles line.

Artifact

The built output of CI, such as a container image, built once and promoted unchanged from staging to production. Trusted CI

Blue-green deployment

Running the new version beside the old one and switching all traffic at once. Safe releases

Burn rate

How fast the error budget is being spent compared with spending it evenly over the window. Burn-rate alerts

Canary

A new version given a small share of real traffic first, watched before it gets more. Safe releases

CI/CD

Continuous integration (merge small changes often, tested automatically) and continuous delivery or deployment (every good build can go, or goes, to production). Trusted CI

Container image

A packaged app with everything it needs to run, built from a Dockerfile in layers. Containers

Deployment (Kubernetes)

The object that keeps a set number of pod copies running and rolls out new versions. Kubernetes

Drift

Real infrastructure that no longer matches its code because someone changed it by hand. IaC

Error budget

The failure an SLO allows, such as 43 minutes a month at 99.9%, which the team can spend on change. SLOs and budgets

Feature flag

A switch that turns a feature on or off at run time without a deploy. Safe releases

Game day

A planned exercise that breaks something on purpose to test systems and people. Capacity and game days

Infrastructure as code (IaC)

Servers, networks and permissions described in files, reviewed and applied like code. IaC

Liveness and readiness probes

Kubernetes checks: liveness restarts a stuck container, readiness keeps traffic away until it is ready. Kubernetes

MTTR

Mean time to restore: the average time from an incident starting to service being back. Incident command

OIDC (in CI)

CI proves its identity to the cloud with a short-lived token, so no long-lived keys are stored. Supply chain

OpenTelemetry

The open standard and libraries for producing traces, metrics and logs. OpenTelemetry

Pod

The smallest thing Kubernetes runs: one or more containers sharing a network address. Kubernetes

Postmortem

A written, blameless review of an incident with actions that have owners and dates. Postmortems

Rollback

Returning to the last good version; the first move when a deploy causes an incident. Safe releases

Runbook

Step-by-step instructions for one alert or task, written so anyone on call can follow them. Incident command

SLI, SLO, SLA

What you measure, the target you set, and the promise with penalties you sign. SLOs and budgets

Terraform state

Terraform's record of which real resources match which code; kept remote, locked and never edited by hand. IaC

Toil

Manual, repetitive work that grows with the system and could be automated. Toil

Courses on Kolom

• DevOps: CI/CD, Containers and Infrastructure as Code: trusted pipelines, Docker, Kubernetes, Terraform, safe releases and the supply chain.
• Site Reliability Engineering: SLOs, OpenTelemetry, burn-rate alerts, incident command, postmortems, capacity and toil.
• Running Software in Production: observability, security and shipping basics every engineer needs.
• GitHub for Teams: pull requests, releases, Actions CI and deploying safely.

What to read next

• Site Reliability Engineering and The Site Reliability Workbook from Google, free at sre.google/books. The workbook's alerting chapter is the source of the burn-rate table.
• Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. The research behind the DORA metrics.
• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois and John Willis. How flow, feedback and learning fit together.
• GitHub Actions documentation at docs.github.com/actions, including the security hardening guide.
• kubectl reference at kubernetes.io, with the official quick reference of common commands.
• Terraform documentation at developer.hashicorp.com.