在过往的运维经历中，很多研发甚至是运维自己都把运维放在了一个资源（服务器、网络）提供者的定位上。
常常就造成了运维人的惯性思维——我是一块砖，哪有需要往哪搬。

思考一个问题：在云计算、大数据、微服务的新时代场景下，我们如何提升运维的价值？

>> 3点提升运维价值 <<
我认为可从以下3点，提升运维工作价值：

1.服务质量

系统无中断地执行其功能的能力，我们称之为高可用性（High Availability，HA）。
度量系统运行情况的指标最常用的是：MTBF（Mean Time Between Failure，即平均无故障工作时间）、MTTR（Mean Time To Repair，即平均修复时间）、MTTF（Mean Time To Failure，即平均失效时间）。

MTBF：新产品在规定的工作环境下，从开始工作到出现第一个故障的时间平均值。MTBF 越长表示可靠性越高，正确工作能力越强 。MTTR：可修复产品的平均修复时间，即从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。MTTF：系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。

而度量高可用性的方式是根据：系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。


计算公式为：A = MTBF / (MTBF + MTTR)

可用性的年故障时间：99.9999%    32秒
99.999%      5分15秒
99.99%    52分34秒
99.9%      8小时46分
99%       3天15小时36分

为了提高 MTTR，要做到出现故障后尽快发现故障，尽快定位故障原因，尽快修复，尽量不造成新的故障。

做好监控能帮我尽快发现故障，所以我们需要一套完善的监控系统。

2.成本控制

总体来说，就是如何利用我们手头的资源尽量的最大化我们的工作服务。
我们需要检测最高系统访问量下的成本消耗，所以我们要有一套完善的监控机制，确保资源不够时候能快速扩容，过了高峰期之后，我们又能快速缩容。

3.自动化和标准化

这个也是现在Devops比较主流的概念了，底层基于cmdb。上次业务系统做好标准化，尽量花很少的成本去做更多的事情。
打通了运维和开发的一个格局，快速的实现产品的迭代发布和更新周期。当然归根结底是我们要把业务系统关联性和监控性打通。
下面是我在前东家的时候，我们对基础平台的构建，当然后面也简单讲到我们对监控系统的二次开发：

监控解决了什么问题
对于我们运维来说，可能百分之七十的时间，都在跟监控系统打交道，那么一个好的运维监控系统能带给我们什么呢？

1.硬件层面的监控

如果服务器出现硬件问题可以提前知晓，提前安排好解决方案，避免突然出现问题造成损失；

2.软件层面的监控

如果系统资源与服务出现问题，可以及时知晓并解决，同时可以根据周期内监控数据，做好调优；

3.微服务层面的监控

在软件工程发展至今，好像不提自己公司有微服务都觉得落伍了。

4.云平台层面的监控

如果我们底层是以openstack、k8s为基础提供pass平台，那么我们监控也是致命的环节。
在出现故障之前替换掉某个主机，或者节点，避免出现更大故障也是需要的（比如做openstack，我们发现ceph硬盘有坏的，要及时更换，同步分片）


运维软件简单介绍

从11年毕业至今，做过CDN行业的运维，在电商行业众划算、试客联盟做过运维经理，在某国内大型FM平台做过Devops工程师，到现在如今在某500强企业任职openstack 工程师。
技术都是由共通性的，只要把某一部分学会了完成我们的目标即可（记住一点，没有好与坏之说，只是你在特定场景下满足了你的生产需求），当然后面我会阐述为啥我们用prometheus。

1.网络监控：Smokeping

Smokeping 是一款用于网络性能监测的监控软件，通过它可以知晓自己公司IDC的网络状况：如延时，丢包率，是否BGP多线等。通过rrdtool制图方式，图形化地展示网络的时延情况，进而能够清楚的判断出网络的即时通信情况。
最早选择这款软件的时候，是在我们对BGP机房选型和网络测试。机房给两台主机，然后我就基于这款软件的IP端去做网络检测，效果挺不错：

2.邮件告警监控：Nagios

Nagios是一款开源的企业级监控系统，能够实现对系统CPU、磁盘、网络等方面参数的基本系统监控，以及 SMTP，POP3，HTTP，NNTP等各种基本的服务类型。另外通过安装插件和编写监控脚本，用户可以实现应用监控，并针对大量的监控主机和多个对象 部署层次化监控架构。

当时使用Nagios主要是做邮件告警监控。但是Nagios有个问题：它是一个流式数据告警软件，可以对达到阈值的主机进行告警，却不利于追述历史数据。所以以前最古老的解决方案就是，nagios + cacti(nagios 告警、cacti图形展示) 结合工作。

3.仙人掌：Cacti

Cacti 在英文中的意思是仙人掌的意思，Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据，使用 RRDtool绘画图形，它的界面非常漂亮。
但是有个缺点：cacti只是提供图形服务，没有提供告警功能，所以还是之前说的nagios + cacti的方案：

总的来说，最开始学习运维的菜鸟时代，觉得cacti高大上。但是可能刚开始基础较差，经常不出图,导致后来又去学了RRDtool的原理。

4.万物监控利器：Zabbix

Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。当然zabbix最优秀的地方在于，简单，并且可以做到自动化，自动发现，灵活的告警规则，可以定制脚本发送，对接各种第三方软件、实现很多自动化的东西：下面是我们基于zabbix 的一个简单结构：

补充：zabbix对我来说是万能了，自定义监控，我们可以涵盖了很多监控。包括硬件状态、带宽状态、域名告警时间等。
由于zabbix有非常优秀的api，所以基于zabbix和cmdb的开发也是理所当然的，简单的截图说明一下我们之前对于zabbix 所做的工作。
同步cmdb数据到主机主：

cmdb与主机的模板绑定：

给主机添加维护：

结合echart出图：

总结：以上都是zabbix的优点，如果说缺点的话那么只能说zabbix 依赖的是mysql数据库，数据量非常大的时候，会存在性能瓶颈问题。所以从Zabbix 4 版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。还有一点是对云原生和微服务的支持。

5.日志分析利器:ELK

ELK是elastic公司提供的一套完整的日志收集以及展示的解决方案，是三个产品的首字母缩写，分别是ElasticSearch、Logstash 和 Kibana。

最初选择ELK是我们遇到日志量越来越庞大的时候；这个时候需要一个实时的，快速搜索的一个日志分析平台，然后我们选择了ELK。主要用来分析：nginx日志，开发业务日志，系统和历史数据日志等、并且对接到了我们的告警平台。

6.云基础设施监控利器:Prometheu

普罗米修斯是我这边最近主推的监控，一来是简单拿来即用的granafa图表。二来是我这边最近所遇到的困境：

基于云平台openstack 、k8s如何做监控、服务如何发现k8s资源并监控。微服务面临的挑战、我们监控的对象是动态可变的。无法进行固定有效配置。微服务实例间的调用关系非常复杂，如何通过网关等查找到我们相关的请求数据。例如我们这边网关是nacos、spring boot体系。监控系统必须在k8s基础上，快速水平扩容，这既是云原生的基本要求，也符合企业系统微服务化演进的实际情况。（罗辉）

在过往的运维经历中，很多研发甚至是运维自己都把运维放在了一个资源（服务器、网络）提供者的定位上。
常常就造成了运维人的惯性思维——我是一块砖，哪有需要往哪搬。

思考一个问题：在云计算、大数据、微服务的新时代场景下，我们如何提升运维的价值？

>> 3点提升运维价值 <<
我认为可从以下3点，提升运维工作价值：

1.服务质量

系统无中断地执行其功能的能力，我们称之为高可用性（High Availability，HA）。
度量系统运行情况的指标最常用的是：MTBF（Mean Time Between Failure，即平均无故障工作时间）、MTTR（Mean Time To Repair，即平均修复时间）、MTTF（Mean Time To Failure，即平均失效时间）。

MTBF：新产品在规定的工作环境下，从开始工作到出现第一个故障的时间平均值。MTBF 越长表示可靠性越高，正确工作能力越强 。MTTR：可修复产品的平均修复时间，即从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。MTTF：系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。

而度量高可用性的方式是根据：系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。


计算公式为：A = MTBF / (MTBF + MTTR)

可用性的年故障时间：99.9999%    32秒
99.999%      5分15秒
99.99%    52分34秒
99.9%      8小时46分
99%       3天15小时36分

为了提高 MTTR，要做到出现故障后尽快发现故障，尽快定位故障原因，尽快修复，尽量不造成新的故障。

做好监控能帮我尽快发现故障，所以我们需要一套完善的监控系统。

2.成本控制

总体来说，就是如何利用我们手头的资源尽量的最大化我们的工作服务。
我们需要检测最高系统访问量下的成本消耗，所以我们要有一套完善的监控机制，确保资源不够时候能快速扩容，过了高峰期之后，我们又能快速缩容。

3.自动化和标准化

这个也是现在Devops比较主流的概念了，底层基于cmdb。上次业务系统做好标准化，尽量花很少的成本去做更多的事情。
打通了运维和开发的一个格局，快速的实现产品的迭代发布和更新周期。当然归根结底是我们要把业务系统关联性和监控性打通。
下面是我在前东家的时候，我们对基础平台的构建，当然后面也简单讲到我们对监控系统的二次开发：

监控解决了什么问题
对于我们运维来说，可能百分之七十的时间，都在跟监控系统打交道，那么一个好的运维监控系统能带给我们什么呢？

1.硬件层面的监控

如果服务器出现硬件问题可以提前知晓，提前安排好解决方案，避免突然出现问题造成损失；

2.软件层面的监控

如果系统资源与服务出现问题，可以及时知晓并解决，同时可以根据周期内监控数据，做好调优；

3.微服务层面的监控

在软件工程发展至今，好像不提自己公司有微服务都觉得落伍了。

4.云平台层面的监控

如果我们底层是以openstack、k8s为基础提供pass平台，那么我们监控也是致命的环节。
在出现故障之前替换掉某个主机，或者节点，避免出现更大故障也是需要的（比如做openstack，我们发现ceph硬盘有坏的，要及时更换，同步分片）


运维软件简单介绍

从11年毕业至今，做过CDN行业的运维，在电商行业众划算、试客联盟做过运维经理，在某国内大型FM平台做过Devops工程师，到现在如今在某500强企业任职openstack 工程师。
技术都是由共通性的，只要把某一部分学会了完成我们的目标即可（记住一点，没有好与坏之说，只是你在特定场景下满足了你的生产需求），当然后面我会阐述为啥我们用prometheus。

1.网络监控：Smokeping

Smokeping 是一款用于网络性能监测的监控软件，通过它可以知晓自己公司IDC的网络状况：如延时，丢包率，是否BGP多线等。通过rrdtool制图方式，图形化地展示网络的时延情况，进而能够清楚的判断出网络的即时通信情况。
最早选择这款软件的时候，是在我们对BGP机房选型和网络测试。机房给两台主机，然后我就基于这款软件的IP端去做网络检测，效果挺不错：

2.邮件告警监控：Nagios

Nagios是一款开源的企业级监控系统，能够实现对系统CPU、磁盘、网络等方面参数的基本系统监控，以及 SMTP，POP3，HTTP，NNTP等各种基本的服务类型。另外通过安装插件和编写监控脚本，用户可以实现应用监控，并针对大量的监控主机和多个对象 部署层次化监控架构。

当时使用Nagios主要是做邮件告警监控。但是Nagios有个问题：它是一个流式数据告警软件，可以对达到阈值的主机进行告警，却不利于追述历史数据。所以以前最古老的解决方案就是，nagios + cacti(nagios 告警、cacti图形展示) 结合工作。

3.仙人掌：Cacti

Cacti 在英文中的意思是仙人掌的意思，Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据，使用 RRDtool绘画图形，它的界面非常漂亮。
但是有个缺点：cacti只是提供图形服务，没有提供告警功能，所以还是之前说的nagios + cacti的方案：

总的来说，最开始学习运维的菜鸟时代，觉得cacti高大上。但是可能刚开始基础较差，经常不出图,导致后来又去学了RRDtool的原理。

4.万物监控利器：Zabbix

Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。当然zabbix最优秀的地方在于，简单，并且可以做到自动化，自动发现，灵活的告警规则，可以定制脚本发送，对接各种第三方软件、实现很多自动化的东西：下面是我们基于zabbix 的一个简单结构：

补充：zabbix对我来说是万能了，自定义监控，我们可以涵盖了很多监控。包括硬件状态、带宽状态、域名告警时间等。
由于zabbix有非常优秀的api，所以基于zabbix和cmdb的开发也是理所当然的，简单的截图说明一下我们之前对于zabbix 所做的工作。
同步cmdb数据到主机主：

cmdb与主机的模板绑定：

给主机添加维护：

结合echart出图：

总结：以上都是zabbix的优点，如果说缺点的话那么只能说zabbix 依赖的是mysql数据库，数据量非常大的时候，会存在性能瓶颈问题。所以从Zabbix 4 版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。还有一点是对云原生和微服务的支持。

5.日志分析利器:ELK

ELK是elastic公司提供的一套完整的日志收集以及展示的解决方案，是三个产品的首字母缩写，分别是ElasticSearch、Logstash 和 Kibana。

最初选择ELK是我们遇到日志量越来越庞大的时候；这个时候需要一个实时的，快速搜索的一个日志分析平台，然后我们选择了ELK。主要用来分析：nginx日志，开发业务日志，系统和历史数据日志等、并且对接到了我们的告警平台。

6.云基础设施监控利器:Prometheu

普罗米修斯是我这边最近主推的监控，一来是简单拿来即用的granafa图表。二来是我这边最近所遇到的困境：

基于云平台openstack 、k8s如何做监控、服务如何发现k8s资源并监控。微服务面临的挑战、我们监控的对象是动态可变的。无法进行固定有效配置。微服务实例间的调用关系非常复杂，如何通过网关等查找到我们相关的请求数据。例如我们这边网关是nacos、spring boot体系。监控系统必须在k8s基础上，快速水平扩容，这既是云原生的基本要求，也符合企业系统微服务化演进的实际情况。（罗辉）