Skip to content
academia.sh
tr
Log in

Course Beginner

DevOps Culture and Fundamentals

By the end of this course

Start course

01

Culture and Flow

Measuring the path from idea to production: the technical counterpart of shared responsibility and who sees which signal, the delay and risk produced by separate teams, mapping the value stream step by step, deployment frequency, lead time, change failure rate, and time to restore moving one another, the overlapping ground of operating approaches, and the length of the feedback loop.

  1. 01 What Is DevOps? The technical and organizational side of shared responsibility: in the same 22 occurrences' separate observation scopes, 9 are visible only to operations, 1 only to development, and 1 in neither scope; 4 occurrences never reach their owner and reaching one averages 7.0 steps; sharing three surfaces brings the unreached count to 1 and the reach time to 5.0 steps; fully combining the scopes brings reach down to 1.6 steps while the development team's load rises from 95 to 107 steps, lead time rises from 25.8 to 34.8 steps, and deployment frequency falls from 5 to 4 releases.
  2. 02 Throwing Over the Wall The delay and risk produced by separate teams: of the 29 context items carried by the same 18 changes, 21 are not written down; in the separate arrangement, 14 items drop at the boundary, producing 10 boundary bounces and 4 production errors; under shared responsibility the dropped items fall to 5, bounces to 3, production errors to 2, and the change failure rate falls from 22% to 11% — but deployment frequency falls from 9.5 to 7.9, wait at the internal transition rises from 8.1 to 12.2 steps, and time to restore rises from 61.0 to 65.0 steps; for the 7 changes carrying silent context, both arrangements produce the same 3 bounces and 2 errors.
  3. 03 Value Stream Mapping the path from idea to production: in a nine-step flow, 20 work items' average 182.0-step lead time breaks down into 70.2 steps of process and 111.8 steps of wait (value-added share 38.5%); of the total 2237 steps of wait, 1485 sit in a single step — the release window; with the release window at 20 steps, no single-step improvement shortens lead time by more than 2 steps; once the window is cut to 5 steps, the same improvements pull apart, with writing dropping from 10 to 5 gaining 32 steps but acceptance approval dropping from 2 to 1 losing 4 steps; and the bottleneck shifts from the release window to writing, then to integration testing.
  4. 04 Delivery Metrics Deployment frequency, lead time, change failure rate, and time to restore as a linked set: while 12 of 60 changes are defective, shrinking batch size from 8 to 2 brings deployment frequency from 3.2 to 13.5, lead time from 34.6 down to 14.9 steps, and the release failure rate from 80% down to 31%, even as the number of errors surfacing in production stays fixed at 12; shrinking the batch to 1 pushes deployment frequency to 20.0 but carries lead time to 69.7 steps; a gate catches 8 of the defects, bringing the change failure rate from 20% down to 7% while pushing time to restore from 45.4 up to 54.8 steps; automatic rollback brings time to restore down to 7.0 steps while rolling back 48 innocent changes; and the three decisions together push lead time up to 109.3 steps.
  5. 05 Site Reliability Engineering Tying the error budget to a number: in a 30-day period, a 99.9% target leaves 43.2 minutes of budget, and a single heavy incident takes 208% of it; without the budget rule, 12 periods measure 630 minutes of outage and 99.878% availability, while turning the rule on exhausts the budget in 8 of 12 periods and freezes for 166 days, yet cuts outage only to 620 minutes while lead time climbs from 3.0 to 12.6 days; pulling the target to 99.95% produces 236 frozen days and 60 unshipped changes, carrying lead time to 49.9 days; halving outage duration exhausts the rule in only 4 periods, availability rises to 99.939%, and lead time stays at 5.4 days.
  6. 06 Feedback Loops The length and error-class coverage of four feedback loops: at cumulative lengths of 2, 30, 240, and 4320 minutes, 42 of 120 errors are caught while writing, 21 at integration, 25 at staging, and 32 fall into none of them and escape to production; the average delay per class ranges from 2.0 to 3810.0 minutes; moving the data-format class to the integration loop adds 12 minutes and brings total delay from 144954 down to 128520 minutes, but catches only 5 of the class's 12 errors early; moving the scheduling class costs 20 minutes for only 1 of 10 errors gained; and all three moves together bring the change failure rate from 53% down to 42% while pushing lead time from 351.9 up to 420.2 minutes.

02

Fundamental Concepts

Counting where the difference hides: the separation of development, test, staging, and production environments, the build once deploy everywhere principle and build artifact immutability, versioned binary and package storage, separating environment-varying values into configuration and secrets, portable application principles, and infrastructure models running from manual setup to declarative provisioning.

  1. 01 Environments Where the difference between development, test, staging, and production hides is counted: how many of ten dimensions diverge from production, how many are written in the environment manifest, which difference conceals which defect class, and how many defect classes skipping a link carries to production.
  2. 02 Build Artifacts and Immutability The build once, deploy everywhere principle is measured: the digest of output produced twice from the same source is compared, the four sources that break reproducibility are closed one at a time, and the number of separate binaries produced by recompiling per environment is compared against a single-output layout.
  3. 03 Build Artifact Repositories Versioned binary and package storage is measured: the distinction between an immutable version and a movable tag is built into a repository model, how many deployments a movable tag pointed to a different artifact is counted, and the retention policy is scanned through the rollback window, repository bytes, and the count of unreachable deployments.
  4. 04 Configuration and Secret Separation The three environments' configuration files are written to disk, and a running checker counts how many keys actually change, how many sit in configuration without changing, and how many are undefined in an environment; the four surfaces a secret can leak through are scanned with a scanner, and caught, escaped, and false positives are written separately.
  5. 05 Twelve-Factor App Eight of the twelve principles are turned into a runnable check that decides by looking at files on disk and is run against a fictional application's real files; how many of eight planted defects were caught, how many escaped, and how many false positives were raised is counted, and what replaces the four principles that cannot be translated is written down.
  6. 06 Infrastructure Provisioning Models The same environment is set up manually, with a script, and declaratively; the difference between two setups, the state a script leaves behind on its second run and when it is cut off midway, and the configuration drift accumulated over six periods are counted. A running reconciler reads the desired state from a file, the actual state from disk, closes the difference, and does zero work on its second run.

Start typing to search.

↑↓ ↵ Esc navigate · open · close