CI/CD 与运维体系逻辑梳理（不增不减）

1. CI/CD 基本概念

• CI/CD 是由 CI (Continuous Integration 持续整合) 以及 CD (Continuous Delivery/Deployment 持续交付/部署) 两个字所组成。
• 为什么要 CI：开发不同功能时，代码可能会有冲突，而持续地整合就能及早化解冲突。

2. CI 流程内容

• CI/CD 中的 CI 流程中该包含什么： 代码格式化检查（Prettier） → 静态检查（找逻辑错误、类型问题、未使用变量、潜在漏洞。） → 自动化测试（保证业务逻辑正确性，避免回归。）

3. SRE（Site Reliability Engineer）角色与监控

• SRE (Site Reliability Engineer 又称网站可靠性工程师)
• 监控（monitoring）让工程团队能实时观察系统状态，通过收集关键指标（延迟、流量、错误率、资源使用率）及早发现问题，而不是等用户报错。
• 监控必须建立清楚的指标、设定警报阈值、定义告警等级（P0/P1 等）、对应的响应时间与解决时间，并在告警发生时快速 Ack、排查、必要时回滚并持续通报进度。
• 整体目标是提升系统稳定性，让开发者能第一时间处理异常，避免事故扩大。

4. On-call（值班制度）

• 如何值班 (on-call)：现代团队普遍采用 “You build it, you own it”，开发者必须参与值班（on-call），负责自己写的服务。
• 值班通常以周为单位轮班，并设有主值班与副值班机制来确保有人接警报。
• 当警报触发时，流程是先及时 Ack、判断是否为真实事故、同步内部与必要时同步外部、优先止损（如快速回滚）再调查根因。
• 核心原则是“先缓解影响，后找原因”，以最小化对线上用户与业务的损害。

5. 事故检讨（Incident Review / Postmortem）

• 事故检讨的目的不是找战犯，而是系统性复盘事故，厘清根因、改进流程、避免未来重演。
• 关键做法包括：聚焦“如何让问题不再发生”与“如何更早发现/更快解决”，明确记录并分享学习成果，以提升组织整体韧性。
• 高质量事故检讨必须保持“无责（blameless）”文化，专注检讨系统与流程，而不是指责个人，否则只会让工程师害怕暴露问题、降低创新与透明度，最终让组织更脆弱。

6. 功能旗标（Feature Flags）与部署风险控制

• 功能旗标（feature flags）让开发团队可以在不重新部署的前提下，对不同用户动态开启或关闭新功能，从而实现“金丝雀部署”（逐步放量）。
• 这样做能避免一次全量上线，把风险控制在小流量内；如果出现异常，可立即停止放量或回滚，将影响范围最小化。
• 它本质上是用工程手段避免人为失误（如错误配置）导致大规模事故，是现代高质量部署流程的重要组成。

7. 软件上线的多层防护流程

• 软件上线并不是“写完代码→直接部署”，而是一个由多层防护组成的完整流程。
• 团队通常会依序经历： 开发 → 内部测试（Alpha） → 狗粮测试（dogfooding） → 模拟环境测试（Staging） → 外部用户参与的 Beta 测试 → 金丝雀部署（小流量分批上线） → A/B 测试验证效果 → 全量上线。
• 核心理念是：通过逐层扩大流量、逐步验证，让潜在问题尽早暴露，把风险从一开始就限制在最小范围，从而确保上线安全、稳定、可控。

8. 可观测性（o11y / Observability）

• o11y 可观测性（Observability）让工程师在系统出问题时，不只是“知道有问题”（监控的工作），而是能快速判断“问题在哪里、为什么发生”。
• 它的本质是提高系统内部状态的透明度，就像看牙医除了知道“牙痛”之外，还需要 X 光片才能精准找出根因。
• 在现代复杂系统中（特别是多服务、多依赖的架构），没有可观测性就只能瞎猜式 debug，成本高且缓慢；因此建立可观测性是高效定位与解决问题的关键基础。