SA和Dev/Ops的挑战

通常企业会招聘很多的SA工程师（系统管理员），该部分工程师负责企业生产环境组件的运维，对于需要人工干预的操作进行人工干预。

目前在国内，各公司通常做法是SRE和SA分离，SRE负责业务侧管理和维护，SA工程师负责企业基础架构的维护，包括服务器、基础环境维护。同时Dev和Ops部门分离，所以带来两种成本。

  1. 直接成本：业务线扩展，Dev和Ops同步增加，人数共同增长。

  2. 间接成本： 消息拉通、同步问题，可能会导致各部门信息不同步，间接导致团队目标不统一。

Dev和Ops部门最大的工作分歧通常出现在新版本发布、变更期间，也可能是发布速度原因。

  • 版本发布： Dev希望随时发布，但是Ops部门希望生产环境一成不变，避免非必要情况下的变更和发版（新版本发布、变更和动力环境割接都有可能导致系统崩溃）

  • 发布速度： Dev部门希望发布是0秒，质量部门希望服务是没有抖动的，但通常来说是不可能的（即使使用平稳变更），可能在变更或者发布的时候会出现服务短暂不可用的情况，所以就可能出现发版或者变更速度跟不上Dev和质量部门的要求。

大型互联网企业SRE解决方案

大型互联网企业会组建DevOps团队，其中，该团队的大部分工程师来自软件开发，其余部分工程师可能不是软件开发工程师，但是该部分成员都具有软件开发工程师的基本技能，可以以软件工程的思路解决SRE问题，同样也可以很容易的同步其他开发部门的需求和信息。

对于常见的互联网架构中，SRE需要完成的大部分工作都是机械性的，所以配备软件开发工程师的优势就在这里体现出来了。机械性的操作，软件开发工程师会构建一些自动化工具进行机械性操作，提高运维效率。

目前国内大型企业中，都在逐步取消Ops工程师的岗位，取而代之的是SRE工程师或者DevOps工程师。如小米，目前已经基本不招聘运维工程师了，招聘主要是DevOps工程师，该部分工程师都具有较强的软件开发能力。这部分工程师的工作内容大部分都是构建开发自己的运维平台，解决自己企业目前运维所遇到的问题。

SRE方法论

SRE基本系统构建：

  • 性能优化，延迟优化，可用性优化，效率优化
  • 变更管理
  • 监控
  • 紧急事务处理
  • 容量规划

研发工作跟进

SRE团队应设备on call机制，on call工程师在工作时间内1on1对接业务侧需求。单个工程师on call时间不应过长，过长会导致处理效率下降。

On call工程师在完成当日工作后应对当天处理的故障及紧急情况做文本输出，作为部门或者全司的wiki输入。

保证SLO下提升迭代速度

通常情况下，快速迭代和稳定的服务是很难沾上边的。所以SRE的一项很重要的工作就是保证SLO的情况下提高迭代速度。

对于任何服务，可用性都不可能是100%，即使真的能把服务做到100%，整个互联网传输过程也不会是100%。如本服务的可用性是99.99%，互联网会有很多层的交换路由，这些设备的可用性也不可能是100%，这里可用性是要通过乘法计算的。

4qTrt0.png

所以，SRE需要考虑如何提升SLO，那么就需要考虑一下三个方向：

  1. 最低可用性是多少，低于这个指标可能会导致用户使用体验降低。
  2. 可不可以用替代方案提高可用性。
  3. 可用性降低会不会影响用户的使用模式

监控

监控在运维体系是非常有必要的。监控并不是一个软件，而是一个方法论。监控可以发现软硬件故障并进行报警。监控体系通常有三个途径：

  1. 监控及报警
  2. 工单系统
  3. 日志系统

应急情况

对于应急情况需要指定MTTF（平均失效时间）和MTTR（平均恢复时间）。通常对于变更产生的应急状况，要制定严格的MTTF，即失效多久之内必须恢复，恢复时间应小于MTTR。

变更管理

对于常见的发布和变更必须要进行备份即容灾，要保证变更有迹可循，变更故障随时回滚。通常对于大型企业都会构建一个配置分发平台，对于变更的配置进行统一下发并讲原配置进行备份。对于每一条变更都要能对应到责任人，并且保证在MTTF内恢复服务，超时即回滚。

需求和容量

发布上线之前要进行服务器容量评估，其数据必须建立在已有的运维和运营数据之上进行评估，要设计一部分的冗余。并且要定期对服务器定期进行打压测试，以便把资源信息和容量对应。