Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
移动时代
端到端的稳定性保障
@唐福林 雪球首席架构师
 关于雪球,关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结,及一些个人的想法
大纲
 大而不同的投资工具
 web 1.0:新闻信息
 web 2.0:SNS 订阅,分享,聊天
 web 3.0:移动 APP,交易闭环
 风来了,风口还缺“会飞的🐷”
 知乎体:在全员都在投身「投资事业」的
公司里工作 是一种怎样的...
 前新浪微博架构师,微博ID @唐福林
 微博短链 t.cn
 微博计数器 redis,rediscounter
 微博用户关系服务
 微博稳定性、性能改进
关于我
 雪球首席架构师,雪球ID @唐福林
 性能,稳定性改进
 业务无关的底层服务,基础组件建设
 团队建设
关于我
 关于雪球,关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结,及一些个人的想法
大纲
 业务方/用户期待的“稳定”
 可访问到
 耗时在可接受访问内
 想用的功能正常
 Now, or never
定义“稳定”
 不可抗力
 地震,海啸
 Great Cannon DDoS
 机房停电,挖掘机挖断出口光纤
 AWS/Azure/阿里云 out of service
 运营商 DNS/Http 劫持
为什么“不稳定”
 技术内部因素
 架构或代码缺陷
 代码或基础设施变更
 新老版本兼容
 访问模式变化
为什么“不稳定”
 系统可用时间多
 核心功能正常
 性能在可接受的范围内
 不可用的时间少
 n 个 9 的可用性
技术定义
 关于雪球,关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结,及一些个人的想法
大纲
 数字说话
 凡是不给出明确数字的指标要求都是耍流氓
 SLA Service Level Agreement
 http://en.wikipedia.org/wiki/Service-
level_agreement
 简单版:9...
 对数据指标项的要求
 区分度高:Key Performance Indicator
 可收集,易收集
 可处理,易处理
 可使用,易使用
 项数量越少越好
用数据说话
典型的访问流程
DNS
互联网 接入层 交换层
应用层 缓存层 存储层
CDN
 APP
 操作成功率:用户操作正常完成次数 / 用户
操作总次数
 非正常包括
 crash
 超时
 server 端报错
用数据说话
 APP
 困难
 怎么记录
 怎么传输
 怎么使用
用数据说话
 公网传输
 传输成功率:传输成功的次数 / 发起传输的
次数
 失败包括
 超时
 被劫持
用数据说话
 公网传输
 困难:无法准确收集
 解决:
 以客户端发起网络操作次数为准
 封装自己的客户端网络操作底层库
用数据说话
 接入层
 成功率:服务端成功接入的次数 / 客户端发
起请求次数
 失败包括
 机房、IDC、云服务故障
 DoS
 配置错误
用数据说话
 交换层
 成功率:成功返回的次数 / 接收到的总请求
数
 失败包括
 配置变更
 容量峰值
用数据说话
 应用层
 成功率:成功返回的次数 / 接收到的总请求
数
 失败包括
 代码或配置变更,重启,bug
 容量峰值,性能瓶颈
 依赖资源或服务超时或失败
用数据说话
 缓存层
 成功率?命中率!
 影响命中率的原因
 业务 key value 模式设计
 容量:MEM,CPU,带宽,QPS
 缓存组件自身设计因素导致的剔除率
用数据说话
 存储层
 成功率:成功存储的次数 / 接收到的总请求
数
 失败包括
 数据丢失
 服务不可用
用数据说话
 内网传输
 传输成功率:传输成功的次数 / 发起传输的
次数
 失败包括
 超时:毛刺,QoS,瞬断
 配置变更
 容量峰值
用数据说话
 内网传输
 困难
 无法收集,或无法处理数据
 发现问题后,无法定位根源,无法解决
用数据说话
 关于雪球,关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结,及一些个人的想法
大纲
 数据收集框架
 没有银弹,也没有哪个现成的开源框架能
帮助你搞定你的所有问题
 Do it yourself,with help of opensource
 Apache Flume 看起来不错,如果你问我有
没有推荐的框架的话
收...
 数据收集原则
 收集原始数据 VS 收集统计数据
 实时收集 VS 异步收集
 在能达到目的的前提下,数据量越少越好,
方式越简单越好
收集数据
 关于雪球,关于我
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
 总结,及一些个人的想法
大纲
 Dashboard
 目标:远远的看一眼,就知道系统现在是
好的/是有问题的
 实现:http://status.aws.amazon.com/
使用数据
使用数据
 监控
 目标:各种指标项的当前状态,历史变化
趋势
 实现:Zabbix,Nagios,Zenoss,Cacti
 http://en.wikipedia.org/wiki/Comparison_of
_network_monitor...
 报警
 目标:故障发生时,实时告知技术人员
 实现:电话(IVR),短信,Email,微信
/QQ 或其它任何通知手段
 原则:
 漏报很危险
 经常误报,比漏报更危险
使用数据
 应用层使用
 旁路使用
 容灾测试
 紧急预案
 后台工具,管理系统
使用数据
 应用层使用
 直接使用
 动态开关配置系统 config service
 Smart client
使用数据
 确认正常
 每次故障恢复后确认
 每次报警后确认
 每次变更后确认
 每次数据发生较大变化后确认
使用数据
 问题跟进
 记录每次故障或问题
 记录解决过程,经验教训
 解决方案工具化,自动化
 解决方案体系化:彻底解决系统内全部类
似问题,保证以后不再出现同类问题
使用数据
 “稳定”的定义
 明确数据指标项
 收集数据
 使用数据
总结
 稳定性保障的难点
 用数据说话的意识:没有数据就没有发言权
 公司层面重视程度:B轮以后再说稳定性
 技术实现难度:APP端的数据收集,网络/云服
务的不可控性
 过犹不及:收集的数据过多、报警过多
一些个人的想法
 技术人员的自我修炼
 态度第一:知道什么样子是“好的结果”,并有意
愿,主动的去追求好的结果。能力可以有差距,
但意识一定要到位。
 个人的好:更快,更炫,更漂亮,更体系化
 具体到稳定性工作上:平常工作中面向失败编
程,体系化的收集...
 技术团队的自我修炼
 支持鼓励每个人追求更好,并在整体上追求好
的结果。
 团队的好:稳定可靠(简单直白),hold 住,
成本低(开发成本,交流沟通成本,维护成本,
废弃成本),行为一致,无人员单点
 具体到稳定性工作上:用最简单可...
 个人与团队追求的统一
 差异部分的处理:控制在小范围内,不溢出到团
队范围
一些个人的想法
 稳定性工作没有终点,我们也正在通往稳定
的路上
 收简历 fulin@xueqiu.com
结束语
聪明的投资者都在这里
Keep Calm
And
Ask Me Anything
Prochain SlideShare
Chargement dans…5
×

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

1 404 vues

Publié le

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

Publié dans : Technologie
  • Soyez le premier à commenter

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

  1. 1. 移动时代 端到端的稳定性保障 @唐福林 雪球首席架构师
  2. 2.  关于雪球,关于我  “稳定”的定义  明确数据指标项  收集数据  使用数据  总结,及一些个人的想法 大纲
  3. 3.  大而不同的投资工具  web 1.0:新闻信息  web 2.0:SNS 订阅,分享,聊天  web 3.0:移动 APP,交易闭环  风来了,风口还缺“会飞的🐷”  知乎体:在全员都在投身「投资事业」的 公司里工作 是一种怎样的体验 关于雪球
  4. 4.  前新浪微博架构师,微博ID @唐福林  微博短链 t.cn  微博计数器 redis,rediscounter  微博用户关系服务  微博稳定性、性能改进 关于我
  5. 5.  雪球首席架构师,雪球ID @唐福林  性能,稳定性改进  业务无关的底层服务,基础组件建设  团队建设 关于我
  6. 6.  关于雪球,关于我  “稳定”的定义  明确数据指标项  收集数据  使用数据  总结,及一些个人的想法 大纲
  7. 7.  业务方/用户期待的“稳定”  可访问到  耗时在可接受访问内  想用的功能正常  Now, or never 定义“稳定”
  8. 8.  不可抗力  地震,海啸  Great Cannon DDoS  机房停电,挖掘机挖断出口光纤  AWS/Azure/阿里云 out of service  运营商 DNS/Http 劫持 为什么“不稳定”
  9. 9.  技术内部因素  架构或代码缺陷  代码或基础设施变更  新老版本兼容  访问模式变化 为什么“不稳定”
  10. 10.  系统可用时间多  核心功能正常  性能在可接受的范围内  不可用的时间少  n 个 9 的可用性 技术定义
  11. 11.  关于雪球,关于我  “稳定”的定义  明确数据指标项  收集数据  使用数据  总结,及一些个人的想法 大纲
  12. 12.  数字说话  凡是不给出明确数字的指标要求都是耍流氓  SLA Service Level Agreement  http://en.wikipedia.org/wiki/Service- level_agreement  简单版:99%的正常请求1秒内正常完成 明确数据指标项
  13. 13.  对数据指标项的要求  区分度高:Key Performance Indicator  可收集,易收集  可处理,易处理  可使用,易使用  项数量越少越好 用数据说话
  14. 14. 典型的访问流程 DNS 互联网 接入层 交换层 应用层 缓存层 存储层 CDN
  15. 15.  APP  操作成功率:用户操作正常完成次数 / 用户 操作总次数  非正常包括  crash  超时  server 端报错 用数据说话
  16. 16.  APP  困难  怎么记录  怎么传输  怎么使用 用数据说话
  17. 17.  公网传输  传输成功率:传输成功的次数 / 发起传输的 次数  失败包括  超时  被劫持 用数据说话
  18. 18.  公网传输  困难:无法准确收集  解决:  以客户端发起网络操作次数为准  封装自己的客户端网络操作底层库 用数据说话
  19. 19.  接入层  成功率:服务端成功接入的次数 / 客户端发 起请求次数  失败包括  机房、IDC、云服务故障  DoS  配置错误 用数据说话
  20. 20.  交换层  成功率:成功返回的次数 / 接收到的总请求 数  失败包括  配置变更  容量峰值 用数据说话
  21. 21.  应用层  成功率:成功返回的次数 / 接收到的总请求 数  失败包括  代码或配置变更,重启,bug  容量峰值,性能瓶颈  依赖资源或服务超时或失败 用数据说话
  22. 22.  缓存层  成功率?命中率!  影响命中率的原因  业务 key value 模式设计  容量:MEM,CPU,带宽,QPS  缓存组件自身设计因素导致的剔除率 用数据说话
  23. 23.  存储层  成功率:成功存储的次数 / 接收到的总请求 数  失败包括  数据丢失  服务不可用 用数据说话
  24. 24.  内网传输  传输成功率:传输成功的次数 / 发起传输的 次数  失败包括  超时:毛刺,QoS,瞬断  配置变更  容量峰值 用数据说话
  25. 25.  内网传输  困难  无法收集,或无法处理数据  发现问题后,无法定位根源,无法解决 用数据说话
  26. 26.  关于雪球,关于我  “稳定”的定义  明确数据指标项  收集数据  使用数据  总结,及一些个人的想法 大纲
  27. 27.  数据收集框架  没有银弹,也没有哪个现成的开源框架能 帮助你搞定你的所有问题  Do it yourself,with help of opensource  Apache Flume 看起来不错,如果你问我有 没有推荐的框架的话 收集数据
  28. 28.  数据收集原则  收集原始数据 VS 收集统计数据  实时收集 VS 异步收集  在能达到目的的前提下,数据量越少越好, 方式越简单越好 收集数据
  29. 29.  关于雪球,关于我  “稳定”的定义  明确数据指标项  收集数据  使用数据  总结,及一些个人的想法 大纲
  30. 30.  Dashboard  目标:远远的看一眼,就知道系统现在是 好的/是有问题的  实现:http://status.aws.amazon.com/ 使用数据
  31. 31. 使用数据
  32. 32.  监控  目标:各种指标项的当前状态,历史变化 趋势  实现:Zabbix,Nagios,Zenoss,Cacti  http://en.wikipedia.org/wiki/Comparison_of _network_monitoring_systems 使用数据
  33. 33.  报警  目标:故障发生时,实时告知技术人员  实现:电话(IVR),短信,Email,微信 /QQ 或其它任何通知手段  原则:  漏报很危险  经常误报,比漏报更危险 使用数据
  34. 34.  应用层使用  旁路使用  容灾测试  紧急预案  后台工具,管理系统 使用数据
  35. 35.  应用层使用  直接使用  动态开关配置系统 config service  Smart client 使用数据
  36. 36.  确认正常  每次故障恢复后确认  每次报警后确认  每次变更后确认  每次数据发生较大变化后确认 使用数据
  37. 37.  问题跟进  记录每次故障或问题  记录解决过程,经验教训  解决方案工具化,自动化  解决方案体系化:彻底解决系统内全部类 似问题,保证以后不再出现同类问题 使用数据
  38. 38.  “稳定”的定义  明确数据指标项  收集数据  使用数据 总结
  39. 39.  稳定性保障的难点  用数据说话的意识:没有数据就没有发言权  公司层面重视程度:B轮以后再说稳定性  技术实现难度:APP端的数据收集,网络/云服 务的不可控性  过犹不及:收集的数据过多、报警过多 一些个人的想法
  40. 40.  技术人员的自我修炼  态度第一:知道什么样子是“好的结果”,并有意 愿,主动的去追求好的结果。能力可以有差距, 但意识一定要到位。  个人的好:更快,更炫,更漂亮,更体系化  具体到稳定性工作上:平常工作中面向失败编 程,体系化的收集并使用数据,尽量降低对正 常业务的影响,持续关注数据指标项的变化, 解决一个问题的时候,会想着解决一类问题 一些个人的想法
  41. 41.  技术团队的自我修炼  支持鼓励每个人追求更好,并在整体上追求好 的结果。  团队的好:稳定可靠(简单直白),hold 住, 成本低(开发成本,交流沟通成本,维护成本, 废弃成本),行为一致,无人员单点  具体到稳定性工作上:用最简单可靠的技术实 现功能,提前准备好各种失败预案,团队整体 技术栈统一化,工作透明化,降低沟通成本, 消除系统单点,消除人员单点 一些个人的想法
  42. 42.  个人与团队追求的统一  差异部分的处理:控制在小范围内,不溢出到团 队范围 一些个人的想法
  43. 43.  稳定性工作没有终点,我们也正在通往稳定 的路上  收简历 fulin@xueqiu.com 结束语
  44. 44. 聪明的投资者都在这里 Keep Calm And Ask Me Anything

×