DevOps 三步工作法之持续反馈的技术与案例

导言

很高兴参与DevOps时代社区的拆书联盟第一季活动，有幸能与几位DevOps大牛一起解读《DevOps Handbook》一书，这本书作者牛，内容也很牛，就连著名的培训机构把这本书作为DevOps认证培训教材。

书中不仅方法论和实践丰富，而且所有案例都是取自于硅谷互联网企业的DevOps最佳实践，很值得我们研读。

《DevOps Handbook》的拆书活动，共分成七部分，我负责的内容是“DevOps三步工作法”的第二部分：反馈实践。

《DevOps Handbook》把持续反馈的内容分成三部分：

• 第一是持续反馈的技术与案例，介绍在持续交付之后构建持续反馈体系的方法，主要是监控和告警能力的建设。
• 第二部分会介绍优秀的持续反馈如何反作用于持续交付和持续集成。
• 第三部分介绍实现持续反馈的非技术要素，包括组织、人员等软文化。

第一部分介绍的是持续反馈最核心的技术——遥测技术。

一、持续反馈的技术与案例

1.1、认识遥感技术

我是做运维出身的，我们聊到监控的话题，这张图是比较经典的图，如果没有很好的规划我们企业运维对象监控的能力，往往我们发布完之后都是一脸蒙圈，保障业务质量要靠求神保佑。

同时做运维监控的成绩很难被衡量，而企业对运维监控的期望值很高，这便有了这么一句话：“出了任何故障，其他环境都是可能有问题，唯独监控是一定有问题！”

如果监控发现不了问题，那一定是监控做得不到位。你很难说服老板说你花个几百万或者十人的团队去把这个监控系统做好，给企业或组织带来什么样的价值，我们怎么样去说服老板，怎么样体现运维的价值，而不是让运维一直在DevOps价值流的最下游，这是我们这次拆书会要探讨的一个话题。

我会摘取很多《DevOps Handbook》中硅谷实践的案例，也会结合我在腾讯这么多年的技术实践，也会拿腾讯的案例跟大家共同探讨怎么做好运维监控。

这本书把持续反馈里面核心的技术用英文描述Telemetry monitoring，翻译成中文是遥测技术。当我念完正本书之后，发现这个遥测技术就是我们平常所说的监控和告警。

本书分了四个大的部分去阐述，第一部分是指标，提出了我们在做DevOps的过程，无论是持续集成、持续交付还是业务已经投产运营了，我们要监控的指标有哪些，这里包括了我们要识别出有哪些指标应该纳入我们的监控范围，我们要怎么样去定义它，怎么样描述这个指标。

举个QQ业务的案例，作为运维我们要怎么样描述QQ这个业务是健康的。按我们正在执行的经验，我们会把QQ的在线用户数C2C的消息量，还有发图片、信息，这种量作为度量QQ健康与否的标志，就是我们对不同指标的定义。

还有范围，像QQ这么大的平台，我们要看一万个指标来判断它是正常的，还是说有一个指标就可以定义它是不是正常的，这就是我们对指标的一些讨论，后面会具体深入讲。

第二个是能力，为了拿到这些指标去度量业务质量，运维人员要去处理它，要对指标按照服务器集群或业务管理的方法、管理策略，来进行指标采集、分析、异常识别、通知等。

这些能力会依托于监控平台，为IT技术人员甚至是为业务产品人员提供服务。换而言之，如果要实现一个监控平台，从基础设施选型、存储架构设计，到软件与硬件的需求，再到一些非功能规范，像日志标准化等这样一些能力，会在探讨持续反馈的遥测技术时跟大家聊到。

为什么要遥测技术，先跟大家分享一个笑话，有时候运维同行交流时都会讲一个段子，其实运维挺容易当的，只要懂的运维三板斧：“重试，重启，重装！”，就行了。

当然这只是一个玩笑，笑话之余还是想引出一个很现实的问题，运维人员日常在处理异常问题或故障时，经常会走入一些惯性思维的陷阱，书中提到一个案例，有多少人在使用Windows系统的时候遇到蓝屏，用户可能本能的会去重启Windows操作系统，慢慢你觉得Windows的蓝屏习以为常了，而重启windows便成为条件反射的解决方法。

但是DevOps的方法论里面其实是不建议或者要人们去杜绝这种惯性思维的陷阱，遇到这种问题应该反思一下，究竟为什么没办法通过监控来识别这个问题，定义的监控指标是不是没有覆盖到这个故障的发生，如果要去度量业务的质量，那指标必须要覆盖它。

不要认为这个事情我们看不见，它就是不存在的，运维最怕的就是墨菲定律，你越不想它发生，它就越有可能发生，如果运维发布了一个应用程序，但是对它的监控仅仅只停留在对服务器的CPU、内存、网络、硬盘的监控，对它的业务指标视而不见，无论那些硬件的指标运行的再好，有可能它的服务都是有问题的。所以我们必须先弄清楚运维的对象应该怎么样去制定我们覆盖的指标，去度量它。

书中提到了Etsy公司的监控实践，简单介绍一下Etsy公司，这本书的作者是三步工作法公司的CTO，Etsy公司是做垂直电商卖一些小众的手工艺品。

Etsy在公司的监控实践里，它2009年就开始从传统的运维模式向DevOps转型，到2011年，这本书的作者认为Etsy这个公司已经转型的差不多了，是一个比较成熟的DevOps公司。

当时他们为了针对一个很简单的电商系统，所有应用层面的指标已经超过20万个，覆盖了他们的应用、操作系统、数据库、网络、服务器、安全等等所有的对象，他们的技术实现是用ganglia做数据采集，用现在很流行的grafana做监控大屏。

书中特别提到一点，2014年时Etsy公司的监控指标已经突破了80万个，但是他在这80万个监控指标的基础上提炼了30个指标来作为他们的大屏监控，无论他的指标再多，他们只要保证这30个大屏的指标不异常，他认为全局的服务是ok的。

这个跟腾讯的海量业务运营下我们的监控实践得出的结论是一样的，目前腾讯SNG有超过10万台的服务器，业务指标加起来绝对是Etsy公司的好几倍甚至上十倍。

我们也得出了一个这样的实践问题，在分布式架构、微服务架构、业务高可用、容灾等技术加持下，度量业务的质量是不是还需要去看到每一个最细节的指标，还是可以再高度提炼一层用来快速度量业务质量的指标？

这时候我们的运维团队选择了提炼了指标，在腾讯内部的DLP智能监控平台，会从成千上万的指标中提炼业务生死指标，用来代表该业务的关键质量。

并且针对不同的监控场景，如异地多活架构的监控，还抽象了专门用于调度指标的监控，这些都是为了把监控指标更好的分层，让运维在服务出问题的时候能快速发现，能及时响应处理这个故障。

书中有个观点，如果想评判一个企业的监控能力的好坏，可以参考下图（左边），是DevOps报告对2014年硅谷很多家公司统计出来的，这张图的数据认为监控能力做得好的企业，它的工程效率会很高。

同时，统计数据中认为运维处理故障的能力是监控能力弱的168倍的。MTTR代表故障发生之后修复故障需要的时间，MTTR时间越短，监控能力越好。

右边这张图，MTTR等于MTTI，就是发现故障的效率，还有MTTK，找到这个故障根本原因的一个平均的耗时，然后到MTTF、MTTR。

所以我们有理由认为只要把我们的监控能力覆盖度做上去，我们可以更快的缩短MTTR，让我们的业务质量可以有更强的监控能力去保障。

构建遥测技术的基础设施，书中提到一点，传统IT团队，如果要做监控，举一个案例，现在我们很多传统行业，以金融为例，金融行业它的组织架构先天分了研发中心、测试中心、数据中心，数据中心更多的是运维，他们负责了基础设施、数据库维护的工作。

对于数据中心来说，如果按照传统职能划分，更多的是保证基础设施指标的可靠，基础设施传统意义上就是网络、设备、主机，更多一点事故，有没有慢查询等。

还是套用刚刚那句话，在业务高可用或者分布式做了这么多年的背景下，我们监控这些指标是不是足够，这些指标是不是能直观反馈出业务真实的情况。

显然答案是不足够的，为此本书提出了下面的能力，需要体系化的去规划监控平台的能力，这里包括了分层监控应该怎么样做，包括对不同的架构层级，IaaS层应该监控到什么能力，PaaS监控到什么能力，应用层监控到什么能力。还有数据处理能力，它是不是能够满足维护业务高可用、业务可靠质量的要求。

腾讯运维的思路也是类似，如果一个典型的互联网架构按照下图展开，DevOps所提倡的价值流，它是从右往左去给用户提供服务，怎么样产生价值，从左往右，用户使用了具体的服务，才会对企业产生价值，我们的技术也才能发挥原有的要实现用户需求的目标。

我们做监控也是一样，按照这样的层级划分，在腾讯织云的监控平台里，对所有的监控指标进行了这样的分层管理，我们把最基础的更贴近于基础设施，没有带任何业务属性的、具有很强的通用性的指标叫低层次指标，把跟业务贴近的指标称之为高层次指标。

但是在海量运维的压力下，就像我所在的腾讯SNG社交网络事业群，所有超过千万的用户的业务有160多款，这么多款业务我们没办法说每个业务又这么复杂的微服务架构，我看你高层次指标，度量你可用性，还是看不过来，因为我们的运营部只有100人，100人维护10万多台机器，160多个业务，假设每个业务有5万个指标，那共有多少个指标？所以我们在高层次指标之上再提炼一层，刚刚也介绍过的DLP指标。

对应看这个倒三角形右边的图，我们基于不同的指标监控，还针对性的去提炼了一些运维的工具，这些都落实到织云的产品中，为的是帮运维更好的去处理不同层次的指标。

举一个例子说明上图，针对低层次的指标，假设应用程序的进程不存在了，那意味着应用程序进程挂了，端口也会不存在，究竟监控系统应该告警还是可以通过自动化的方法去把它解决，还有主机的硬盘容量满了，是不是有一些约定俗成的规则去自动化的完成无用文件的清理，实现简单的治愈。

同样的，高层次的指标有很多，像我们做业务监控时，究竟应用的日志是落地还是不落地，如果是落地的，就通过日志去采，变更的过程与业务指标变化之间关联如何实现，配置管理要怎么做，怎么样通过高层次指标提炼出DLP指标，这要求CMDB、自动化系统、监控系统之间要有关联的方法和经验沉淀。

1.2、遥测技术的应用

介绍完遥测技术，再来看看在它的应用场景。遥测技术可以应用在什么地方，书中给了三个方面。

第一，对运营中的服务，已经投产的业务应用，我们应该有所监控、有所识别。

第二，对CI/CD阶段，同样也要提炼一些指标来进行识别，例如每一次构建耗的时间、错误数或失败数，也需要去做监控做统计，部署的过程中，有哪些测试环节出错了，这个发布是不是应该正常把风险带到生产环境，还是说发布的一个过程。

第三，书中还提到在构建监控能力时，应该尽可能把监控能力服务化，包括哪些能力是可以给用户自助去完成的，或者提供可二次开发的API给开发团队，让他们按照他们的使用场景去封装。还有监控平台自身的高可用和性能的评估，这是很DevOps的做法，我们一起来看怎么样去达到这一点。

腾讯的一个案例，我们对基础设施的监控不仅仅局限于一些简单的硬件指标，还把它深入拓展成很多维度的指标，这张图不一定枚举全，但是想说明这样一个事情。

为了保证不同环境的一致性，我们甚至会对内核参数的配置、NTP时间服务、系统重要的补丁，crontab的内容，都加上监控。

同样，对硬件产生的dmesg、coredump、操作历史、负载等等的监控，都把它归为系统监控，系统监控在腾讯的实践中是属于最低层次的指标，这些低层次指标可以逐层汇总成高层次指标，能够反映业务的一些问题。

如果低层次指标要往高层次指标去靠，最直接做法，相对也是不需要研发团队太多去改动他们的业务代码或者说不需要嵌入太多运维团队要求业务逻辑，《DevOps Handbook》这里提出，可以通过对应用日志的监控来实现对高层次指标的收集。

书中的例子，美国航天局NASA，每次发射火箭时，工程师们都会做足了指标的采集，对每一个零配件的方方面面具体在运行时的表现都有实时的监控，来确保这次火箭发射。

因为一个火箭发射可能涉及几十亿上百亿的成本，如果发射失败，这个消耗是很大的。在模拟操作时，就应该确保每个零件是ok的，以保证结果是符合预期的。

这里提出来，在DevOps所提倡的IT价值流的过程中，每个成员在价值流中的每个动作是不是都覆盖了，指标监控都有相应的日志输出。

这里对日志提出了几个方面、几个维度标准化管理的思路，包括对日志的类型应该怎么样做，包括记录业务流水的日志还有技术的日志等，甚至可以记录它的性能信息，记录它事务的一些信息。

日志需要分成不同级别，与Linux系统的syslog日志级别类似，包含Debug、Info、Warn、Error、Fatal的级别，不同的级别意味着输出的详细情况是不一样的，这就让日志监控拥有分层，或者监控识别异常的时候，它就会有一个取舍，知道哪一个错误是优先级的。

例如像Fatal的错误，致命的错误，可能我们在设计一个告警能力的时候，它就应该打电话，如果只是警告的级别，可能隔天发一个统计的邮件让我们去处理。

还有对日志格式的要求，建议我们从日志输出的路径、内容，它的格式是什么样子的，它的编码是什么样子的，是用逗号分割还是用分号分割还是用井号分割等等，都是便于我们在做日志分析的时候采集难易度的问题。

还有日志管理的问题，日志怎么写的，是无限的这么写下去单个文件还是每个文件写200兆，循环写10个文件，这些都是需要我们在做日志监控时要考虑清楚和提前规划的。

此外，在定义日志内容的时候，书中还给了一些建议，我们可以按照指标类型的不同，可以区分开业务逻辑的日志长成什么样，非功能的日志长成什么样，性能的日志，还有可以尽量去记录一些日志的关键事件是怎么样的，这是书中给的几点建议。

右边是腾讯运维在做项目时的一些日志标准化的图，为了脱敏，我画掉了一些关键的信息。

大概想表达一点，如果运维团队能跟开发团队有一个很好的协商，在真正编码之前我们能把很多可能对业务逻辑、功能逻辑无关的一些非功能的需求说明清楚，提出来之后，实现这种东西，对大家都是有好处的。在持续反馈的阶段，这个很有利于运维对服务的监控。

做织云平台日志监控时，我们对日志监控能力做了从低到高的分层，最简单的日志分析，在织云里叫做特性上报，做监控平台的工程师不需要去理解业务的日志是怎么样计算的，各个指标之间究竟是做加法、做减法还是做最大值、最小值、平均值这种逻辑。

监控只提供平台能力，而业务开发或运维只要在应用程序中或在旁路的脚本计算好，然后将得出的值，通过调用监控平台的能力往服务端去上报。

织云监控agent会暴露上报数据的API给用户，用户自定义的算好逻辑，然后给监控服务端上报数值，例如100、100、100、120、150、160、170，然后服务端就会根据用户配置的异常识别策略，假设大于150我就会给你发告警。

这就是一个最简单的方法，这个是解耦的比较彻底，但是这样要求研发人员他可能要具备比较强的意识，这种特性上报的方法会在开发侧造成比较多的工作量。

还有一种这种的方法是日志采集，我们按照约定俗成的日志格式，应用程序把日志输出，运维按照标准化约定的格式去做日志的监控，识别完会在服务端展现，这个技术类似于开源的ELK技术。

最好的状态是日志不落地，直接通过API的形式，应用程序直接把它的流的数据上报上来。这种监控方法要求研发要键入一定的运维提供的API、SDK，提供统一的数据传输通道的能力还有汇总的能力，例如要做一分钟的汇总，来降低Agent端对服务端的压力，这一块特别是在移动APP的监控，像QQ同时在线有2.7、2.8亿，如果不做收敛，每秒都上报，会有几个问题。

第一，用户端的耗电承受不起。

第二，服务端要囤大量机器来扛住这么大的并发上报请求。

在腾讯的监控实践中，基本上90%以上都是通过嵌入API、SDK形式实现对业务的监控，因为这样做不仅实时性好，而且在客户端这边为了做监控而消耗本地的硬件性能也是相对最可控的。

再附上腾讯的流式监控平台的架构，无论是对日志文本的采集还是对流式数据不落地的数据监控模式，对服务端的能力来说都是类似的，如果大家做过流式监控，看这个架构图都大同小异，流式监控无非分成三个部分定义：

第一部分是数据采集端

第二部分是列的处理逻辑端

第三部分是做最后的告警还有一些数据可视化的端，这一块不详细讲，在腾讯做了这么多年的监控实践里，最难的是我们如何能够通过这种流出来的后台架构，能够承受海量的流式数据的上报。

我在《运维三十六计》里也提到了容量管理的原则，空间换时间，我们在实时处理的Storm集群之前搭了消息队列，让消息队列来扛住这个大并发，在消息队列之前还搭了一个做转发请求的集群。

这个集群可以做几个用途，第一可以按照我们的需求将不同的流数据转发在不同的Storm集群去处理，来分摊大业务上报请求量，避免因影响其他的小业务。Storm处理完，我们会把准实时的结果数据存在消息队列kafka，在线的一些运维监控系统就实时，因为kafka跑的是内存，可能成本比较大，这个取决于投入监控的运营成本，成本投入得多，那存储的时长越久。

《DevOps Handbook》还提到怎么把遥测技术服务化这里协调提到一个Etsy公司的案例，Etsy公司的这个工具叫statD，它在github那里已经开源了，我专门去搜了一下，有1000多个星，大家如果感兴趣也可以看一下。

这个技术跟我刚刚介绍的织云特性监控的技术基本上一模一样，它其实就提供了一个Agent，让你可以部署在具体的主机上，它不理解你的业务逻辑，你自己的应用程序要按照statD的格式，把监控数据处理成K:V的形式，例如CPU50、CPU51、CPU55，这样去报，它就会在后台绘出右边这个图，你上报K是Login100、Login200、Login50、Login30，你就可以在它的服务端设置一个最大、最小值，然后它来做告警。

当然设置阈值是不是最优雅的，我们会探讨怎么样去识别异常。具体statD怎么样去实现这种方法，我没有细看，我们可以基于我们做织云特性监控的实践经验去跟大家说，必要的四步：

首先申请id，去给这个id报很多K:V，或者报字符串，报字符串也是可以做告警的。你的业务程序一直去自我判断你去上报，ok，你突然报一个no，然后你在我的服务端配置，遇到这过no的字符串的时候就发告警，或者你报Error、Fatal都可以，或者你也可以设置成所有非ok的都会发告警，然后服务端就会给你绘出来，ok就一条线，非ok就掉下去了，告诉你策略的识别，这个比较好理解。

书中还提到假设我们现在已经构建成了一套很完善的遥测技术，监控告警能力做得很好了，它还提出我们光是有指标还不行，我们还要把这个指标在DevOps团队中透明起来，因为DevOps文化里有一个很重要的文化就是要分享，我们之间没什么可以隐瞒的，各角色成员之间的信息都是透明的，开发人员不要捂着掖着，你代码质量差就是差，你要告诉团队。运维也是，发生了故障，你就告诉团队错了。

书中还提到一点，当然老外的文化肯定是强调要免责、不问责、不罚款，这是贯彻实施DevOps的价值观。但是还提到一点，有点惊呆了我，我告诉我的小伙伴，我的小伙伴也惊呆了。

书中特别提到一点，在Etsy的文化里，他们会把自己的故障信息甚至都同步给他的客户，他的大屏会对客户开放，并且上面发生的每一个故障客户都可以看得到，Etsy工程技术的负责人说，把监控指标具体的情况对整个团队公开，不仅有助于公司内部IT团队的团结，加强他们的沟通、信息的传递、持续的反馈，公开给客户还有利于增强客户对他们技术能力的信心，但是不确定在中国这样操作合不合适。

书中还提到，我们要不停的去思考为什么遥测技术能给我们带来怎么样的能力，像我们之前也提到了，做好了监控体系的规划和它的指标覆盖，可以把生产环境中的MTTR，就是故障处理的时间缩得很短。

同时对生产质量做很精确的度量，在做持续交付的时候很好的度量。同时，当故障发生的时候，这个指标很清晰，是谁的问题，就事论事的去解决它，而不是单纯说开发团队把锅甩给运维团队，或者运维团队为了不想背锅又去扯皮，加重上线发布的流程等等。

这种东西都是不利于DevOps提倡的最终实现企业的共同目标，因为企业IT的目标就是为了实现企业的目标。通过这样的做法，我们能够不停的去修复指标，不停让我们的开发和运维、测试合作更紧密，慢慢就变成DevOps的团队。

书中还提到一个Linkedin监控平台的实践，Linkedin是2003年成立的，当时他那种业务模式在北美很受欢迎，迅速获得了用户，用户的基数应该是独角兽式的增长，一年增长到上亿用户。

他们很快意识到一个问题，当年运维团队做监控的时候也只是针对传统基础设施的监控，他们当时起了一个实习生的项目，让实习生尝试去推一些日志标准化，自己写一些采集的方法，在基础监控之上做好业务监控。

这个案例最终得出了一个平台，叫做Zenoss，这样一个Linkedin现在在用的系统，他现在也把这个系统产品化了，大家也可以在谷歌上搜一下，这个系统也可以对外提供服务，监控你公有云上云主机的服务，可以上报到Zenoss的服务端，可以给你做可视化的监控。

这是当年一个实习生做的项目，截止到2010年时，它已经变成Linkedin这家公司里最核心的监控平台之一，由这个监控平台所衍生出的很多核心的业务指标都被用大屏展现出来，所有去Linkedin参观的客户也好，自己内部的无论是业务人员还是IT人员，都可以看到，是很关键的东西。

作者也希望从这个案例论述监控真的很重要，但是我们的监控不仅仅是为了做监控而监控，一定要去思考怎么样能跟业务的价值做贴合，这才是我们做监控的意义。

除此之外，有了对指标的定义，还需要对监控的指标做持续优化的工作，包括我们一定要坚持找到我们目前所有的指标是不是有一些缺陷，例如不要陷入这种惯性思维，假设有一个指标，它一直告警，久而久之就像狼来了不管它了，我们要重视每一个误告警，要要让它根治。

这里我特别想提一个，我2009年在腾讯负责的是系统运维，当时我们生产环境的服务器规模还不是特别大，2万台实体机，一个系统运维，就是我。

当时老板给我安排了一个特别的任务，老板觉得说为什么生产环境的硬盘容量告警一直困扰着大家，要求我想办法去把它优化掉。

当时我做了一些数据的分析（95%的硬盘使用率就告警），发现一些硬盘告警重复告警很多，每次告警完，虽然有人及时处理，但仅处理到90%，并未根治。可能隔两天又写到95%，又产生告警。

按照二八原则，80%的告警都集中在那20%的机器，没办法可以根治它。后面我在我们内部推磁盘清理策略，把容易产生告警的自动清理的规则，人能清理，机器也可以清理，把一些日志不合理的情况修复了，这个告警就不存在了。这个案例也是想说明我们千万不要陷入这种惯性思维，不要让狼来了长期存在下去，我们要让误告警消失。

文章还提到间指标上下文关联很重要，例如我在社区在同行里也经常交流这样一个事情，很多运维同行都提到了一个问题，我在做变更的时候，监控系统太多了，我没法每个系统都去屏蔽告警，我不屏蔽，做变更时又会产生大量的误告警，怎么办，这个典型就是一个监控指标没法跟其他系统进行上下文关联的分析。

我在做织云产品设计时也考虑了很多，我们的变更怎么样跟我们的监控，我们的基础监控怎么跟我们的业务监控去关联，一定要有个上下文关联的机制，无论是通过配置还是通过自动去识别，这个关联是很必要的，特别是在我们海量规模运营的过程中，一定要做好。

同时他还提出需要对我们持续交付的全过程来进行监控，这里给了个建议，他认为持续交付的全过程主要分成五大块，第一块，我们部署完，你能不能马上看到我业务指标的变化，你部署完能不能马上看到我具体部署的这个应用程序或者说这个微服务它的延时、负载、返回码、成功失败率的变化，还有我部署完这10台基础设施、10台主机，它的基础信息有没有变化，硬盘使用率有没有涨，硬盘IO有没有涨，等等，这个供大家去完善。

我们有理由认为指标监控的目标绝对不是为了监控这堆废铁它是好是坏，最主要的目标还是要监控我们的业务，这个铁盒子，我在外企呆过，外企把主机和服务器叫box，这个box运行的状况其实不是我们最care的，我们care的是假设运维发布了100台主机，哪怕有10台失败，如果业务不受影响，相应采取的处理措施是完全不一样的。

这样我还是引入刚刚那个图，低层次指标其实是面向于技术人员的，或者说低层次指标我们面向于运维，那运维有必要去标准化它，通过一些高效可靠甚至是自动化的方法去解决低层次指标发现的问题。

你通过负载均衡，通过怎么样的一些运维工具去处理。高层次指标是要运维与业务开发一起去看的，最终能代表业务质量的指标，如果拿腾讯织云的实践按理来说，就是DLP指标，技术人员（开发与运维）应该是跟业务共同去看的，如果这次发布，在灰度的过程中业务的DLP指标就受影响了，那这个灰度必须马上停止回滚。

越面向于技术的指标越丰富，越面向于业务越是要少而精的，这样才能体现出监控对业务的价值，还有技术驱动业务价值。

这里是书中Etsy公司的案例，在他们部署Pipeline中，部署Pipeline就是他们自动化部署的流水，大家其实可以看一下，黑色的竖线是他们在做PHP发布的时候，他们一发布，7点发布，发布完陆续就会有一些深蓝色的新产生的bug，有用户反馈了，浅蓝色是他们逐渐接到很多反馈，8点他们再发了一次变更，修复了深蓝色的。然后去做这样的一个变更跟我们监控的结合。

除了刚刚介绍到的几个层次，我们要对基础设施低层次的指标要监控，高层次指标要监控，DLP指标要做监控之外，在《DevOps Handbook》里还提出了，对指标的覆盖度不要满足于现状，要确保每一个会影响到DevOps交付流水线的所有对象相关的指标都要纳入监控。

这里也给了几点，基础设施对一些环境变量是不是也可以监控起来，资源的一致性，现在我们做很多自动化的操作，就存了两份数据，一份是在数据库的数据，一份是运行在生产环境的数据，怎么样对比它的一致性。

今天我们没有重点去聊自动化，如果后面我们有机会直播聊自动化，我也可以跟大家聊一下我在这块的技术实践是怎么实践的。

还有日常运维活动，像有些团队经常在凌晨做的跑批量操作，每次跑批的效果是怎么样的，是不是每天它的耗时都是差不多的，是不是突然有一天，假如跑批平常都是用一小时的，今天十分钟就跑完了，有可能就是异常， 运维对这些活动都需要去监控，还有备份、调度，甚至是舆情，甚至是看看App Store有没有人在骂业务等等，这些监控都是需要不同的指标去覆盖。

讲完监控技术、监控基础设施还有监控指标应该怎么样定义怎么样去规范，接着聊一下第一大部分的第三小部分，拿了这么多指标，怎么样可以识别每个指标是正常还是异常，一些异常分析算法。

书中给了一个案例，Netflix，美国最大的视频网站，当时Netflix遇到的一个问题，因为做点播的视频平台，他们的集群很大，大到一些集群有大于1000台主机，他对这1000台主机进行监控的时候，他们遇到了一个问题，原则上1000台机器提供相同的服务，它所有的指标表现都是一模一样的，他们遇到的第一个问题，怎么样可以找到一些outlier，用中文解释就是一些离群值，怎么样识别。

他们可以结合他们的自动化，假设1000台机器，所有的cpu都是50%的负载，突然有10台是80%，又是无状态的，我是不是可以自动把那10台干掉，把80%弄掉，因为基于木桶原理，这里也广告一下，在《运维三十六计》的容量管理里也写过类似的策略，对所有的容量管理，一个集群都是一个木桶，木桶的最短板就是你这个集群里负载最高的设备，你就把它干掉，来确保水位一样，这样才是最健康的集群状态。

Netflix找到了一个方法，下面我们看一下这个方法，指标异常分析的第一种方法，标准差。这个方法其实就是反馈一个数据集它的离散程度的，标准差越小，这个数据集里面各个值之间偏差越小，反之亦然，偏差大，越离散就有问题了。

标准差用了一个算法，叫高斯分布，高斯分布是高斯发明的，在腾讯内部我们习惯用正态分布这个称呼，分三个级别，右边这个图，凡是符合标准差分布的数据集其实都是处于一个中型的分布，当我们第三标准差偏差越小，数据和数据之间的差异不会超过99.7%。这里我列举了它的一些优点，不具体展开讲这个算法。

标准差的优点有一个好处，不需要人工定义阈值，在多年织云监控实践中，得出了一个经验，阈值是不可靠的，随着业务量的变化或者随着服务的升级，阈值的准确性要靠人维护，一旦你照顾不周，就会变成误告警，然后整个监控告警可信度就会受到挑战。

所以我强烈推荐大家能不用阈值的就不要依赖阈值。用正态分布实现动态阀值的不足是对数据集有一定的要求，你必须要符合高斯分布中型的图形才可以。

标准差的识别，它给了一个案例，当有一个Nginx作为web服务的时候，假设突然502的返回码增加了，出告警了，就以HTTP的返回码作为业务质量的反馈，我们马上就可以来看每个监控对象指标的表现情况，应用层面是不是被攻击了，数据库被拉挂了，后端服务不可用，或者操作系统级别是不是有什么问题，是不是这时候在做一些数据大量的备份，把主机的IO吞吐满了，导致DB数据处理性能很差，有一些SQL堵住了，网络吞吐是不是受影响了，这样技术人员马上就可以通过标准差的方法去识别，因为一台Nginx，当业务请求固定的前提下，在用户不会爆发增长的前提下，所有的业务指标其实都是一个平滑增长的过程。

如果按照我们第二标准差，你前一个点和后一个点的数据不要超过95%，前一个点还是100%，那你后一个点是95%，我都认为你是正常的，你不要跌到90%或者80%，这样我们就可以结合业务场景说这种场景可以结合第二标准差，动态的判别识别出异常。如果企业的业务更稳定，就像腾讯很多业务相对都比较稳定，就像QQ的同时在线，是很稳定的，我们就可以用第三标准差来做这种识别。

标准差很好，正态分布很好，不需要设置阈值，很自动化很智能，但是它对数据集有要求，假设现在有一个数据集是像左边这个图形这样，不满足高斯分布，我们应该怎么样去处理。

大家可以看左边的图，如果按照高斯分布的方法，把每个时间点的平均值都求出来，然后你会发现它的图形像右边这个图形一样，数据集不符合高斯分布的图形，不是中型的。

它是一个长尾形状的，这种形状没办法用正态分布，因为如果用正态分布用第三标准差，你会发现就会一直告警，用第二标准差、第三标准差，第三标准差都不行，你看它9月9号那个值，跌得这么高，是不行的。

但是事实上又会存在这种图形，是什么样的情况下会存在这种图形，就像广告投放，它是有一定的规律性的，例如每天都会投一些新广告，举业务场景，微信广告，但是有些广告点的人多，有些点的人少，点的多的可能就比上一个广告高一点，但是也不会高到哪里去。一旦高起来，运维又要做一些动作，例如可能需要扩容等，这种方法怎么解决。

书中给了另一种方法，与腾讯监控的实践类似，书中把这种告警异常的识别方法给了一个名字，叫平滑性或者平滑度，它其实是一种很典型的做法，我们在互联网做监控的时候也会这么做，那就是基于时间序列的指标的分析。

平滑性，右边这个图，蓝色的线代表了实际业务的情况，黑色的线是我们取了5分钟一个时间窗口，或者3分钟、1分钟一个时间窗口，把这个时间窗口里面实际产生的数据做一个平均，这个平均的目标是为了削峰填谷，就是抖动的全部把它过滤掉，这样得出来的一个平均数的曲线是一个平滑的值，对这个平滑的值再来用标准差，再来用正态分布，再来用跟历史数据的对比，反正就不用阈值，你可以跟同比、环比对比，这个数值如果是平滑的，如果它没有超过标准差，那认为这个数据平滑的，它是可以正常运作的。

书中还给了Netflix的案例，Netflix有一个工具，大家都知道Netflix是亚马逊云最大的客户，他全部的服务都是跑在公有云的。

他们需要根据他们具体的一些广告、电视连续剧，收看得好，那他的广告曝光率就高，他需要根据他的动态负载来自动扩缩容，这个场景其实在腾讯或者在我所负责的织云平是很常见的场景，容量涨了，马上给它扩容，下下去。

左边这个图其实就是基于时间序列它的业务走势，基于这一个时间序列的走势，我们可以预测未来一段时间业务走势是什么样子，或者根据历史经验，如果我的曲线涨成这样，它肯定就涨不上去。

这时候就可以启动他的Scryer，申请AWS的机器给他扩容。右边这个图，下降的时候都是垂直下降的，这就是它的容量，它的容量如果是70%，扩10台机器可能变成65%，就垂直下来了，然后再扩，一点点这样扩下去，而不是一次扩到位，他是根据最真实的容量表现情况去扩，保证他每一笔消化在公有云上的费用都是性价比最高的，而不是说我现在的业务涨上去了，老板你马上给1000台机器给我储备，但是它是不是涨到1000台的请求量，不知道，所以这时候这个做法值得我们参考。这个做法跟我在一些运维大会上分享腾讯织云的做法也是类似的。

书中还提到了一些针对异常指标分析的方法，包括包括傅立叶、K-S，K-S是基于历史数据，可能运用了统计学同比环比这种东西。

还特别提到，无论是Etsy公司还是Linkedin公司，他们认为监控的平台做到最后，他们都在运维团队培养了一些叫做学统计学的运维工程师，这个我们也一样，甚至现在我们在做智能化监控的时候，我们织云团队也招聘了一些学数学的博士在给我们做机器学习智能算法，也希望后面跟大家深入探讨。

书中提到的是方法无限，但是我们为了更智能的去预测或者分析指标的异常，我们没办法逃避的，必然要面对运维人员或者做监控平的运营开发人员，他必须得掌握一些统计学或者一些机器学习的新时代的高科技的算法。

这里给了一个Etsy的案例，像这样的一个曲线分布，如果用标准差的方法或者说平滑度的方法，都解决不了这种问题。

这个图形如果基于平滑度的算法，一旦它的业务量跌下来之后，在12月，在这里，业务量跌下来之后，在这里如果是平滑度的话，它会告警一次，但是告警完，如果你没及时处理，后面它的平滑度就不会再告警，因为它一直会很平滑，因为它的指标没有恢复到之前的那个层面。

对于这种图形，他提出了可以基于KS算法，基于历史数据，在这个虚线的时间点，一定要恢复到这个值，不然它就没办法。

书中海油一个观点，我们做业务监控时，一定要严格意义的根据我们的业务形态去做。

假设这个图形是我们电商做完促销回归到平常，那是ok的，但是我们做促销，像马上双十一，双十一一定会涨的，明年的双十一也是会涨的，后年的双十一也是会涨的，如果有一年的双十一没涨，那它一定是有问题的，这些历史数据我们都需要不断去沉淀，应用到我们的异常识别中，让我们的算法更加智能。

提一下机器学习，机器学习有一个好处，无论是有监督还是半监督的算法，可以通过一个算法库，它可以按照一些比较智能的方法，能够选用一个最精准的算法来分析现在的图形，找到异常。