接口服务规划的个人想法

标签：google   时长   容灾   使用   频率   程序   接口   mil   rpo   

遇到的问题：

1. 过去一年事故频发
2. 事故恢复时间过长
3. 对事故现场没有很好的取证，不便于日后的分析
4. 架构模块在使用的时候没有实质性对产生影响做分析，带有盲目性

解决方案的个人想法：

1. 容灾:
   1. 关键参数
      1. NRO - 网络恢复目标（灾难后的网络恢复时间）
      2. RPO - 恢复点目标 （灾难前最后一次备份的时间，数据丢失）
      3. RTO - 时间恢复目标 （灾难后恢复物理系统环境的时间）
      4. RAP - 访问恢复目标（验证应用功能是否正常运行的时间）
2. 保存现场
3. 故障转移
4. 事故恢复
5. 逻辑优化

重构，借用工具。上线必须保证：httpunit功能测试，LoadRunner负载测试通过。

1. 性能优化
2. 后期优化

利用大数据分析，将业务问题转化为大数据问题。日志分析，监控异常，逻辑优化，响应时长分析，并发分析，数据恢复，保存现场数据，提供可持续改进的数据基础。

提供数据的频率：

1. 流量异常：必须实时或近实时的进行
2. 战略性业务业务决策的趋势分析：分析可采用批量模式
3. 数据采集(后续)

反正我的blog除了乐视同事也没有别人看，不涉及信息安全。把接口架构图放在这里，以后好找：

不是我画的图果然就看起来高端大气上档次[汗]。性能优化是我的日常工作，可以慢慢来。如果遇到什么闹心的线上事故，建议看看

《打错一个字母-瘫痪半个互联网    亚马逊AWS的云存储服务S3超高错误率宕机事件》

《google.com宕机一小时》

《gitlab程序猿用一条错误命令误删了整个数据库》

心情会好很多！

接口服务规划的个人想法

标签：google   时长   容灾   使用   频率   程序   接口   mil   rpo   

原文地址：http://www.cnblogs.com/xiexj/p/6516057.html