- 继续推动运维标准化和流程化
标准化和流程化的落地，往往还会伴随着对已存在的系统部署方式进行迁移至标准化的操作。这其实要求我们在执行标准化和流程化以后的所有运维操作完全按照运维的标准和流程进行，对于执行以前的运维工作要进行迁移，目的是要实现所有系统和运维的标准、流程化。对于迁移，一般比较好的方案是：首先保留已存在非标准化系统，同时搭建标准化环境，进行已存在系统的部署并进行测试，测试无误后，与已存在非标准化系统并行运行，同时提供对外服务一段时间后，在评估，最后将已存在非标准化系统进行下线，以达到系统平滑得由非标准化迁移至标准化的目的。
- 建设CMDB
目前线上环境都跑在阿里云， 其它环境基本都是用友云cloudstack, 虽然开发者中心有资源池各主机的信息，但是目前服务器的管理还是依靠手工去登录处理，信息维护也是依靠用户接入或删除主机到资源池，具体信息维护起来麻烦且没有一个直观、统一去监控和配置管理的地方
要做的：
建立用友CMDB系统，结合阿里云SDK、用友cloudstack SDK，开发者中心资源池信息等，建立一个CMDB平台，第一步，能实现所有主机信息的实时显示和统计，如主机配置、资源使用情况、上面跑的应用。通过一个业务，如www.diwork.com, 能查出访问链路图， 如首先经过哪个SLB, 然后到哪台nginx, 再到哪个容器和哪个RDS等。 第二步，能根据业务的使用情况，对重要业务能实现根据资源池的负载来自动创建和销毁主机，如果负载高， 则自动创建按量付费的主机，如果负载低，则可自动销毁主机以节省开支。第三步， 能根据不同的业务制定不同的执行策略，如遇到CPU,硬盘报警、业务报错不可用，访问超时等，可被自动调用处理。
监控
监控是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供翔实的数据用于追查定位问题，分析业务指标等。
目前的不足之处：
之前用Nagios, ganglia, open-falcon, zabbix等作监控报警， 但是只能监控到主机基本指标， 在开发者中心大量使用容器自动分发部署后， 如何监控容器及k8s及各业务指标成为了重要需求， 目前主要监控报警是用prometheus系列来做的， 另外还有一些自写的自动化监控采集脚本去周期性执行并触发报警， 目前监控报警能做到主机基本指标、域名和api调用可用性和访问效率、容器及业务应用的可用性监控，发送到微信，友空间及邮件。
目前的问题是：
- 报警泛滥，没有达到很好的关联性分析，合并，降噪
- 没有很好的去做自动处理， 更多依赖于手工处理
- 现实情况出现的很多故障都并没有那么简单，大部分情况下，这种单一唯独的监控都没有办法很好的覆盖业务的监控需求，发现问题后不能快速定位，只能去一个个手动去查日志分析
下一步要做的：
制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度
1.坚持业务指标采集是代码的一部分原则不动摇，提高指标覆盖率
2.监控方式和指标要标准化，工具支撑系统化
原则1，没有人比模块的研发人员，更清楚其工作机制，更关心其运行状态，模块自身的可运维性就是代码功能的重要组成部分。每次业务逻辑部分的代码变更，都应该伴随着监控指标采集的相应更改。
有了原则1，还远远不够，没有好的工具和体系支撑，提高指标覆盖率就是一句空话。在运维层面，应该制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度。
谈谈监控标准化，标准如何定义？
1.每个业务的每个接口，都要可被监控
2.每个接口的监控指标，必须至少包含：
cps
latency-50th/75th/95th/99th…
error_rate
error_count
3.可以在2的基础上，扩充相关自定义指标，比如：
caller
callee
这样就可以细化到调用关系级别的数据
4.所有的指标上报，采用主动push机制，无需预先注册
有了标准化的指标，很少的几个告警策略就能覆盖到绝大数的业务模块，而不用担心针对每个业务添加不同的告警策略。同时可以针对每个业务，根据不同的用户，建立各自的dashboard，比如针对老板、研发、运维、测试，关注的dashboard侧重点都有所不同
每一个系统的最终用户都一定是人，从用户的角度，模拟用户的访问路径，从而实现一个全面的端到端监控能力，目前已经做了一部分工作，
能够完成事件的触发。也即实现从数据发现、分析、定位、到问题解决的闭环
通过这个闭环我们可以构建各种故障的自愈能力。通过及时的发现异常，快速的恢复，能够有效的提升业务的可用性和质量。
举个实例的例子：当系统发现机器的CPU有异常的时候，需要对 CPU高负载进行故障干预和恢复，这种情况下我怎么做？
我们可以取到告警的信息，告警里会告诉我这台机器的IP地址和告警的值； 通过IP，可以从CMDB中查一下这个机器属于哪个业务，再根据业务信息可以查询到同业务下还有那些机器； 然后我们通过同业务的IP地址把其它机器的当前CPU值都查询出来，得出的平均值再去和告警的CPU值来对比； 最后判断出是否需要系统干预。如果需要修复，系统会根据告警的IP地址到CMDB中去查询相应的恢复策略，再进行处理。
通过这种灵活和完整的验证处理闭环，我们就可以构建出各种可靠的自动故障恢复策略
我们可以把用户请求过程中所经过的节点和链路全部监控起来。再通过综合的分析和汇聚，从而有效果的掌握业务的运行状态，并及时发现异常。
具体实现时，我们可以从最底层的基础网络和链路逐步往上是应用服务器、应用组件、组件请求、服务质量、到最上层的业务状态实现全部的监控覆盖。
1.在线日志分析，使用各种正则表达式来提取相关指标
2.这种方案，定制化程度高，维护成本高，试想想，过了三个月，面对你所配置的一大堆正则表达式规则，你有勇气去面对和维护吗？同时在线分析日志，会对在线服务器造成较大的性能消耗。
3.离线日志分析
4.该方案时效性较低，对日志的耦合高，同时大量日志的传输分析需要的资源消耗也是非常可观的，不够经济，不够轻量。
5.实例自身暴露相关status接口
这种方式，理念已经较为先进了，研发在设计和开发模块的时候，就已经充分预见到了需要暴露哪些指标，来有效的监控自身的运行状态和各种统计信息，但是一千个人眼里有一千个哈姆雷特，每位研发同学都有自己的见解，于是这些接口输出格式和意义各不相同，缺乏一致性的规范，在整体运维的层面，造成困难。
6.各种「外挂」形式的监控程序
这种应该是最糟糕、最落后的方式了，研发在设计和开发模块的时候，没有一丝丝的“监控”意识，没有暴露自身的状态和信息，甚至也没有打印相关重要日志，等到这样的代码上线后，才想起来，是不是需要加一些监控。那么对于这些既成事实，受限于业务的压力，运维只能抛却原则和底线，无奈妥协，然后想尽各种旁门左道的办法，给业务模块写监控外挂。这些外挂和每个模块自身特性紧密耦合，业务一不小心改了，监控外挂就得跟着改；同时如果每个业务模块都这么搞，基本上这些业务就处于事实上的“不可运维”状态了。
看完上面的几种情况分析，再一次说明，规模化的运维，不能是见招拆招，应该全局统筹。针对监控，我们提炼了两条基本原则：
1.坚持业务指标采集是代码的一部分原则不动摇，提高指标覆盖率
2.监控方式和指标要标准化，工具支撑系统化
原则1，没有人比模块的研发人员，更清楚其工作机制，更关心其运行状态，模块自身的可运维性就是代码功能的重要组成部分。每次业务逻辑部分的代码变更，都应该伴随着监控指标采集的相应更改。
有了原则1，还远远不够，没有好的工具和体系支撑，提高指标覆盖率就是一句空话。在运维层面，应该制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度。
谈谈监控标准化，标准如何定义？
1.每个业务的每个接口，都要可被监控
2.每个接口的监控指标，必须至少包含：
cps
latency-50th/75th/95th/99th…
error_rate
error_count
3.可以在2的基础上，扩充相关自定义指标，比如：
caller
callee
这样就可以细化到调用关系级别的数据
4.所有的指标上报，采用主动push机制，无需预先注册
有了上面的一些标准化的指导思想，我们就可以着手开发lib库，推进业务模块接入了。以nginx为例，监控指标采集，可以参考我们的实现http://book.open-falcon.org/zh/usage/ngx_metric.html ，采集到的指标包括：
nginx指标标准化
1.api tag: 即nginx request uri，各统计项按照uri区分。当api为保留字__serv__时，代表nginx所有请求的综合统计
2.error_count、upstream统计项根据实际情况，如果没有则不会输出
有了这些标准化的指标，很少的几个告警策略就能覆盖到绝大数的业务模块，而不用担心针对每个业务添加不同的告警策略。同时可以针对每个业务，根据不同的用户，建立各自的dashboard，比如针对老板、研发、运维、测试，关注的dashboard侧重点都有所不同。
配置管理
常见的配置包括以下一些内容
1.各种开关，比如降级的开关、debug开关、ab测试的开关等
2.各种可配参数，比如超时时间、并发数、日志级别等
3.上下游连接信息
上下游的连接信息，与环境的耦合度最高，是最复杂、最多变、最难处理的部分
配置管理
1.代码（配置）和环境解耦合，用户写好代码，不用再关注测试环境、线上多套集群的差异性，不用关注实例具体跑在哪些资源上。
2.配置集中化管理，使得我们具有自动化拓扑的能力，以及快速切换的能力。
3.支持即时生效、健康检查、负载均衡。
此外，自动注册和发现，这些特性都可以在现有的基础上，方便的叠加。对于运维的系统和基础设施建设，理念的一致性和延续性非常重要，当前的任何一个方案，都要充分考虑和未来三年的长远方向是否一致，今天所做的工作是否在为长远目标铺路，最忌讳的情况就是后来的方案需要不停的推翻早先的方案，业务的改造成本是要重点考虑的。
监控
监控是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供翔实的数据用于追查定位问题，分析业务指标等。
那么残酷的现实情况是怎样的呢？
1.在线日志分析，使用各种正则表达式来提取相关指标
2.这种方案，定制化程度高，维护成本高，试想想，过了三个月，面对你所配置的一大堆正则表达式规则，你有勇气去面对和维护吗？同时在线分析日志，会对在线服务器造成较大的性能消耗。
3.离线日志分析
4.该方案时效性较低，对日志的耦合高，同时大量日志的传输分析需要的资源消耗也是非常可观的，不够经济，不够轻量。
5.实例自身暴露相关status接口
这种方式，理念已经较为先进了，研发在设计和开发模块的时候，就已经充分预见到了需要暴露哪些指标，来有效的监控自身的运行状态和各种统计信息，但是一千个人眼里有一千个哈姆雷特，每位研发同学都有自己的见解，于是这些接口输出格式和意义各不相同，缺乏一致性的规范，在整体运维的层面，造成困难。
6.各种「外挂」形式的监控程序
这种应该是最糟糕、最落后的方式了，研发在设计和开发模块的时候，没有一丝丝的“监控”意识，没有暴露自身的状态和信息，甚至也没有打印相关重要日志，等到这样的代码上线后，才想起来，是不是需要加一些监控。那么对于这些既成事实，受限于业务的压力，运维只能抛却原则和底线，无奈妥协，然后想尽各种旁门左道的办法，给业务模块写监控外挂。这些外挂和每个模块自身特性紧密耦合，业务一不小心改了，监控外挂就得跟着改；同时如果每个业务模块都这么搞，基本上这些业务就处于事实上的“不可运维”状态了。
看完上面的几种情况分析，再一次说明，规模化的运维，不能是见招拆招，应该全局统筹。针对监控，我们提炼了两条基本原则：
1.坚持业务指标采集是代码的一部分原则不动摇，提高指标覆盖率
2.监控方式和指标要标准化，工具支撑系统化
原则1，没有人比模块的研发人员，更清楚其工作机制，更关心其运行状态，模块自身的可运维性就是代码功能的重要组成部分。每次业务逻辑部分的代码变更，都应该伴随着监控指标采集的相应更改。
有了原则1，还远远不够，没有好的工具和体系支撑，提高指标覆盖率就是一句空话。在运维层面，应该制定统一的监控标准，推行统一的最佳实践，提供统一强大便捷的metrics lib库支撑。这样才能更容易的推进自动化进程，以及更高的监控指标覆盖度。
谈谈监控标准化，标准如何定义？
1.每个业务的每个接口，都要可被监控
2.每个接口的监控指标，必须至少包含：
cps
latency-50th/75th/95th/99th…
error_rate
error_count
3.可以在2的基础上，扩充相关自定义指标，比如：
caller
callee
这样就可以细化到调用关系级别的数据
4.所有的指标上报，采用主动push机制，无需预先注册
有了上面的一些标准化的指导思想，我们就可以着手开发lib库，推进业务模块接入了。以nginx为例，监控指标采集，可以参考我们的实现http://book.open-falcon.org/zh/usage/ngx_metric.html ，采集到的指标包括：
nginx指标标准化
1.api tag: 即nginx request uri，各统计项按照uri区分。当api为保留字__serv__时，代表nginx所有请求的综合统计
2.error_count、upstream统计项根据实际情况，如果没有则不会输出
有了这些标准化的指标，很少的几个告警策略就能覆盖到绝大数的业务模块，而不用担心针对每个业务添加不同的告警策略。同时可以针对每个业务，根据不同的用户，建立各自的dashboard，比如针对老板、研发、运维、测试，关注的dashboard侧重点都有所不同。
部署
说起来很简单，部署就是将代码、配置、数据，在一组资源上，保持给定数量的实例在运行。
但，现实是骨感的，存在着这样那样的痛点：
1.新业务接入沟通成本高
2.环境依赖多（PHP/java/golang/c++）
3.上下游连接信息管理乱（拓扑不明确，散落在各个目标服务器上）
4.用户体验不统一（编译打包、发单、审核、执行、观察各个环节脱节）
5.增量更新存在协同上的问题
部署和变更，我们的一些原则：
1.以版本为发布单位
2.统一的接入流程和打包规范（也可以很方便的构建为docker image）
3.集中化的配置管理，配置与线上环境解耦
4.统一的上线流程和检查机制（preview、小流量、集成监控告警、集成趋势图）
5.日志依赖解耦（网络日志）
可以预见，经过坚持不懈的标准化改造，线上服务：
1.配置和环境解耦了
2.监控标准化了
3.部署规范化了
4.日志网络化了
5.数据service化了
6.实例自发现了
7.资源容器化了
8.全自动化调度，顺势而为罢了。
标准化和流程化的建设思路一般是包括三大部分：日常工作梳理、标准化和流程化制定、日常工作标准化和流程化执行
其实在标准化和流程化落地的初始阶段，往往会给工程师带来各种不方便和诸多不适应。典型的例子如下：标准化、流程化给工程师带来的感觉是事情变得复杂繁琐，自己的手脚被束缚，本来很简单的一个事情，几条命令几秒钟就可以搞定，但在执行标准化和流程化之后，变得需要涉及多人或岗位，同时也需要几十分钟甚至几个小时才能搞定，而最后实际操作的可能也就一开始的那几条命令。这是标准化初期的普遍现象，对于出现这种问题要积极沟通解决，让工程师们尽快度过这种看似繁琐、效率低下的初期阶段。解决方法有三：
首先是对工程师以及流程干系人进行标准化和流程化意义的普及。让大家了解知道进行标准化和流程化的意义，标准和流程得进行运维工作，可以大大减少人为失误，同时让大家在同一标准下工作，减少交流成本，相互之间的配合也会更加紧密。团队协作流程化处理问题最大程度的减少相互之间的影响。最后，标准化和流程化是最运维自动化最基础准备。
加快运维自动化的建立。尽快将固化的标准和流程进行自动化的编码开发，大大减少人为操作，提高运维效率，这样运维工程师的日常工作因为大大减少人工操作，较以往会更加轻松。
优化标准化和流程化。标准化和流程化的制定是基于实际的日常运维工作的，在实际执行过程中，应该根据实际情况，进行不断的优化调整，以达到最优。
通过以上三步，减少工程师在执行运维标准化、流程化的烦恼，让大家积极参与进来，推动标准和流程的实施，以快速实现运维的自动化。
标准化和流程化的落地，往往还会伴随着对已存在的系统部署方式进行迁移至标准化的操作。这其实要求我们在执行标准化和流程化以后的所有运维操作完全按照运维的标准和流程进行，对于执行以前的运维工作要进行迁移，目的是要实现所有系统和运维的标准、流程化。对于迁移，一般比较好的方案是：首先保留已存在非标准化系统，同时搭建标准化环境，进行已存在系统的部署并进行测试，测试无误后，与已存在非标准化系统并行运行，同时提供对外服务一段时间后，在评估，最后将已存在非标准化系统进行下线，以达到系统平滑得由非标准化迁移至标准化的目的。
技术标准: 网页打开速度在1秒内
自动化体系和数据化体系。自动化体系以持续交付为核心，数据化体系以智能监控和运营分析为核心
日志标准化:
日志分为webserver日志／用户端日志／应用端日志／接口级日志等等。在定义日志标准的同时，提供sdk化的能力，最终把数据采集回来呈现的效果要平台中看到，在通过数据去驱动决策／驱动优化
- 基础软件及配置标准化
- OS,统一到Centos7, 内核参数统一, 统一主机名命名规范, 资源规格统一(如4C8G, 8C16G, 16C32G)
一个是基础软件及基础设施的标准，主要是操作系统的版本必须统一，内核参数统一，基础设施上，我们用KVM虚拟化技术将我们的资源做成2C2G、8C16G这样的资源模板，确保资源配置的统一。二是应用及配置标准化，这个后面细讲。第三部分是技术架构标准化，技术架构这块分接入层、中间件技术、缓存、DB等，关于技术架构标准化这块，可能是在其他的分享里面可能见得不是很多，这块我后面还是通过案例把基础架构为什么做标准化，它的重要性和它的意义在案例中体现一下。
全链路跟踪系统
随着分布式服务和微服务的增多, 各类应用组成了网状的分布式调用关系, 典型的调用关系如前端Web系统, 各类java应用,缓存, DB,消息组件等, 复杂的调用关系大大提高 了问题定位, 链路调用合理性, 强弱依赖,瓶颈分析等一系列问题的复杂性.
0 Comments