✏可用性

doc/软件工程/容量保障.md

@@ -3,6 +3,26 @@
 - 容量规划：以尽可能小的成本确保系统当前和未来的容量充足
 - 容量治理：解决已知的容量问题，预防未知的容量问题
 
+## 容量管理
+
+![](/assets/202492194154.webp)
+
+容量水位：
+  - 业务容量水位：指的是系统中业务负载与业务容量之间的比率，计算公式为：业务容量水位 = 当前承载的请求量（事务量）/ 能承载的最大请求量（事务量） * 100%。这一指标主要衡量整个服务链路的流量，从用户接入到后端数据库。
+  - 资源容量水位：指的是系统中具体资源的使用情况，计算公式为：资源容量水位 = 当前消耗的资源量 / 总体可用的资源量 * 100%。这一指标关注的是CPU、内存、I/O等资源的使用情况，以识别潜在的资源瓶颈。
+
+容量观测：
+
+系统容量的实时监控和长期趋势预测。通过实时的容量监控大盘和定期的容量巡检，可以密切关注系统的水位状态和关键性能指标，及时发现并处理如性能退化和流量上升等问题。此外，容量管理平台和压测平台也是容量观测的重要工具，分别用于数据累积、管理和系统压测
+
+容量分析：
+
+评估当前资源是否满足需求、制定资源补充策略以及确定资源补充的时间节点。这一过程需要结合动态规划和最优化理论等数学模型，深入分析系统的服务特性，构建服务画像，并基于这些分析来制定精准的资源补充计划
+
+容量处置：
+
+指在系统容量不足时采取的应对策略，包括增加资源、内部调度、限流丢弃、功能降级和缓存优化
+
 ## 量化指标
 
 ### SLA

doc/软件工程/架构/系统设计/可用性.md

@@ -29,6 +29,26 @@ level: 1
 - CP：
 - AP：分布式架构
 
+## 变更管控
+
+变更前：
+
+- 详细记录：记录变更的具体内容，包括更新的代码模块、变更执行者的信息，以及是否完成了QA测试。如果测试被跳过，必须说明原因。
+- 风险评估：评估变更可能对系统的影响，特别是功能和资源使用量的变化。确保评估尽可能准确。
+- 制定回滚计划：准备详细的回滚计划，以应对变更后可能出现的问题。回滚计划应包括配置、代码或数据的回滚步骤，尤其是在涉及数据变更时提前备份数据
+
+变更时：分级发布，将变更细化为多个阶段，逐步对特定服务实例或可用区进行操作，以降低整体风险
+
+- 变更顺序：按可用区依次进行，不要并行操作。当一个可用区出现问题时，可以快速切流到另一个可用区。
+- 变更检查：在每个阶段结束后进行严格的变更检测，关注可用性、延迟、资源消耗等指标。
+- 变更干预和处置：一旦发现异常，立即阻断变更，视情况采取单实例摘除、切流或回滚的措施
+
+变更后：检查关键指标，确保变更没有引发问题
+
+- 自身服务状态指标：监控调用成功率、响应延迟和CPU使用情况等服务健康状况。
+- 业务核心指标：确保变更不会对其他依赖服务产生负面影响，关注业务指标波动。
+- 上下游关键指标：监控上下游服务的调用频率、延迟和性能指标，防止因变更引发的流量激增导致服务超载
+
 ## 数据逻辑保护
 
 大部分影响可用性的原因是人为操作的失误