/nw-platform-engineering-foundations

name: nw-platform-engineering-foundations
description: Foundational platform engineering knowledge from key references -- Continuous Delivery, SRE, Accelerate, Team Topologies, Chaos Engineering, and Secure Delivery. Load when contextual grounding in platform engineering theory is needed.
user-invocable: false
disable-model-invocation: true

Platform Engineering Foundations

Continuous Delivery (Humble and Farley)

Key principles: Build quality in | Work in small batches | Automate almost everything | Pursue continuous improvement | Everyone is responsible (shared ownership).

Pipeline progression: Commit -> Acceptance -> Capacity -> Production stages. For detailed stage definitions and quality gates, see `cicd-and-deployment` skill.

Site Reliability Engineering (Google -- Beyer et al.)

Key principles: SLOs over SLAs (internal targets stricter than external) | Error budgets (balance reliability and velocity) | Toil elimination (automate repetitive manual work) | Embrace risk (calculate risk, do not eliminate it).

Observability: Four Golden Signals (latency, traffic, errors, saturation) | SLI -> SLO -> Error Budget -> Alerting chain | Dashboards for investigation, not monitoring.

Accelerate (Forsgren, Humble, Kim)

DORA Metrics

• **Deployment frequency**: how often code deploys to production
• **Lead time for changes**: time from commit to production
• **Change failure rate**: % of deployments causing failure
• **Time to restore**: time to recover from production failure

Performance Levels

| Metric | Elite | High | |--------|-------|------| | Deployment frequency | Multiple times/day | Daily to weekly | | Lead time | < 1 hour | 1 day to 1 week | | Change failure rate | 0-15% | 16-30% | | Time to restore | < 1 hour | < 1 day |

Use DORA metrics as baselines when assessing current state and setting improvement targets.

Team Topologies (Skelton and Pais)

Team Types

• **Stream-aligned**: delivers value to customer, owns full lifecycle
• **Platform**: provides self-service capabilities, reduces cognitive load
• **Enabling**: helps teams adopt new practices, temporary engagement
• **Complicated subsystem**: owns complex technical domain

Platform Principles

Platform as a product (internal developer platform) | Self-service with guardrails | Reduce cognitive load on stream-aligned teams | Thinnest viable platform.

Use when designing platform team structures and determining which capabilities to centralize vs delegate.

Chaos Engineering (Rosenthal et al.)

Principles: Build hypothesis about steady state | Vary real-world events | Run experiments in production | Automate experiments continuously.

Practices: GameDays (scheduled chaos experiments) | Fault injection (network latency, failures) | Chaos monkey (random instance termination).

Secure Delivery (Building Secure and Reliable Systems)

Principles: Least privilege (minimal permissions) | Defense in depth (multiple security layers) | Zero trust (verify explicitly, assume breach).

Pipeline security: SAST in CI | DAST pre-production | SCA for dependency vulnerabilities | Secrets scanning | SBOM for supply chain transparency.

GitOps (GitOps and Kubernetes)

Principles: Declarative desired state in Git | Automated reconciliation | Drift detection and correction | Pull-based deployments.

Tools: ArgoCD (Kubernetes-native GitOps CD) | Flux (GitOps toolkit for Kubernetes).

Patterns: App of Apps for multi-environment management | Helm with GitOps for parameterization | Kustomize overlays for environment differences.

Constraint Impact Analysis Template

Use when assessing platform constraints before designing infrastructure.

## Platform Constraint Impact Analysis

| Constraint | Source | % Delivery Affected | Priority |
|------------|--------|---------------------|----------|
| {constraint} | {architecture/ops/security} | {X}% | {HIGH/MEDIUM/LOW} |

### Constraint-Free Baseline
- Maximum theoretical deployment frequency: ___
- Components that can proceed without constraints: ___ ({X}%)
- Quick wins available now: ___

### Decision Rules
- Constraint affects > 50% of delivery: address as primary focus
- Constraint affects < 50% of delivery: address as secondary
- Constraint affects < 20% of delivery: consider deferring

### Recommendation
Primary focus should be: {constraint-free opportunities or primary constraint}