无论是基于云平台还是IDC，又或者是openshift，我们搭建出的一套完整的DevOps环境，不能太依赖于其本身的稳定性以及可靠性，需要对这一套环境进行运维，运维内容包括但不仅仅限于trouble shooting、monitoring等。

今天我们会从运维的角度来聊下我们需要对一套 DevOps 系统如何进行维护。

1、监控定义

观察并记录系统状态变化和数据的流程。

• 状态的变化：可以通过状态的直接度量或者更新日志来表示
• 数据：可以通过记录内部组件和外部系统之间的请求和响应来记录

支持这些功能的软件系统即监控系统。

2、监控目的

寻找整个环境中的坏点，搜集多层指标，记录日志，绘图以及分析日志，以及时找方法修改，恢复整个系统的健康。

下图为AWS云平台某一虚机的监控状态：

3、监控指标

大部分监控数据来自于系统的不同层级，为了实现监控的大部分指标，我们需要把整个系统包含在监控中。被监控的基本项包括输入，资源和输出。资源可以是软件资源，也可以是基础设施指标（CPU、Memory等）

监控指标主要包含以下几项：

1）故障检测

首先，我们需要对故障做个定义，故障是指系统中部分元器件功能失效而导致整个系统功能损坏的事件。

从Infrastructure的角度看，任何环节都有可能出现问题，如断电，断网，机器死机等等，由于这些问题是依赖于基础设施的稳定性以及可靠性，用户对该类问题没有绝对的好办法，但是可以做一些高可用的措施，比如异地多活，多可用区容灾等。

从软件层面看，故障可能是部分接口出问题，也可能是整个系统崩溃。

软件故障检测主要有三种方式：

• 监控软件从外部对系统进行健康检查（AWS Cloudwatch等）
• 系统内的特殊代理执行监控（自己安装的一些代理软件）
• 系统自己检测到问题并发出报告

我们可以更早的发现的问题，并在软件层面做及时的修改，以免整个系统的瘫痪。

2）性能

性能下降检测是监控数据最为常见的用途。毕竟对于一个完善的系统，故障发生的概率远远比不上性能下降来的多，因此，如何及时反馈整个系统的性能以便能够采取措施提高性能，成了一个系统能否对外提供稳定服务的关键。

性能的度量包括：

• 延迟：延迟是指从一个请求开始，到获取服务端响应数据为止所经历的时间。这一阶段会有几个部分组成，其最主要延迟来自于网络传输时间+服务器处理时间。因此，在监控处理的时候， 我们可以着重监控网络性能以及服务器的处理性能，设置指标如服务器20s内无响应出发报警等。
• 吞吐量：吞吐量是单位时间内某个特性类型的操作数量，如每分钟读取硬盘数，或者每秒钟的事物数等等。吞吐量提供了一种系统范围的度量，延迟只关注单个客户端。当然吞吐量的绝对值并不能说明根本问题，比如吞吐量的下降有可能是用户数的下降。
• 使用率：资源的使用量或者使用百分比，通常在用户感兴趣的资源中插入探针来度量。比如CPU、内存、硬盘。CPU可以定义阈值超过80%报警，高使用率可以作为提前预警延迟或者吞吐量的问题，因为高的使用率会导致服务器处理性能下降，处理速度变慢，导致客户端收到的响应变慢。

我们一起来看下一个简单监控系统：

在监控过程中，我们需要对告警做一个过滤或者合并，比如，当CPU超过80%并保持80%以上1分钟，那么触发一个报警，那么，这种情况下，CPU超过80%，且在1分钟内降下来，就不算一个告警，应予以过滤。

一旦监控数据被搜集起来，那么我们就可以做许多的事情：配置警报通知运维人员或者开发人员告知系统发生了变化，对于系统的健康状态做一系列的报表等。

简单明了的Dashboard可以将监控数据只管反馈给运维人员，当然，监控系统也允许运维人员进行深层次的log调取以及数据分析，这对错误诊断，RC（Root Cause）分析和决定最佳解决方案有至关重要的作用。

4、监控 DevOps 的过程

1）持续变更下的监控

由于云的广泛使用以及Devops变更是常态的特性，我们对于Devops系统的监控受到了很大的挑战：

• 云弹性​

公有云，如AWS、Azure提供了IaaS和PaaS层的服务，他使得基础设施资源变得唾手可得（如果钱够的话），我们可以对虚拟机资源进行一系列的横向或者纵向扩展，往往是简单的鼠标点几下就可以实现。

而且对于大多云平台来说，都会提供AutoScaling的服务，当你的虚机某些指标超过预设的阈值时，就会实现横向的扩容，保证服务的可用性，或者缩减机器，减少成本。这就给监控策略以及监控方案的实施带来了很多不便，比如代理的部署。

• 自动化的 DevOps 运维​

他能出发很多零散的运维操作，比如升级，重配置，备份等等。持续集成和持续部署使得软件变更更为频繁，我们一天可能会发布几十甚至上百个版本，每次部署都是对系统的一个变更，这也会影响到监控，因为每一次的发布都需要更新监控数据，你不可能拿老的数据来分析新版本的问题。

我们应该尽可能的自动化警报，监控配置的过程其实也是一个DevOps的过程，它应该也需要自动化，当你提供一台新服务器时，需要自动在监控系统中注册这台机器，当服务器停止时，应该自动触发注销流程。

2）微服务的监控

谈到DevOps系统，我们就无法避开微服务，它使得可以为每个服务提供一个团队，但是，这样会让你的系统变成一个深层次系统，每个外部请求都可能要穿过大量内部服务才能得到响应，如果一个服务响应很慢，那么整个响应时间就会拉长。

在大型系统中，在任何用户能够忍受的范围内，一部分的响应延缓会导致整个系统的响应不可接受。对于在具有许多节点的微服务架构中，尽早确定并修复问题节点，是一个很大的挑战。

3）大容量分布式数据的监控

在一个大型系统中，安装的每个agent都有可能影响CPU、内存等性能，而且每秒钟可能会产生数以百万级的log数据，关于数据量，有如下考虑：

• 在很小的时间间隔内收集性能指标的开销是巨大的​

取决于系统当前的状态，运维应该使用可变化的可调节的间隔，而不是一个固定的时间。监控颗粒度可以根据业务的重要程度做一定的区分，比如对于关键业务启动详细监控（1min）对于非关键业务可以启用一般监控（5min）。

• 使用分布式日志或者消息系统搜集日志，而非自己构建

比如，分布式日志搜集系统Logstash，能够搜集所有类型的日志，并且在本地处理，这种类型的系统可以减少开销，甚至在本地识别错误。比如Kafka，一个高性能分布式消息系统，可以将输入数据以及处理过程解耦。

持续部署的实践提高了变更的频率——从应用到底层基础设施，面对这种变更，需要我们的监控做实时的调整，这就要求监控本身也是自动化的；对于云带来的变革，监控策略和监控工具也要做响应的适应。

系统的复杂度，分布程度和规模都在增加，指标和日志的巨大容量要求新一代基础设施能支持对大量的监控数据的收集、传输和存储。一旦收集了大量的监控数据，为了从这些数据中筛选出有效的数据， 可能要依赖于大数据的分析。

二、NOC & MSP

可能有的朋友还不知道NOC和MSP是什么。

1、NOC

NOC即Network Operation Center，如果要用一个直观的概念描述NOC的话，我只能说：7*24。

不论你正在享受晚餐，还是在电影院享受二人世界，又或者你正跟兄弟们准备上高地。。。一个电话过来，所有的都得放下，因为你的系统可能正遭遇服务中断，或者宕机，又或者被黑客攻击，少则用户投诉，多则损失上亿。

运维本身就是一场没有硝烟的战争，你必须在尽量短的时间内，给出响应，查出原因，保证损失的最小化。

对于DevOps系统来说，首先，我们需要明白的是，他的存在是为开发服务的，我们构建这一套系统的目的，就是为了减少产品从开发到上线的时间。

因此，我们必须保证DevOps系统的稳定性以及高可用性，因为你不会知道到哪个开发团队会通宵用你的系统来构建、测试、以及发布版本，一旦你的系统出现的问题，比如CI阶段卡住或者发布不了版本，那么在没有灾备的情况下，开发团队只能疯狂的Call你。

如果你有一套在家的办公系统，能够随时解决问题，倒也是一种方式，但是更多的时候，你需要对你的DevOps整个系统进行7*24小时的监控，不要等到问题发生了，开发团队给你电话了，才被动的去寻找问题的原因，而是通过一系列的监控工具预先发现问题，把可能发现的问题扼杀在摇篮里。

当然，不是所有问题都能够预先发现的，很多事故的产生都具有偶发性，因此我们需要定义一个流程作为应急方案，下面是一种比较Common的流程：

对于一个NOC完整流程，当我们的系统出现警告，那么我们就需要同时做两件事情：

• 通知 DevOps 的开发团队以及运维团队有警告产生，那么开发或者运营团队需要对整个警告做一个认定，需要在规定的时间内将这个问题open；否则，就会将这个问题上报至更高一级的领导，直到问题解决为止。
• 同时，NOC Team 应该对此告警做一个模拟测试，是否本地也能复现整个错误，如果可以复现，那么立即将此告警上升为故障，并且通知所有干系人，直到问题在规定时间内解决为止；否则，继续观察整个警告的解决状态，如果一直处于open未解决状态，那么 NOC Team 就需要一直测试，直到改警告的状态被置为 Solved。​

对于NOC来说，更多的是需要在警告出现的第一时间内将流程运行起来，保证与此警告有关的干系人能够第一时间收到消息，并且把fix的流程跑起来，同时需要对产生的告警进行常规测试，判断该警告的严重的程度，决定是否要上升该警告的级别。

2、MSP

MSP即Managed Service Provider，如果说NOC是警告的过滤者，那么MSP就是警告的终结者。

其实，MSP并不是一个新鲜的词汇。在企业IT市场上，这个词至少有20年以上的历史。只不过，在国内较少被提及。因为在过去相当长的时间里，国内企业喜欢自己建设、自己管理IT系统。

而在欧美发达国家，托管服务早就被广泛接受，提供这类服务的商家就被叫做managed hosting provider服务托管。

这个业务模式在欧美尤其盛行，很多大型服务提供商都在扮演服务托管的角色，为企业提供IT系统代运维或者代管理数据中心基础设施服务直到云的出现，才将MSP这个名词重新提到公众的视野，但是如今的云MSP的概念已经有所不同。

托管服务只是云MSP的职能之一，其他职能还包括为企业提供与公有云相关的咨询、规划、改造、迁移和管理服务。

对于基于云平台搭建的DevOps平台，当然也是属于我们MSP所关心的范围。我们简要来列举下MSP所需要做的事情：

1）问题跟踪

这个是所有MSP需要处理的最Common的问题，一旦系统出现问题，我们需要查看一些log来进行问题跟踪或者历史操作查询，直到找到根本原因，并把问题解决。

这些可能会涉及到使用云平台现有的trouble shooting工具，或者自己在现有的资源上安装agent。

但是，需要注意的是，对于安装工具的性能需要有个清晰的认识，比如在生产环境上安装一些重启生效的工具是有一定风险的，因为如果不重启，工具不生效；重启的话，有可能会影响现有业务。

2）业务咨询

这个不是针对于具体的Service，但是范围也是很广泛的，包括云平台架构的优化、数据库的设计、云平台资源问题的咨询等等。

这些对于MSP Team来说，都要有专业的人员对接，一旦用户出现此类的咨询，比如一个VPC内的EIP上限是多少，我的业务需要多少EIP，是否需要提前申请例外，云平台申请流程是什么等等，需要给出比较专业的解决方案，这样才能增强用户的信任度。

3）资源规划

尤其是对于云平台，如果说使用了云平台，不能把预算做到最低，那么上云有什么意义？

一个好的MSP团队应该有能力帮用户把云平台的cost精算到个位数，对于当前业务所需要的云平台资源要有一个清晰的认识，在保证高性能和高可用的情况下，把资源的经费降到最低。

4）管理服务

• 对于用户的权限管理

这也是一个比较科学的话题，既要保证用户对资源的操作的最小权限，又要保证整个平台的安全，要知道，一旦用户的权限给错，导致用户有权限删除资源，而正好他又不小心这么做了，那么对于整个平台可能是灾难性的。

所以，需要有专门的人员对当前的用户权限等做严格的把关，保证整个平台在权限角度的安全。

• 对于数据安全的管理

这是一个比较古老的话题，因为这是很多用户决定是否上云的一个关键点，对于这一点，我们可以建议部分上云，关键数据坐落在本地的IDC，运算部分push到云平台上，这样既能节省资源，也能消除用户对于数据安全的顾虑。

当然，目前云平台提供的加密机制也是比较完善的，有静态数据加密和动态数据加密等等，安全系数甚至比本地要高。

5）Dashboard

对于一个完善的MSP团队，一个易用且功能完善的Dashboard是非常重要的，毕竟，用户不会拿着你给的Linux操作数据一行行看

NOC和MSP是连个联系紧密的模块，NOC为MSP提供分析数据的来源，MSP为NOC分析数据以及提供九诀问题的方案。小的方面来说，一个DevOps系统需要这样的系统支撑；大的方面来说，MSP和NOC对于一个完整的分布式系统也是不可或缺的。

本文对于 DevOps 系统的运维做了简单的介绍，当然，运维的过程以及期间遇到的问题远远不止这些，我们需要在运维的过程中不断发现问题以及解决问题，直到把整个DevOps 系统做到尽量的完善。

世界上唯一不变的就是变化，因此，对于 DevOps 的运维也不能过于死板和固守，因为基于云平台的架构以及对于云平台底层知识的匮乏，有时候基于云平台的底层bug，可能很难找到根本问题或者根本找不到问题，那么，我们为什么不能先解决问题，再去找根本原因呢？

来源：​ ​http://www.jianshu.com/p/83901e7c2679​​