前言
三个月前，我换了工作，到某金融集团的的应用运维团队。从初创型的互金公司到一家大型的传统金融公司，我感受了巨大的差异。
外界互联网企业，大家总是谈论的的微服务、DevOps、持续集成和持续交付、容器化部署的这些概念，在这几乎完全没有用到，甚至很少听到。
工作方式的巨大转变，引起了我对运维工程师这个角色的核心价值，产生了一些思考。作为一个笃信“目的即本质”的我来说，觉得抓住一份工作的核心价值所在，才能对照自身评估自己是否符合这一角色定位，是否适合坚持长期发展，找到长期发展的准绳，不至于偏航。
作为运维核心价值
要明晰什么是运维的核心价值，也就是要弄明白，从整个软件行业运维的角色定位来看，运维的核心价值在哪里？怎样增强自己实现核心价值的能力的问题。
软件产业本质其实还是工业，它的产品和传统的工业产品形态虽然有巨大差异，但其实在生产流程中还是和传统工业有诸多本质的相似之处。如果把软件生命周期看作汽车的生命周期，那么开发工程师就是汽车设计生产人员，负责将汽车（软件）从需求，转为技术设计图纸变为实实在在的产品，主要作用发挥在汽车生命周期的前期。而运维工程师就不同了，运维工程师通常是软件生命周期的中后期才介入的。就像汽车驾驶和维修的人员，而软件用户就像是汽车的乘客。运维人员要采用一切技术手段和管理手段，保证“汽车”的正常、安全、稳定、高效、舒适的运行，把乘客带向能为公司创收的“目的地”。换言之，开发输出的是有形的产品，运维输出的是无形的服务，即一种为软件消除、控制运行中产生的风险的服务，这和金融领域里“风控”的角色非常类似。所以运维的一切工作和能力建设，都是为了控制风险这个目标为依归。
现在IT行业内运维的工作以机器采购、机房建设、网络规划、系统装机、应用部署、中间件维护、监控处理、自动化运维等多种形态存在，很多人把运维工作看做一种打杂的工作，负责的都是重复又繁杂的工作，甚至很多运维人本身也看不到自身的价值感。
但是，把运维工作的本质理解成一种为软件运行消除和控制风险，就可以很好理解运维工程师为什么承受着这么繁重而且庞杂的工作内容了。开发工程师把软件设计并且开发出来，运维工程师就负责把软件运行好。就像一辆汽车的司机，要把汽车从汽车厂带向正确的方向、一路上规避各种各样的风险，定期对汽车进行检修和保养维护。所以，开发工程师和运维工程师最本质的差别就是，前者生产软件产品本身，而后者围绕前者生产的的产品，提供一系列风险控制的服务。那么，就让我们从风险控制的视角，来思考探究运维工作的核心价值和其方法论。
“打在胎里就有随时流产的风险，当妈的一口烟就能长成畸形，长慢了就心脏缺损，长快了就六指。好容易扛过十个月生出来了，一不留神害得让产钳把脑袋夹扁了。都躲过去了，小儿麻痹、百日咳、猩红热、大脑炎，还在前面等着呢。哭起来呛奶，走起来摔跤。摸水水烫，碰火火燎。是个东西撞上，那就是个半死。钙多了不长个，钙少了罗圈腿。总算混到会吃饭、能出门了。天上下雹子，地上跑汽车。大街小巷是个暗处就躲着坏人。你说赶上谁都是九死一生，不送命也得落个残疾……”
在软件的“一生”中，就像一个人的生命历程一样，可能面对各种让你猝不及防的风险。只有充分认识风险，才能控制风险。
风险的分类
软件面对的风险多种多样，可以按风险发生的阶段、风险产生的层面、造成的影响大小、导致风险的原因等等不同的维度去划分。为了抓住风险控制这一核心目的，我们就从导致分险的原因这一维度开始着手。
导致风险的原因
先天性风险
所谓先天性风险，主要指的是在软件设计阶段，就存在系统性缺陷引发的风险。需要强调的是，软件设计阶段不仅包括软件的业务逻辑、开发框架、依赖的中间件、数据库，还应包括软件运行的服务器硬件、操作系统、以及网络架构等环境因素。 许多开发者只关注代码的编写，而对软件运行的环境因素知之甚少，甚至不屑了解少学习。任何一个在技术领域有追求的技术人，都应对此保持一种鄙夷的态度，古语有云“不谋全局者，不足以谋一隅”。一个只顾埋头编写业务代码，不掌握软件整体设计逻辑和全部软件生命周期的开发者，终究只配当一个“代码工人”，而无法成长为一个优秀的设计者或者技术leader。
先天性的风险，主要在软件设计阶段，没有经过足够细致周密的技术调研和论证，或者说有些问题，难以在软件上线生产环境之前得到暴露。这很大程度上，就是由于设计软件的技术团队欠缺统领全局的能力。往往这种风险，因为缺乏生产环境那么丰富的业务场景，难以在简单的功能性测试中检查出来。于是，运维往往沦为离这一类风险“最近的消防栓”。但是大多运维工程师没有软件设计的经验，解决起这类问题来也经常显得束手无策。说到底，一个不懂运维的开发团队会给开发“埋坑”，而一个不懂开发的运维团队就不知如何“填坑”。当然，这也是DevOps作为全局“填坑”手段，产生的原因所在了。
变更性风险
曾有幸聆听《SRE Google运维解密》中文版译作者——前谷歌SRE孙宇聪先生的演讲，他演讲中有一个观点让我印象深刻，他说开发的工作目标是对系统进行变更，而运维的工作目标是追求系统稳定，而变更本身就是一种对已有的稳定的系统的破坏。变更就是一种破坏这个观点，可以帮助理解了作为运维角色的很多问题，联系自身，我很快理解当时所负责的版本发布的工作，对于运维角色的意义所在——把变更的风险控制起来。
版本发布只是变更的一种，一个系统变更的元素可以有很多。包括：硬件基础设施、操作系统、开发框架、应用代码、中间件、网络结构、配置文件、数据库。在一个互联网公司，最常发生的变更也最易产生风险的，当要算应用代码、配置文件，以及数据库了。版本发布工程师在发版过程中，往往都要做涉及这三项的变更，可以说版本发布是一项“高危”性质的工作。
控制此类风险，没有什么诀窍，关键就是要减少变更，包括变更的次数和变更的元素和其变化量。但是像版本发布的变更，其变更需求和方案并不是在版本发布过程中产生的，而是在软件需求分析、设计研发阶段产生的，运维工程师要控制其变化量，就只能提前介入到软件需求分析阶段，运维工程师应该争取在项目需求阶段和设计阶段，对导致不可控风险的需求和设计方案，具有一票否决权。但是在以变化求生存的互联网时代，运维工程师不能成为变化的阻力，在慎重阻挡不合理需求和设计方案的同时，运维工程师更应该给出合理化建议，帮助需求的落地。许多企业完全不让运维参与前期需求评审的工作，认为运维与需求无关这种由来已久的观念，可以说在这个产品迅速变化的时代，已经显得非常不合时宜了。但让人欣喜的是，已经越来越多的企业把运维工程师加入了需求评审会。
还有关键的一点是，在执行变更的过程中，严格制定规范的变更控制流程，杜绝变更方案之外不必要甚至是错误的破坏行为。
人为的风险
传统运维大大小小的事，都需要工程师亲自上阵、手工操作，对人的依赖性非常强。而人的行为能力受知识水平、体力、情绪、性格等诸多因素影响，难以量化、难以预见，更难以将由此带来的风险隐患控制起来。
使用制度来规范人的行为固然有一点效果，但纵使在一些成熟的公司设立了严格的制度，执行的不确定性依然很高。另外，如果依靠制度来将人的行为禁锢得太死，个人认为是不利于人的发展，不利于发挥人的价值。工程师作为高级技术人才，应该充分尊重其作为一个脑力劳动者的价值，使其精力投放在更有创造性的事情上去。
我认为，在运维领域最理想的目标，应该将重复琐碎的工作，都交给机器去做。运维工程师需要做的是：为运维管理及操作提供智力支持，并为自动化运维体系提供持续改进的动力。
实现这个目标是一条漫长的路，但是每一个运维的领导者，都应该带领团队踏上此条漫漫征途！这不是一个可做可不做的选项，在互联网高度普及的时代，对任何一个拥抱互联网的信息系统的维护团队来说，这是运维的必由之路，是选择停滞不前，被随业务剧增的流量暴击，每天疲于救火，应付不迭而累死？还是于崇山峻岭之中，劈开自我解放的光明坦途？答案不言自明。
系统性缺陷引发的风险
系统性缺陷指的是有系统设计时，包括网络架构和应用架构，以及整体环境逻辑设计时，未能充分考虑到各种可能发生的场景。这种风险，往往在日后特定场景下才会暴露出来。内部系统和外部系统风险。
制度流程性风险
制度流程不清晰、不严密，可能造成对风险管控存在“三不管”的责任死角，不能有效管控风险，出了问题互相推诿。处理问题，做不到迅速反应、标准化的机制，造成风险不能快速被修复。
风险控制的手段
风险控制的本质是在设计阶段尽可能消灭导致风险的因素，把确实难以彻底消灭的因素，采取技术和管理手段，将其严格限制在可接受、能及时有效应对的范围内。
减少人为：
标准化，自动化运维的日常工作
减少破坏：
变更本身就是一次破坏，控制基础设施变更、软件版本发布过程。最大限度地减少更新的内容、更新的次数，是控制“破坏”型风险的根本之道。
措施：
变更必须要有方案：严格设计、评估变更方案，严格按变更方案执行，不做变更方案以外的多余操作、误操作。
微服务：
近年来流行的微服务架构设计，其核心就一个字——“拆”，将大应用拆成小应用。微服务的优势就在于“小”，因为“小”，它具有以下三点优势：
1.资源利用上：针对不同应用的性能要求特点，给其配置最符合需要的硬件资源，做到对硬件的充分资源；
2.人员职责上：让每个工程师对自己负责的部分充分理解方便工作推进和工作交接；
3.变更环节里：减少总体工程项目代码量的变更，减少了变更带来的风险。
当然微服务化的落地，也可能产生新的风险，譬如微服务之间的调度和通信就需要依赖网络和一些中间件，增加了依赖性，所以微服务必须做到网络和中间件的高可用。再者，微服务架构设计时，不能一味地为了“拆分”而“拆分”，因为过度的拆分，可能引入新的协调性风险。因而要合理评估和权衡，拆分带来的风险和收益。最后，拆分后对应用服务调用链路的监控、中间件的监控，以及应用的熔断、降级方案必须跟上，来管控协调性的风险。
容器化交付：
Docker近年来成为IT技术圈谈论和实践的技术热点话题。其最大的好处，我认为在两点，其一是，隔离了资源，定制化不同应用之间对资源的需求；第二，正是做到了对应用所需要资源的隔离，将应用和其所依赖的依赖库以及系统环境因素进行了一个打包，所以实现了一次编排，随处运行。所以，对Docker的使用应该在全流程环境中使用（开发环境、测试环境、灰度环境、生产环境），可以将因运行环境的变化导致的可能风险，降到非常低接近0的水平（理论上能降到0，但是与网络架构和应用服务架构设计时，达到的解耦程度有关）；
配置中心：
前文提到的解耦合，配置中心就是解除应用和环境耦合的神器。在版本发布中经常有这样的场景：同一应用的同一配置项，在不同的环境中需要设置不同的取值。在传统的自动化程度较低发布流程中，负责版本发布部署的工程师，需要根据环境的不同，逐个修改配置文件。一个应用可能有几十个甚至几百个配置项，而一个完整系统可能由数十个甚至上百个应用构成。如果赶上一次涉及应用较多的大版本发布，对部署工程师来说，都是一次对细心和耐心的考验，更直言不讳地说，是一次冒险。运维工程师可能因误操作，而导致生产事故。所以要减少配置变更，集中式配置中心要和分布式配置文件模版相结合，做到既能对配置做集中式的管理，又可以根据需要，针对单个实例做细粒度的配置管理。
减少权限：
三权分立：
将系统的操作权、分配权、审计权“三权”进行分割，分配给不同的人，互相制约。
分治：
按照不同业务、不同机器、不同集群、不同中间件，分配给不同的团队／人员管理，预防整体破坏的可能性。在中小型公司，此种做法并不完全可行，如不能做到按人的维度，分治，至少做到对账户角色的维度进行分治。
减少入口：
减少对外暴露的入口，可以方便做流量以及安全管控和行为审计。代理服务器、统一API网关、统一管理后台、堡垒机；
减少流量：
互联网行业流量就是金钱，大家都喜欢流量才对，为什么我说要减少流量呢？这里说的的减少，并非减少总量，而是让流量均匀流入，减少流量暴增式场景的产生，使得瞬时流量峰值不超过系统承载能力。例如，12306购票从原来一次性放票调整为分批次放票， 淘宝双十一活动从双十一当天延展到半个月，还有我之前公司做活动营销推广短信，也是分批次触达用户。这些措施都降低了流量的瞬时峰值，使其不超过系统的承载能力。
减少外部依赖：
所谓外部，不一定是公司以外的系统，也可以指本公司其他团队的系统。我们把掌控能力边界以外的系统，都视为外部系统。外部系统不归属本团队控制，甚至难以做到高度的协同，属于是难以控制的因素，比如调用外部系统（支付、风控、DNS解析、NTP、第三方登录认证等等。 有的外部的依赖确实难以摆脱，起码做到与外部系统建立并保持有效的协同机制，比如版本更新信息同步、管控双方调用通道、双方都设置专人对接维护调用关系等等措施。
增强监控：
监控，分为“监”和“控”两大阶段，“监”是能做到对风险信息及时、有效得收集，其粒度和时间密度要能满足控制风险的需要，“控”是对“监”得到的风险信息进行判别处理，其关键在于阀值的设定是否合理和对应的解决方案是否全面有效。我认为，一个完整的监控应该由这么几个部件组成，数据收集器、数据处理器、存储器、仪表盘、阀值、告警器以及监控处理方案组成。除了数据处理器、存储器和仪表盘不一定必须，其他的部件对于一个完整的监控来说缺一不可。尤其是监控处理方案，常常被忽视，或者说被认为难以设定。但是，缺了处理方案，“监控”就只做到了“监”，缺少了有效的“控”，就不再算一个完整点“监控”。
监控是用来捕捉处理风险的，告警器被过于频繁地触发，就会导致监控处理人变得麻木，从而导致监控丧失效力。合理地设置数据收集器收集策略和阈值大小，建立必要的收敛机制，误报屏蔽机制，是杜绝这种现象的根本。监控和软件本身一样，需要不断改进和优化，才能实现最好的对风险捕捉以及处理效果。
增强性能:
扩容，升级硬件／软件性能，cpu、内存、硬盘容量、io效率、缓存、并发线程数，性能问题往往符合“木桶效应”，系统整体性能由最短板决定。优秀的运维工程师，应该要对每个业务流程涉及到的性能消耗特性，有全面的了解，及时补齐短板，防患于未然。
增强应对的速度：
根据场景变化，能快速地扩容、降级、熔断、恢复、回滚，实现这一目标的三要素是：快速而全面的监控机制、标准的事件处理流程、高度自动化的运维工具。
增强审计：
收集到足够丰富合理的审计信息，建立定期审计的制度，对既往操作行为，查漏补缺，筛查违规操作，对完善制度和流程是十分必要的。
增多备份：
所谓狡兔三窟，数据也应该多做几份冗余。标准的备份方案应该做到“两地三中心”，即在两个城市，拥有三个以上数据中心。每个数据中心，都能做到独立运转。不同数据中心之间，能在较短的时间范围内快速切换，数据灾难发生时，可以将对用户的影响降到最低。其次，配置文件包括应用配置文件，操作系统的配置文件和中间件、数据库，都应该尽量做到备份，同代码一样，引入git等版本管理工具，实现版本化管理。备份要形成制度，根据数据的变化频率，重要程度，确定备份周期和备份方法。备份不可只“备”不“复”，往往很多团队的备份，平日都不做恢复演练，到了真正需要恢复时发现根本无法从备份恢复出数据。所以，需要定期做备份恢复的演练，确定备份文件可用，恢复流程和方法执行顺畅。
增强制度：
增强不是增多制度条目数量，繁文缛节不是一个务实的技术团队的应有风格，而是追求用最简练的办法，增强制度逻辑的严密性和可操作性。把上述原则以制度文件的形式确立下来，凝聚开发、测试、运维和运营团队的共识。
DevOps对于风险控制的意义
DevOps这个概念近年很火的概念，每个人都有不尽相同的理解，其根本目标在于打通开发团队和运维团队无形的墙，提升生产效率和软件研发和运行质量。DevOps是一个以此为追求目标，也是一种为此目标的文化，更可以是为此目标而落地的手段和工具。其落地方式通常就是实现自动化的开发、集成、测试、交付以及运维管理的流水线。
所以，DevOps绝不等同于运维开发，运维开发只是实现DevOps工具落地的一种组织行为和手段，也是被大多数公司认可的有效手段，然而完整的DevOps往往还应该包括自动化的需求管理、开发、构建、编译、测试，而不仅包括从发布流程才开始接手的运维自动化。
我接触到有些精干的小公司，甚至没有专门运维开发的团队，他们按照自己团队的特点，通过文化宣贯，组织协作全体技术人员，对各自板块的自动化流程和工具落地，并且进行对接，从而完成跨团队全流程的自动化流水线，也很好地实践了对DevOps的落地。
自动化对于风险控制的意义：
1.降低人为操作导致的不可控性
2.减少风险控制的成本：包括物质成本和人力成本以及时间成本。
自动化的前提和基础
高度的标准化：
标准化硬件、标准化软件组件、标准化流程制度
统一的资源数据库（cmdb）
方法：
流程高度抽象、功能细粒度切分、模块化/组件化，在这点实践上，比较优秀的案例，当属腾讯的蓝鲸。
实践DevOps
将风险控制的过程，进行抽象和优化，将作为一种服务的管控 风险过程，进行标准化、流程化和自动化，并最终转化为可用于控制风险的产品，实现产品化。
一个践行DevOps理念的工程师，不论自己所处的角色是开发、运维还是测试，都要向自己负责软件生命周期阶段的上下游，去管控风险。做到提前介入，向后延展。
个人认为，ITIL和DevOps虽然理念不同但是其出发点都是消除风险。ITIL讲究严格的流程控制和职责划分，大家各司其职，通过在各个环节之间建立高耸的“墙”和细密的“网”来“封堵”和“过滤”掉风险。DevOps强调跨部门跨团队协作，消除生产中的技术和制度障碍，提高生产效率，采用敏捷开发、快速交付，通过持续地集成和交付来消灭已产生的风险。ITIL是大步稳进，DevOps就是小步快走。ITIL追求尽可能一步到位，DevOps讲求持续改进。因而，DevOps是应对迅速变化的互联网行业的有效手段，而ITIL在业务形态稳固的传统行业更有生命力。所以，不能一昧赶时髦，为了DevOps而DevOps，一定要结合业务实际，可以兼容并蓄地吸收两种理念，根据业务需要进行落地。
运维团队领导，作为组织目标和计划的制定者、实施者，必须对风险拥有全局观，从长远规划建立风险控制体系的目标。重视考虑团队成员发展，实现个人发展和组织目标的有机统一，让专业的人去做专业的事。增强技能培养，发挥人的脑力价值，带领团队从琐碎重复的工作中解脱出来。7*24小时都在应对风险，不是运维的价值所在。7*24小时无风险，才是运维真正的价值！