DevOps Principles

Mental model

Cisco objective 4.12 says “Describe the principles of DevOps practices”. DevOps is a culture that merges Development (people who write software) and Operations (people who run software) into one team with shared responsibility.

The acronym to remember: CALMS.

• Culture — collaboration over silos
• Automation — if a human does it twice, automate the third time
• Lean — small batches, fast feedback, continuous improvement
• Measurement — if it is not measured, it is not improving
• Sharing — knowledge, tools, failures, learnings

Culture

Dev used to toss code “over the wall” to Ops. Ops cursed, deployed Friday night, got paged at 3am. DevOps culture removes the wall: Dev writes the code and carries the pager; Ops contributes to the design before code is written.

• You build it, you run it. The team that writes a service also operates it.
• Blameless post-mortems when something breaks. Focus on the systemic cause, not the human.
• Trust by default. Access to shared tooling by any team member, not gated behind change-advisory boards for every small change.

Automation

Human effort moves up the stack. Repetitive work goes to a machine.

• Version control for everything — code, configs, infrastructure, runbooks, docs.
• CI/CD pipelines that run tests, build, deploy, and verify without a human clicking buttons.
• Infrastructure as code (Terraform, Ansible) so a new environment is a Git push.
• Automated testing so a change ships in minutes with confidence.

Lean

Borrowed from Toyota’s manufacturing. In software:

• Small changes, often. 10 one-line commits beat one 500-line commit.
• Fast feedback. CI runs in minutes, not hours.
• Build-measure-learn: ship the smallest thing, see how it does, adjust.
• Eliminate waste: meetings that could be chat, docs no one reads, features no one uses.

Measurement

• DORA metrics (industry standard):
  • Deployment frequency — how often you deploy.
  • Lead time for changes — commit to prod.
  • Mean time to recovery — incident to resolution.
  • Change failure rate — % of deploys that cause an incident.
• SLO / SLI / SLA — explicit targets (“99.9% of API calls return in <200 ms”).
• Observability — logs, metrics, traces so you can SEE what the system is doing.

Sharing

• Internal engineering blog posts after an outage.
• Open-source what is not a competitive advantage.
• Pair programming / mob programming.
• Rotating on-call so knowledge spreads.

Common DevOps practices and tools

NetDevOps

Applying DevOps principles to network engineering:

• Store all device configs in Git.
• CI pipeline lints YAML / Jinja templates.
• CD pipeline pushes config via Ansible / RESTCONF / NSO.
• Monitoring: streaming telemetry via gNMI, dashboards in Grafana.
• On-call rotation for the automation itself.

Cisco objective 1.7 (version control) and 5.1 (model-driven programmability) sit inside this NetDevOps story.

Common anti-patterns

• “We have a DevOps team” (missing the point — DevOps is a culture, not an org chart).
• “We bought Jenkins, we are DevOps” (tool, not culture).
• Dev writes code that only Ops knows how to deploy.
• Change advisory board meets Tuesdays and Thursdays to approve each deploy (killed by speed-of-light fiber latency).

FAQ

Is DevOps the same as agile? Related, not identical. Agile is about development methodology (short iterations, working software). DevOps extends agile practices across Dev AND Ops to make shipping fast and safe.

Is SRE the same as DevOps? Site Reliability Engineering (coined by Google) is Google’s specific implementation of DevOps principles. Lots of overlap; SRE puts more emphasis on error budgets and formal SLOs.

Can a solo engineer “do DevOps”? Yes. The principles apply at any size. Version control, automation, measurement, learning from mistakes — all applicable to a solo project.

Does Cisco need me to know specific DevOps tools for the exam? No. 4.12 is describe-level. Know the CALMS acronym and the principles behind each letter.