运维事件定义（运维事件定义标准）

本篇文章给大家谈谈运维事件定义，以及运维事件定义标准对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享运维事件定义的知识，其中也会对运维事件定义标准进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、什么是运维？运维工种有哪些
• 2、运维是做什么的
• 3、运维的资深运维工程师眼中的运维
• 4、数据自动化运维应该注意哪些事项

什么是运维？运维工种有哪些

运维（Operation and maintenance）一般是指对大型组织已经建立好的网络软硬件的维护，其中传统的运维是指信息技术运维（IT运维）。

所谓IT运维管理，是指单位 IT 部门采用相关的方法、手段、技术、制度、流程和文档 等，对IT 运行环境（如软硬件环境、网络环境等）、IT 业务系统和 IT 运维人员进行的综合管理。

随着信息化进程的推进，运维管理将覆盖对整个组织运行，进行支持的管理信息系统涵盖的所有内容，除了传统的IT运维，还拓展了业务运维和日常管理运维。

其参与的对象也从IT部门和人员，拓展到组织的管理层和各部门，及其相关的业务骨干。运维的最终结果是对软件运行中各种性能的维护。

运维工程师从工作方式上分为几大类：

1，运维工程师/运维开发工程师：

负责具体的产品线运维工作，同时也需要掌握开发的能力，深入业务，最了解业务的痛点和问题，同时研发/优化针对产品业务需求的平台、工具和手段，能够接触到各类优秀的系统架构并有能力做出优劣对比，同时对业务的掌控决定了相应运维工程师在业务发展中的作用。长远发展是成为大型系统的架构师。

2，运维平台研发工程师：

专门研发运维相关通用平台和技术，需要有一定的产品线运维经验或从产品线中拿到运维需求。对研发能力有较高的要求，对系统的设计有较严格的标准，并且能够理解用户需求，做出适合服务运维和满足运维工程师使用体验的运维产品，长远的发展是成为各个技术纵向领域的技术专家。

3，数据库研发工程师/数据库工程师：

数据库方向是运维技术中较为特殊的一个方向，由于业务的重要性通常需要专设岗位，业界在该方向也有深厚的研究和积累。主要方向有数据库内核、云数据库等，长远发展是数据库领域的技术专家，数据库架构师。

4，运维经理：

运维同学做事情的过程中通常需要协调多个RD和QA同学，对协调和推进能力要求比较高，对一些技术深度还不错，协调和推进能力比较高的同学非常适合转型管理职位，长远的发展和技术部门的管理职位一样目标是CTO、CEO。

各个方向上的工程师发展到一定阶段后，没有明确的界限，需要同时具备较强的运维、架构、编程、算法等能力，是一个要求很高要求的职业。

扩展资料：

运维以技术为基础，通过技术保障产品提供更高质量的服务。运维工作的职责及在业务中的位置决定了运维工程师需要具备更加广博的知识和深入的技术能力：

1，扎实的计算机基础知识，包括计算机系统架构，操作系统，网络技术等；

2，通用应用方面需要了解操作系统、网络、安全，存储，CDN，DB等，知道其相关原理；

3，编程能力，小到运维工具的开发大到大型运维系统/平台的开发都需要有良好的编程能力；

4，数据分析能力：能够整理、分析系统运行的各项数据，从中发现问题及找到解决方向；

5，丰富的系统知识，包括系统工具、典型系统架构、常见的平台选型等；

6，综合利用工具和平台的能力；

7，运维工作的复杂性对这个岗位的运维工程师们的软素质也提出了要求：时间管理能力，特别是碎片化时间的处理能力；沉稳的心态，面对紧急情况时需要处变不惊；沟通能力、团队协作，运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；

8，工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是最高线上权限者，需要谨慎心细；

参考资料：百度百科---运维

运维是做什么的

运维开发工程师的职责是：负责日常运维工作；推动及开发高效的自动化运维、管理工具，提升运维工作效率；制定和优化运维解决方案，包括但不限于柔性容灾、智能调度、弹性扩容与防攻击；探索、研究新的运维技术方向。
运维开发工程师的任职要求是：1、本科及以上学历，年龄在18周岁以上；2、熟悉常见应用服务的配置和优化；3、能熟练使用常用的监控软件；4、善于分析思考问题，有责任心；5、服从工作安排，身体健康。

运维的资深运维工程师眼中的运维

以下是中国互联网业界部分资深运维工程师对运维的看法（涉及隐私，相关人名采用首字母缩写）：
CXY:
运维是一个非常广泛的定义，在不同的公司不同的阶段有着不同的职责与定位，如果以operation字面的含义去理解，认为就是敲几行操作命令的工作，那就错了。 对于初创公司，运维工程师的工作可能需要从申请域名开始，购买/租用服务器,上架，调整网络设备的设置，部署操作系统和运行环境，部署代码，设计和部署监控，防止漏洞和攻击等等。对于大型的公司，对于运维工作的要求越来越高，也催生了更细化的运维分工：从大的方向，可以分为网站运维，系统运维，网络运维，数据库运维，IT运维，运维开发，运维安全等方向。
很多非从业人员对运维的看法一般属于IT运维的一个非常小的职责：装系统^^。 一些研发工程师对运维的看法也只局限运维工作的几个点：部署, 变更, 监控，响应。
无论做什么运维，最基本的职责都是保证业务能够稳定运行。所以必须成为业务稳定性的owner。有些人通常认为运维工程师像消防员，7*24小时响应异常，救火。但是稳定性的运维工程师和医生的职业更接近。医生也分各种科室，也有急症室，需要先判断病人的问题，对症下药。
业务有着各种各样的需求，如果运维工程师能够满足业务需求，或者主动挖掘业务的痛点和改进方法，就能为业务实现更多的价值。
在满足业务需求时，应该分清主次，优先面对业务快速发展非常重要的需求，例如稳定性，部署和变更效率，容量管理。稳定性不用多说，如果用户没法稳定使用你的业务，什么产品特性都没有价值。对于百度这样极速发展的互联网公司，每天都有大量的升级更新需要提供给用户，如何在异地的大集群上最快的满足产品的升级需求，同时让用户对升级过程无感知，这是我们的追求。当用户会用百度来测量网络是否可以上网时，就是对运维质量的褒奖。
其次，可以横向看看不同业务的需求。如果能够把多个业务的需求抽象出来，把一些有通用价值的工作平台化（例如数据库，cdn，监控，流量接入和调度，大数据的存储和计算），也能在这个方向进行深入的发展。在百度这样的巨大的流量和服务器规模下，你不仅有巨大的空间和挑战，也有着充足的资源和支持，可以开发和应用业界最前沿的技术。
有一定的积累后，可以进入到宏观和微观的两个层面，从整个公司层面考虑业务的智能部署和调度（涉及网络，硬件，系统，应用开发方式等各个要点），进一步提升效率和节省成本。
如果能够懂业务，理解业务的模式，紧密结合业务进行优化和创新，也是运维工程师体现价值的另外一种方式。有很多产品上的创新，专利的申请，论文的发表，业务指标的提升，直接或者以合作的方式由运维工程师贡献。
YBX:
运维工程师相对研发人员来讲，可以全局观察所维护的计算机系统，特别是高阶运维工程师，不存在模块界限，这种独特的位置带来很多价值： 知道准确的系统瓶颈点，进而知道系统准确的容量；在系统出现瓶颈前，知道如何快速提供容量。 知道系统的风险点，可以协调风险点上下相关关联模块，做出冗余策略；相比集中解决单点模块稳定性，更合理。 长期从事相关工作，积累较多的架构设计经验，可以指导新架构设计和审核。 从公司不同业务角度看，运维可以从中抽象相同的模块，统一管理，形成有效的平台和自动化管理方法 同样从公司不同业务角度看，可以统一调配资源，进而节省资源。
KZ: 设计并实现可以提高公司服务可用性，可扩展性，延迟和效率的软件。 处理日常紧急事故，修正，替换问题组件。并设计规避问题方法。 设计和实现新的超大规模分布式系统架构和标准。 参与服务扩容计划和预测服务增长趋势，对软件和系统性能进行调优。 提供在线咨询服务和现场解决问题服务。 构建自动运维平台，解决日常问题。 构建知识库，预测可能的问题。 XX:
运维即生产环境以及和生产环境相关的资源、服务的维护的整个过程，包括了相关的技术、流程手段，确保生产环境稳定、高效、低成本的运行。
运维一方面为对业务功能最终负责，其价值的体现为最大化助力产品价值的发挥。这通常是通过将产品功能的运行表现提升到极致来达成的。例如搜索引擎的运维重点要保障用户在搜索时候的极致体验：稳、快、准、新、全。而一个在线聊天系统的运维应该是确保用户聊天过程的实时与顺畅。另一方面为对在线业务的成本最终负责。其价值的体现为降低服务运行成本
运维工作的开展方式一般取决于所维护的业务特点需求，形成所需的多个主题方向进行开展。通常的解决方案中包括如下的一些主题方向：事件管理、配置管理、变更管理、容量管理等。
运维工程师的要求特别严苛，因为运维工程师针对不同的问题，需要不断的补充扩大自己的知识和研究范畴。
在初级阶段，优秀运维工程师会体现出格外出众的主动性和责任心，面对陌生的业务会主动学习和拓展自己对业务对认识和相应的知识范畴，以能够足够的胜任业务的独立维护。
在逐步的发展阶段中，注重总结反省的工程师会逐渐成长为高阶运维工程师，通常他们会有比较体系化的服务运维理解。也有一部分工程师由于出色的项目管理规划能力，逐渐成为项目经理
再进一步的发展，高阶的运维工程师对于产品的理解将非常的透彻，因而在这种情况下，高阶运维工程师甚至可以成为产品的产品经理、产品研发的咨询顾问，在产品功能的设计与开发中起到至关重要的角色。
SJY:
一个运维工程师所需的技术体系以其专业方向而异。但基本的计算机系统架构，操作系统，网络技术的掌握是基本要求。例如你可能需要熟练掌握linux操作系统的使用，熟练使用各种脚本工具来处理日常工作任务，精通TCP/IP协议栈以排查一个大规模网络系统中的流量异常问题等。更进一步的你需要形成一套软件可运维性方面的经验积累，以此作为后续工作的指导。
一个运维工程师在初期阶段目的是掌握维护一套系统所需的所有软硬件知识和经验。进阶阶段是需要能够设计开发一套基础的体系软件，以支撑业务系统的稳定可靠运行，即开发服务于软件的软件，以支持更大规模的业务系统，提高运维生产力。最高阶段是反作用于软件系统的构建和运行阶段，使得系统从诞生阶段起即具有天然的可运维性，以最大化系统的生产力，同时最小化对外部支撑资源的依赖。
ZM：
运维工程师首先应该是软件工程师（Software Engineer），只是责任和侧重有所不同。
运维工程师不是系统管理员。和系统管理员最大的差别是，运维工程师的工作不仅仅是配置和管理系统，而且可以运用软件开发的方法来增强系统的功能、或者对数据进行分析。
运维工程师应该是软件工程师、系统工程师等角色的综合体，和一般软件工程师相比、应该具有更加广博的知识背景
运维的职责在于： 保证服务的稳定运行； 考虑服务的可扩展性； 从系统的稳定性和可运维性的角度，提出开发需求； 定位系统的问题，甚至可以直接修正bug； 对突然出现的问题做到快速响应和处理； 运维的日常工作： 需要对系统的需求和设计方案进行分析，思考在保证稳定性方面有哪些可以加强的地方，并和系统的研发人员进行有效沟通； 使用工具、或者写程序，对运营数据进行分析； 写程序以建立工具或平台，去加强系统的稳定性； 运维工程师最重要的是会运用编程和软件的方法来解决问题。发展的道路应该和软件工程师没有很大的区别，差异只是关注点和领域方向的不同

数据自动化运维应该注意哪些事项

一、基础数据概况

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、VPN等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。

服务器管理。这里假定企业实现了虚拟化，大部分系统和服务都部署在虚拟机，而虚拟机是部署在物理机上。服务器管理分物理机和虚拟机分开管理，同时又密切关联。虚拟机在哪一台或几台物理机需记录清楚。

根据产品线中定义的运维优先度等级，在资产管理中的每一个节点标注上相应的等级分值，以便出现大规模故障，有选择、有重点、有顺序地逐一解决问题。

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系统文档的一个存放和查阅的地方。

运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。

总结

基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。

关于运维事件定义和运维事件定义标准的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维事件定义的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维事件定义标准、运维事件定义的信息别忘了在本站进行查找喔。