DevOps Foundation flashcards
DevOps Foundation · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- CALMS framework
- A DevOps adoption model with five dimensions: Culture, Automation, Lean, Measurement and Sharing. It is used to assess organizational readiness and to balance technical work with cultural change.
- The Three Ways
- Gene Kim's three DevOps principles: the flow of work from development to operations, fast feedback from right to left, and a culture of continual experimentation and learning.
- Wall of confusion
- The adversarial boundary between development and operations that forms when the two groups are measured on conflicting goals, rapid change versus stability, producing handoffs, blame and slow delivery.
- DevOpsDays origin
- The DevOps movement's name was popularized at the first DevOpsDays event in Ghent, Belgium in 2009, organized by Patrick Debois after early discussions on agile infrastructure.
- SRE versus DevOps
- Site Reliability Engineering applies DevOps principles through service level objectives, error budgets and toil reduction, while DevOps is the broader cultural and organizational movement that SRE operationalizes.
- Blameless postmortem
- A structured incident review that assumes people acted reasonably given the information they had, and seeks systemic and process causes rather than individual fault so future incidents are prevented.
- Psychological safety
- Amy Edmondson's term for a shared team belief that asking questions, admitting mistakes and raising concerns will not be punished or humiliated, which enables learning and faster feedback.
- Westrum generative culture
- A culture type from Ron Westrum's typology that is mission-focused, encourages cooperation and information sharing, and treats failures as opportunities for inquiry; it correlates with higher delivery performance.
- You build it you run it
- Werner Vogels' principle that the team that builds a service also operates it, aligning incentives so developers experience the operational consequences of their design and quality decisions.
- Two-pizza team
- A team sizing heuristic, popularized at Amazon, holding that a team should be small enough to be fed by two pizzas, roughly six to ten people, to limit communication overhead.
- Little's Law
- A queueing formula stating that the average number of items in a system equals throughput multiplied by average time in the system; it shows that reducing work in progress shortens lead time.
- Continuous delivery
- A practice in which every change is automatically built, tested and kept in a deployable state, so releasing to production is a routine business decision rather than a risky project.
- Continuous deployment
- An extension of continuous delivery in which every change that passes all automated pipeline gates is released to production automatically, with no separate human approval step.
- Trunk-based development
- A branching model where developers merge small changes into a shared mainline at least daily, avoiding long-lived feature branches that cause painful merges and delay integration feedback.
- Blue-green deployment
- A release technique using two identical production environments: traffic is switched from the live blue version to the newly deployed green version, allowing instant rollback by switching back.
- Canary release
- A deployment pattern that routes a small percentage of real traffic to a new version before full rollout, comparing error rates and latency to limit the blast radius of a bad release.
- Infrastructure as Code
- Managing servers, networks and configuration through version-controlled definition files instead of manual steps, so environments are reproducible, reviewable and consistent across the delivery pipeline.
- Immutable infrastructure
- A model in which servers or containers are never modified after deployment; changes are made by building and replacing instances, which removes configuration drift and makes rollbacks predictable.
- Test pyramid
- A testing strategy with many fast unit tests at the base, fewer service or integration tests in the middle, and very few slow end-to-end user interface tests at the top.
- Three pillars of observability
- Metrics as numeric time series, logs as discrete event records, and distributed traces as request paths across services; these telemetry types are used to understand production behavior.
- Idempotency
- A property of an operation that produces the same result whether run once or many times; configuration management and infrastructure as code tools rely on it so repeated runs converge.
- Deployment frequency
- A DORA metric measuring how often an organization successfully releases to production; higher frequency indicates smaller batch size and a smoother, more automated delivery pipeline.
- Lead time for changes
- A DORA metric measuring the time from code commit to that code running in production. Shorter lead time indicates a fast, automated and low-friction delivery pipeline.
- Change failure rate
- A DORA metric giving the percentage of production deployments that cause a degraded service and require remediation such as a hotfix, rollback or incident response.
- Time to restore service
- A DORA metric measuring how long it takes to recover from a failed deployment or incident, often reported as mean time to recovery; it reflects detection and rollback capability.
- Error budget
- The allowed amount of unreliability, calculated as one minus the service level objective. A 99.9 percent monthly SLO leaves about 43 minutes of permissible downtime.
- Goodhart's Law
- The observation that when a measure becomes a target, people optimize the measure rather than the underlying goal, so metrics must be paired and reviewed to avoid gaming.
- PDCA cycle
- The Deming improvement loop of Plan, Do, Check and Act: hypothesize a change, trial it, compare results against the expected outcome, then standardize or adjust the approach.
- Kaizen
- A Japanese Lean concept meaning continuous incremental improvement, carried out by the people doing the work rather than only by specialist improvement teams or large one-off transformations.
- Five Whys
- A root cause analysis technique that repeatedly asks why about a problem, typically five times, to move past visible symptoms toward the underlying process or system failure.
- Chaos engineering
- Deliberately injecting failures such as killing instances, adding latency or dropping network links into a production-like system to test resilience and reveal weaknesses before real outages do.
- Inner source
- Applying open-source practices inside an organization: shared repositories, visible code, contribution guidelines and peer review, so teams can reuse and improve each other's work.