zabbix 硬件功能_运维人员成为组织骄子之路—小运营大智慧：从zabbix开始

乐维社区 1周前

IT运维部是企业重要的部门，组织的运维人员是保障企业正常运行的根本，很多时候他们充当企业“救火员”与“消防员”的角色。在业务部门眼中，运维人员常常因自带技术优势而充满神秘色彩及无所不能。那么，现实中运维人员的状态是如何的呢？作为技术人员该如何突破自己成为组织的佼佼者呢？
以下是乐维丁振兴老师微信讲座全文：
大家晚上好，我是乐维的丁振兴。
今天我主要讲四个内容，一是组织对运维的诉求分析，还有运维技术的功力，从构建基础操作系统开始，第三个从技术到管理的进化，第四个就是运维人员的晋升通道。

一、组织中业务部门与IT部门的对弈

第一个内容讲对弈，主要是业务部门人员和IT部门人员的博弈分析，相互埋怨的一些问题。在业务人员眼中IT部门是成本部门只会花钱而不挣钱，大部分甲方，乙方公司都是一样，互联网公司可能要稍微好一点，主要是IT人员缺乏服务意识，这个情况比较突出。
做事情没有明确的承诺也是引起对弈的重要原因。IT虽然是一个科学，但是这种科学由于若干个技术领域的不确定性，导致运维人员对工作没法承诺，总是说我尽力，我尽快。通常做IT的人对自己的技术很有自信，有些时候就是自信过了头认为自己很牛，包打天下。大部分IT人员还存在一个情况，就是头痛医头，脚痛医脚，其实这个也不完全是IT人员的问题，因为作为一个信息系统来说，本来它涉及的面就非常广，很多知识点没有涉猎也很正常。针对一些服务意识不是很强的从业者，组织也会提出一些解决方案，比如明确首要责任，负责人就是第一次接到这个case的人。
再来分析一下，业务部门在IT人员眼中的“五宗罪”。IT部门办了100件好事不一定记得住，但是办坏了一件事儿，这个就刻骨铭心了。在业务部门看来也只有他们想不到的，没有IT部门办不到的。还有比较突出的情况认为企业流程是IT部门自身的事情，与自己无关。这个有做过ITIL相关的事情的人应该很清楚，也埋怨IT部门花了很多钱，却总是没有把事情办好。二、从部门鸿沟到IT治理

上面这个图就是我要讲的运维与业务部门的鸿沟，怎么来弥补这个鸿沟呢？首先，公司最核心是关注营销战略，然后到业务战术，再到业务运营，这里面会涉及到波特五力模型，就是企业当前已处在的一个市场地位。通常是由这五力构成的，这五力决定了公司在中长期，短期的业务策略是什么，然后接着才是业务经理根据公司决定的业务策略去给公司做业务，接着到下面的业务运营。这些业务会对IT部门泛IT部门去提需求。
在IT部门就翻译到IT治理，IT治理是一个很宏大的话题，会涉及到开发技术，运维技术，服务级别管理，就是IT部门能够提供给业务部门的一些服务级别是什么？以及能力管理，对业务部门能够交付的能力是哪些？当然还有些其他的能力。接着就开始到运维的运营，包括我们常见的服务台，事件，变更，发布之类的流程，再对上提交这种报告。三、IT运维部门服务成熟度模型

作为IT运维部门，是提供对公司业务内外部的一些客户提供IT服务，可以归纳提出了一个服务成熟度模型。很多企业IT部门都会经历这五个过程。目前在国内，这个成熟度比较悲观，大多数企业可能只是停留在第二层，包括一些很牛的公司，一些运营商或者银行，都只是停留在第二个被动的成熟度范围。
许多中小企业IT运维部成熟度是混乱的，但这要依赖IT组织的这个管理者，如果他没有什么工具，他能做到第二步，能把这个被动的做好就非常不错。被动这里能够看到他是处于一种救火式的，清单式的记录，有些企业会做成类似工单的记录平台，有些就做日报周报，有这个然后启动问题管理流程，然后就有警报和事故管理。这个时候我会带入到一些Nagios，zabbix，普罗米修斯做一些警报的事情。
然后到第三个阶段主动的，能分析一些趋势，这里包括一些服务的趋势和性能的趋势，需要有度量工具，没有度量工具改善服务质量是非常难，几乎是不可能，设定服务的阈值，然后能测量应用的可能性，有成熟的问题，配置，变更，接入等管理，再上一些工具，包括监控工具，包括ITSM工具，那基本上能达到这个级别。这个级别其实工具是其次的，重要的是用工具的人。
用什么东西来度量你在组织中的位置，或者你在组织中的生存空间呢？
有几种方法，一种方法，首先就是看组织业务，这是最重要的，组织有没有资金支持，如果没有的话，大体来说IT部门如果没有发展到很强势的地位，通常都是成本部门。有几个阶段，一个是从成本部门，以技术为中心，以服务为中心，到以业务为中心的逐步转化，有意向做到第三个阶段，如果组织有这个经济实力往这个方向去靠的，那么你所在的组织，无论是甲方还是乙方前途会相当远大。如果组织会向第三或者第四层去靠的话，尤其是第四，IT部门可以作为一种业务创新部门，那就不要问这个企业给你开多少工资，先待下来再说，这个会非常有前途。

上面讲的这张，就是讲到主动式。我经常会提到zabbix监控，据说在中国有83%的企业运维在用这个，这个是一个主观统计，客观数据不精确。但我认为他也说明zabbix在中国是比较热的，相反的，我曾经问过，美国搞运维的一些朋友，在美国用Linux系统用的比较多一点，这里面其实有些历史背景的。
现在国内有不少公司在用普罗米修斯，他的一个优点就是TSDB持续数据库非常厉害，但是zabbix最新的4.2版本，也会有这这方面的技术的支撑。关于这方面的资料zabbix社区里面也有，目前在社区里，乐维也贡献了一些技术文章，我们也有一些技术交流的QQ群（177428068），如果有需要，大家可以进群了解。四、从IT工具到IT运营
我们是从zabbix1.6的版本，在2011年开始跟的。那个时候就开始做二开了。当时是直接改它的底层代码。zabbix它有比较明显的优势就是一个模板能力，就是你基本上要做什么监控，想做什么，Openstake，都可以监控，zabbix官方这些模板就是简单好用。但是要深入去用的话，最好我们技术同事对Openstake他本身的结构体系要有所了解，一般可用性可以监控得到。但要监控比较深的参数，就会比较难。
zabbix本身也有他的缺点，数据量大的时候会存在一个卡顿的问题，所以我们在做二次开发的时候，在这方面做了大量的优化，包括数据库层，现在大大提升了他的一些吞吐能力，现在基本可以做到分布式的，一个存储跟运算最大可以输512个节点。zabbix目前受到最大的诟病是显性化不足。目前要对他进行深度的二次开发，目前是200多张表，要清楚地读懂这么多表需要掌握的东西很多。

zabbix是一个非常强大的工具，我们目前只是把它当底层的一个很好的采集工具，它的灵活性和它的开源，从这个工具到IT运营还有段差距，首先在管理层面他需要得到业务保证，如果只是监控几个CPU内存，这个有价值，但是它的价值不是那么大。
最主要的是监控底层的IT，它的可用性和它的性能到底跟我业务有什么关系，核心做监控它其实是对核心业务的保障和对核心基础架构的保障，当然这两个是管理秩序。一个技术要带入到一个团队，还有它的性价比，目前的国内有不少的这种同行。做运维的人都会写些脚本做些报表，这都非常不错，有些技术爱好者会把这个用来画，去把它投到屏上，图都很漂亮，我每去一个有做这件事情的公司，这帮运维的兄弟那种精神面貌都非常好，我建议大家去试一下，提高自己做分析决策的能力。
做这些东西对于管理者来说，他更关注显性化和透明度，其实说到底就是那个投屏，要把底层显性给老板和干系人，要让他们看到。技术会有先进性，稳定性，兼容性，可自主性，不依赖性，可持续性和技术服务。这里是我个人建议，但乐维也有蛮大一部分产品代替了传统的网管产品，抢了那些份额。五、基础架构平台运维规划

接下来这张图，这是乐维在给客户做的运维功能规划，最后做完我们客户开玩笑说这张图十年八年可能都做不好，从这个图的底部来看，这是基础架构的监控平台。乐维现在做的比较多的是统一监控平台，包括web的拨测，主机网络设备，网管产品还有数据库。目前zabbix对数据库的监控做的不是太好，所以我们重新改掉了这个数据库监控，用我们DBA攒了多年的脚本就重新写了一套中间件，这个就是要做API。官方那个模板也还可以的，基本上能达到一些要求，包括应用，只要你有心都可以找到这些方法和工具。
还有底层、应用层的，主要包括对应用系统的监控，这个侧重点会是APM，目前国内做APM的也有很多成熟的厂商。不过基础架构这块会涉及动环，越做越深发现越来越难，我最近看到社群，很多人在问监控硬件，我建议在做监控硬件的时候，你们的组织里面有人得对基础架构的密布要有一些了解，这样做才搞得定。
右边这边是业务监控，通常乐维在跟企业做项目的时候会建议客户做IT运维要有“三驾马车”。一个对IT基础架构的监控，当然我说的架构包括应用包括动环及业务层面的监控，如果还能把服务管理也做起来，基本能保证这个企业运维管理成熟度能去到很高的水平。
在上面就是统一的告警平台，乐维把zabbix一些应用的告警，包括动环的告警，我们最多做过15个各色监控系统，把告警统一抽取过来，然后做告警的管理和收敛，我们目前能做到通过规律去规避，总结出一些相似度，然后做些规避措施。如果说在业务体系下面收到若干个告警，那这些告警在图里总会存在，这个业务的告警它的根因是什么？如果根因能被找到，乐维有个功能叫业务地图，在这个框架下面把所有N个告警都收为一个，这个是我们在做的一个事情。
再往上走，有流量分析，这个涉及到APM这块的功能，包括网络的流量，业务的流量，网站的流量以及数据库的流量。先做一些流量分析接着就是一些自动化运维。乐维底层用的是Ansible，原子脚本拼装然后单个去执行，或者是批量去逐行执行，然后带入到业务场景里面去。这些业务场景就是修改密码，批量执行某个文件替换，乐维在装这套产品的时候，我们就拿Ansible去批量下发。
然后接着是配置数据平台，这个有人叫CMDB，有人叫配置管理，我们最近学中台的概念，我们叫配置数据中台，其实是一个意思，但是这里面信息量很大，构建CMDB本身不难，难的是采集和定义这些CI项，还有一个难点就是关系。目前做配置管理的平台，采集方式也是装agent，然后通过agent去爬一些技术CI项，管理CI项，都是通过人工来录入或者批量导入的，然后接着去顶多就往前一步配置CI的关联项。
那我为什么要提到这些？我们的目标很简单，就是替换掉以前管运维的Excel。zabbix本身就能拿到一些技术的CI项，比如说装的什么操作系统，他的CPU内存磁盘等等，然后接着把一些管理的CI项匹配进去，包括购买的时间购买的厂商维保的时长。然后把这些搭进去，我们还有个模型设计器，把它做成跟监控匹配的功能。
然后左边就是智能分析，有底层的IT基础架构的这些配置中台的项目，有底层的性能，还有它的状态信息及底层的应用，动环数据和业务的数据。拿到这些数据保证业务的可用性和连续性之后，这些数据是可以拿来消费的。在乐维的规划里面，它会叫做智能分析。我们目前能够想到的是在业务系统里面带入一个功能，顶层的业务系统跟底层的IT基础架构，它呈现出CMDB的配置关系，也叫故障影响分析。就比如说业务系统当前出现故障，可以从图上面关注系统，下面技术架构呈现红色或者橙色。
如果业务系统本身没问题，下面的基础架构出现了红色或者橙色，以前简单运维都会去看一下这个业务系统有没有问题，然后巡检就结束了，他其实不知道背后某个技术架构可能出现一些风险，比如说C盘爆了，而这种是到时候才能发现的，如果有有效的告警手段，其实能够做早期的自动分析，包括故障定位，然后做规则、策略和更新定位。
再远的说，就是往上要去做服务管理。这里面会提到一个知识库，为什么我把知识库提到服务管理这个领域来呢？因为知识它存在于两个载体，一个载体在底层处理基础架构故障的时候，它会留下一些技术知识，比如说出了一个告警，他背后要处理方法分析到的原因是什么，处理方法是什么，这个可以给记录下来。第二个载体是在运维的流程中，比如说一个配置管理员，还有一个基础架构的网管及服务器运维，结合企业的一些管理流程，会总结出企业的运维管理流程相关的知识，它是存在流程中的，如果把这两个混合一起处理，知识库就会相当完美了，我们可以把他带个帽子叫可持续消费知识库。
接着就是运维分析这个领域的，包括运维报表，大数据分析，这个就不说了。

然后做完这些就完了吗？这个图说上一天也不过分，正常来说这个图上的内容要做八九年，现在免费送给大家。接着就是统一展示，包括大屏，业务地图，网络拓朴。我看到zabbix社区有些人配图很漂亮，这些挺有耐心，乐维是做了自动发现，我们图形化界面会略好一些，图表的展示，然后门户，待办工单，工作台，仪表台，仪表盘，还有服务登记，这个就不说了。左边是操作的管控操作的权限通知，模板包括菜单维护模式，这个图这是比较标准的管理信息系统。
好了，今天就讲到这里，谢谢大家，如果有讲的不对的地方讲的不好的地方，请大家多包涵，谢谢。