본문으로 건너뛰기
cccskills
무료GitHub에 공개

nw-platform-engineering-foundations

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구Kubernetes
설치 방법 보기

포함된 파일(1)

  • SKILL.md4.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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

MetricEliteHigh
Deployment frequencyMultiple times/dayDaily to weekly
Lead time< 1 hour1 day to 1 week
Change failure rate0-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}

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

Detailed 5-phase workflow for creating agents - from requirements analysis through validation and iterative refinement

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

nWave-ai/nWave6202026년 9월 16일 업데이트

nWave-ai의 스킬 모두 보기

이 스킬의 문제 신고