第一篇：银行IT运维管理的心得
银行IT运维管理的心得
银行运维的压力非常大
• • • 随着金融市场的开放，银行业的风险控制会面临挑战，风险管控优先级要放到最高。尤其是系统风险的的防范，要使用先进的方法论和工具，须做到精细化的风险管理。银行的科技部门压力很大，业务不断增长要求IT持续满足业务需求,系统多，耦合多。一个新系统的建设往往要设计多个系统，各个厂家之间无法协调，问题经常出现。现在银行的系统的建设非常困难。基本上所有需要的系统都了。但是可能不太好用。主要是系统升级，或者部分新的系统的建设。这些都涉及和其他很多部门，系统的关联。系统的上线也需要非常长的时间。• 公司内部共有约上百个系统。系统越来越多。工作越来越多。不象以前可以简单地上一个新的系统，几个月搞定，很有成就感。现在不仅没有，担心的事情，调节的事情一大堆。• 现在有很多公司给银行提供IT产品和服务，选择看似很多，但实际看来做好一个系统确实越来越难，希望各个厂家要充分理解客户和客户的需求，有创新的想法和做法提供到用户，而不是只是关注自己产品和服务本身，这样双方的合作才能可持续发展。• 开发商方面的人员变动非常快，营业和技术人员。刚刚熟悉了，找到了一个好的开发团队，转眼人不在了。现在上一个新的系统，不仅要确认这个公司如何，这个项目经理如何。如果这个公司或者这个项目经理不好，也不能用。• • 数据集成和治理：系统复杂而分散造成数据分散和标准各异，经常无法得出一份权威的报表，矛盾凸显。需要花大力气进行数据的管理。
业务部门不理解科技工作，科技人员不大懂业务，往往会造成沟通困难，项目实施进度缓慢。一个经验是让科技人员到不同的业务部门轮岗，让他们熟悉业务。做项目时，这个人就是部门协调人。• •
但是运维系统很难上
• • • • • IT部门主要应对业务部门的要求，开发了很多的系统
IT部门对于自己的系统的自动化，运维管理的投入和开发确是很少。
随着银行的业务系统的膨胀，复杂度的增大，IT系统的风险在加大。
IT部门的高层对风险的认识比较高，但是他们不清楚具体的对应方法。
IT部门的底层，各个部门的认识不统一
开发部门：着眼于开发 银监会要求银行提供不间断服务。在奥林匹克，万博等重大活动时要求行长签署保障书，军令状。
去年以来有几个重大事故，都是运维人员的失误造成。以下银行事故：
– 华夏银行，光大银行系统，民生银行系统事故。IT主管或被免职，或被警告
运维部门：希望能够对系统进行统一的管理维护，但对开发完毕的系统
没有修改的权利
具体操作人员：更多地关系自己的工作，对如何改进缺少想法
运维产品内容
• ITIL流程管理
运维管理流程控制，综合服务台。大中型银行需要。但是千万注意CMDB，这个东西真难搞，搞不好，一身问题。产品：BMC • 综合监控（各类银行）
相对比较容易理解：网络，硬件，中间件。
问题：应用的监控，需要开发。联动太深，以后对应用程序的变动又会有影响。只能是浅层次的结合。
产品：IBM Tivoli，BMC，日立 JP1 • 自动化（各类银行）
一般这个概念还不太为人知道，国外应该是日本银行做的比较好一些。国内做的相对比较早，比较好一点的是浦发银行。
内容：批量处理的统一自动调度，灾备切换流程自动化，各种手工作业的自动化。相对比较难以了解，但是很实用，可以一步拓展。其实就是流程化，但是和一般的流程不同，可以对系统自动进行操作。
问题：技术人员和开发厂商对这个概念还不太明确。产品：日立JP1，其他公司也有，但内容相对不太全面。
国内厂商：号称什么都可以对应，但是产品不规范，小的政府部门还可以，银行就算了。
第二篇：IT运维心得分享范文
360公司运维心得分享
在很多“外人”的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。
当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。
在360，运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级，进行产品化改进，核心目标是为了降低运维成本、缩短研发周期、让产品试错更廉价。理想很丰满，现实很骨感，从最初服务少量项目、几十台服务器，发展到大量具有数亿用户的项目，我们也在不断摸索，在试错中成长。在这个过程中，我们经历了两次重要的升级。第一次升级：运维工具化
运维工作中有很多琐碎的、重复的事情，初期我们只有两个IDC，服务器数量有限，项目数量也较少，靠纯手工劳作还可以应付。但随着时间的推移，项目暴增，随之IDC和服务器的数量也成倍增长，同时360各项目都是小团队在做，开发风格不同、习惯各异，但极致要求响应速度，如果运维工作按照之前方式进行，很难满足需求。大势所趋，我们必须进行工具化升级，将重复的事情自动化。
在工具化过程中，我们秉着低成本、拿来即用的原则，借鉴业界成型的方案，同时将精力用在对开源软件的研究中，有开源工具就绝不自己凭空创造。初期，我们只围绕开源软件做周边脚本开发，不动核心代码，在实践中总结经验。例如，在最基础的部署软件环境中，我们基于YUM搭建了自己的包管理系统，将常用软件打包，同时根据项目做成模板，这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成，服务器批量操控依赖SaltStack。就这样 我们的运维兵器谱在不断地丰富。
另外，运维工作离不开监控报警，这是一件让无数运维人苦不堪言的事情。而会休息才会工作，监控体系必须优化。
我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等；应用级主要监控常用软件的健康状况；项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常；用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多，开源工具有Nagios、Cacti、Ganglia、Zabbix等，同时自己也开发了一些针对项目场景的监控工具，但万变不离其宗，都是围绕上述几个维度进行监控，然后再进行分级预警和报警。
为了减少报警骚扰，我们分级处理，将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例：每天下午6点，统计 磁盘使用率超过80%的机器，发出邮件预警，下班前解决；在预警的基础上，超过85%触发短信报警；超过90%就要持续报警，避免事故的发生。此外，随着 服务器数量的增多，硬件故障在所难免，架构设计需要考虑高可用方案，冗余范围内的服务器故障会以邮件预警的方式发出，避免对运维工程师的骚扰。
有了监控工具和分级机制，还需要有好的制度。为了大部分人可以安心休息，我们每天有专人负责处理常规报警，遇到无法解决的问题才要求他人协助。第二天的负责 人要针对第一天的报警找出根本原因，并尽力解决，因为如果无法根治，困扰将持续发生。所谓线上无小事，实际工作中复杂场景引发的问题数不胜数，所以可以宽 容第一次错误，但不能接受同样问题发生第二次，要不断地总结和完善。
工具化是运维的必经之路，是向更高层发展的基础，面对运维这样复杂的学科，这样一个极其磨炼人意志的工种，运维工程师需要用聪明的方式解决复杂的问题，节省时间，去做更有意义的事情。
第二次升级：运维产品化
我刚提出运维产品化时，有朋友开玩笑说，你做后端运维吃苦受罪这么多年，看着产品经理吃香的喝辣的，羡慕嫉妒也想转行做产品吧。也有人说，你是在偷换概念，不就是做自动化运维平台嘛。其实提出这个概念，一方面是源于有了足够的工具化积累；另一方面是想换一种思路做运维，培养产品观，站在用户的角度思考问题，让处于后端的运维工程师主动挖掘需求，围绕运维做更多的探索，提升团队技术能力，解决海量用户带来的问题。有了这个想法，就需要将无形的技术转变为有形的产品形态，同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人，意在让小伙伴们借助巨人的肩膀成长，轻点鼠标，运筹帷幄。
想到做这个平台，源于对实际工作需求的观察。产品经理有了创新点之后，开发工程师就想以最快的速度上线，但又会很痛苦，因为产品就好比宝塔明珠，塔基需要一 层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟，“兄弟有难得拔刀相助”，因此我们明确了开发工程师就是运维平台的用户，运维工程师在平台的建设 中扮演了多重角色，是建设者也是使用者，但目标是为用户解决问题，让我们的用户有极致的用户体验。基于这些想法，我们勾画出了宏伟蓝图，提供一个塔基，第一层提供核心基础服务，如Web、RDB、NoSQL等；第二层提供通用基础服务，构造一个完美的平台，让开发工程师受益。但勾画的平台功 能大而全，需求都是我们替用户假想的，这样做的后果就是进展缓慢，但做出的功能没人用。我们在失败中反思，意识到需求还得从日常工作中去挖掘，平台上每个功能模块都必须解决用户的痛点。互联网精神唯快不破，要围绕“快”找痛点。早期开发和运维的合作中，更多的是邮件、IM及当面沟通，跨团队的沟通成本是第 一个痛点。初期平台建设中，我们从加速流程开始进行摸索，以“需求任务流”为核心，将通用需求规范流程，统一需求提交页面，同时尽量为用户提供选项，而不是随意填写，尽量减少沟通成本，同时为完全自动化打好基础。由于完整的自动化流程开发成本比较高，初期我们还“投机取巧”，用户提交需求以后，只是把格式 化的邮件发送给运维工程师。运维工程师使用半自动化工具干活，完成后再通过平台任务流告知用户结果，手工操作的部分是隐藏在平台后面的，用户不得而知。就 用这种方式，我们的平台积累了不少用户和口碑。之后我们将日常需求分层、分类：主机类包括主机申请、账号授权、软件部署等；Web类包括配置文件管理、域名管理等；DB类包括建库、建表、SQL审核、授权等。再攻克技术难点将一个个需求实现完全自动化，点点鼠标解决问题。
关于需求任务流，还有个小插曲，标准的任务流由提交、审核、驳回/通过组成。但这个流程太死板，例如用户提交的一个需求，在审核的过程中有待商榷，运维工程师会和开发工程师 沟通，最终达成一致意见即可，而如果按标准流程需要驳回再提交。为了让用户少一次操作，我们增加了管理员可编译功能。有些同事反对这样做，觉得不符合常 理。不过有时候常理是需要结合实际场景打破的，就为了让用户使用更简单。
近期为了进一步提升项目试错阶段的速度，我们在平台上推出了一个新功能：“项目孵化器”。以典型的Web业务为例，以往，申请Web Server、账号、数据库实例、负载均衡等是提给运维最基本的需求，每一步都是时间成本。使用“项目孵化器”可以最大限度解决这个痛点，只需在平台上进 行两个步骤：第一步填写业务名称，预估峰值QPS；第二步选用MySQL、MongoDB、Redis等相关数据库资源。两步之后，Web Server、数据库实例等所需资源会瞬间展示在用户面前，同时包管理、配置文件管理、代码发布系统、监控系统等配套辅助功能随之开通。
与之前的模式相比，效率和规范化都有明显提高。说起来很神奇，但实现理念很简单，我们提炼日常项目中的通用方案，构建资源池，在项目发展初期最小量匹配资源。在孵化器的设计阶段，我们听到了很多不同的声音。例如，让用户填信息不够全面，架构太简单不满足全部需求，诸如此类问题，让人头痛欲裂。经过过往项目 分析及用户调研，发现项目尚处于试错阶段，快速试错是首要需求。至于项目发展中衍生出来的需求，可以再用平台扩展功能去解决。当利用孵化器建立一个试错项目之后，用户进入平台想看见什么？展现形式如何？还能做什么？这些问题随之而来。
众所周知，项目中的关联关系是个复杂的问题，解决不好，就像一盘散沙无法联动。为了解决此问题，首先我们确定平台各功能模块以项目名为主键，将项目的域名、负载均衡、Web Server、数据库、通用基础服务等相关联。项目后期各功能模块的扩容可以借助关联关系自动化完成。例如增加一台Web Server，即可自动部署软件环境，完成相关节点授权、上传代码、测试上线。
展现形式上我们借鉴社交网站的实现方案，以“我的项目”为中心，用户进入平台以后默认页展示项目在平台中用到的各功能模块信息，例如域名、主机数量、数据库实例和监控指标等。做到信息清晰可见，操控简单易用。
在平台建设中，我们一直遵循两个准则：第一，把事情由复杂变简单；第二，给用户极致的用户体验。所谓极致，就是要超出用户的预期，但只有挖掘用户潜在的需求，才能做出超出预期的功能。传统的运维模式，大多是开发工程师提需求，运维工程师满足需求，运维工程师主动推进的意识不够。360的文化中有很重要的一点是Ownership，一个项目的成功与失败，运维工程师是有责任的，因此需要在日常工作中时刻提醒自己“这个项目是我的，为了让项目变得更好，我们需要主动思考，为开发工程师提供更多的增值服务”。例如一个项目上线前，会默认部署日志收集模块，收集汇总后进行访问日志自动化分析，以时间维度展示访问量走势，同时辅以IP地址分析模块展示地域及运营商分布。同时基于访问日志状态码做进一步的页面分析，然后以日、周、月维度生成一份体检报告，以及应对方案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和我们的距离，一起去探讨、改进，做出更多有利于项目发展的功能。结束语
运维工作在一家公司中至关重要，但传统的运维模式一定程度上限制了运维工程师的技术发展，更抑制了创新思维，我们需要利用运维“宽泛技术”定位的优势开拓思路。例如运维工作需要和很多开发团队合作，协助架构设计，在这个过程中会接触到很多开发团队的技术积累，可以把各家之所长进行聚合，将一些基础服务进行平台化改造，资源共享。也可以根据项目的需要，主动做技术研究，将基础服务做成一个个小产品，提供给开发团队使用，帮助项目缩短研发周期，稳定发展。在当今技术背景下，运维工程师应该在红海中寻找蓝海的思维模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。
第三篇：银行IT运维职责
最佳答案检举IT运维是IT管理的核心和重点部分，也是内容最多、最繁杂的部分，该阶段主要用于IT部门内部日常运营管理，涉及的对象分成两大部分，即IT业务系统和运维人员，该阶段的管理内容又可细分为七个子系统：
■ 设备管理：对网络设备、服务器备、操作系统运行状况进行监控
应用/服务管理：对各种应用支持软件如数据库、中间件、群件以及各种通用或特定服务的监控管理，如邮件系统、DNS、Web等的监控与管理
■ 数据/存储/容灾管理：对系统和业务数据进行统一存储、备份和恢复
■ 业务管理：包含对企业自身核心业务系统运行情况的监控与管理，对于业务的管理，主要关注该业务系统的CSF（关键成功因素Critical Success Factors）和KPI（关键绩效指标Key Performance Indicators）
■ 目录/内容管理：该部分主要对于企业需要统一发布或因人定制的内容管理和对公共信息的管理
■ 资源资产管理：管理企业中各IT系统的资源资产情况，这些资源资产可以是物理存在的，也可以是逻辑存在的，并能够与企业的财务部门进行数据交互
■ 信息安全管理：该部分包含了许多方面的内容，目前信息安全管理主要依据的国际标准是ISO17799，该标准涵盖了信息安全管理的十大控制方面，36个控制目标和127中控制方式，如企业安全组织方式、资产分类与控制、人员安全、物理与环境安全、通信与运营安全、访问控制、业务连续性管理等
■ 日常工作管理：该部分主要用于规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决经验与知识的积累与共享手段IT运行维护管理的每一个子系统中都包含着十分丰富的内容，实现完善的IT运维管理是企业提高经营水平和服务水平的关键。运行/维护阶段与服务/支持阶段的分界线为前者是面向IT部门内部的管理，而后者是面向业务部门、企业中的其它人员或直接面向客户。
第四篇：IT运维项目管理心得—风险管理
IT运维项目管理心得—风险管理
过在PMP的学习，结合多年的IT运维项目实施管理工作经验，我对项目管理中的风险管理有了进一步的学习和认识，我真正认识PMP项目管理在现实生活中的运用。
风险管理是预防、规避项目风险的主要手段，是完成项目计划内的期限、预算内费用、规定的技术指标等的重要保障。在每个风险管理周期都应该做好从设计、合同、进度、质量、费用、沟通等管理工作中收集相关信息，并将这些信息反映在风险管理过程中的各环节工作中，并及时进行反馈。
现将我对项目风险管理的理解总结如下：
1、做好风险识别
在项目启动阶段，将对项目需求及项目实施过程中可能面对的风险进行全面的识别，结合公司已有的风险评估表，对识别出来的风险进行评分。
2、做好风险管控
在项目实施阶段，对前期已识别的风险，按照不同的风险等级进行管控，针对高危等级的风险（如：客户关键业务系统宕机）通过外包（购买原厂服务）或采取一定措施降低风险值的方式解决（提供专业人员提供24小时值班监控）；针对中等级的风险，则制定相应的风险解决方案（如：巡检、定期保养、设备实时监控），来减少或缓解风险的发生概率；针对低等级风险，则采取定期监控方式。
3、做好风险监测
风险监测是持续不间断进行的过程，主要包含跟踪已识别的风险，监测残余风险和识别新的风险，形成风险管理监控报告，对重新识别的风险进行排序形成风险评估表，为管理人员提供决策的量化依据。通过对风险的良好监测和控制并形成风险管理监控报告，在风险发生前做出有效决策，减少风险造成的损失。（慧翔天地广州学员黄贤裕）
第五篇：运维管理定义
运维管理(IT Operations Management)帮助企业建立快速响应并适应企业业务环境及业务发展的IT运维模式，实现基于ITIL的流程框架、运维自动化。
核心思想随着国内企业业务信息化的深入, IT运维部门所负责的IT设备及软件的运行维护工作变得越来越复杂，技术难度也越来越高。传统的IT工具和流程集中在技术上，而不是业务目标上。业务服务管理(Business Service Management)使IT能轻松满足业务的需求，转变企业的环境，使业务部门和IT部门领导者能够拥有统一的语言，通过统一的界面面对挑战，理解新变化所带来的影响。
BSM主要强调从业务的视角来看待企业的IT运维，从而最大化发挥IT对企业业务的推动作用，这就IT运维的核心思想。
着眼点IT系统的业务服务管理主要着眼点
一、确立以业务价值为核心，业务驱动管理的管理思想面向业务要首先在IT管理的战略层面上建立“业务驱动”的IT治理和管理思想，使得业务部门的目标和IT运维的目标一致，都是为了企业整体战略目标的实现，把对业务的支撑能力和管理实效，作为评价IT系统效用和IT部门工作的首要指标。只有这样，才能在全企业范围内建立“技术服务于业务发展”的意识和文化，是真正实现IT与业务融合，共同为企业的战略目标服务。
二、建立关键业务服务模型今天的业务部门对应用程序的依赖性比过去更强了。应用程序软件可以实现关键业务流程的自动化 —自动化既包括付款、资金转账、下订单和订单履行。由于应用程序故障或性能问题可能导致严重的业务影响，因此业务部门迫切需要 IT 部门在发生问题时提供更高的应用程序服务级别和更快的问题解决方案。所以，必须结合企业战略和目前业务运营情况，辨识企业业务服务，特别是关键业务应用。为这些核心业务系统服务，建立和企业未来发展愿景、目前IT架构、管理模式等相适应的业务服务模型，能够清晰地描述业务与IT之间的关联关系和IT服务的关键目标。
三、管理信息共享目前，出于对IT资源专业化、精细化管理的要求，企业部署了诸多的监控管理工具，如网络监控、系统监控、数据库监控工具等。一般来说，这些监控工具往往来自于不同的厂商，彼此之间缺乏信息共享的手段。而一个具体的业务是由网络、主机、应用本身所组成，管理信息无法共享，这就造成了当一个故障出现时，无法通过系统直接自动分析并定位故障点，加大了IT故障的分析难度，降低了解决问题的效率。业务服务管理可以有效整合企业已经构建的众多IT监控系统，将分散的IT管理信息集中到一个单点的管理平台中，从而可以快速进行故障定位。
四、根源问题定位随着企业业务的快速发展，IT环境越来越复杂，IT组件越来越多，同时各组件之间的关联关系也更加纷乱和复杂。业务服务管理能够提供有效的根源问题定位能力，它着眼于企业的核心业务系统，通过集中与业务相关的IT信息，根据业务逻辑和IT组件之间的关联关系进行建模，企业可以在业务模型中的任何一点进行快速的根源问题分析和定位，大大提高了解决问题的速度和准确度。
五、故障影响范围评估当我们发现IT故障时，我们不仅应该关注故障本身，更应该考虑该故障对业务系统的影响。通过建立业务服务影响拓扑，可以快速的了解企业的关键性业务及业务故障时的影响范围，通过了解企业具体的业务环境，优先处理关键故障点。
点击咨询 