×

扫描二维码登录本站

标签: 暂无标签
  如何建设一支能够解决问题、创造价值、有活力的、不断进取的IT运维团队,并带领这支团队?充分发挥这个团队的优势力量,是运维业务有效开展的关键。运维策略是直接体现运维业务的经济价值所在。好的运维措施、方法可以延长设备使用寿命,充分发挥该设备、物品应有的作用,创造更高的经济价值;错误的运维措施、方法可能缩短设备使用寿命或毁坏设备,严重时会带来一场巨大的灾难。信息安全是IT运维质量最重要的指标之一,只有通过有效、可行的管理、监控手段才能降低安全风险,防止重要数据泄漏,保障数据安全。
  1、IT运维队伍组成
  IT运维涉及的专业有:网络、数据库、操作系统、服务器(包括小型机)、存储、桌面运维、视频会议、门户、美工、业务管理系统等。这些专业的专业性很强,需要专业化人才进行运维管理。各专业知识面不一样,能从事运维工作的业务面也不一样。如从事网络、操作系统专业的运维人员可以从事桌面运维工作,但从事桌面的运维人员不一定能从事网络、数据库、存储维护工作。对涉及信息安全的专业必须分开运维,如网络权限、数据库权限、操作系统权限、存储权限、业务管理系统权限管理这几个专业必须独立,不得互相兼用,但做技术的可以兼用。IT运维中技术难度低的工作,工作量较大,人员需求较多,而技术难度高的工作,工作量相对小,人员需求相对较少。因此以上提到的每个专业的人员都必须有,但总的工作可以统一协调安排。
  IT运维管理人员较少,工作量大,因此对人员专业面、专业素质要求高。对重要专业要能吃得透,在项目建设中能把握住方案的要害,所组建的设备、系统平台既要保证运行可靠、高效,还要不浪费,而且便于维护。在运维中要能制定合理可行的运维策略,完全了解所管辖的设备运行和停运的风险。在指挥运维作业时,能指出不规范或错误的操作,能意识到相应的风险,并能做到不瞎指挥。不违章指挥。
  运维人员按专业设组,每个组至少有一名技术专家,该专家负责解决该专业的疑难问题,根据日常运维业务量配备相应的技术人员,在信息安全不互斥的情况下可以兼用。
  对以下两个专业特别指出:一是网络专业,该专业覆盖面大。专业性强,影响面大,因此从事网络专业人员的数量有一定要求,并具有5年及以上网络从业经验。专业上具有以下能力:能够独立配置该公司所有品牌的网络设备,能够随意组网,能够优化网络设备的安全策略,能够利用常用工具快速查找、分析、处理故障。二是数据库专业,该专业风险大,数据库一旦故障可能造成所有业务管理系统中断,严重会造成数据丢失,带来无法弥补的损失。因此必须取得DBA证书,并具有5年及以上从事数据库开发或维护工作经验的,才能独立从事数据库维护工作。
  2、IT运维队伍的管理
  一个团队要有凝聚力,相互协作,听指挥。尤其在处理疑难问题和应急情况处理时,更需要团队的力量。每个运维人员必须有相应的岗位及岗位职责。IT运维的岗位应按以上提到的IT专业设置。由于工作量的不平衡,在信息安全不互斥的情况下,可以兼任其它岗位,相互渗透。而且便于人才的培养。每台重要设备确定一个主责任人,特别重要的设备可以增加一个辅助维护人员。IT技术更新极快,新技术学习、专业相互渗透、常规培训必须保证足够的时间和次数。每人每周参加一次集体的培训,相互培训、相互学习,取长补短。每个专业的技术专家每年至少得参加一次一周左右的外送培训。每天发生的运维业务很多,有常规的、有临时的、有应急的。如何使这些业务不落掉。做到每个运维业务定人定责。随时能跟踪运维进度。因此我们需要利用我们的强项IT技术,建一个问题管理系统,对整个业务执行过程进行监控。做到定人提报问题或定时发布常规任务,定人分配问题。得到任务的人员及时对问题进行处理,如果个人处理不了,可以找相应专业的技术专家处理,技术专家处理不了可以找团队共同处理,直到问题关闭。问题的处理过程及措施都在系统中体现。问题处理不及时,或没达到用户的要求。将会报警并产生扣分项
  有了以上的问题管理系统,就可以监控、跟踪每个运维业务,提高信息共享、传输的效率。从而提高运维的工作效率,防止工作失误。周报、月报及每人的考核、团队的考核以系统中具体的数据为依据。应急预案的编制、审核、演练、处理、记录、分析演练、分析事故处理等整个过程,对这个团队处理应急情况尤其重要。预案编制一定要可行、责任到位,而且要言简意赅。容易理解好接收。涉及到的专业、管理部门都要参与审核并签字通过。应急预案应定期演练,只有通过演练才能了解这个团队在处理应急问题时还哪些不足。整个应急预案的演练或事故处理都应该如实按预案要求做记录。为演练或事故分析提供依据。演练分析或事故处理分析可以为这个团队增加事故处理经验,并从中吸取教训。
  3、IT运维策略
  运维策略决定了运维的质量,直接体现经济价值。可以提前发现问题、解决问题,把事故扼杀在萌芽状态。可以继续发挥旧设备的作用,创造新价值。IT运维策略需要注意几点。
  (1)运维应有侧重点,对管辖的设备划分重要等级,根据重要性确定具体设备的运维点、运维措施、运维方法、运维周期。核心机房设备最重要,其次是普通机房设备。
  核心机房设备根据重要性排序:供电系统,消防系统,温、湿度控制系统,存储设备,核心交换机,重要服务器,汇聚交换机,普通服务器,边界设备。尘土、静电是机房设备最大的敌人,大功率设备的散热系统最容易产生故障被破坏。散热系统发生故障后就直接导致温度过高,从而毁坏设备,严重时会造成火灾。因此大功率设备的散热部位是维护的重点部位。
  机房的散热、防尘、除湿、保湿就显得更重要。再次是数据库的重要,主要体现在数据库平台的入侵检测、安全监控,数据文件、日志文件的安全备份,异地容灾。
  (2)重要设备的故障记录,每台重要设备的每次故障及故障处理过程都要有记录。这可以建一个小系统,录入重要设备的台账,记录所关心的重要参数。重要设备的维护策略、故障及处理记录在系统中体现,可供查询,建立动态台帐和历史档案。当新故障发生时,可以利用历时故障及处理过程加以分析,可以帮助新故障的处理。也能为以后维护该类设备提供经验。调整相应的维护策略
  (3)运维方法不当,容易毁坏设备,严重时会造成灾害,因此必须了解一些注意事项。
  运维时重点注意两方面:一是防静电。IT设备根据设备所处的重要等级不同,部分设备的板卡可以热插拔。热插拔板卡时一定要注意防止身体上的静电传到设备上,避免毁坏设备。因此必须带上防静电腕带并接地。平时操作机房设备时也应该带上防静电腕带。这一点很多人都容易被忽视。二是跳线。有些设备的跳线很多,特别是新换板卡,跳线颜色、插头都是一样的。容易跳错。一定注意不能按经验跳线,要看说明书或图纸。否则容易烧毁板卡或设备。跳完线后,最好是请另一个同事根据图纸核实跳线,确认无误再对设备上电。
  (4)每台重要设备、系统、平台的常规维护都应编写一个可行的、容易理解的、简单的操作流程,指导每次常规操作维护。
  每个人对自己管辖的重要设备的操作流程要烂熟于心,并能指导协作的人员一起处理故障。以机房UPS每半年进行一次的充、放电为例,所有开关的开或关是有顺序的,且开机或关机的顺序是不同的,若关错一个都会烧坏UPS主机。另外,还有一组开关在正常情况是不能开的,但在关闭某些开关后又是可以开的,而这个功能又是需要的,若开错顺序或开了不该开的开关都会损坏设备,严重时会造成主机或电池爆炸,酿成火灾。因此必须应有一个可行的操作流程做指导。
  对数据库的数据备份也同样存在顺序的问题或操作漏项问题。如果数据库没有完全停下,就不能做完全恢复的数据备份。另外只有数据文件的备份,无日志文件的备份。也不能做完全恢复的数据备份。因此如果没有数据备份和数据恢复的操作流程指导。数据备份和恢复就容易失误。造成数据丢失。
  (5)重要设备降级使用,修旧利废。某些设备到了报废年限。但由于平时保养措施到位,状况良好的可以降级使用,提高旧设备的利用率。降级的原则是,主设备降为从设备,核心设备降为汇聚设备,存储设备降为备份设备,服务器降为实验平台或监控电脑。多台旧设备拼装使用,但这种情况通常在重要程度较低的末端使用。
  (6)操作系统不要轻易重装。如果数据备份不全,重装系统时容易造成用户数据丢失,另外由于重装操作系统的时间太长,升级打补丁需要很长的时间,同时目前需要安装的安全软件和应用软件也越来越多。这将会影响用户办公。许多操作系统问题可以通过修复系统解决,除非中了系统类的病毒,必须重装系统。
  4、IT信息安全
  IT信息安全需从建设和运维两方面控制风险。从运维的角度就降低信息风险应注意几点事项。
  (1)要有必要的网络安全监控措施,比如端点准人、入侵监测、网上行为管理、网络流量监控。
  (2)掌控核心网络设备及出口网络设备的权限和密码、数据库及数据库平台的权限和密码、安装数据库平台的操作系统权限和密码、业务管理系统的权限和密码。以上四类权限和密码如果有一项掌控不了,或互相串通,都保证不了业务系统的数据安全。
  (3)数据库安全是信息安全的根。数据库安全的监控手段很多,比如数据库日志监测、非法用户监测、数据库平台的非法访问监测、防火墙监测。
  (4)网路设备、出口设备的安全策略设置优化直接影响网络安全。
  (5)网络拓扑结构一定要保密,只能在有限的范围内公开。这是网络攻击需要的重要资料。
原文出处:lifecycle/ityw/71576.html




上一篇:ITIL实施案例的落地要素分析 (二)赖汉伟
下一篇:实施了ITIL之后,我们如何验证ITIL落地的效果呢?
admin

写了 834 篇文章,拥有财富 28725,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies
huangjie528 发表于 2013-9-9 21:39:10
学习了。
Powered by ITIL  © 2001-2025
返回顶部