其他
从故障中学习:稳定性设计和管理实践探索(下)
弹性工程-探索未知的未知
什么是弹性工程?
弹性工程与运维
对系统中的组件进行监控 利用机会表现自己(非贬义) 预测事故发生概率 事故和故障响应 预估未来运行情况 学习系统特性
监控Monitoring 响应Reacting/Responding 预测/适应Anticipating/Adapting 学习Learning
我们给系统定义清晰的边界、层级和范式 系统有自保措施 系统资源有足够冗余 系统有安全防护措施 最佳实践和验证有确保机制 系统组件有最终责任制
经受得住瞬时冲击 快速平滑从失败中恢复 优先处理高优先级任务 识别并应对异常情况 适应外部环境的变化
团队组织
服务生命周期
以人为本
度量:团队必须就做哪些事情可以提高用户满意度并消除与用户满意度无关的报警达成共识。使用SLO(Service Level Objectives)度量用户满意度,应当选取能代表用户满意度的边界指标来定义SLO,例如业务错误率,产品策划和客服通常很清楚这一点,要知道复杂系统总工作于部分降级模式,因此拿内部指标来衡量SLO并没有意义。实际上这有点类似于我们常说的业务监控,只是SLO只强调用户受损程度。通过SLO建立与用户反馈闭环对一个产品来说至关重要,这是发现问题的关键因素。我觉得SLO不仅仅局限于服务端,还应延展到用户侧客户端,毕竟客户端代表最终用户。
可观察性:团队对线上健康度的感知必须始于用户症状,而不是潜在原因。重视故障定位。如果没有底层报警,如何得知SLO报警的问题原因是什么?我们需要故障根因定位能力,通过日志、指标构建全链路trace等可观察性工具来关联内部状态,仅测量并收集所有数据但却不分析数据不会对业务产生价值,场景化的分析和可视化至关重要。
协作:团队必须确保彼此合作互相分享知识,并且能培训新成员。只定义好SLO并打造一系列监控报警工具并不会保证系统的连续性。最终需要人去运行系统、调试系统,并且随着系统迭代和新组件的引入,需要保持不断学习才能获得持续的系统洞察力。培训计划很重要,最常见的就是详尽的事故调查记录和事故总结。开发owner自己的服务并不是营造一个信息孤岛,而应保持开放,允许团队成员与团队外成员都可以提问题,只有这样才能进一步理解事故本身,并且更全面了解不同人针对事故的观点。跨团队的协作沟通不仅仅包含上下游关系,还可以包含多个职能角色,例如客服、开发和SRE。
风险分析:团队需要一个框架来确认风险修复的优先级别,使系统可靠度满足用户需求。提前预测并解决系统风险,识别并应用最佳实践形成稳定性解决方案,不断预知并化解风险。
中心化团队
事故原因是什么? 如何避免事故?是否遵循了稳定性最佳实践?如果遵循了稳定性最佳实践,是否可以避免本次事故? 避免事故需要做哪些跟进工作? 有没有可以提升故障排查速度的点? 有没有能使事故影响面变得更小或者影响时间更短的工具? 这个事故以前发生过么?是不是一种事故典型? 事故处理过程中有没有错误决策导致事故影响时间变长或事故影响面变大?