Guide DevOps Navigator

A DevOps guidance agent that helps teams navigate the DevOps landscape, selecting appropriate tools, establishing workflows, and implementing practices that improve delivery speed, reliability, and collaboration.

When to Use This Agent

Choose Guide DevOps Navigator when:

• Starting a DevOps transformation and need guidance on where to begin
• Evaluating DevOps tools and platforms for your team's needs
• Establishing DevOps workflows and team practices
• Improving collaboration between development and operations teams
• Building a DevOps roadmap aligned with business goals

Consider alternatives when:

• Implementing specific CI/CD pipelines (use DevOps Expert Consultant)
• Setting up cloud infrastructure (use a cloud architect agent)
• Managing incidents and monitoring (use an SRE agent)

Quick Start

Copy
# .claude/agents/guide-devops-navigator.yml
name: Guide DevOps Navigator
description: Navigate DevOps tool selection and practices
model: claude-sonnet
tools:
  - Read
  - Write
  - Glob
  - Grep
  - WebSearch

Example invocation:

claude "Our 15-person engineering team wants to adopt DevOps practices. We currently deploy manually once a week. Help us create a 6-month DevOps adoption roadmap"

Core Concepts

DevOps Toolchain Map

Category	Open Source	Commercial	Cloud-Native
Source Control	Git, Gitea	GitHub, GitLab	CodeCommit, Azure Repos
CI/CD	Jenkins, GitHub Actions	CircleCI, TeamCity	CodePipeline, Azure Pipelines
IaC	Terraform, Pulumi	env0, Spacelift	CloudFormation, Bicep
Containers	Docker, containerd	Docker Desktop	ECS, Cloud Run
Orchestration	Kubernetes, Nomad	OpenShift, Rancher	EKS, GKE, AKS
Monitoring	Prometheus, Grafana	Datadog, New Relic	CloudWatch, Azure Monitor
Logging	ELK Stack, Loki	Splunk, Sumo Logic	CloudWatch Logs
Security	Trivy, OWASP ZAP	Snyk, SonarQube	GuardDuty, Defender

DevOps Adoption Roadmap

Copy
## 6-Month DevOps Roadmap

### Month 1-2: Foundation
- [ ] Implement trunk-based development with PR reviews
- [ ] Set up automated CI (build + test on every PR)
- [ ] Introduce infrastructure as code for one environment
- [ ] Establish basic monitoring and alerting

### Month 3-4: Automation
- [ ] Automate deployments to staging environment
- [ ] Implement automated security scanning in CI
- [ ] Add integration and E2E tests to pipeline
- [ ] Set up centralized logging

### Month 5-6: Optimization
- [ ] Enable automated production deployments with approval
- [ ] Implement canary or blue-green deployment strategy
- [ ] Establish SLOs and error budgets
- [ ] Conduct first blameless post-mortem
- [ ] Measure DORA metrics and set improvement targets

Team Structure Patterns

Pattern	Description	Best For
Embedded SRE	SRE engineers within product teams	Large orgs (50+ engineers)
Platform Team	Shared team provides DevOps platform	Medium orgs (15-50 engineers)
Full-Stack DevOps	Every developer does DevOps	Small teams (<15 engineers)
Consulting SRE	SRE team consults with product teams	Transitioning organizations

Configuration

Parameter	Description	Default
team_size	Engineering team size	Required
current_maturity	Current DevOps maturity (1-5)	Self-assessed
deployment_frequency	Current deployment frequency	Required
cloud_provider	Primary cloud platform	Required
budget	Tooling budget (low, medium, high)	medium
timeline	Transformation timeline	6 months

Best Practices

1. Start with the highest-pain workflow, not the most popular tool. If deployments are the biggest bottleneck, start with CD automation. If production issues take hours to diagnose, start with observability. If merge conflicts consume half of sprint time, start with branching strategy. Address the team's most painful workflow first — this generates immediate value and builds momentum for further DevOps adoption.

2. Adopt tools incrementally, not all at once. Introducing CI/CD, IaC, containers, Kubernetes, and monitoring simultaneously overwhelms the team and increases failure risk. Adopt one practice per quarter, measure its impact, and stabilize before adding the next. A team that masters CI in Q1 and adds CD in Q2 is more effective than a team that partially implements everything at once and masters nothing.

3. Measure before and after every practice adoption. Without baseline measurements, you cannot demonstrate improvement. Measure deployment frequency, lead time (commit to production), mean time to recover, and change failure rate before adopting new practices. Track these metrics monthly and share the improvement trajectory with the team and leadership. Measured improvement sustains organizational support.

4. Choose tools that match your team's skills and growth trajectory. A team of 5 developers does not need Kubernetes — Docker Compose or a PaaS like App Service is sufficient. A team of 50 engineers with complex microservices does need an orchestrator. Choose tools that match current needs with room to grow. Over-tooling creates maintenance burden without proportional value. Under-tooling creates bottlenecks that slow the team.

5. Build a platform team when the organization exceeds 15-20 engineers. Below this threshold, every developer manages their own DevOps. Above it, duplicated effort and inconsistent practices create inefficiency. A platform team builds shared CI/CD pipelines, deployment tooling, and monitoring dashboards that product teams consume. The platform team accelerates all product teams by providing reliable, self-service infrastructure.

Common Issues

DevOps transformation stalls after initial quick wins. Teams automate CI and see immediate improvements, then momentum fades because the next improvements (CD, IaC, observability) require more effort and organizational change. Maintain momentum by setting quarterly milestones, celebrating improvements with metrics, and connecting DevOps improvements to business outcomes (faster feature delivery, fewer production incidents, reduced on-call burden).

Tool proliferation creates more complexity than it solves. Without governance, each team adopts its own CI tool, monitoring platform, and deployment process. The result is 5 CI systems, 3 monitoring tools, and no standardization. Establish a "blessed toolchain" that the platform team supports. Teams can use other tools but are responsible for their own support. Standardization reduces cognitive overhead and enables shared best practices.

Developers resist DevOps practices because they see it as "ops work." DevOps is a cultural change, not a job transfer. Developers may resist writing deployment configs, monitoring dashboards, and runbooks because they see it as operations work added to their plate. Frame DevOps as ownership: "you build it, you run it" means faster feedback, more control, and fewer 3am pages because you caught issues before production. Start with practices that immediately benefit developers (faster CI, self-service environments) to build buy-in.