SRE体系12----全过程可靠性建设

可靠性不是SRE或运维一个团队的责任，运维更多的是保障基础架构层面的可靠性。如果把业务系统比作一盆花草，若是花草有先天性缺陷，无论后期如何精心维护，也是事倍功半，必然要出问题。所以当我们要提升可靠性时，需要从业务系统整个生命周期的视角去做努力。高可靠性的系统是设计出来的，不是运维保障出来的。与其后期重构，不如三思而行。

通常我们的业务系统要经历下面几个过程：

1. 产品需求收集
2. 产品设计与实现
3. 测试与验证
4. 部署和发布
5. 运维

在公司开发新业务的初期，需要快速推出产品响应市场需求，高速迭代。这时候产品的可靠性和稳定性是让位于研发效率的。当产品稳定以后再考虑提升可靠性，这样做的成本是很高的，因为很多东西已经定型了，再去重构，修改，迁移要花费大量的精力。所以最好再业务一开始就考虑可靠性需求，用良好的设计降低后期运维的压力。接下来针对这几个过程中SRE可以介入的地方进行论述：

产品需求阶段：
明确新产品的业务定位，根据重要程度确定核心业务，核心模块，核心流程及保障等级，设定合理的SLO。同时规划和预留响应的IT基础架构资源

产品设计阶段：
这一阶段最核心的是软件的架构设计，需要和研发部门的架构师多沟通。就可靠性来说，架构设计上的缺陷比bug更危险。其中业务架构、系统架构、应用架构通常由软件架构师负载，确保业务系统在物理和逻辑层面上符合冗余，高可用，自愈等原则。而SRE和运维工程师更多的是在部署架构上下功夫，确保地基不出问题。例如建立灾备数据中心。同城多活数据中心，云上和云下协同。配置宿主机的反亲和性，确保相同类型的实例不会部署在同一台宿主机上等。。。

测试与验证阶段：
单元测试，集成测试，回归测试等，这一阶段SRE和运维更多关注压力测试，确保为业务系统预留了充足的资源容量。

部署和发布阶段：
通过devops工具实现自动化部署和发布，屏蔽手动操作带来的风险。借助CMDB等平台，确保基础信息的一致性和环境的一致性，避免环境差异带来的部署风险。实行灰度发布策略，把发布新业务的风险降低。

运维阶段：
完善基础设施监控指标，同时配合开发人员建立业务系统自身的后台监控。定期召开生产会议，对出现的故障分析定位，改善可靠性指标。在业务平稳时，可以通过混沌工程，定期举行灾备演练找出系统的薄弱点加以改进。