运维工作很无趣吗？值不值得做？ 第1页

我觉得运维很有意思。特别是当能够抽象出属于自己运维理念并在工作中印证对照的时候，会有一种在实现自我价值的满足感。这里分享一下我运维生涯总结的一些个人感悟。不定期更新想到啥写啥，可能会比较散大家将就看。以后有空我会整理一下

1、学会用时间纬度分析运维事故；

一个事故有故障产生时间点、报警感知点（或用户感知点，取先发生的点）、运维受理时间点、故障升级时间点、根因确认时间点（或解决方案确认时间点，取先发生的点）、故障恢复时间点。每相邻的两个时间点形成一个时间段，各个时间段加总就是著名的Incident MTTR。那么为啥要分成几段？因为每一个时间段的长短都代表一种或几种具体的IT运维能力的成熟度。举例，故障产生点到报警或用户感知点的时长代表贵司监控覆盖度，感知点到受理点的时长代表贵司的监控有效度或用户响应度等等等等。这个技巧的具体的用法是在复盘的时候除了问“这个事故怎么产生的？”再多问几个“为什么这个事故里这一段时间那么长？”，你就会发现其实运维的问题远比系统挂了这件事多得多

2、采用广泛风险跟踪管理

运维成熟度的评估和测量来自于整体事故的总合，但是具体IT运维风险的识别却来自于每次对单个事故的具体分析和风险建档跟踪。ITIL里这一块的最佳实践叫Problem management（问题管理），但是我个人不太推荐完全照搬，盖其太过关注技术根因而忽略了非技术风险。现实运维中的非技术风险靠个人经验是危险的，哪怕运维规范和章程也只是减轻了一些常见风险。比如巡检和业务高峰期变更就是非技术风险，可以通过规范章程改进，但现实中其它的非技术风险数不胜数且同样致命。比如多外包商服务模式的混乱、用户错误、业务变更不通知IT、三不管地带等等等等。有意思的是当一个重大事故用上面介绍的方法被分成时间段后，通常能很容易地暴露出多个风险，有技术的有非技术的。所以每次故障发生后总结归纳跟踪这些问题并定期报告会产生可以指导行动的报表（actionable report）。归根到底，从日常事故中鉴别、分类和持续跟踪技术和非技术风险的能力才是确保运维能力不断改进的基础。如果我们看到吃一堑再吃一堑的情况不停地再发生，除了懒政之外，基本上都是这种能力的缺失

————————————————————

再来说一下老生常谈的监控话题，这个话题太大我先说几个常见的误区，有空再回来做一些深层次的总结和个人思考。

误区一：补锅式监控

出了事故后加监控这事每个运维都干过，短期可能有挺有效但是时间长了监控越加越多，长期来看除了收获越来越多的误报，大家觉得事故变少了吗？我曾经见过一个单一系统埋了两千多个监控点还是每周出事故。这里其实有一个有点反常识的知识点（敲黑板）：基于错误模式匹配的异常检测是低效的。高效的监控是识别正常模式，正常之外皆为异常。熟悉时序数据的同学大概率知道anomaly detection，它的原理就是先根据正态分布原理计算出统计学上的“正常”区间——其余皆为异常。现实世界的运维里你的系统会以各种千奇百怪的有些你八辈子都想不到的姿势挂掉，正常的姿势却只有一种，紧接的下面一个误区就详解一下什么是正常姿势。

误区二，监控做不好是因为缺少专业监控软件

我司的WAN经常发生地域间网络连接质量问题，一些事故里需要花几个小时才最终定位到是网络端问题，于是网络团队花了大价钱买了最专业的网络监控软件。然并卵，问题照样抓不到。后来我复盘他们的问题时发现都在抓各种高端网络设备指标和错误，端口丢包率，SNMP TRAP和更多我不知道干嘛的指标。于是我用脚本和iperf做了个最土的监控：检测每两个地域间的丢包率和延时，然后他们就再也没有错失过WAN问题的报警了

提这事就是为了说明一个道理：再好的监控工具也只是工具，不等同于监控能力。抓不住关键指标，再专业监控软件也帮不到你。那么怎么去识别最重要的监控指标呢？（这里我先略过一个服务的概念以后有机会细说）用户用得舒心的网络服务长啥样？其实很简单——网络通且速度快，对应指标就是丢包率和延时。好了现在我们开始抽象，把网络两个字换成任何服务可以得到用户对服务的最重要的感知指标就是：功能可用（availability）且在预期的时间内完成（performance）。可以自己尝试一下泛化这个概念。比如公司附近新开业了一家哥佬官火锅店（提供就餐服务）。结果你慕名而去的时候服务员说今天号领光了（service unavailable），或者有号但是你要排三个小时的队（capacity问题照成的performance降级），请问你的心理阴影面积。

好用的监控首先会把目标放在识别和采样这两个服务关键指标上，再去向下扩展到会直接影响到这两个关键指标的相关指标。这两个指标如此之关键，以至于在运维语境下已经等同于user experience了。

———————————————

一切皆服务（Only service matters）

有多少人想过我们到底在监控什么？一台服务器硬件本身是没有监控价值的，甚至通了电开了机装了操作系统和应用软件之后还是没有监控价值。只有在服务器上运行的应用开始被业务使用之后，这台服务器才开始具有监控价值。那我们具体在监控什么东西呢？服务器的作用就是为了跑应用代码，代码要有输入输出。所以服务器向代码提供了计算服务（computing service）和网络和存储（IO）服务。前者监控中体现为CPU利用率、RunQ、内存利用率等指标；后者体现为disk latency、file system utilization等。看出来了吗？应用代码在使用服务器提供的computing和IO服务，而我们在监控这些服务器提供的服务。再泛化一下，这台服务器是提供数据库服务的被你的应用服务器调用，你要监控数据库指标吧；你的应用是给其它业务应用提供鉴权服务的，你需要监控请求成功率和请求延时吧？你的业务应用是给客户提供采购订单输入服务的，被终端客户直接调用的，你要监控用户使用感受吧？你的用户在一个下单到库存到配送的业务流程中为客户提供一站式采购服务的，你需要监控整个流程效率和流程异常吧？现实世界中有且仅有各种服务们在相互调用。取决于你在这个生态里的哪一层，这层的服务就是你应该监控的首要目标。服务越靠近客户价值，监控价值也就越大，通常也会意味着越难以监控。前面已经介绍了服务的两个最重要指标，不再介绍。下面我们引出关于服务第二个最重要的概念：

运行时服务调用依赖（service mapping）

服务每一次被使用可以叫做产生了一次服务调用（service call），服务为了满足这次调用产生的所有活动，包括对其它服务的调用称为一次事务（transaction）。大家应该已经看出来，这是一个树状结构的层层服务调用，每个节点都是一个transaction，大的transaction包着小transaction。研究过调用链监控的同学对这个概念会很熟悉，本来微服务就是同一个平面上的服务间的相互调用，这里只不过又加了一个纬度反映不同服务层次间的依赖。这里可以抽象出一个概念了，服务间的关系有两个方向：平面的调用和纵向的依赖。服务间是如何调用的和transaction的具体执行相关是动态的，而依赖通常相对比较静态。为什么要介绍这么抽象的东西呢，因为清晰了解服务间调用依赖关系再加上层层服务监控几乎是所有运维人的最终梦想，意味着可以实时了解到一个事故的根因以及产生的业务影响。如果看历史数据这样的能力提供了持续服务改进和风险收益评估需要的大量信息。

个人认为一个称职的运维需要站在他支持的服务上向前后上下各看多看一层服务：上看依赖你的业务服务；下看你依赖的基础服务；前看调用你的服务；后看你调用的服务。如果各个方向上分别继续穿透更多的层，那基本上不是架构师就是产品经理。

我们需要多少监控工具。监控是运维里最老生常谈得话题之一。运维入门通常是Nagios或Zabbix之类的，进阶一点就开始捣腾ELK和时序数据，牛逼一点的上调用链监控。看起来林林总总工具一大堆，其实归根到底监控最重要的就是服务测量，其余的报警通知画图等功能都是测量的外围。专用监控工具开箱即用给了一堆通用组件的测量方法，当你发现你要监控的东西已经没有这种开箱组件可以用的时候就开始捣腾从数据源头比如日志或程序埋点自己做测量了，历史数据太多粒度太细你就开始上时序数据库了，为了适应微服务和快速定位根因就开始上调用链了。最终开始测量监控业务流程了就可以叫中台了，到此你的监控也差不多齐活了。所以监控工具选择真的很多，但是每种用一样就好，如果不是技术狂最重要的是不贪多够用就好。花太多力气选工具远不如想想监控啥好，最土的工具只要能监控对的指标就能起大作用。上新工具这事最好留到你真的碰到了技术限制的挑战再说