王璞/树人云创始人&CEO博士美国乔治梅森大学计算机科学专业。曾就职于Google、Groupon、StumbleUpon等硅谷互联网公司。擅长分布式计算、大规模机器学习、海量数据处理。曾任谷歌广告部数据平台架构师，负责管理全球每秒流量最高的架构平台。运维环境的新变化。DataCloud是一个基于容器的轻量级PaaS平台。当它落地到企业客户时，客户很难理解一个平台背后隐藏着什么。任何平台和工具都是和方法论相结合的，比如研发工具、持续交付工具等等，都有一套方法和概念。今天主要分享SRE理念在传统企业的落地。随着技术的发展，运维环境发生了新的变化。比如在互联网场景下，线上业务和线下业务的区别非常大。规模化、分布式：从传统的封闭系统架构向分布式开源系统架构演进，系统规模增长迅速，尤其是谷歌互联网业务数据中心，拥有超过200万台服务器，规模非常大.技术栈复杂：开源技术层出不穷，加上大数据技术，技术栈越来越复杂。大流量高并发：用户基数迅速扩大，互联网场景大流量，高压并发压力加大。和唯品会的朋友聊过，推广几个小时就引来了近百万的流量，这在传统线下是从来没有遇到过的。高频变化：大量新业务的推出和各种与业务相关的线上活动带来高频变化。国内电商每个月都有节假日促销，而且变化比较大。互联网公司至少每周进行一次更改。对于传统的企业客户来说，是非常大的。例如，银行大多每六个月进行一次更改。这些运维环境的新变化，主要是由互联网场景的变化引起的。DevOpsDevOps的知识结构非常复杂。从规划设计阶段到开发阶段，很多企业客户是不可能实施的。甚至一些互联网公司也未必能够从设计到开发、交付、上线，完全做到DevOps。运维IT服务管理流程示例：流程图中数据和细节太多，很多细节至今没有深入涉及。开发运维一体化DevOps是开发运维一体化，从业务需求到开发、交付、上线一体化。上层是DevOps的理论部分，中层是技术部分，底层是基于软件的基础设施。真正把DevOps实现好需要理解的东西太多，成本太高，所以Google总结了一套SRE在DevOps方面的概念，尤其是在运维方面。这种SRE方法论是谷歌运维中的DevOps思想。最佳实践。SRE的由来首先要明确概念：DevOps有很多实践，丰田汽车等传统制造企业也使用DevOps。SRE是DevOps的一种实践，更倾向于互联网公司。前面说了，SRE在Google内部以运维为主，开发设计不多，敏捷开发就不提了。SRE是怎么来的？2003年，谷歌数据中心的规模应该有几千甚至几万台服务器。那个时候没有运维，更多的是叫系统管理员。很多系统管理员无法管理大型X86服务器系统（IT硬件设备都是大型机设备，系统管理员管理的大部分是小型机，谷歌从不买大型机），所以被迫从开发找了7个人转移到生产运维，他们是数据管理中心，在运维过程中发现了很多问题。首先，在系统管理、运行脚本等方面有很多重复性的工作，这些开发工程师对重复性的工作是相当抗拒的，所以他们开发了大量的运维工具来实现自动化运维。开发工程师现在是SRE。三角图展示了谷歌SRE工程师日常工程的内容和职责，主要是工程研发，其余为日常运维。传统运维模式传统的系统管理员是盯着机器看，但是随着人员成本越来越高，解决的问题也不尽相同，效率低下。面对服务器规模越来越大的问题，统一运维的模式已经不适合互联网场景。SRE岗位职责开发：SRE工程师大部分时间都在写代码，必须有很强的开发能力。日常运维：除了开发，最重要的就是管理资源，比如所有资源的效果和性能。例如，在一个大型的互联网数据中心，服务器规模巨大，资源利用率对数据中心的成本非常重要，因此降低数据成本非常有帮助。谷歌数据中心的利用率还是比较高的。数据中心有一个数值，就是数据中心用多少电来制冷，多少用在服务器计算上。谷歌在计算上每花费1千瓦时，只有一小部分用于服务器冷却。怎么理解呢？对于Gmail服务，无论是活跃用户还是非活跃用户，谷歌一年使用Gmail服务的电费不到一美元。数据中心对成本和资源利用有非常严格的考虑。SRE是帮助Google实现数据中心的最大利用率。因为有超过200万台服务器，谷歌损失了10%，相当于消耗了20万台服务器。如果谷歌全部使用虚拟机，额外的开销大约是15%，甚至20%。如果所有的服务器都变成虚拟机。Google的资源基本上有20%不能用。至少已经虚拟化了数十万台服务器。底层系统消耗是谷歌无法接受的。如何高效-SRE。对于变更管理，谷歌不同于传统的运维。传统的运维在做变更的时候需要开发提供上线。Google的SRE并不是开发出来提供给SRE上线的。正是SRE为各种变更发布准备了平台。每一个系统启动变更都是由开发者自己发布和启动的。应急响应：应急响应需要像传统运维一样有人值守，保证系统出现任何问题都有人解决。传统运维模式VSSRESRE：优：自动化、可编程、高效。SRE强调自动化，大部分运维工作都是通过工具自动化来完成的。缺乏：人才少，团队建设和管理没有参考依据，系统管理需要管理层支持。Network、kernel等。同时，SRE行业的参考资料相对较少，主要是Google等大公司使用。传统运维：优秀：很多经验可以借鉴，容易招，工具多。传统运维经验非常丰富，尤其是绝大多数企业都是传统模式。缺点：人员对自身技能高度依赖，人员规模与系统规模成线性关系。每个系统都需要独立的手动切换，依赖脚本管理。传统运维的缺点是很多事情都是靠人力来完成的。这样一来，服务器越来越多，业务规模越来越大，人越来越多，效率就提不上来了。SRE文化的三个要点长期关注研发工作谷歌的SRE文化做得很好，保证SRE有足够的时间进行研发，将每个人的运维工作限制在50%以内，保证有足够的时间写程序。SRE在每个8到12小时的轮班窗口中最多只能处理两个事件。坚持演练Google定期进行SRE演练。例如，最高级别的演练是定期关闭数据中心并进入维护状态。基于这种情况，开发在编写程序时必须考虑到容错性、数据中心的不可用、硬件的不可用以及其他相关软件系统的不可用。经过长期演练，谷歌内部系统的容错能力得到了增强。容错能力强的系统，对于运维来说是一种良性循环。出了问题不容易关停，SRE运维的压力自然会降低。决策和发声SRE关注的是非功能性需求，比如稳定性等。这些非功能性需求是在程序开发和编写的早期引入的。如果一个系统尽可能满足SRE的非功能需求，系统上线相对容易，但是如果一个系统不满足SRE的要求，每个月告警太多，SRE可以带来这样的系统上线了，但是SRE并没有接手运维。谷歌内部有句谚语，如果SRE对某件事说不，那它就无法完成。SRE服务质量目标构建一个基于平台的服务体系平台和工具，实现自动化和自助服务由工具平台自动完成。制定各项规章制度，明确SRE内部分工。比如GoogleSearch有SRE，GoogleAds有SRE，还有设计平台等等，这些都是面向业务的。虽然SRE部门不多，但加起来有一半的SRE分散在各个业务部门，负责相关的工作。容量规划和容量管理SRE根据业务容量规划各个业务系统，包括搜索系统和内部软件架构的系统。它必须有准确的自然和非自然增长需求来进行容量管理规划，并且必须定期进行压力测试以控制资源。需要衡量单核CPU能处理多少广告，搜索系统的并发数等等，这些性能消耗和性能关联都是由SRE完成的。业务部门提供一个数据，比如搜索部门的开发。业务系统的开发一定不提需要多少CPU，提供的负载指标就是多少并发搜索，每秒处理多少请求。SRE通过压力测试将负载转化为资源需求。不同的搜索部门每秒处理10000个请求，10000个请求需要多少CPU。这些都是关联负载资源的压力测试。任何关于利用率的讨论和改进都可以保证SLO并最大化迭代速度。比如一个业务系统新版本有20%不可靠，新版本不如旧版本稳定，旧版本99%可靠，新版本20%可靠，那么新版本所有online无法做到99%的稳定，所以只有一部分可以在线服务5%的用户，这样至多1%的用户不能使用服务，仍然满足SRE提出的99%可靠性的系统要求。SLO用于SRE和开发之间，以达到最大的上线速度，也平衡了两者之间的矛盾。变更管理变更管理：70%的生产是由变更引起的。谷歌的更改必须间接发布，其系统具有自动回滚，减少了新版本上线的影响。有效监控谷歌对监控非常严格，尤其是在警报方面。每一次报警都必须有明确的动作，将要执行的操作写在变更手册中。Google具有三个有效输出：警报、票证和日志。任何报警都必须在正确的值班姿势下有明确的动作。谷歌要求在发生报警后，值班人员可以查阅手册来处理问题。如果告警是新的，值班的SRE不会处理，而是升级告警，请开发者帮忙处理。在值班的时候，SRE主要解决线上问题。一旦出现问题，特别是告警严重的问题，会通过工具半自动回滚。回滚后保证业务稳定可用，业务可以快速恢复。Google内部要求，如果问题出现次数超过3次，则必须有自动修复的方法。必须从根本上解决问题或自动修复。用容器来实现SRE理念12条规则12条规则是一个非常好的设计模式，在很多互联网应用中普遍使用，适合开发和运维人员。log12规则要求将日志视为事件流，这对于容器来说很容易做到，因为容器的标准输出是事件流的形式。持续集成和持续交付流程我们和很多企业发生了碰撞，尤其是传统企业，流程需要监管，没有办法做到完全自动化，需要大量的人来做。如果变更申请需要人，构建和部分测试可以自动化，让工具来完成，但是企业里面还是有很多测试是人工的，尤其是一些IT部门上门来做的测试。有很多工具可以自动处理变更，自动记录变更过程中遇到的很多问题，方便变更后的回顾。配置管理把配置文件塞进容器里，程序就可以访问了。另外，配置文件是和程序一起封装打包的。这些方法没有对错之分，只是哪些客户可以接受，哪些客户不能接受的问题。日志被定向到标准输出。传统企业中很多日志文件都是以文件的形式收集的。日志中的问题有特定的审核和审批流程。容器以标准化的方式封装了应用程序。日志文件写在容器内部，程序不做任何改动。通过外部手段对容器进行内部搜索，带来了很多问题。如果程序在容器中写入大量日志怎么办？管理？日志文件达到几G怎么办？严重损害容器的性能，这也有利也有弊。如果日志文件挂在容器外，客户已经有了处理方法。容器需要额外的配置和额外的参数，容器需要迁移到其他服务。如何保证碎片化的日志被完整收集，还是很多问题。这个问题，不同的容器有不同的方法。监控目前遇到的大部分客户都有完善的监控系统，而客户在使用容器平台后不希望有新的监控系统，因此需要对接客户已有的系统。弹性伸缩如果业务负载过大，系统程序需要对实例进行扩容。以前可能只有3个集装箱装载，现在3个都不够了。扩大到10个，怎么触发呢？人为触发还是自动触发？如何理解这个实例在触发后是否正常终止？实例收缩也很复杂。很多传统企业都是交易型的，不能随便搬。大部分触发条件都没有看到自动收缩，都是手动触发的动作。大多数企业在处理申请时，必须确保程序上处理的业务完成后才能关闭。如何判断程序已经处理完毕？这时候需要修改已有的程序，而客户又不想改程序，怎么办？比如用负载均衡器感知一个程序，在后台实例的流量完全结束后关闭，这是很多实际的考虑。测试标准如何确定模型是否成功？这里有个曲线，SRE注重自动化，提升平台效率。蓝色代表业务规模。相当于是开发者的数量，也可以理解为数据中心的服务器数量。这与业务规模成正比。如果业务规模大，业务人员多，开发人员肯定多，负载高的服务器数量多，蓝色曲线一定是快速通道。任何企业都希望业务快速增长。红色运维数据与人有关。任何企业都不希望人和企业一起成长。业务增加10倍，开发人员增加7-8倍，业务人员增加7-8倍。显然，成本太高了。SRE模式成功的标准是业务快速增长，无需逐年增加人员，通过平台自动化满足业务增长的需求。比如谷歌，服务器从2003年的几千台增加到1万台，到现在已经超过200万台，人数也是按照这个比例增加的。这就是整个SRE带来的持续的效率提升。以上是树人云对于SRE在传统行业落地的思考。如果大家有更多的想法，欢迎加小数微信：xiaoshu062到树人云微信群进行交流。技术干货、外语翻译、活动预告，都在这里！扫描二维码关注树人云微信公众号。
