软件工程 · 小纸条

核心：runbook把症状、诊断、缓解、验证和升级路径写给压力中的值班者；规则：高频且确定的步骤优先自动化，但自动化保留权限、审计和停止开关；应能围绕“连接池耗尽手册先确认影响，再查请求堆积与下游，限制流量后验证恢复”交付可复核制品。

核心：上线前不仅看功能，还看容量、安全、观测、值班、恢复和依赖；规则：每项门禁要有可读证据与接受风险的人；清单勾选不能替代演练；应能围绕“新服务提交SLO、仪表盘、告警、runbook、容量压测、威胁模型和回滚记录”交付可复核制品。

核心：云成本是架构反馈，应与业务价值、利用率和可靠性联合优化；规则：优化前建立单位成本和性能基线，优化后确认未把成本转移给可靠性或人工；应能围绕“把每千次报告成本拆为计算、存储和出口，发现无人读取的高频预计算”交付可复核制品。

核心：高耦合变更需要共享依赖、冻结窗口和沟通，但协调不能变成大批量借口；规则：协调聚焦不可独立的风险；能用契约和渐进交付解耦的部分继续小批量；应能围绕“结算、财务和客服共同安排账期迁移，先做兼容部署并明确负责人”交付可复核制品。

核心：删除旧系统需证明消费者迁移、数据处置、审计保留和回退窗口结束；规则：退役完成包括流量、数据、基础设施、凭证、告警、文档和成本全部清零；应能围绕“旧API先发使用清单与截止日，提供迁移工具，监控零调用后撤销权限和密钥”交付可复核制品。

核心：债务应按利息、风险、阻塞范围和偿还成本排序，而不是按抱怨热度；规则：用事故、等待、缺陷和变更成本量化利息；偿还任务进入正常组合；应能围绕“脆弱部署脚本每月造成两次失败且阻碍发布，优先于很少变化的旧命名”交付可复核制品。

核心：团队定期联合观察交付、质量、可靠性、安全和体验，选择少量系统改进；规则：指标用于提问和实验，不直接奖惩个人；所有改进声明预期影响与复查日期；应能围绕“每月用趋势讨论前置时间、逃逸缺陷、SLO、漏洞修复和开发者等待”交付可复核制品。