VUCA 这个词在高效运维社区好几个分享当中都有提到过，现在是变幻莫测的时代，有很多不确定性、易变性、复杂性、模糊性，我们现在的需求变得越来越模糊不确定。以前开发使用瀑布型的模型，完成一个交付可能需要几个月的时间，需求是固定的。但是现在面对越来越多的竞争对手，越来越多的新需求，我们会有很多的不确定性。比如上线一个类似拼多多的拼团业务模型，业务部门往往希望在几周内进行需求交付。
因此，VUCA 带来的持续不断的变化，对于底层的监控系统造成了非常大的挑战，包括技术栈的挑战，包括人员的专业能力上的挑战。所以很多时候，VUCA带来的变化也意味着各种不确定的挑战。
一. Fintech的挑战
大家认为运维的第一要务是什么？
从表面看，运维是一个消耗的部门，会消耗很多金钱和资源，所以对于我们来说运维的第一要务是止损。只有保证线上系统的高可用性，保证业务稳定性，以避免不必要的损失。
上图是一家咨询公司给出的数据，每分钟的Downtime对企业造成的损失。而对于金融行业，尤其是银行而言，这个数字往往会更大。
所以 VUCA 带来的变化给我们带来了很多的困扰。
最大的困扰就是基础架构急速扩容：基础架构的容量会指数级的增长。
其次的困扰就是新技术和新产品的引入：原先银行倾向于使用小机，但是现在我们有越来越多的虚拟化、大数据平台。有些企业会去IOE，会引入华为、浪潮等一些国产品牌；在组成虚拟化集群的时候，时不时会有一些兼容性和稳定性的问题。怎么去监控这些新产品，怎么去发现潜在的问题，这对于我们的运维人员来说也是很大的挑战。
再次，对于人员技术栈的深度要求越来越高。刚进入IT行业，我是一个只会玩玩windows服务器的系统管理员，而现在除了windows，还需要精通linux、虚拟化、存储技术、服务器软硬件、python脚本语言，除此之外还要了解一些算法、安全、DevOps、Scrum敏捷等技术。随着IT行业技术不断的革新，对于人员技术栈的深度要求也是日益提高，这也可以从现在招聘岗位的薪资价格和对面试人员的能力要求中看得到。
最后一点，不同团队之间的协作。开发、业务、运维人员常常会站在自己的角度提出需求：
开发看重代码交付的有效性和效率；业务看重的是业务可用性和一些运营指标；运维更多关注底层基础架构的稳定性。如何满足各方面不断变化的需求，也是VUCA时代给我们带来的挑战。
二. Fintech环境下的监控目标
FinTech环境下的监控目标是什么呢？
在移动互联网时代来临之前，可以说我们长期处于在传统的银行业，服务器数量、人员数量都是在一个比较小的规模上。然而我们现在处于移动互联网的时代，金融科技的环境下，发生了很多的变化，我们有两个APP，一个是手机网银APP，一个是掌上生活APP。
面向互联网的应用使得我们的基础环境，有一个指数性的增长。我们现在会有几千台服务器，甚至上万的服务器，我们的架构也会从以前的单点应用服务器，转变成越来越多的使用微服务、分布式等更先进的技术解决方案，而应用数量也增长了很多。
开发语言仍然使用Java，C#等比较传统的开发语言，但也会逐渐使用python，ruby等比较热门的语言。所个环境的变化，使得我们也引入 Devops、Scrum 敏捷等等一系列的概念、方法论到组织中。
对于运维人员而言，我们需要监控的东西有很多。一般而言，监控的层次是一个金字塔形的架构。通常我们会从操作系统层进行监控，在它之上，我们需要监控中间件和应用；在它之下，我们还需要监控虚拟化层、存储、硬件等。而在每个层面，我们需要监控的东西也是多样的，比如我们监控数据库，会有MySQL，SQLserver等多个产品。
另外，对于监控的阈值标准，每个企业都有自己的标准。即使在团队内部，开发和运维人员也有各自考量的围度。在企业内部，运维人员常常需要面对多个开发团队，因此对于运维人员而言，需要了解的技术也会随之增多，有时候甚至要通过阅读代码去了解如何部署监控，了解需要监控那些指标等。
总儿胭脂，要合理地，有效地部署一个较为完善的监控系统，从技术、平台、组织的各个角度来说，都是非常复杂的。
另外一方面，相信大家也会碰到类似的问题：操作系统、数据库和网络管理员都会说自己负责的系统是健康的，而业务上却反馈了一些异常甚至不可用。归根结底是由于某些监控的不到位，监控深度不足。我把监控深度定义成了四个部分：
第一部分是可用性监控：这是最简单的层面监控，比如：监控端口是否活。
第二部分是性能监控：比如：虽然CPU正常运作，但CPU的占用率是否一直处在一个很高的水平？
第三部分是日志监控：主要是应用日志监控，其次还有安全审计日志、系统日志等。这些日志监控可确保我们人员操作的合规性。应用日志也会为后续的全链路监控提供跟踪依据，为故障定位作为参考依据。
最后一部分是自定义监控：我们会有很多来自于业务方面的需求，自己定义的指标，比如过去十分钟的成交量有多少，虽然这些kpi可以通过其他方式查询到，但是如果能够直接集成在监控系统中进行查询，提供附加的自定义监控，那就能更好地满足业务监控需求，从业务的角度去了解企业业务的运行状况。
综上所述，监控的深度有以下这四方面：可用性监控、性能监控、日志监控、自定义监控。
三. 为什么选择 Zabbix?
选择监控产品的话主要有三种方式：一是完全自研发（如小米的open-falcon），二是基于开源产品进行二次开发（如Zabbix，nagios），三是使用纯粹的商业化产品（如scom，tivoli）。
开源产品可以很好的满足自身的需求，但是开发周期较长，对于开发人员的要求较高，短期内很可能没有太多的产出；
而商业产品虽然有完善的售后支持，但商业产品基本是闭源的，厂商更注重契约精神，对于一些个性化的需求，要么难以实施，要么实施周期非常长，难以进行定制化或者个性化的监控。同时很少有哪一块商业监控产品能够满足全栈级别的监控。
而基于开源产品的二次开发，虽然需要一定的学习成本，但有较好的兼容性和可定制化，不需要花大量的资源去购买商业许可和支持，对于有一定研发能力的企业来说，是比较理想的选择。
另外由于异构平台的兼容性，我们也希望有一款能够覆盖大多数监控需求的产品，实现统一监控，综合考虑最后我们选择Zabbix，因为它在监控的广度和深度上处在一个较好的平衡点。
Zabbix有哪些特点？
● 开源免费，社区支持。 它没有社区版和商业版之分。● 分布式高可用 。很多的监控软件可能就是单点，没有缓存，没有HA等等这些技术。而Zabbix在这方面有这些必要的特性。
● 低级别发现和自动发现 。随着我们的监控设备数量越来越多，我们发觉添加监控这一步很烦，要么就是重复添加了，要么就是遗漏添加了，出故障之后你才发觉有些必要的监控没添加。所以低级别发现和自动发现这两个功能是非常有用的，它能大大提升监控的准确性和及时性。
● 全栈级的监控 。前文提到了我们需要监控的平台以及在每个平台中不同的产品。我们的确可以搭建多套独立的平台去完成监控，但是能否有一个平台可以实现全栈级统一的监控？Zabbix可以。
● 可定制 。现在很多企业都在引入DevOps流水线，但很少有将监控纳入其中的。监控在整个DevOps流水线中应该是一个重要构成部分，因为CI/CD更多偏向于持续交付，但是交付完之后对于运维人员来说，还需要进行持续监控。Zabbix提供了标准的API可以和DevOps流水线做一个很好的集成。
四. 最佳实践&案例分享
最后，分享一下关于Zabbix的一些最佳实践，这些最佳实践可能会对大家在实际环境当中使用Zabbix（或者其他监控系统），会有一定的借鉴作用。
4.1 分布式自动化监控
以前我们的监控系统都是单点的，随着服务器的增加，我们会更注重监控系统本身的稳定可用性。
服务器数量持续增长，应用数量也在增长，对监控系统的压力也会有所增大。同时我们需要有一个平台——而不是多个平台去做监控——有多个平台，势必会导致监控噪音，或者重复添加监控。
另外，我们需要减少人为手工添加监控的情况发生——这可能导致一些监控的遗漏，或者说即使这个监控对象加入了监控系统，但没有合理地增加必要的监控项目。因此必须通过自动化监控（而非手动监控）去确保监控的有效性。
上图中，在每个网络区域会有一个Proxy，相当于班长的角色，它会收集班里面的所有信息，proxy会去和master沟通，这样的话会避免在防火墙上开放太多额外的端口。这也是个分布式监控，用户可以通过Web端访问Zabbix，去实时了解当前系统的状态。防火墙上只开通了必要端口，这样的话不需要打通很多的网络，提升了整个系统的安全性。
对于自动化监控，在Zabbix中可以轻松实现。管理员只需要定义3个要素：监控的主机，模版（某一类型的主机有哪些监控项目；监控项目触发的阈值时多少）以及负责人（某一类型的主机由谁来负责管理）。
以下是具体的实现方式：Zabbix会自动定期扫描用户定义好的网段
（192.168.0.0/16；123.1.0.0/24）。只要定义一次，之后就会每隔一定时间去扫描一次。然后发现网段中存在Windows服务器，Zabbix自动会将它加入到监控系统，并关联Windows模板。同时我们定义这些Windows服务器是属于Windows团队的管理员进行管理，并让两者形成关联。
因此，管理员需要人工进行的只是定义主机网段，定义关联模版，定义关联团队。只要把这些定义完后，Zabbix就会自动定期扫描，一旦匹配这些规则便自动进行关联，省去人为干预的不准确性。
这种自动化监控避免监控缺失或者监控噪音，不需要手动添加监控，只需要定义规则，把后面所有的持续监控的事情都交给了Zabbix去做，这样最大程度减少了整个环节当中人为介入的不可控性。
4.2 双维度管理
在实际监控的过程中，我们可能会遇到这要的情况：我们监控者一台服务器上的数据库、中间件和操作系统。
因为视角不同监控的需求也不同：数据库团队只关注数据库的报警，中间件团队只关注中间件的报警，操作系统团队只关注操作系统的报警，各团队之间只希望收到和自己有关的报警。同时处于安全合规的考虑，在确保报警的有效性的同时，我们还需要确保监控权限最小化。
在Zabbix 中，我们把监控定义成了两个维度，一个平台维度（Platform），一个业务维度（Service-Line）。
平台维度是指所监控的主机上运行着哪种数据库、中间件或者操作系统中。
业务维度是指所监控的主机属于那个业务条线。比如一台用于用户系统的Linux服务器，同时也跑着Tomcat中间件，我们将把它放入P-APP-Tomcat、P-OS-Linux及S-Business-User组中。
所有的P组都会和对应的模板进行关联，以实现标准化监控；S组和人员关联，确保只有业务相关联的人员可以查看监控和收到监控报警。因此，监控既不会有遗漏，也降低了监控噪音。实现了自动化、标准化的监控。
4.3 告警通知
部署完了监控后，接下来我们进一步讨论告警通知机制。总的来说，我们遵循分层通知、多渠道通知、细化通知内容的原则。
分层通知：对于不同的严重程度的报警，我们设定了不同的报警级别和报警策略。Zabbix中有5种报警级别，实际生产过程中，我们使用了其中的三种：Disaster，Warning和Information。
我们定义Disaster为直接影响生产的问题，需要管理员立即处理，这些报警也会在第一时间通知到对应的管理员及其直属领导，以及7x24小时的监控中心值班人员；
而对于一些潜在的问题，或者急迫性没那么高的问题，我们会设置成Warning级别，这些报警只会发送给对应的管理员，管理员可选择立即或者稍后处理。Information级别的报警一般用于测试或者不重要的报警级别。
多渠道通知：我们通过大屏幕展现、Email、短信等多个方式进行告警通知。确保第一时间可以将这些通知触达到用户。
细化通知内容：如下图可见，当告警通过短信等渠道被触发时，我们会尽可能将所有的问题纳入在告警中，包括了报警的状态，具体触发报警的内容，报警的服务器及IP地址，当前状态的具体值，联系人和电话。
之所以这么做，可以让相应人员第一时间了解当前监控对象的状态；同时，7x24小时的值班人员也可以第一时间联系对应的管理员，精准触达。
4.4 面板展现
无论哪一类的监控系统，多需要有完善的视图展现功能。传统商业软件的定制化较差，或者没有那么容易上手，无法满足自定义的需求。在Zabbix中，提供了丰富的图形展现功能。
随着Zabbix版本的不断迭代，视图展现得到了不断提升。如上图，这是一个在Zabbix2.2版本中的一个面板展现，我们会把整个面板分成上下两部分。上半部分的每一朵云就是一类业务系统，比如用户登录系统，安全系统等等。可以通过不同的颜色知道当前系统的健康状态：
比如红的就代表这个系统存在Disaster级别的报警，黄色就代表存在Warning级别的报警，这样也方便管理员第一时间处理这些故障。也可以通过形状知道当前系统是否处在维护状态（橘色的长方形表示这个系统处于维护模式）。
下半部分提供了一个告警列表，通过告警列表可以获知相当多的信息：当前告警的级别，当前哪些告警时活跃的，是什么时候发生的，发生了多久等等。
3.4版本以后，包括现在4.0的版本，可以做很多定制化。提供更多样的展现。
如果觉得Zabbix的展现不够满意，也可以寻求Grafana、EChart等第三方的插件来实现。
4.5 自动化带外管理
带外管理是比较高级的功能。很多时候服务器会莫名其妙宕机了，我们需要进入机房去找服务器，然后使用一个移动工作台登陆，非常麻烦。
Zabbix可以通过这种方式做自动化带外管理。带外管理痛点如下：
● 不靠谱! 机房人工巡检不及时、有遗漏。● 太坑爹! 固件缺陷等潜在问题无法及时发现。
● 太繁琐! HP、DELL、Huawei等多套管理平台，无法统一。
● 成本高! KVM专有设备需要额外购买，额外KVM交换机支持。授权、机房容量都是成本。
各种厂商都提供了自己的带外管理软件，上面这三个图分别对应的是惠普、戴尔、华为的三个带外管理界面。他们的基本功能类似：重启服务器、服务器软硬件配置、固件升级等操作。
我们会把这些机器的管理口，全部接入带外网络。带外网络中会有一台DHCP服务器自动分配IP地址。OOBProxy这个Zabbix代理会定期扫描整个网段。一旦发现有对应的服务器上线，就会将它加入Zabbix并套用带外的模版。该模版基于IPMI标准实现，因为通过的标准协议，所以不需要考虑品牌的差异性。同时通过Zabbix收集到的数据将为CMDB提供标准化数据。事实上，通过这个方案，初步实现了替换KVM平台，去除了昂贵的硬件和授权成本。
4.6 持续集成/持续交付
发布应用的时候必然会对服务器、中间件、应用等进行一系列的操作，这个时候就会产生监控噪音。如何降低上线过程中的噪音，如何和其他平台做持续集成，也是监控平台需要考虑的。另一方面，在现有业务扩张越来越大，如何科学、合理地进行容量规划，也是监控系统的职责之一。比如我们现在有一个新的抢购应用，如何评估这个系统需要多少服务器、多少资源，Zabbix可以提供这方面的参考依据。
大多数正在进行持续集成的企业，都会有版本控制（如git）和持续集成（如Jenkins）平台，同时通过一些配置管理工具（如anisble）对各个基础平台进行配置管理。
在上图中，如要进行上线发布Jenkins就会通过调用Zabbix标准的API将对应的监控对象放入维护模式，避免了在上线发布过程当中，监控噪音的产生。同时Zabbix会将它收集到的数据和CMDB同步，CMDB的数据也会和其他DevOps平台进行共享，保证我们线上配置是最新的、可用的。同时Zabbix也会接入一些通知平台，微信、短信、邮件等，从而将告警第一时间通知用户。
因此，Zabbix为整个持续集成和持续交付提供了标准的API，可以和DevOps的流水线进行高度集成。同时它也可以收集各种数据，为后期的容量规划，做一个参考依据，而不是拍脑袋决定后面需要多少资源。
综上所述，大家可以根据上述的最佳实践评估哪个监控平台更适合各自企业的需求。Zabbix的好处在于开源免费，我相信Zabbix从功能性上来说，不一定有BAT的自有监控平台那么强，但是它投入的资源非常少，是一个适合中小企业进行全栈式监控的平台。
从管理成本和资源开销层面来说，Zabbix也是非常绿色高效的，不需要花太多人力在监控层面。但需要明确的是任何监控平台都不是万能的，Zabbix也不例外。对一些非常深入的需求，比如对某个应用做详细分析，任何平台都无法自动实现。但总的来说，Zabbix覆盖了80%的监控需求。使用Zabbix的最大收益是减少了人工介入，通过它的自动发现、低级别发现等高级功能，以及和其他DevOps流水线上的系统的高度集成，实现了全栈式无感知的监控。
原文发布时间为：2018-11-14
