移动时代端到端的稳定性保障经验谈

1. 移动时代
端到端的稳定性保障
@唐福林 雪球首席架构师

2.  关于雪球，关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结，及一些个人的想法
大纲

3.  大而不同的投资工具
 web 1.0：新闻信息
 web 2.0：SNS 订阅，分享，聊天
 web 3.0：移动 APP，交易闭环
 风来了，风口还缺“会飞的🐷”
 知乎体：在全员都在投身「投资事业」的
公司里工作 是一种怎样的体验
关于雪球

4.  前新浪微博架构师，微博ID @唐福林
 微博短链 t.cn
 微博计数器 redis，rediscounter
 微博用户关系服务
 微博稳定性、性能改进
关于我

5.  雪球首席架构师，雪球ID @唐福林
 性能，稳定性改进
 业务无关的底层服务，基础组件建设
 团队建设
关于我

6.  关于雪球，关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结，及一些个人的想法
大纲

7.  业务方/用户期待的“稳定”
 可访问到
 耗时在可接受访问内
 想用的功能正常
 Now, or never
定义“稳定”

8.  不可抗力
 地震，海啸
 Great Cannon DDoS
 机房停电，挖掘机挖断出口光纤
 AWS/Azure/阿里云 out of service
 运营商 DNS/Http 劫持
为什么“不稳定”

9.  技术内部因素
 架构或代码缺陷
 代码或基础设施变更
 新老版本兼容
 访问模式变化
为什么“不稳定”

10.  系统可用时间多
 核心功能正常
 性能在可接受的范围内
 不可用的时间少
 n 个 9 的可用性
技术定义

11.  关于雪球，关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结，及一些个人的想法
大纲

12.  数字说话
 凡是不给出明确数字的指标要求都是耍流氓
 SLA Service Level Agreement
 http://en.wikipedia.org/wiki/Service-
level_agreement
 简单版：99%的正常请求1秒内正常完成
明确数据指标项

13.  对数据指标项的要求
 区分度高：Key Performance Indicator
 可收集，易收集
 可处理，易处理
 可使用，易使用
 项数量越少越好
用数据说话

14. 典型的访问流程
DNS
互联网 接入层 交换层
应用层 缓存层 存储层
CDN

15.  APP
 操作成功率：用户操作正常完成次数 / 用户
操作总次数
 非正常包括
 crash
 超时
 server 端报错
用数据说话

16.  APP
 困难
 怎么记录
 怎么传输
 怎么使用
用数据说话

17.  公网传输
 传输成功率：传输成功的次数 / 发起传输的
次数
 失败包括
 超时
 被劫持
用数据说话

18.  公网传输
 困难：无法准确收集
 解决：
 以客户端发起网络操作次数为准
 封装自己的客户端网络操作底层库
用数据说话

19.  接入层
 成功率：服务端成功接入的次数 / 客户端发
起请求次数
 失败包括
 机房、IDC、云服务故障
 DoS
 配置错误
用数据说话

20.  交换层
 成功率：成功返回的次数 / 接收到的总请求
数
 失败包括
 配置变更
 容量峰值
用数据说话

21.  应用层
 成功率：成功返回的次数 / 接收到的总请求
数
 失败包括
 代码或配置变更，重启，bug
 容量峰值，性能瓶颈
 依赖资源或服务超时或失败
用数据说话

22.  缓存层
 成功率？命中率！
 影响命中率的原因
 业务 key value 模式设计
 容量：MEM，CPU，带宽，QPS
 缓存组件自身设计因素导致的剔除率
用数据说话

23.  存储层
 成功率：成功存储的次数 / 接收到的总请求
数
 失败包括
 数据丢失
 服务不可用
用数据说话

24.  内网传输
 传输成功率：传输成功的次数 / 发起传输的
次数
 失败包括
 超时：毛刺，QoS，瞬断
 配置变更
 容量峰值
用数据说话

25.  内网传输
 困难
 无法收集，或无法处理数据
 发现问题后，无法定位根源，无法解决
用数据说话

26.  关于雪球，关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结，及一些个人的想法
大纲

27.  数据收集框架
 没有银弹，也没有哪个现成的开源框架能
帮助你搞定你的所有问题
 Do it yourself，with help of opensource
 Apache Flume 看起来不错，如果你问我有
没有推荐的框架的话
收集数据

28.  数据收集原则
 收集原始数据 VS 收集统计数据
 实时收集 VS 异步收集
 在能达到目的的前提下，数据量越少越好，
方式越简单越好
收集数据

29.  关于雪球，关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结，及一些个人的想法
大纲

30.  Dashboard
 目标：远远的看一眼，就知道系统现在是
好的/是有问题的
 实现：http://status.aws.amazon.com/
使用数据

31. 使用数据

32.  监控
 目标：各种指标项的当前状态，历史变化
趋势
 实现：Zabbix，Nagios，Zenoss，Cacti
 http://en.wikipedia.org/wiki/Comparison_of
_network_monitoring_systems
使用数据

33.  报警
 目标：故障发生时，实时告知技术人员
 实现：电话（IVR），短信，Email，微信
/QQ 或其它任何通知手段
 原则：
 漏报很危险
 经常误报，比漏报更危险
使用数据

34.  应用层使用
 旁路使用
 容灾测试
 紧急预案
 后台工具，管理系统
使用数据

35.  应用层使用
 直接使用
 动态开关配置系统 config service
 Smart client
使用数据

36.  确认正常
 每次故障恢复后确认
 每次报警后确认
 每次变更后确认
 每次数据发生较大变化后确认
使用数据

37.  问题跟进
 记录每次故障或问题
 记录解决过程，经验教训
 解决方案工具化，自动化
 解决方案体系化：彻底解决系统内全部类
似问题，保证以后不再出现同类问题
使用数据

38.  “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
总结

39.  稳定性保障的难点
 用数据说话的意识：没有数据就没有发言权
 公司层面重视程度：B轮以后再说稳定性
 技术实现难度：APP端的数据收集，网络/云服
务的不可控性
 过犹不及：收集的数据过多、报警过多
一些个人的想法

40.  技术人员的自我修炼
 态度第一：知道什么样子是“好的结果”，并有意
愿，主动的去追求好的结果。能力可以有差距，
但意识一定要到位。
 个人的好：更快，更炫，更漂亮，更体系化
 具体到稳定性工作上：平常工作中面向失败编
程，体系化的收集并使用数据，尽量降低对正
常业务的影响，持续关注数据指标项的变化，
解决一个问题的时候，会想着解决一类问题
一些个人的想法

41.  技术团队的自我修炼
 支持鼓励每个人追求更好，并在整体上追求好
的结果。
 团队的好：稳定可靠（简单直白），hold 住，
成本低（开发成本，交流沟通成本，维护成本，
废弃成本），行为一致，无人员单点
 具体到稳定性工作上：用最简单可靠的技术实
现功能，提前准备好各种失败预案，团队整体
技术栈统一化，工作透明化，降低沟通成本，
消除系统单点，消除人员单点
一些个人的想法

42.  个人与团队追求的统一
 差异部分的处理：控制在小范围内，不溢出到团
队范围
一些个人的想法

43.  稳定性工作没有终点，我们也正在通往稳定
的路上
 收简历 fulin@xueqiu.com
结束语

44. 聪明的投资者都在这里
Keep Calm
And
Ask Me Anything