36 KiB
运维支撑培训
提纲
运维支撑应该具备的价值观
日常工作和开发工作的关系
监控
质量意识
应急处置
故障管理
2. 概览
2.1 提出 SRE 的动力？
Cheng: 研发：随时随地发布新功能，没有阻拦； 运维：一旦正常工作，不要进行任何改动； 变更是稳定的大敌，80%的故障由变更造成；运维关注点?
2.2 SRE 聚焦问题点
确保长期关注研发工作：Google 将 SRE 团队的运维工作限制在 50% 以内，剩余的时间花在研发项目上。你需要拥有上帝视角，才能更好的解决问题。 在保障服务 SLO 的前提下最大化迭代的速度：Dev 和 Ops 不可调和的矛盾点是 [公式] 。 但是请记住，任何软件都不应该一味地追求 100% 可靠，因为大多数情况下 99.999% 和 100% 的可靠性是没有实质区别的。所以你需要「错误预算」。 错误预算的另一个好处是用一个明确的、客观的指标来决定服务在一个单独的季度中能接受多少不可靠性，用来控制调节发布速度。
Cheng: 我们似乎还没有到达到这样的阶段，但方向上是不错的，不要在某些方面的可靠性上追求100%，不管是硬件的或者软件的，因为我们的资源是有限的。而是应该思考，在合理SLO下，如何及时发现问题（监控系统和体系），发生故障后怎么办？ 当然有些系统除外，比如核电站控制系统，登月系统，导弹系统
你需要思考的是，花费巨大的精力将系统变为 100% 可靠是否能为用户带来实质意义上的好处？ 从用户终端到服务器之间有很多中间系统（用户终端、家庭 wifi、网络提供商和输电线路等）这些系统综合起来的可靠性要远远低于 99.999%。
监控系统：一个监控系统应该只有三类输出：紧急警报、工单、日志 不论是如何优秀研发人员，过多的噪音，一定会影响你对事物的判断。狼来的故事教育我们，你要在狼真的来的时候才去呼救。
应急事件处理：自愈是目标，任何需要人工操作的事情都只会延长恢复时间。要牢记：一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的可用性更高。 一个缓慢的不断重启的实例要好过一个不重启一直泄露资源的实例。
Cheng: MTTF,MTTR,MTBF所以我们可以看到 MTBF = MTTF + MTTR，因为MTTR通常远小于MTTF，所以MTBF近似等于MTTF；因此我们平时常用的衡量指标就是MTBF和MTTR。 衡量稳定性的指标明确了，那我们稳定性的目标也就明确了： 提高MTBF 降低MTTRF 重点是MTTR，初次，我说故障发现时间也很重要，MTTD(discovery)，阶段性每次关注，也许以后不用关注 建立运维手册，playbook
Cheng：关注自愈/自动化修复的幂等性。
变更管理：制定符合自己公司的强管控的变更管理策略，会是一件很有趣、很有意义的事情。比如 Google 最佳实践： - 采用渐进式的发布机制，比如灰度、滚动升级 - 迅速而准确的检测到问题的发生，失败的定义，以及如何验证和发现 - 当出现问题时，安全迅速地回滚 - 需求预测和容量规划：这两点是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。一个盈利性公司的特点是业务不会停滞不前，所以用户群一定会增长并且必然会增长。请为你设计的系统预留这部分容量，如果不能预留，也请能发现增长的趋势，及时作出应急举措。 系统不是摆设，不是死的，动态增长 - 资源部署：确保新上线的容量能够正确地服务而用户，你需要为自己的系统设计合适的上线验收策略。 - 效率与性能：高效地利用各种资源是任何盈利性组织都要关心的。SRE 和产品研发团队应该共同监控和优化整个系统的性能，这就相当于给服务增加了容量和提升了效率。
2.3.3 能否站在全局视角上看问题？
一叶障目，不辩春秋。 你需要足够熟悉自己负责的业务，但同时你也需要全局视角。一个完整的请求到底发生了什么 用户请求的处理过程：用户 -> dns -> 反向代理（负载均衡）-> 网关（鉴权） -> 业务 -> 缓存 -> DB
3. 指导思想
3.1 学会拥抱风险
「过分追求稳定性不仅限制了新功能的开发、产品交付给用户的速度，同时也很大程度的增加了成本。」
风险，定义为遭受伤害或损失的可能性。
3.1.1 如何度量服务的风险？
基于时间的可用性—— 可用性 = 系统正常运行时间 / (系统正常运行时间+停机时间) 请求成功率—— 可用性 = 成功请求数 / 总请求数 在 Google 基于时间的可用性毫无意义，Google 所采用的故障隔离手段保证在任何时候，任何地方对于一个给定的服务，总是可以处理一定的用户流量（ps 总结，有钱任性） 请求成功率的计算需要注意一点：不是所有请求都是平等的，一个新的用户注册请求失败和一个单纯的后台接口调用请求失败是不同的
Cheng: 拿WIFI举例：云管的请求失败和portal的请求失败的响应要求也是不同 所以，在我们故障处理过程中，我常常问的第一句话是，影响了多少用户，用户是那个给业务带来增长和收入的因素
3.1.2 判断服务风险的容忍度？
用户的容忍度：
- 用户可用性目标
- 用户可接受的故障类型（持续低故障率或者偶尔发生的全网中断哪一个更糟糕？）
服务自身对所依赖基础设施的要求：
- 了解所依赖基础设施的可用性目标
- 在基础设施的故障时候，是否有逃逸策略
- 尝试优化基础设施的成本
Cheng: 我们有没有测算过云基础设施的故障率，从我的个人体会看，是比较高的，HA或逃逸策略是很重要的。
3.1.2 设计合适的「错误预算」
便利店收银员在收银的时候，公司会规定一个「收银差异」，在差异内的误差金额由公司承担。而「错误预算」的作用和功能类似于「收银差异」，它的使用使得讨论发布速率更容易，同时可有效的减少任何关于事故的讨论。
为发布和稳定性之间设计一个平衡点，而这个点的体现就是「错误预算」。如果你的错误预算足够的多，你可以快速迭代发布新版本，反之，请保持基于「错误预算」的契约精神，谨慎对待每一次发布。
Cheng：错误预算的数据来自中立的监控系统。
3.2 服务质量目标
对于可靠的运维系统来说，你需要了解系统中各种行为的重要程度。Google 倾向于用不同的语义描述不同的行为，服务质量指标（SLI）、服务质量目标（SLO）以及服务质量协议（SLA）。
服务质量指标：请求延迟（处理请求所消耗的时间）、错误率（请求处理失败的百分比）、系统吞吐量（每秒请求数量）、可用性。 服务质量目标：服务某个服务质量指标的目标范围值。比如，定义搜索请求的服务质量目标为延迟小于 100ms。 SLO 的选择和公布可以帮助设立用户对于服务质量的预期，以及应对那些没有根据抱怨「服务太慢了」的行为。 服务质量协议：指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没达到服务质量目标之后的后果。
Cheng: 内部更关注SLO，内部设置的目标，驱动你的测量阈值(例如，仪表板和警报)。通常，它应该比 SLA 更严格。 例如，如果你设置了 99.9%的 SLO，那么服务可以停机的总时间如下: 30 天：43 分钟(3/4 小时) 90 天：129 分钟(~2 小时) 5个9：99.999%：5分钟 (每年)
''' 集群可用性的关键指标包含五个：集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。 集群健康度：通常使用 Healthy，Warning，Fatal 三个值来描述，其中 Warning 和 Fatal 对应告警体系，例如 P2 告警发生，那集群就是 Warning，而 P0 告警发生，那集群就是 Fatal，必须进行处理。 Pod 创建成功率：这是一个非常重要的指标，蚂蚁集团一周的 Pod 创建量在百万级别，如果成功率波动会造成大量 Pod 失败，同时 Pod 成功率下跌也是集群异常的最直观反映； 残留 Terminating Pod 的数量：有人可能会好奇为什么使用残留 Terminating Pod 的数量，而不用删除成功率？这是因为当 Pod 数量达到百万级别后，即使删除成功率达到了 99.9%，Terminating Pod 的数量也有数千，残留这么多 Pod 占用应用容量，在生产环境中是不可接受的； 服务在线率：这个指标是通过探针来衡量的，探针失败则意味着集群不可用； 故障机数量：这是一个节点维度的指标，故障机通常是指无法正确交付 Pod 的物理机，集群故障机需要做到“快速发现，快速隔离，及时修复”，否则会对集群容量造成影响。
'''
3.2.1 指标在实践中的应用
运维人员和最终用户各关系什么：只有理解用户对系统的真实需求才能真正决定哪些指标是否有用，盲目将监控系统中的所有指标都定义为 SLI 不是一个好方法。
用户可见的服务系统 : 可用性 存储系统：延迟、可用性和数据持久性 大数据系统：关系吞吐量和端到端的延迟
指标的收集、汇总、标准化
平均值 + 累计概率分布是个好建议
Cheng: 最大化的降低误报率，假阳性 - 是一种无谓的开销，去毛刺
3.2.2 目标在实践中的应用
思考用户关系的方面入手，而不是现在能度量什么入手。
目标定义：清晰具体为上 目标选择：不要仅以目前的状态为基础选择目标、保持简单、避免绝对值、SLO 越少越好、不要追求完美，SLO尽量保持简洁，好的SLO能指导团队有效优化产品，而不是做无用功 有效的控制手段：比较指标和目标，以决定是否执行什么操作 不要建立过高的用户预期：留出一定的安全区、实际SLO也不要过高。
3.3 减少琐事
3.3.1 定义琐事
琐事被定义为手动性、重复性的、可以被自动化的、突发的、没有持久价值的、与服务同步线性增长的。
Cheng: 系统的增加带来人力开销的线性增加
3.3.2 正确理解工程工作的定义
工程工作（Engineering）是一种新型的，本质上需要主观判断的工作。典型的活动主要包括： 软件工程：编写或修改代码，以及所有其他相关的设计和文档的工作。 系统工程：配置生产系统、修改现有配置，或者用一种通过一次性工作产生持久的改进的方法来书写系统文档。 琐事：与运维服务相关的重复性的、手工的劳动。 流程负担：与运维服务不直接相关的行政负担。
3.3.3 平衡
平衡琐事的比重，Google 建议琐事所占有的比例要低于 50%。 「救火很重要，但是疲于一直救火，会阻止你去思考该如何从本质上去解决问题。」
Cheng: 早期的WIFI平台，感觉一天到晚处于救火状态，大家提心吊胆，参加过第一届互联网大会重保的同事应该都有体会。原来天翼看家也是。
3.4 分布式系统的监控
如果你需要随时随地知道服务的运行状况，那么你需要构建一个适合自己业务的监控系统。知道服务运行状况的最终目的是保证服务的稳定性，确保其能更好的服务用户。
3.4.1 监控的 4 个黄金指标
延迟：服务处理某个请求所需要的时间。能够区分请求成功和失败这点很重要。 流量：使用系统中的某个高层次的指标针对系统负载进行度量。比如每秒 HTTP 请求数量等。 错误：请求失败的速率，显示、隐式、或者是策略性导致的失败。 饱和度：系统中某种受限资源的具体度量，比如 CPU 、内存等。 监控中度量指标不是目的，需要为所度量指标设置合适的阈值，以期在指标不符合预期的时候，能迅速做出反应，缩小影响范围，这才是重点。
Cheng：如果有大量的监控结果需要主观判断分析和复杂响应，设计不佳，应重构，好的告警，应该能够直击问题，从而快速响应。 Cheng: 思考监控度量指标的精度、分组、汇总处理等。
p56 -- 监控系统应该回答的问题
Cheng: 监控指标简化，不常用的（比如一个季度没有用到）移到候选区。
p51: 我们会避免任何“魔法”系统--例如试图自动学习阈值或自动检测故障原因的系统。。。。我们坚持监控系统规则越简单越好，同时要求这些监控规则可以检测到某个非常简单、具体，但是严重的异常情况。用于容量规划、流量预测等方面的监控规则可以稍微复杂一些。
Cheng：按这样的标准AIOps成了反模式???
健康检查 健康检查有两种模式：由外向内的健康检查，验证服务是否正在运行，并确定服务的响应时间/延迟；由内向外的健康检查，跟踪应用程序和系统指标，可以在事故发生前发现潜在的问题(包括性能问题)。 模式1 由外向内的健康检查 正常运行时间（Uptime） —— 这个指标回答了一个由来已久的问题，“我的服务是否在运行，是否在做应该做的事情?”健康检查程序 ping 了待查服务后，如果收到了响应，就说明服务启动了，如果没有响应，就意味着需要开始补救工作 用户感知的时延（User-perceived latency） —— 我们必须从全球多个位置检查服务时延。例如，从日本访问服务的用户感知的时延可能与从西班牙和美国访问服务的用户感知的时延不同。可以使用健康状况检查 API 调用的时延作为用户感知时延的代表。 上述两组的组合还可以作为服务的综合可用性信号。
Cheng: 支撑验证就属于这类 模式2 由内而外的健康检查 那么应该关注哪些应用程序指标呢？至少收集以下四种信号。 请求率 —— 服务有多忙？ 错误率 —— 服务中是否存在任何错误？如果有，有多少个，多久发生一次？ 请求时长 —— 服务响应请求需要多长时间？ 饱和度 —— 服务有没有超载？还有多少增长空间？ Cheng: 比如看家的S3的使用情况，IOPS的情况【IOPS测算？】，队列的饱和度 饱和度趋势预测
反模式: 使用日志对指标建模 使用日志数据对度量建模开销很大(意味着需要花更多的钱)，并且增加了提取、处理和反馈的时间，从而增加了 MTTD(平均检测时间)，这两种后果都不可接受。
告警反模式
- 不要依赖人工观察。 随着系统规模和复杂性的增加，我们不能依赖人工 24/7 的盯着监视器来查看服务运行状况趋势，并在超过阈值时呼叫某人来解决问题。我们需要依靠机器和算法，在出现问题时通知我们主动触达，这也能够排除人为错误，并尽可能将过程自动化。+自愈
- 并非所有告警都是等价的。 不要以相同的方式对待所有告警，将服务中的每个小问题都作为告警发送电子邮件/Slack 通知只会导致垃圾邮件泛滥，并大大降低信噪比。对于每一个可能导致客户问题/违反 SLA(关键问题)的服务问题，都需要呼叫工程师(使用类似 PagerDuty 的东西)进行处理，其他所有内容都应该作为问题单记录，或者作为日志记录。降低假阳性比例
Cheng: 云宽带监控的假阳性
3.4.3 降噪
过多监控会带来负面效应，对比一天收到几条和几百条监控你的前后变化，会发现这是一件「被人忽略，但是收益很高」的事情。
Cheng: 告警过多/告警风暴=没有告警
Cheng：打补丁 vs. 根本修复，打补丁可以为根本解决争取时间，但会形成技术债务。
3.5 Google 的自动化系统的演进
3.7 简单化
3.7.1 系统的稳定性与灵活性
3.7.2 乏味是一种美德
3.7.3 我绝对不放弃我的代码
3.7.4 「负代码行」作为一个指标
3.7.5 最小 API
3.7.6 模块化 + 发布简单
4. 具体实践
4.1 基于时间序列数据进行有效的报警
4.1.2 报警
从日常生活中来看，我们报警，是因为遇到了需要警察帮忙才能解决的问题，系统的报警也应该如此。频繁报假警的会被处罚，对于一个具有仲裁机制的监控系统来说也应该如此，对于那种多次发出报警但是没有人响应的报警，删除它或许不是一件坏事情。 「提升专注力是一件好事情，可有可无的东西请统统忽视它。」
4.2 应急事件的处理
4.2.1 on-call 轮值
on-call 是一种手段，目的是为了保障服务的可靠性和可用性。为了 on-call 的工程师能够快速的解决问题，平衡 on-call 工作是一个很好的建议。
从数量上平衡：SRE 团队 50% 的时间花在软件工程上，在其余的时间中，不超过25%的时间用来on-call 211法则：50%软件工程；25%on-call；25%其他日常运维；该法则下，25%时间用于on-call，要满足7x24小时on-call轮值制度，至少要8个SRE。
Cheng: 我们实践：25%on-call很多内容是由支撑承担（书中体系没有支撑团队&监控团队的概念，告警直接响应给运维）。 3层过滤，1层统一监控，2层支撑人员，3层才到运维 面向终端用户，建议非常紧迫的服务5分钟内响应，非敏感业务30分钟。
从质量上平衡：每12个小时的轮值最多只能处理两个紧急事件。 避免「过度联想」和「习惯性思维」。 事物的本质很少呈现表象上。脱脂牛奶也可以假装护肤霜。
Cheng：合理安排，保持适度压力，避免过度疲劳 on-call资源：
- 清晰的问题升级路线
- 清晰定义的应急处理步骤
- 无职责，对事不对人的文化氛围
4.2.2 有效的故障排查手段
系统正常，只是该系统无数异常情况下的一种特例。 —— John Allspaw （ps 这句话和「幸存者偏差」理论都很让我震惊）
事后: 故障复盘的核心：从故障中学习和提升！ 故障复盘的教训：故障根因往往不止一个，聚焦引起故障原因都是哪些，是否都有改进空间。 故障复盘的心得：解决问题，而不是不断提出新的问题！ 1、故障复盘三问 1）第一问：故障原因有哪些？ 2）第二问：我们做什么，怎么做才能确保下次不会出现类似故障？ 3）第三问：当时如果我们做了什么，可以用更短的时间恢复业务？（这点非常重要） 注意事项：对事不对人，不允许出现互相指责和埋怨甩锅。故障复盘的核心是找到原因并加以改进，落地优化。 2、故障判定的三原则 1）健壮性原则：每个组件自身要具备一定自愈和高可用能力，而非全部由下游依赖方兜底； 2）三方默认无责：对内谁受影响谁改进，对外推进第三方改进(稳定性要做到相对自我可控，而不是完全依赖外部)； 3）分段判定原则：对于原因较复杂或链路较长的故障，建议分段评估，不同段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。
CG：确定了一个问题根源时，应该将系统问题位置，如何定位，如何修复，如何防止，待办事项总结下来。
4.2.2.1 理论
故障排障过程被定义为反复采取假设-排除手段的过程。大致就是通过观察系统的监测指标和日志信息了解系统目前的状态。再结合我们对于系统构建的原理、运行机制，以及失败模型的了解，提出一些可能的失败原因。
4.2.2.2 实践
书写系统的故障报告是个好习惯，系统故障报告里要写清楚：
- 系统预期是什么
- 系统实际的结果是什么
- 如何重现故障
- 如何修复故障等 报告问题 -> 定位 -> 检查 -> 诊断 -> 测试和修复 这个一个完整排障的链路。
p120 高等级故障，你的第一反应可能是立即开始故障排查过程，试图尽快找出问题根源，这是错误的！不要这样做。 定位问题的过程中，最重要的不是排障，是如何尽最大可能让系统恢复服务。 定位问题时，应及时保存问题现场，比如服务器日志，以便以后进行根因分析。
Cheng: 5WHY，不停问问题，最近的一次私有化监控故障为例。 现象：用户局部间歇性不可用。 W：能否应急？如何快速恢复业务？（这一问题与故障的等级有关） W：与哪些平台相关？各平台有没有故障？Action：检查平台。 W：网络有没有故障？Action：抓包分析，有出包，回包部分丢失。 => 网络问题（假设） => 验证 W：包在哪里丢失？Action：上联SPINE进一步抓包，定位
总结：
-
- 不可经验武断；疑难故障的排查是一系列的假设+验证；网络问题的假设没有错，结论显示判断结果有错，实际上并不是上联设备配置问题导致丢包，而是下联设备的IP配置问题。
-
- 事后总结（验尸报告-postmortem） CG：确定了一个问题根源时，应该将系统问题位置，如何定位，如何修复，如何防止，待办事项总结下来。 morgue
Cheng： 做的好的？做的不好的？
- 监控是不是发现、及时、到位？误告警？
- 应急响应有没有发挥作用？有没有可以完善的地方？
- 远程不可访问了怎么办？带外访问通道？
关注最近一次变更
4.2.3 紧急事件响应
东西早晚要坏的，这就是生活。
Cheng：紧急事件必定是不常发生，不常处理之事，必不擅长。所以要建立应急流程，并不断演练熟悉。
4.2.3.1 当系统出现问题时怎么办？
测试导致的紧急事故：chaos engineer，停止测试，恢复数据 变更部署带来的紧急事故：回滚
Cheng: 三个案例值得运维支撑的同学学习
所有系统不但一定会出问题，而且会以没有人能想到的方式出现问题。所有的问题都会有对应的解决方案。
4.2.3.2 向过去学习，而不是重复它
Cheng：
- 为事故保留记录，历史就是学习其他人曾经犯过的错。所以，故障总结要能够复盘，才能变成资产，否则是摆设。
- 提问脑补，甚至那些大的、不可能的问题。比如云宽：
- vsw故障怎么办？vcpe故障怎么办？bras故障怎么办？
- 整个DC有问题怎么办？
- 系统被流量攻击怎么办？
- 系统负载突然提高超出规划容量怎么办？
- 鼓励主动测试，对提出的问题，制造场景来演练。chaos
4.2.4 紧急事故的管理
如果事前没有对可能发生的紧急事故进行演习，事故发生时，一切管理理念都不起作用。
嵌套式职责分离： - 事件总控：组织，协调 - 事件处理团队：执行，解决，由实际处理人组成 - 发言人：向相关方发布故障处理进展，确保相关方都知道事故处理进展 - 规划负责人：为处理团队提供支撑工作？bug记录、职责交接安排、处理过程特殊操作的记录等
通知中心：受到事故影响的部门或者负责人需要实时跟事故总控负责人联系 实时事故状态文档：确保关联的每个人知道事故的进展 明确公开的职责交接文档：确保后续处理的人能够最快投入处理
Cheng：以上职责至少需要，总控、处理团队、发言人；总控和发言人可以合设。以前要求高等级故障集中处理，鼓励面对面集中处理（war room），考虑到跨团队和故障发生时间等因素，看起来是有难度的，至少确保以上职责人员紧密连线、信息共享、及时跟进。可以“拉群”讨论处理，IRC。 故障演习，团队贯穿，内外部
4.3 事后总结和问题根源分析
4.3.1 事后总结：从失败中学习
Google 事后总结的哲学：协作和知识共享，建立事后总结文化。
事后总结的主要目的是为了保证事件被记录下来，理清所有的根源性问题，同时关键的是，确保实施有效的措施使得未来重现的几率和影响得到降低，甚至避免重现。 事后总结不是一种惩罚措施，而是整个公司的一次学习机会。
SRE中最重要的是「对事不对人」的事后总结不应该简单地指责或者抱怨某个团队，而应该确实提出服务如何能够获得进步。
Cheng： 总结的条件：
- 二级及以上故障
- 数据丢失
- on-call需要人工介入的回滚、流量切换等
- 解决耗时过长的
- 监控问题（人工发现，而非告警发现）
Cheng： 开放的评论系统，透明化的共享机制 postmortem模板 拥抱故障，卓越运维
4.3.2 跟踪故障
提高可靠性的唯一方法论是建立一个基线（baseline），同时不断跟踪改变，Google 使用 Outalator——一个故障跟踪分析工具来做这件事情。
该系统可以获得如下信息：
- 每次 on-call 轮值发生的报警次数是多少
- 上个季度中可操作的报警和不可执行的报警的比例是多少
- 哪个消耗的人工最多等
- 能够对历史数据进行定量的分析，找出可优化的方向，这些是将来可改进的基本点 。
4.4 测试
chaos
4.5 容量规划
4.5.4 应对过载
Cheng：自适应节流，学过自动控制的知道一个负反馈的东西很类似，基于请求拒绝数量来衡量是否过载，客户端调节请求量，好处是减少系统开销 Cheng：记录重试次数，重试直方图p219，重试比例高，直接返回，无需重试 如果请求没有成功，以指数型延迟重试 流量抛弃和优雅降级：学会避免处理那些不值得处理的请求 服务降级是研发架构的事情，还是运维思考的事情？
4.6 软件研发
4.6.4.2 Google SRE 保障数据完整性的手段
SRE 假设任何一种数据保护机制都可能在最不合适的时间出现问题，同时没有一种银弹可以同时保护所有事故类型，所以需要分级进行。 完美的理论不代表实现也是完美的。
Cheng:
- 备份 vs 存档 存档：审计、取证、合规，恢复时间不是最重要的考量因素 备份：快速恢复，最少丢失
- 不断演习，关键不是备份，是恢复。确保N时间恢复 -> 将N不断逼近0
4.7 产品设计
4.7.1 可靠地进行产品的大规模发布
还记得前面说过的发布工程师嘛？嗯，我觉得除了像 Google 这么大体量的公司以外，很多公司应该都没有这个岗位吧…… （ ps 突然想起了全局架构组，感觉好像有点类似的样子)
Cheng：
- 好的发布流程，需要反复实践来提升速度和可靠性。
- 谁来组织发布？研发？运维？很多公司由SRE或研发人员兼。
大的软件公司，LCE（launch coordination engineering）发布协调工程师干这个事，这个挺清晰：
- 审核，gate，提供发布可靠性的建议
- 协调
- 跟进，发布过程的所有技术问题
- 反馈
- 总结最佳实践，给SRE和开发提供发布培训 我们是支撑兼了这个角色，支撑为什么可以牵头组织上线？
- 审核、协调、跟进、反馈都是可以的，但程度较浅。理念要有
- 支撑是第三方，跳出运维和研发。
- 流程就是流程，支撑不深入运维和研发细节，有利于客观的执行流程。
- 支撑是内外桥梁，熟悉应用本身和常见故障的处理，上线后可以更好的做UAT。
- LCE，经验/跨职能的视角/客观性，流程考虑可靠性，往往和效率矛盾，不断优化发布流程。
4.7.1.1 起草一个发布检查列表
容量规划：容量规划与冗余度和可用性都有直接关系 故障模式：是否是单点，依赖服务不可用如何处理 外部依赖：是否依赖三方代码，是否有合作伙伴依赖你的服务，发布时是否周知他们等 。。。。
Cheng: 分析发布的每一步，问可能故障的备用方案。 所有发布是灰度或金丝雀的，每一批量都有自动验证步骤。制定灰度策略：如几台机器 - 某个数据中心 - 全球全部服务器。 A 比如云宽灰度策略：内部体验用户 - <100个用户小批量验证（3-7天） - 2000用户（3-7天）- 8000用户单网元满载（7天） - 半个DC - DC
4.7.1.2 可靠发布所需要的方法论
Cheng:
长期常规工作，认识不够，无法改变或优化 对问题视而不见，拒绝优化
Cheng:
- 制定SLO
- 找到2、3件永久性解决问题的工作
- 发现问题(面临最后期限压力时的第一个受害者) - 写入错误报告/团队文档
- 坚持解释你的逻辑推理
- 良好的文档目的是确保团队在一个新的情况下不会重复旧的错误
规范的作用： 即使大家出发点是好的，人们总会默认或倾向于选择阻力最小的路径，这些最小路径可能没法让人绕开陷阱。 规范的作用恰恰是为绕开这些陷阱设置的指南。 我们学过网络协议应该知道，传输过程中要设置很多冗余位，做什么用，纠错！网络介质常常会有不可靠的时候，用开销来检查或防止错误。 人也一样，常常有不可靠的时候，怎么办，就需要有规范约束，对于成熟的生产过程减少发散性。 本质上，规范是让你走既定的路线，减少思维发散，是不利于创新的，所以不能过度，过度造成组织固化，但必要的制度和规矩对于组织管理还是必须的。
此外，流程尽量能够固化到工具上，而不是通过手工指挥棒，人工的指挥棒执行过程中容易过度和变形。
把on-call工作融入到SRE职责中，SRE只有融入日常on-call，才会有自动化改进动力，体会帮自己干活。 注意：on-call时间占比不能太高，不能以淹没运维开发工作为代价，on-call类似体验生活 < 50% 最可用的工具通常是那些每天使用他们的人写成的。
把chaos融入故障演练中。
建立实时的事故状态文档，事故总控人最重要的职责就是维护事故的实时文档。最好可以多人同时编辑。关注共享范围。
一些总结
概念：
- 故障预算：故障预算的概念是思考问题方式的改变，有故障预算表示故障是不可避免的，故障是创新过程的一个部分。确保在保证SLO下的最大迭代速度。可靠性指标与投入呈指数分布关系，你需要思考的是，花费巨大的精力将系统变为 100% 可靠是否能为用户带来实质意义上的好处？
- MTTR，MTTF，playbook
变更管理必须思考的关键问题：
- 灰度方案？用户影响最小化
- 问题检测？第一时间捕获失败
- 回退方案？预设失败怎么办
- 其次才是其他非功能性特性，安全、容量、效率、利用率、性能。。。
SRE文化特质&理念：
- 天然排斥重复性、手工操作
- 崇尚技术能力，快速开发替代手工操作
- 应急事件处理：自愈是目标，任何需要人工操作的事情都只会延长恢复时间。要牢记：一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的可用性更高。 一个缓慢的不断重启的实例要好过一个不重启一直泄露资源的实例。
- 以事后总结为荣，无论有没有触发告警
- 对事不对人
- 过多告警等于没有告警
- 无效备用不如没有备用
- 你看到的跟我看到的世界虽然是同一个，但是感受却截然不同。 作为用户，我看到的只是一个可用的系统，这个系统能够完成我需要的功能。我不需要知道背后的原理。 作为研发，除了功能外，你需要做到能够快速理解底层的实现。能够看到截然不同的世界，我觉得这是很有趣的事情。
- 开发里的方法论同样适合：不要重复造轮子。在巨人的肩膀上，才有可能看的更高，所以不要重复造轮子，而是学会基于轮子去造车。
- 希望不是一种策略，hope is not a strategy，理性思考。故障的容忍度、测试的深度、发布频率、金丝雀持续的时间等，这些决定不应该受办公室政治、不理智的恐惧、一厢情愿的希望所驱使。
- 拥抱风险，拥抱变化
- 思考从根本上解决问题，「救火很重要，但是疲于一直救火，会阻止你去思考该如何从本质上去解决问题。」 扩容扩容扩容，重启重启重启
- 如果系统正常运行中需要人工干预，应该将此视为一种bug。正常的定义会随系统进步而改变。
- Cheng：如果有大量的监控结果需要主管判断分析和复杂响应，设计不佳，应重构，好的告警，应该能够直击问题，从而快速响应。
- Cheng: 切记故障处理原则，先抢通，再修复
- 你的公司是否拥有无指责的文化，专注于真正的根源并解决系统性的问题，或者你们的公司文化是“责备和羞耻”的文化，出错时人们会因此受到惩罚？
- 持续改进。
- 可靠性是最基本的功能。
- 痛苦的事情频繁做，故障演练不是走过场。
孙子兵法有云：为将者，未虑胜，先虑败
注意：任何运维故障，运维的领导必须是第一个知道的人，如果他从别的人或者部门中知道这个故障，那么就很被动，而且是故障处理人失职表现。
事后总结
先形成事后总结的习惯，进一步得到要求是在事后总结总获得进步，而非例行公事
条件
- 二级及以上故障
- 数据丢失
- on-call需要人工介入的回滚、流量切换等
- 解决耗时过长的
- 监控问题（人工发现，而非告警发现）
内容：
- 基本信息：发生时间，跟踪人等
- 事故影响
- 根因分析
- 触发条件
- 解决方案
- 待办事项
- 经验教训
- 做的好的
- 需要改进的
- 时间线
- 标注出发现时间
运维支撑职责：
- 可用性改进
- 延迟优化
- 性能优化
- 效率优化
- 变更管理
- 监控
- 容量规划和管理
- 紧急事务
轮值on-call:
- on-call度量
- 每个工程师呼叫响应数量
- 每个工程师被呼叫时间间隔
- 非工作时间接收量
- 团队每周>1，负载过高
- 应该解决的问题
- on-call团队成员如何轮转？
- 每次轮转持续多久？
- 某个工程师没响应会发生什么？
- 某个工程师无法胜任怎么办？
- 同时有几个工程师处于on-call状态？
- 多名on-call工程师如何分工？
- 如何处理不可预见的事故？
- 目标：
- 一个成功的事故响应系统的目标很简单 - 先于客户影响前发现事故，最理想的情况是发现并修复它。
- so,必须有监控和告警
- 故障：该策略强迫我们停止对该服务的任何新工作，直到我们修复导致该事故发生的根本原因或提出相应的减缓措施。 - 拉灯
- on-call手册
支撑组织：
- 建立一线、二线甚至三线支撑团队，一线一般为7x24小时值班的人员；
- 二线一般是资深工程师，或者是对应的应用开发/测试同学；
- 三线一般是主管或者是外部的厂家，如涉及硬件、IDC机房等相关服务方。
我们运维支持，不再谈论公司中有多少独立项目，而是在谈论如何让所有人参与。 通过使用整个公司相同的工具和技术来完成。