作者简介：
梁定安
腾讯织云卖力人，目前就职于腾讯社交网络运营部，开放运维同盟委员，腾讯云布道师，腾讯学院讲师，EXIN DevOps Master讲师，凤凰项目沙盘教练，复旦大学客座讲师。
导言
很高兴参与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的，但是我们做匆匆销，像立时双十一，双十一一定会涨的，明年的双十一也是会涨的，后年的双十一也是会涨的，如果有一年的双十一没涨，那它一定是有问题的，这些历史数据我们都须要不断去沉淀，运用到我们的非常识别中，让我们的算法更加智能。
提一下机器学习，机器学习有一个好处，无论是有监督还是半监督的算法，可以通过一个算法库，它可以按照一些比较智能的方法，能够选用一个最精准的算法来剖析现在的图形，找到非常。
文章版权归DevOps时期社区所有，不得商用转载，如学习转载请注明出处。感激！
