运维体系建设套路

随着时间和工作经历的沉淀，会所在的领域逐渐形成一系列解决问题的'套路', 高端的叫法：方法论。有了'套路'，就可以根据公司现状和组织特点建立相应的体系。

当下特点：

当前公有云除了让企业不用关心IDC机房，物理交换机，物理服务器外，还提供了功能丰富的基础组件和中间件，让企业侧的运维不用考虑繁琐的中间件/基础组件的高可用和运维架构，更加聚焦业务侧。出于业务发展特点的需求，第一步：怎么样让业务快速运行起来。这一阶段，需要了解业务的关联关系，业务部署文档， 侧重于广度领域,特点是快。业务发展到一定阶段，就到第二步：怎么样让业务运行得更好? 本质是做精细化工作，如:优化之类的事情， 特点是好。那么在两阶段共存的场景下(既快又好)，如何能够做好运维的保障工作呢？ 根据笔者过往的经验 ，需要流程体系和专业技术，两者都要硬，两者都要抓。

一. 先谈流程体系的建设:

新时代的运维已经不涉及IDC机房，交换机，路由器，服务器硬件，各种中间件和基础组件。这种现状有好也有坏处(好处:交付更加便捷，不涉及组件高可用，中间件底层技术 坏处:运维全领域链条只能了解部分)。这种现状会让运维会站在从研发到应用交付的层面上看待运维保障工作，因此运维的规划可以集中在研发效能体系建设，监控体系建设，变更体系建设，最后是运营体系建设。以下是示意图:

其中 研发效能体系，监控体系，变更体系 是基础， 这些基础工作没有做好，故障频发是高概率的，这种情况下谈不上技术运营。技术运营体系建设作为更高阶段的工作，在运维体系从0到1的过程中涉及不多，因此在此不作详解。

先谈一下基础体系--变更体系，线上的变更：涉及到运维基础层，运维应用层，应用层，业务层， 变更的所属层级越低，影响面和破坏力就越大。就笔者10多年的血泪经验，故障的大多数都来自于变更，越是蜜汁自信的操作，越是要慎重。由于参与变更的人可能是不同团队中不同的成员，变更的范围涉及到不同的层级，每个层面变更的风险以及团队成员在领域内的专业技能参差不齐以及认知差异，极有可能产生故障。如何保障变更不出故障？

建标准和流程，控制风险。

以下是变更的示意图：

让不论是资深技术人员，还是初级技术人员都归纳到相同的规范标准下工作。

再谈一下基础体系--监控体系：

谈到监控，大部分技术人员首先想到的是常用的监控软件zabbix/prometheus/nagios等。监控体系的建设当然少不了监控软件的使用，但除去监控软件的使用，还有大量的跟监控的事情需要做。监控体系本质解决 监控的完整性，监控的准确性，监控的时效性，因此会涉及到监控的频率，可用性/性能维度，质量维度。

例如可用性维度指标的制定，采集，告警；性能维度指标的制定，采集，告警；质量维度的指标制定，采集，告警；还有涉及到不同的层级：接入层，网络层，系统层，基础层，应用层(中间件和自研应用), 业务层。各个维度和各个层级组合才能称得上立体监控，否则谈不上。以下是示意图:

其中接近实时频率的监控产生的海量数据会对运维层面的高可用，扩展性，性能，多机房等带来挑战。同时在性能监控的维度，要做到'洞察秋毫', 也是很有挑战性的，因为如果要做到'洞察秋毫', 至少在相关领域有一定的水准，深度了解其机理。例如：某个接口出现延时，那么是应用自身逻辑层所致？还是JVM的GC所致？还是协议栈TCP重传所致？还是glibc的ABI不兼容导致应用重试产生延时？还是内存分配导致的延时？还是老内核CPU调度延时？总之，从应用上层直到底层的任何环节，都有可能成为延时的原因，从这个角度来看，监控是无止境的。

二 . 专业技术方面的建设：

发现问题是监控体系干的事情，解决问题是运维事件管理/运维问题管理等偏向技术运营体系干的事情， 两者相互促进。告警事件产生的问题/或者人为反馈的问题（技术相关的），转交到运维人员手中，运维人员有不同的处理方式来解决。一种是较浅层次就事解决事。另外一种是体系化思维来思考，该技术问题在自己的技术认知领域属于哪个范畴，在这个范畴的哪个细分领域？ 或者该技术问题已经超过自己的技术认知领域，需要方法论或者摸索来攻克，一旦技术问题解决，不但补齐了技术认知，极有可能会形成自己的方法论或者摸索'套路'。 例如： 监控系统有告警事件，反馈某个接口超时，10秒后自动恢复了， 断断续续出现过2次，但业务层无告警/也无用户投诉。应用运维对此事件可以深入调查，也可以忽略。但是深入调查了一番，很有可能发现: 在宿主机流量高的场景下触发内核3.10. nf_conntrack 的bug导致源端口被复用，从而引起双栈(ipv4/ipv6) IPv6下的 DNS 的response 无法被正确接受， 从而导致域名解析超时，进而影响到某个接口响应慢。技术问题的两种处理方式带来结果差异很大，第一种方式工作10年积累1年工作经验，第二种方式工作10年积累10+的工作经验。个人强烈推荐第二种处理方式，但是第二种方式会带来一个'缺点': 比较辛苦。

纵观 监控-->发现问题--> 技术运营-->解决问题， 本质上是可以形成一个能力闭环， 让参与者在体系化专业知识和形成方法论的过程中形成良性循环。虽然1，2次解决问题不能改变什么，但是随着不断地解决各种问题，终究会产生量变到质变的过程。

以上仅经验所谈。（不喜勿碰）