Update nexus wiki content

wiki/sources/engineering-sre.md

@@ -0,0 +1,55 @@
+---
+title: "SRE (Site Reliability Engineer) Agent Personality"
+type: source
+tags: [sre, reliability, observability, devops, agent]
+date: 2026-05-01
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-sre.md]]
+
+## Summary（用中文描述）
+- 核心主题：SRE（网站可靠性工程师）Agent 个性定义——将可靠性视为可量化预算的专业生产系统专家 Agent
+- 问题域：大规模生产系统的可靠性管理——SLO 定义与测量、错误预算消耗追踪、可观测性体系构建、Toil 自动化、混沌工程
+- 方法/机制：SLO 驱动决策（错误预算剩余则发布功能，耗尽则修复可靠性）→ 三支柱可观测性（Metrics/Logs/Traces）→ Golden Signals 监控（Latency/Traffic/Errors/Saturation）→ Blameless 故障复盘文化 → 渐进式发布（Canary → Percentage → Full）
+- 结论/价值：SRE Agent 是工程团队实现 99.9%→99.99% 可用性提升的关键角色，每个 9 需要 10 倍成本投入
+
+## Key Claims（用中文描述）
+- SRE Agent 通过错误预算框架将可靠性量化为可支出资源：错误预算剩余时允许功能发布，耗尽时强制修复可靠性
+- 可观测性体系必须同时覆盖 Metrics（趋势/告警/SLO追踪）、Logs（事件调试）、Traces（跨服务请求链路）三个维度
+- Golden Signals（Latency/Traffic/Errors/Saturation）是所有监控系统的最小必要信号集
+- Toil 必须自动化而非靠人力英雄式应对：重复两次的操作必须自动化
+
+## Key Quotes
+> "Reliability is a feature. Error budgets fund velocity — spend them wisely." — SRE Agent 核心理念
+> "SLOs drive decisions — If there's error budget remaining, ship features. If not, fix reliability." — SRE 决策框架
+> "Blameless culture — Systems fail, not people. Fix the system." — SRE 文化准则
+> "Lead with data: 'Error budget is 43% consumed with 60% of the window remaining'" — SRE Agent 沟通风格
+
+## Key Concepts
+- [[Service Level Objective]]：定义服务"足够可靠"的衡量标准，包含 SLI（指标定义）、Target（目标值）、Window（时间窗口）
+- [[Error Budget]]：错误预算——SLO 未达标时间的允许额度，驱动功能发布与可靠性工作的优先级决策
+- [[Observability]]：可观测性——通过 Metrics/Logs/Traces 回答"为什么这个坏了"的能力
+- [[Golden Signals]]：黄金信号——Latency、Traffic、Errors、Saturation 四个最小必要监控指标
+- [[Chaos Engineering]]：混沌工程——在生产环境主动注入故障以发现系统弱点的实践
+- [[Toil Reduction]]：Toil 消除——将重复性运维工作系统化自动化的实践
+- [[Canary Deployment]]：金丝雀发布——渐进式（而非大爆炸式）的服务部署策略
+
+## Key Entities
+- Prometheus：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 采集）
+- Grafana：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 可视化与告警）
+- OpenTelemetry：云原生可观测性标准（SRE Agent observability stack 的 traces 和 logs 集成框架）
+
+## Connections
+- [[engineering-devops-automator]] ← complements ← [[engineering-sre]]
+- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-41-NFRs-and-Error-Budgets]]
+- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-59-Achieving-Reliability-with-Amazon-EKS]]
+- [[engineering-sre]] ← extends ← [[engineering-backend-architect]]
+- [[engineering-sre]] ← builds_on ← [[DevOps-Automator-Agent]]
+
+## Contradictions
+- 与 [[engineering-devops-automator]] 存在张力：
+  - 冲突点：自动化与人工干预的边界
+  - 当前观点（SRE）：人工 on-call 和故障复盘不可完全替代，系统故障需要人介入判断
+  - 对方观点（DevOps Automator）：通过完全自动化消除人工干预，强调 self-healing 机制
+  - 协调：两者互补而非矛盾——DevOps Automator 负责构建自动化基础设施，SRE 负责监控、错误预算决策和人工 on-call