DevOps Fundamentals and Culture
What this domain covers
The DevOps fundamentals domain tests whether you can explain why network teams adopt DevOps practices, not just name tools. Expect questions on CALMS, the Three Ways, DORA metrics and blameless incident review, framed around Junos change workflows.
Core rules and concepts
- CALMS - Culture, Automation, Lean, Measurement, Sharing. Automation without the culture and feedback parts is just scripting.
- The Three Ways: (1) systems thinking and flow - small batch sizes moving left to right through the pipeline; (2) amplify feedback loops - telemetry, alerts and automated tests return information fast; (3) continual experimentation and learning.
- DORA four keys - lead time for changes, deployment frequency, change failure rate and time to restore service (often abbreviated MTTR). High performers score well on all four; speed and stability move together.
- Blameless postmortem - the output is a systemic fix, not a person to blame. "Human error" is treated as a symptom of a design that let the error reach production.
Worked example
A team's change failure rate is 30%. The reflex is to mandate extra sign-offs. Applying feedback thinking instead: the pipeline captures the pre-change show configuration | compare rollback 1 diff, deploys with commit confirmed 5, and runs post-change assertions on BGP peer state. Failures now self-revert within five minutes and the diff is attached to the ticket, so the postmortem sees what actually changed. Change failure rate falls because failures are caught and reverted, not because fewer changes ship.
Traps that cost marks
- Treating "DevOps" as a team name or a single tool.
- Assuming reliability and deployment frequency trade off against each other.
- Reading MTTR as "mean time to repair" when DORA defines it as time to restore service.
- Calling a postmortem blameless while still listing an individual's action as the root cause.