自动化运维平台建设浅析

阅读: 评论:0

• 79
效解决雷达基数据无法上传或上传率低的问题。
(2)另外一种故障是:在雷达正常运行情况下,雷达基数据无法正常上传。经研究分析发现,导致这一故障出现的主要原因有:业务用计算机软、硬件出现故障,如网络接口损坏、传输软件崩溃或是系统崩溃等,当出现这些故障时,及时组织技术人员更换备份用计算机,有效消除故障,确保计算机与系统正常稳定运行。另一原因是局域网出现故障,例如集线器、局域网、网线开路等出现故障,导致计算机与网络系统无法正常使用,当出现上述问题时,及时组织技术人员点击计算机左下角的“开始”,点开开始
后再点“运行”,之后输入ping以及同一路由器或集线器局域网内另一台计算机的IP地址,输入后点击确定,计算机便会出现一个黑窗口,Request time out,这就说明是网络连接问题,如出现小范围的局域网故障,技术人员可利用网络测试仪进一步诊断出故障原因、类型等,在此基础上采取相应解决措施如跟换路由器、集线器或网络,可有效消除故障,确保计算机与网络系统安全稳定运行。但若是出现光端机及外局域网故障时,技术人员则需点击计算机左下角的“开始”,点开开始后再点“运行”,之后输入ping以及集线器或路由器小局域网内另一台计算机的IP地址,就会出现Reply from 和 IP 地址等,这说明内网正常,而故障很可能是由外网原因引起,在此情况下,技术人员输入通过光端机外局域网计算机的IP地址时报“Request time out”,便可证实这一猜想,即故障类型确实为外网故障。当出现外网故障时,台站无法解决,需联系通信经销商进行处理,而台站可以用无线网络或是电话拨号传输系统来进行正常的资料传输工作,最大程度降
低故障影响,确保天气雷达运行效率。
3.产品显示工作台 PUP
产品显示工作台 PUP在工作过程中也会出现一些问题,如PUP 无法正常显示图像或是PUP与RPG断开连接等,这些运行故障会给天气雷达的正常使用造成负面影响,当上述故障出现时,需及时准原因,采取相应措施进行解决。具体分析如下:
(1)PUP处于报警状态,显示 PUP 和 RPG 连接断开。经研究分析发现,导致这一故障出现的原因为:与RPG连接的PUP过多,如超过6台,在此情况下RPG会有选择性的断开与一些设备的连接,导致故障发生。要想有效消除该故障,只需关闭PUP或 RPG软件重启就可恢复正常。
(2)PUP 产品上的图全是黑的,没有任何图像。这一故障出现的原因为 PUP 产品显示区里历史产品太多或电脑还在运行其他的程序,导致计算出错。消除这一故障的措施为:将PUP软件关闭重启,就可恢复正常。
4.结语
综上所述,要想确保新一代天气雷达系统的安全稳定运行,就需做好各项检查维护工作,如时间校对、病毒查杀、规范操作等,确保天气雷达系统运行安全。同时相关技术人员还需准确掌握新一代天气雷达系统计算机及网络构成以及工作原理,当故障发生时,能及时出原因,采取相应措施进行解决。
1.背景
随着技术的发展,各类自动化运维技术和产品,尤其是前沿互联网公司开放出来的自动化运维技术架构,已逐步在企业中应用,并帮助企业提升整体的IT运维能力。
而对于传统企业来说,IT系统的运维的建设与发展而言,也逐步面临如下的一些现状:
(1)规模大:平台规模呈快速增长趋势,新业务规划需要更庞大而又灵活的IT架构来进行支撑,服务器数量、运营数据、安全风险种类日益增多;
(2)技术栈复杂:各类操作系统、虚拟化平台、应用中间件、业务配置选项等加大了管理复杂度,软件定义数据中心、容器技术、大数据、云计算等高效技术的引进增加了IT 人员技术储备的压力;钢丝绳滑轮
(3)新的开发模式:业务系统的开发运维,从单体、瀑布架构,向Devops、微服务架构演进;
(4)IT敏捷性的要求:应用发布、更新比以往更频繁,应用可用性要求为永久可用等等。
信息系统整体运维也面临着从旧运维模式到新运维模式的转变,传统运维模式的三个重要特征:
(1)依赖于运维人员的运维管理技能与经验;
(2)以脚本作为配置管理的主要手段;
(3)各个系统之间没有打通,运维管理需要在不同的系统与平台间手动切换。
新的运维模式具有三个方面的特征:
(1)运维管理不再依赖运维脚本,而是基于场景化的运维工具;(2)运维平台强调自动化,能够进行自动化任务、故障恢复等;(3)强调可编排(编程)性,能够通过编排等手段支持复杂的运维场景。
因而对自动化运维的探索和建设,目前已处于一个可以落地发挥业务价值的阶段了。
2.技术方向
业界自动化运维的建设,尤其是以互联网技术为代表的自动化运维建设,发展和建设方向大致有如下几个:
(1)日常任务处理自动化:将IT日常运维工作中重复性的工作进行流程抽象,行程可自动化编排的处理流程;
• 80
内衣生产•
阀门加工
(2)应用监控及故障自愈:实现应用功能级别监控,以及流程化的故障自愈和非流程化的故障智能处理;
(3)DevOps体系:实现应用开发运维一体化的标准、流程和操作实施;
(4)无人值守运维(智能运维):已经一定程度上实现了智能运维,但这仍然是下一个自动化运维阶段可期待的突破;
(5)辅助运营(运维数据深入挖掘):通过运维数据的处理与挖掘,实现运营辅助和决策辅助,为企业业务带来价值。
同时,主流的技术阵营如下:
(1)以Ansible、Chef、Saltstack、Puppet等为代表的开源阵容,集中关注在任务脚本编排,作业调度能力上;
(2)以BMC、IBM、华为等为代表的商用产品阵容,集中关注在CMDB、服务器运维自动化、巡检自动化等能力上;
(3)以腾讯蓝鲸为代表的PAAS技术平台阵容,集中关注在驱动各类IT对象,和基于PAAS的体系化建设。
在进行技术选型和产品选型过程中,有一个很关键的规划经验在于,自动化运维不应以技术和平台为驱动力,而是要以运维场景为驱动力。这也是自动化运维落地的难点所在:自动化运维需要满足且持续不断满足业务定义的运维场景,而运维场景有着变化、灵活、跟企业运维模式紧密相关的特点。
自动化运维框架建设的原则应充分考虑场景化运维的复杂性、扩展性和灵活性。
并应该具备如下几种能力:
(1)自动化运维平台应具备丰富的驱动能力,它能驱动企业各个IT组件,包括新的技术如互联网组件、大数据平台等,旧的如已有的一些各个厂商的设备,它的扩展性要比以往的要求更高,而不是局限在厂商自己软硬件产品的自动化运维工具上,要脱离工具上升到平台级别;
(2)平台能高效集成企业运维流程,将ITSM和ITOM高度联动,实现流程真正的自动化;
(3)运维应具备运维开发的能力,运维IT需要从传统产品化运维人员,走向开发运维,自己能通过运维开发的方式实现自己的个性化运维需求,并帮助业务实现敏捷交付;单面铜基板
89c20513.基于1+N的自动化运维建设思路
而在开始进行自动化运维落地的时候,往往会遇到先做规划再逐步建设,还是先取价值度高的场景再持续建设的选择。
先做规划再逐步建设:先规划出未来的自动化运维蓝图,包括自身具备的功能模块,与周边系统的关联,数据流等,再逐步累加进行堆积;这种方式的好处是整个建设更具备指导性和计划性,但缺点是无法持续的优化建设蓝图,到适合落地的模式;
先取价值度高的场景再逐步累加的方式:先选取一些典型的场景,如应用发布、自动化巡检、补丁更新等场景,逐
步建设,然后持续累加,在进行到一定阶段的时候探知到适合自己企业的目标和蓝图;这种方式的好处是当前做的自动化运维建设是具备实际价值的,便于价值呈现后的后续建设,缺点是缺乏理论指导,需要后续持续构思适合自己的运维蓝图;
结合以上方式的优点,建议采用的方式是基于场景的1+N的方式:
图1 1+N场景方式
耐热粘合剂组建团队牵头规划设计并负责基础技术平台的建设,具体的运维功能可以由各专业、各部门自行开发维护和发布,形成1十N的组织模式。
此模式具有如下特点:● 发挥多方积极性,各取所长● 快速形成比较完备的企业级能力● 对平台的基础功能和核心框架要求高● 要求各团队具有较强的运维开发能力● 各部门能自己选取价值度最高的场景进行建设
4.结语
传统的IT运维模式依赖运维人员的经验与技能,随着信息化的发展,IT运维管理工作的复杂度和难度的大大增加,传统式被动、孤立、半自动式的IT运维管理模式经常让IT人员疲惫不堪,IT自动化运维迫在眉睫。本文分析了传统企业IT运维的现状,研究了业界自动化运维的技术发展方向和技术阵营,定义了自动化运维框架的三种能力,创造性的提出了1+N的基于场景的自动化运维建设思路。
作者简介:
马欣欣(1987-),女,汉族,黑龙江齐齐哈尔人,现工作于广州市增城区人民政府永宁街道办事处,本科、高级项目经理,研究方向:信息系统管理、研究及运营。
林克全(1986-),男,汉族,广东汕头人,工作于广州供电局有限公司,高级工程师,硕士,研究
方向:信息项目管理、应用系统研发与运维。

本文发布于:2023-06-10 16:54:09,感谢您对本站的认可!

本文链接:https://patent.en369.cn/patent/2/133698.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:运维   故障   建设   技术   进行   计算机
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2022 Comsenz Inc.Powered by © 369专利查询检索平台 豫ICP备2021025688号-20 网站地图