网上有关“数据自动化运维应该注意哪些事项”话题很是火热，小编也是针对数据自动化运维应该注意哪些事项寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。
一、基础数据概况
CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，与未来的IT运维管理标准化和流程化紧密关联，并且支持流程的运转。运维管理平台创建初期或初版中的CMDB更多是偏向IT资产管理，我们在这里定义的IT资产管理，暂时抛除公司个人使用的普通PC机。
日志主要存储CMDB中涉及到服务器或是其它设备的日志信息。
DB主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库。由于数据库的重要性，所以在基础数据中单独一个模块管理数据库，包括生产数据库、测试数据库、开发数据库。数据库的日志放在日志模块进行统一管理，监控和备份。
知识库主要存储日常运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
二、基础数据三要素
基础数据要求完整、准确、实时，这三个特性缺一不可。
1.完整性
完整性，要求在数据采集整理阶段，要一一梳理，不能有遗漏。任何一个设备的疏漏都将会导致未来出现问题。例如最近的勒索病毒在防范上需要给服务器升级打补丁，这个时候就是根据服务器清单一一对照，升级。如果有遗漏落下的服务器未及时打补丁而导致病毒入侵，后果将很严重。那么，如何做到完整性呢？大致可以分为以下几步：
首先数据采集阶段多人（推荐三人以上）同时对IT资产进行采集，那么在数据采集完成后，将会有三份或以上的IT资产清单。
接下来就是相互确认阶段。相互check对比两方的清单和自己梳理的清单，找到不一样的地方，大家在一起开会进行讨论。经过这个阶段，会产生一份相对完整且三方（或以上）认可的IT资产清单。
最后就是三方（或以上）一同针对认可的IT资产清单进行最终check，确保最后的清单，是经过多方讨论确认，并最终又check过的IT资产清单。此时这份IT资产清单，相对比较完整。另外在梳理、讨论和check的过程中，针对新增、变更、删除的IT资产一定要及时更新我们的IT资产清单。
2.准确性
准确性要求IT资产清单或是CMDB中存储的数据不能与实际情况有任何差异。要做到基础数据的准确性除了在数据采集阶段要下功夫外，要在运维管理的每一个阶段定期对基础数据进行审计，确保基础数据中的数据无误。一般月度一小审，半年一大审，具体情况根据企业的IT规模而定。
3.实时性
基础数据的实时性可以确保数据的准确性。即基础数据的每一次变动，包括增加、删除、修改，不论大小，只要有变动（在运维流程完结阶段，执行运维操作成功后，就要及时更新基础数据。忽略基础数据的实时性，必将导致准确性大打折扣，在以后的月审、年审中必将导致额外的工作量。一般在审计的过程中，当数据的错误率达到一定程度后，需要重新梳理全部数据，以确保最终的准确和完整。
CMDB
CMDB总的来说分为：产品线、资产管理、供应商管理三个部分。
总的思路是：通过产品线管理IT资产，通过IT资产信息管理硬件或服务提供者，供应商管理。
1.产品线
产品线是指整个公司所有IT系统、产品按照属性进行归类划分。这有一个前提，就是梳理整个公司的IT项目和IT服务。这里项目也可以理解为每一套IT系统，例如OA、CRM、订单系统、支付系统等等。
IT服务主要是指：应用服务（Tomcat、WebLogic、数据库服务等），基础IT服务如Nginx、Varnish、Redis等。通过项目和服务两个维度来管理IT资产，尤其是虚拟机。因为一般系统和服务都是部署在虚拟机上，虚拟机的宿主机则是一台台物理主机。
产品线的划分一般除了根据业务分类划分几个大的产品线外，还需要划分一些基础产品线，如：信息安全产品线，主要管理信息安全、网络安全等系统和设备等;基础服务产品线，如Nginx反向代理大部分系统，Varnish缓存Web静态资源等。
在这里单独说一下产品线和项目包括的服务必须制定运维优先级等级。运维等级的制定不能简单定义为多少级，而应该是为每一套系统进行运维优先级打分，分值不能一样。这样保证在大面积故障的时候，可以根据优先级解决问题。
2.资产管理
资产管理主要有以下几个方面。
首先是比较大的机房管理。有的企业可能会有多个机房，每个机房的基础信息，如带宽、位置、值班电话等都需要加以整理存储用来管理机房信息。机房中的机架、机柜、交换机、路由器等硬件信息，机房的空调、UPS电源、环境监测系统等都属于机房管理的范畴。
安全设备管理。安全设备管理这里主要包含防火墙、IPS、WAF、***等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。
服务器管理。这里假定企业实现了虚拟化，大部分系统和服务都部署在虚拟机，而虚拟机是部署在物理机上。服务器管理分物理机和虚拟机分开管理，同时又密切关联。虚拟机在哪一台或几台物理机需记录清楚。
根据产品线中定义的运维优先度等级，在资产管理中的每一个节点标注上相应的等级分值，以便出现大规模故障，有选择、有重点、有顺序地逐一解决问题。
3.供应商管理
供应商管理主要是管理由第三方企业提供的IT系统或设备的服务信息。记录供应商的具体信息、值班电话、硬件备件库等信息。
以上几个模块单独管理，但是又密切相连。如产品线包含哪些项目，包含哪些服务，这些项目和服务部署在哪些虚拟机上，虚拟机又在哪一些物理机上，物理机分布在哪些机房和在机房中的具体位置，物理机在机房中的网络位置和网络架构如何，经过哪些安全设备等等。
反过来需要知道某一些机房有哪一些物理机，物理机位置，安全设备，以及安全设备与物理机的网络架构等，物理机上又有哪些虚拟机上部署了哪一些项目和服务等。系统和服务属于哪些供应商提供，供应商又提供了哪些系统、设备或服务器等。都要多维度进行管理。要求做到某一环节的故障，一查就知道所有受影响的系统和服务。CMDB中的信息相互交织，多维度查询和管理，构建出一张完整的总体架构图，通过总体架构图除了展现出各个部分的基础信息外，还描述了所有的依赖关系，做到坏一点而知全面。
日志
通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻击会在系统安全日志中有一定的体现。
1.系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能append。
2.应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
3.数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
4.设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
在CMDB中梳理的IT基础设施的基础上，对日志进行分类收集、管理、分析和监控，配着监控管理模块的系统，就已经可以达到多方位监控IT系统，保障IT系统的安全稳定。
DB
由于数据和数据库的重要性，在基础数据中，数据库作为单独的模块存在，根据环境划分为：生产数据库、测试数据库、开发数据库。严格区分三种环境的数据库，避免测试数据到生产环境，生产数据到测试环境等。另外数据库中数据也为业务监控提供数据依据。通过查询数据库中的数据，依据业务逻辑进行判断是否有错误或是遗漏的数据。
知识库
知识库在整个运维管理中是一个辅助功能，主要为运维提供事件管理、问题管理。很多朋友可能会疑惑为什么把事件库和问题库放在知识库这里，这些不是应该在CMDB中吗？这里稍微解释一下，其实本人也并不太清楚这种办法是否可行。在CMDB模块中更多是偏向IT资产管理，为以后的运维操作提供运维范围和运维目标。而事件（主要指运维过程中遇到的所有的运维事件）和问题（需要进行变更发布才能解决的事件升级）更多是在IT资产之上，是解决IT资产的过程中遇到的事件和问题。如果把CMDB作为IT运维的基础管理对象和范围目标的话，事件和问题应该单独出来。也许在后面的运维管理中，逐渐强化CMDB的功能，会把事件库和问题库回归到CMDB模块中。
知识库中还包含经典案例库，主要是解决一些常遇故障、经典问题的解决方法的整理和归档。
解决方案库只要是一些常用的或是探索中的解决方案，例如：Nginx+Tomcat+Redis部署方案，FastDFS分布式文件服务器方案等。
文档库主要用来存储运维管理过程中执行的运维标准和规范以及运维的流程规范，常用的一些规范举例：
文档库也包括一些企业或是部门的规章制度，与供应商的合同条文等。主要是涉及到IT系统文档的一个存放和查阅的地方。
运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。
总结
基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。
计算机问世以后，人要和计算机打交道，需要程序设计语言，这种语言不仅应让计算机理解，而且还应让别人看懂，使其成为人际交往的工具。程序设计语言的标准化最早提到日程上来。60年代程序设计语言蓬勃发展，出现了名目繁多的语言，这对于推动计算机语言的发展无疑有着重要作用。但同时也带来许多麻烦。即使同一种语言， 由于在不同型号的计算机上实现时，作了不同程度的修改和变动，形成了这一语言的种种“方言”，为编写出程序的交流设置了障碍。制定标准化程序设计语言，为某一程序设计语言规定若干个标准子集，对于语言的实现者和用户都带来了很大方便。软件工程标准的类型也是多方面的。它可能包括过程标准(如方法、技术、度量等)、产品标准(如需求、设计、部件、 描述、计划、报告等)、专业标准(如职别、道德准则、认证、特许、课程等)以及记法标准(如术语、表示法、语言等)。表1)软件工程标准分类软件生存期 软件生存期 概念需求设计实现测试制造安装与检验运行与维护引退标准类型过程方法 技术 度量 产品需求 设计 部件 描述 计划 报告 专业职别 道德准则 认证 特许 课程 记法术语 表示法 ISO5807 语言 在全面考虑以上两个方面的情况下，软件工程的标准可用一张二维的表格来表示。表1)和2)给出了这个二维表的大致格式。2)表是1)表的继续。表中填入了三个标准的例子：表2)软件工程标准分类技术管理 确认与验证 技术管理确认与验证 过程管理产品管理资源管理评审与审计产品分析测试标准类型过程方法 NSAC-39NSAC-39NSAC-39技术FIPS 105 度量 产品需求 设计 部件 描述 计划 报告 专业职别 道德准则 认证 特许 课程 记法术语 表示法 语言 ①FIPSl05是美国国家标准局发布的《软件文档管理指南》 (National Bureau OfStandards，Guideline for Software documentation Management，FIPS PUB 105，June 1984)②NSAC—39是美国核子安全分析中心发布的《安全参数显示 系统的验证与确认》(Nuclear Safety Analysis Center，Verification and Validation for Safety Parameter Display Systems，NSAC—39，De— cemberl981)③ISO 5807是国际标准化组织公布(现已成为我国国家标 准)的《信息处理——数据流程图、程序流程图、系统流程图、程序 网络图和系统资源图的文件编制符号及约定》随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写程序，扩展到整个软件生存期。诸如，软件概念的形成、需求分析、设计、实现、测试、制造、安装和检验、运行和维护直到软件引退(为新的软件所代替)。同时还有许多技术管理工作(如过程管理、产品管理、资源管理)以及确认与验证工作(如评审与审计、产品分析、测试等)常常 是跨越软件生存期各个阶段的专门工作。所有这些方面都应逐步建立起标准或规范来。
对比是 数据分析 最基本的方法，通过对比识别数据差异。但是对比有得失。在分析过程中，对比得当可获得精准结论，但对比分析也存在陷阱，比如某产品近期销售数据在下滑，想当然得会得出结论此产品受欢迎度在下降，但是查看销售比（销售数/DAU）却在上升，所以只是因为DAU下降了。
所以如何去有效对比？
1、 横向、纵向多维度对比
对比的前提是两个事物或统一个事物的两个状态，其次必须要有一个对比的指标或标准（这里可称为对比的度量）。对比的两事物一个是主体，另一个是客体。也就是明确对比的三要素：主体、客体和度量。比如小明比小王高5cm，就是一个最简单的对比，这里小明是主体，小王是客体，度量身高，且人们对于身高这个度量存有共识。但如果去大排档吃一碗炒饭50元，可能觉得很贵。那如果是取希尔顿吃一碗炒饭128元可能就不觉得贵，这里我们选择了常识作为比较的基准，客体也没有问题，问题在于我们所谓的“常识”并非所有人的“共识”，如果不是共识，就要非常谨慎地得出结论，否则就容易从自我出发做出判断，影响结论的中肯性。
2、建立标准化的对比客体和度量
就是因为标准可以是认为确定的，所以存在质疑和不确定性。
建立标准化的对比可以是时间标准、空间标准、特定标准、计划标准。
3、 比率的对比
常见的对比是大小的对比、数量的对比，比如销售额的对比，人数的对比，使用不同的对比指标会得到不同的结论，我们把对比标准的选择叫做视角，视角不同，结论不同。比如上述对比小明小王俩同学，身高是视角事宜，除此之外还有年龄、学习成绩、颜值等等。在对比各种变化的原因时，我们也有各种模型，我们所要做的就是找到合适的对比视角。
直接描述事物的变量：长度、数量、高度、宽度等
加工后可得到：增速、效率、效益等指标，这才是数据分析时常用的。
如下图的AB公司销售额对比，虽然A公司销售额总体上涨且高于B公司，但是B公司的增速迅猛，高于A公司，即使后期增速下降了，最后的销售额还是赶超。（数据都是笔者瞎编的，工具用的是FineBI）
3、 指标的逻辑与管理指标
数据分析师有一个关键的职能就是要设计“指标”来对比，设计指标和应用指标有着天壤之别。比如某保健品公司，他们的产品是各类补品及奶粉，他们的业务与市场中人口的出生率、老龄化速度、市场整体购买力、对保健品的消费观念有着直接关系，还与政府对这个市场的管控力度有关。分析这么多之后，有没有一个指标来反映这些综合的因素，它的正反代表着好坏。
考虑到以上因素需要构建一个综合性的指标，这需要各种数据的加权计算。在不考虑市场规模的情况才，可以先构建一个指标指数模型：
Y=aX1 + bX2 + cX3 + dX4+……
Y 可定为市场吸引力指标值
X1 可定为老龄化程度
X2 可定为市场整体购买力
X3 可定为市场对保健品的品牌的看法
X4 可定为政府对这个市场的管控力度
abcd是系数，分别代表影响力程度
当然以上只是简单的罗列，实际情况比如X2还能分解出多个影响指标，甚至整体可以换成乘法模型，指数模型。。。
4、 对标的层次和维度
设定了各项管理指标后，剩下的就是比较工作了。从变化到追踪事物变化的诡计，找到问题的根源，从而找到书屋发展规律，这个过程叫对标。对标可以和自己比，也要和别人和竞品比。
对标的维度有规模指标、速度指标、效率指标、效益指标。
规模指标比如营业额、销售额，电商平台的UV、日活，医院的一天接诊数量，年营业收入额；
速度指标往往代表着活力，也是看未来趋势和潜能的重要指标类，包括各种运营管理指标的速度指标。
效率指标即投入和产出比，如果投入的是时间，月度产值、季度产值；如果投入的是净资产、则净资产周转率；如果投入的是人，人均产值，人均销售额。
关于“数据自动化运维应该注意哪些事项”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！
