DevOps & Operations

Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the testing, building, and release of software. They enforce parity between environments and remove manual intervention from the release path.

Blue-green deployment runs two identical production environments simultaneously. Only one serves live traffic at a time, allowing instant rollbacks by routing traffic back to the previous environment.

A canary release deploys a new version to a small subset of users before rolling it out to the entire infrastructure. This limits the blast radius of unexpected failures.

A rolling update replaces instances of an application incrementally. This allows deployments to proceed without taking the entire service offline, maintaining capacity while transitioning to a new version.

Feature flags decouple deployment from release. They allow code to ship to production in a dormant state, and enable teams to turn features on or off dynamically without redeploying the application.

The Compose specification defines a developer-centric model for multi-container applications. It standardizes how services, networks, and volumes are declared in YAML.

The strategy of decoupling schema changes from application deployments, allowing databases to be restructured without locking tables or interrupting live customer traffic.

An operational framework where a Git repository acts as the single source of truth for declarative infrastructure and applications, relying on software agents to continuously pull and synchronize the desired state.

The Open Container Initiative (OCI) Image Format Specification standardizes how container images are built, packed, and signed. It ensures interoperability between different container engines and registries.

Semantic Versioning (SemVer) is a formal convention for assigning version numbers to software releases. It dictates how version numbers reflect the nature of underlying code changes, enabling automated dependency resolution.

Artifact registries store compiled software components. Immutable builds guarantee that a compiled artifact never changes once pushed, ensuring the exact code tested is the exact code deployed.

A rollback strategy defines how a system reverts to a previous stable state after a failed deployment. Automated and tested rollbacks are essential for maintaining service level objectives.

Core principles of defining environments through machine-readable code, enabling idempotency, desired state configuration, and automated reconciliation.

Managing, locking, and securing Terraform state files, the critical mapping layer between declarative code and cloud provider APIs.

The practice of replacing infrastructure components entirely rather than modifying them in place, guaranteeing consistency and eliminating configuration drift.

Detecting and automatically correcting drift between the desired state defined in version control and the actual state of the running environment.

Patterns for dynamically issuing and revoking temporary credentials, eliminating hardcoded secrets and secret sprawl.

Keeping development, staging, and production environments as similar as possible to prevent deployment failures caused by configuration differences.

Using the Domain Name System to dynamically locate and route traffic to ephemeral services in distributed architectures.

Automated probes used by load balancers to determine if a backend server is capable of handling traffic, preventing requests from being routed to failed instances.

Strategies for dynamically adjusting the number of active computing resources based on real-time demand, ensuring performance while minimizing costs.

The POSIX standard syntax for scheduling recurring background jobs, specifying the exact minute, hour, day, and month a script should execute.

The analytical process of predicting future system resource requirements based on historical trends, business projections, and known scaling constraints.

The foundational declarative resources used to orchestrate containers, manage networking, and handle configuration in Kubernetes.

Managing container health and traffic routing using liveness, readiness, and startup probes.

The foundational network guarantees of Kubernetes, where every Pod gets a unique IP and can communicate without NAT.

Defining minimum guaranteed resources and maximum caps to prevent noisy neighbor problems and node starvation.

Optimizing container builds by structuring Dockerfiles to maximize cache hits, reduce build times, and minimize the final image footprint.

Defining and managing long-running background services, dependencies, and restart policies using the Linux init system.

Deploying helper containers alongside a primary application container within the same Pod to augment its functionality without modifying its code.

The Linux kernel features that provide containers with their own independent network stacks, interfaces, and routing tables.

The standardized directory and file layout required to package, configure, and deploy applications as Helm charts on Kubernetes.

The Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O) of a collection of processes.

The standard specification for explicitly defining which pods are allowed to communicate with each other, enforcing a zero-trust network model within a cluster.

The automated process of inspecting container images for known vulnerabilities (CVEs) and cryptographically verifying their origin to prevent supply chain attacks.

The foundational data types - Metrics, Logs, and Traces - required to understand the internal state of a complex distributed system.

Understanding the cost and performance impact of attaching highly unique labels, like user IDs, to time-series metrics data.

Tracking a single request as it travels across multiple network boundaries and microservices using injected context headers.

The shift from human-readable text logs to machine-parsable JSON logs to enable complex querying and automated alerting.

Centralizing logs from distributed ephemeral containers into a searchable, indexed database.

Designing alerts that require human intervention and eliminating noisy warnings that train engineers to ignore paging systems.

Defining numerical targets for system reliability that balance the need for feature velocity against the risk of user-facing outages.

The essential metrics - Latency, Traffic, Errors, and Saturation - that provide a complete picture of a service's health.

A vendor-neutral standard for generating, collecting, and exporting telemetry data across modern distributed systems.

The open, text-based standard for exposing dimensional metric data over HTTP so that monitoring systems can scrape and index it.

The IETF standard (RFC 9474) defining a consistent, machine-readable JSON schema for APIs and microservices to report their health status to orchestrators.

A standardized, hierarchical management structure designed to coordinate emergency response and eliminate chaos during severe outages.

The practice of investigating outages without assigning human fault, focusing instead on the systemic vulnerabilities that allowed the failure to occur.

A critical metric that measures how quickly a team can diagnose, mitigate, and resolve a production outage.

Explicit, step-by-step technical manuals designed to guide engineers through mitigating specific alerts and routine operational tasks.

The discipline of experimenting on a distributed system to build confidence in its capability to withstand turbulent conditions in production.

Techniques for controlling the rate of traffic sent or received by a network interface controller to prevent resource exhaustion.

A software design pattern used to detect failures and encapsulate the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.

Isolating elements of an application into pools so that if one fails, the others will continue to function, preventing total system collapse.

A network resilience strategy that spaces out repeated requests to a failing service to prevent self-inflicted Denial of Service attacks.

The design of external, black-box monitoring systems that verify a service is actually reachable and functioning from the perspective of a user.

A standardized scale (usually SEV-1 to SEV-4) used to instantly communicate the business impact of an outage and determine the appropriate level of response.

Designing systems to intentionally disable non-critical features during high load or partial outages to preserve core functionality.

The operational structures and human-centric schedules that ensure a system is supported 24/7 without burning out the engineering team.

The strategies and metrics used to restore business operations after a catastrophic event, focusing on acceptable data loss (RPO) and downtime (RTO).

The mechanisms by which a downstream system signals an upstream sender to slow down its transmission rate, preventing catastrophic resource exhaustion.

A dedicated infrastructure layer for managing, securing, and observing service-to-service communication within a microservices architecture.

The automated process of replacing cryptographic certificates before they expire to maintain secure HTTP connections without downtime.

The standardized HTTP header used by servers to explicitly tell clients exactly how long to wait before attempting a failed request again, preventing thundering herds.

A mechanism at the transport layer that periodically sends empty probe packets across an idle connection to ensure the peer is still reachable and to prevent firewalls from dropping the connection.

An event-driven architectural pattern where one service sends automated HTTP POST requests to another service the moment an event occurs, replacing continuous polling.

The principles of authenticating entities (users and machines) and authorizing their specific permissions across cloud environments and clusters.

The cryptographic trust framework that enables secure communication over untrusted networks via digital certificates and mathematical proof of identity.

The architectural mechanism for ensuring that retrying a failed network request never results in a duplicated action, such as charging a customer's credit card twice.