1、IT 运维管理流程介绍ITIL 框架 流程分类 流程名称 流程描述及分类故障处理事故发生后，第一时间及时的恢复服务、上报各级主管及相关人员，有些在规定时间不能解决或没有解决方案时，就需要将事故的处理任务交给更有经验和有权限的支持人员。并协调资源快速的解决。性能事故处理 对系统性能问题的事故进行及时处理。事故自动恢复 当事故发生后，自动重起进行恢复。事故手工申报事故发生后，第一时间及时的恢复服务、上报各级主管及相关人员，并协调资源快速的解决。事故解决升级由于现场技术能力有限无法解决的事故或在规定时间无法提出行之有效的解决方案时，需将事故进行升级处理，交给更有经验和有权限的支持人员，请求协助。事故
2、跟踪升级 若事故不能在指定时间内完成，可以马上升级。事故报告 当事故发生时，在分析和调查后，提出相应的报告。事故紧急启动方案事故发生了一段时间，紧急联系厂家或者相关合作伙伴来解决问题。事故管理故障处理预演 对故障进行模拟式的处理。问题记录建立问题记录流程，将自己已解决或未解决的问题及故障登记出来，供大家参考或分析解决。问题关闭 关闭问题问题管理问题跟踪 协调各方资源，对问题进行详细的跟踪分析，并确保问题解决。配置审计 对所有配置项进行账目式的核对。服务支持配置管理 配置信息登记 记录和维护 IT 系统配置情况，包括配置，配置项，版本、规格、数量等等。配置报告 定期报告所有受控配置项的当前状态及
3、其变更更轨迹。主机与操作系统配置变更发现网络配置变更发现应用配置变更发现主机系统、网络、软件、配套环境等方面的操作或变更。口令变更发现 自动发现口令被修改，通知 IT 服务经理。口令手工变更 系统口令需要定期维护更改、VPN口令申请。用户信息变更 人员信息维护-人员注册注销、调动。变更管理系统需求变更 牵涉到能力管理。Delta 上线流程 补丁，升级。Full Release上线 全新应用经过开发，测试、上线。系统版本管理 对版本进行增，删，改。发布管理系统推广 系统上线后进行推广培训。可用性改进 对系统、服务或资源进行可用性的提出改进方案。可用性管理 可用性报告 形成系统或资源可用性的报告。
4、能力预测报告 对系统、服务或资源进行评估预测。能力评估报告 对系统、服务或资源进行评估预测。能力管理能力改进与优化 对系统进行调优、程序修改等。服务满意度调查针对服务水平，对客户进行满意度调查。服务水平改进 根据调查和评估的结果对服务水进行改进。服务交付服务水平管理服务水平评估 对服务水平进行评估。报告维护周报 自动触发维护周报。维护月报 自动触发维护月报。例常报告维护年度总结 自动触发维护年度总结报告。每日检查 自动触发每天检查的提醒。每周检查 每周一触发检查提醒。系统健康检查 系统健康检查报告、系统全面检查。例常检查重大节日前检查 在重大节日到来前作提醒检查。重要事件提醒 及时对系统中存在
5、的隐患进行提醒。口令过期提醒 对系统口令过期进行提醒。断电提醒 在断电前作提醒工作。提醒例常杀毒提醒 对每周或定期进行杀毒工作进行提醒。维护例常会议通知 对例常会议的维护工作发放通知。维护例常培训通知 对例常培训的维护工作发放通知。维护任务指派 定期定时的分发指派任务。节假日值班安排 对节假日的值班情况进行安排。维护工作维护例常值班计划 对日常的值班计划进行维护。自动杀毒 定期定时地进行杀毒工作。杀毒跟踪对杀毒的情况进行跟踪，检测并记录杀毒的信息，及可以时之有效跟踪病毒情况。自动数据备份 对系统数据进行自动备份。自动数据管理 fileserver，数据增，删，改。FTP 服务维护 对 FTP
6、服务进行维护支持。Web Server维护对 Web Server 服务进行维护支持。自动化运维自动化J2EE 应用服 对 J2EE 应用服务器进行维护支持。务器维护数据库维护 对数据库进行维护。Lotus Domino维护 对 Lotus Domino 进行维护。DNS 维护 对 DNS 进行维护支持。代理服务器维护 对代理服务器进行维护支持。域管理器维护 对域管理器进行维护支持。定义了网站可用性指标，如何获取网站的可用值? 监控工具该粉墨登场了。多数网站都会倾向于利用开源软件自行搭建监控平台。笔者一向认为，即使网站有一台服务器，也应该搭建监控工具，这是保障网站能持续改进的基石。常见的开源监
7、控工具有 Nagios（www.nagios.org）、monit（ 也可能是当前国内最被广泛采用的监控软件了，根据官方描述，Nagios 是开源的主机、网络、服务监控程序，从这个描述能看出，Nagios 的设计目标是很庞大的。依赖其强大的扩展性，通过分布式监控模式，管理上千台甚至更多的服务器也不在话下。而对于大型集群环境，Ganglia (http:/ganglia.info/) 是个不错的选择。另外商业化运作的比较好的开源监控工具或框架还有 Zenoss (http:/ (http:/ (http:/ OpenNMS(http:/opennms.org/) 等。这几个的定位都是“企业级“监
8、控平台。当然，功能的确不比 Nagios 差，也有的弥补了 Nagios 的一些不足之处(比如 Zenoss 增强了对 Windows 服务器的监控能力)。但出于种种原因，在国内的流行程度并不广泛。(图 2: Nagios 分布监控示意图图片来源: http:/ Web 监控需要就不得不提 Nagios 灵活的插件机制，最简单只需要几行 Shell 代码就能实现基本的插件功能。多数情况下，脚本捕获系统日志中的特定事件，通过 NSCA Client 发送给中心监控服务器即可。灵活性是衡量监控软件的一个重要标准，从这一点说，多数传统的商业网管软件怕是都不如 Nagios 这样胜任现在日趋复杂的网站
9、环境。提到网管监控，必然要谈到 SNMP。跨平台或者针对专有设备的监控离不开SNMP，但有的时候 SNMP 的安全性也的确会带来严重问题。这就需要运维团队中的安全专家对监控系统机制的安全性做整体评估，或是提升运维团队的安全意识以避免在监控过程中引入更多的安全问题。有些公司的运维团队喜欢自己写监控工具而不是利用已有的第三方开源工具。这种重复发明轮子的做法笔者认为是不可取的。这样做最明显的一个缺点是软件本身的维护成本可能会更高，而且团队人员变动的时候后续代码维护也是个潜在的问题。至于商业工具的选择，这里不作评价。报警机制光有监控而报警机制跟不上，不能及时把紧急情况下的信息传递给运维技术人员，那么监
10、控形同虚设。现在报警信息发送途径主要有邮件、IM、SMS 三种(过去书籍中提到的传呼方式已是明日黄花)。这几个途径中，邮件告警可能是最简单的，实现起来容易，一行命令即可做到，但因为邮件本身的异步属性和邮件服务器的延时问题，很难让运维人员及时得知信息。所以，如果比较严重的告警信息必须考虑其它实时性比较高的方法。至于发送到 IM，如果 IM 是支持 Jabber 的，实现起来并不难，可靠性也会有一定保障，而如果 IM 比较封闭，那么可行性就不大了，除非 IM 公司对你开放 API ，否则任何取巧的技巧来发送消息的方法其可信赖性都不强、SMS 是大家都比较倾向的一种方式，只是有很多人不知道具体如何实
11、现，说白了也就是一层窗户纸。如果有电信服务提供商(SP) 能够提供基于 Web 的调用接口给你，那么直接利用 Wget 或是 cURL 工具模拟浏览器处理表单信息即可，几行命令即可搞定。如果不具备这样的条件，不妨考虑一下短信 Modem，现在市场上这样的短信 Modem 很多，价格不贵，大多都提供二次开发的功能，简单的写点脚本即可实现目的。至于网上有人推荐的免费短信服务，因为实时性比较差，笔者是不推荐的。天下没有免费的午餐，这样的服务往往信息发送优先级很低，而且，短信到达率很难保障。值得一提的是，报警服务器本身也需要监控的。建议定期发送测试邮件、测试短信来验证告警功能处于正常状态。尤其是在节假
12、日来临前更要反复确保该功能是正常可用的。一个成熟的运维管理环境包括机房环境的管理，网络设备的管理，链路的管理，端口的管理，流量的管理，业务仿真端口的管理，各种系统服务器的管理，数据库，中间件，应用系统等软管理等等。l 运维系统应该能够提供统一的运维平台，管理人员可以在同一页面进行作业计划、工单等方面的处理，为用户提供一个集中处理的平台而不需要到各个功能模块中去分别处理。l 作业任务是整个运维体系中非常重要的一环，维护人员需要通过作业任务的执行对现有系统运行情况进行了解，以便为网络优化和问题处理提供更好的分析数据。同时系统提供自动化的任务功能，能够使作业中日常的工作能够自动执行，减轻运维人员的日
13、常工作量。居然能够让作业自动化配置与布署。控制好作业的时间周期的- 通过 Mocha ITIL 最佳实践方式的 4 个循环阶段(Plan-Do-Check-Improve)，循序渐进的实现 IT 运维流程;- 通过 Mocha ITOM 提供的 CMDB 为核心，将各配置项相互关联，通过拓扑方式展现，一目了然;- 通过 Mocha ITOM 提供的流程与表单的结合，通过可视化修改与配置，更好地实施 ITIL 式运维计划;- 通过不同 KPI 指标，规范 IT 运维工作量分配和绩效考核;- 持续改进循环是所有 ITIL 流程的基础，通过计划-实施-检查-改进后，不断完善 IT 运维流程，提升 I
14、T 运维效率。由于环境十分复杂，企业会指派不同的人员维护数据中心中不同的数据。需要了解所有不同角色与数据中心设备之间的交互过程，角色之间责任重叠。企业的高层决策者需要参与整个计划的过程并做出决策。 数据中心的完整资产信息数据中心中包括大量的服务器和设备，首先需要收集这些硬件资产的信息，以及这些资产之间的关系。资产之间的关系对于计划非常重要。这里举例来看一个服务器和网络之间的关系：o 通过一个逻辑定义的 IP 地址访问服务器 o 必须在操作系统中定义一个网络接口才能定义 IP 地址 o 服务器中必须有一个物理网卡来支持操作系统中定义的网络接口 o 网卡具有特定的属性，例如 MAC 地址，用来通过
15、物理链路和数据中心内的其他设备连接 o 网卡必须连接到交换机的一个端口上 o 交换机也拥有自己的关系，例如端口属于哪一个模块，交换机之间的连接关系 上述的资产信息需要被收集起来。图 5-9 展示了一个数据中心的例子： 绘制业务数据流在将设备逻辑关系文档化后，为了确定可以实现自动化部署的部分，正确理解配置这些设备的流程非常重要。另外了解设备在 业务功能上的用途 也很重要。根据这些信息，我们基本可以确定数据中心的基础构架，例如路由器、交换机、数据库服务器和负载均衡器这些设备的变动比较少，而且配置方式比较特殊，因此不适合使用自动化部署。而应用服务器通常使用相同的硬件并且经常发生变动，根据我们收集的信
16、息分析来看比较适合使用自动化部署。下图是一个业务数据流的例子： 图 5 - 10 数据中心范例的数据流自动化部署完成后，可以在没有人工干预的情况下将一台服务器从裸机开始到操作系统部署到应用部署完成，而后还能够将这台新的应用服务器加入应用服务器群集，并开始对外提供服务。 了解手工部署流程将数据中心设备当前的结构和使用情况文档化后，还要将管理数据中心的 IT 流程文档化。这样就可以将设备从抵达到进入数据中心需要进行的工作整理为一个步骤列表。这个列表包括上架和接电等手工步骤以及可以融入自动化管理平台的自动化步骤。部署流程通常是跨组织角色的，并且应该和现有的自动化技术结合组成完整的解决方案。通过这种文
17、档化之后，你就可以理解一个数据中心的那些部分可以使用自动化管理。每个组织在实施自动化管理时有一套独特的步骤，并且每个步骤都有不同的需求，因此这样的自动化管理平台并不是一成不变就可以解决所有问题的。针对每个用户不同的环境、不同的流程，我们都需要对这个云计算平台进行定制化。这样才能满足不同用户的需求。 组织结构自动化部署涉及到很多复杂的步骤，包括物理基础架构、操作系统、网络基础架构、应用程序部署、监控、项目管理以及和其他部门的协调。一般日常的服务器部署不需要和其他部门协调就可以完成，除非存在组织上的、安全上的或其他方面的原因。 在很多组织中，架构中很多部分被认为对业务是非常关键的。例如，网络架构部
18、门需要满足网络可用性以及变更管理和安全性问题的服务级别协议。而云计算平台通常需要改变 IT 文化，要更好的使用这个平台，就需要将组织中的每个部门都融入到其中。 标准化很多组织的 IT 环境都是异构的，这使云计算平台的实施变得更加复杂。因此最好的方法就是数据中心的设备都使用标准的硬件配置，使硬件类型最少化。例如针对应用程序服务器层，使用统一的硬件平台可以减少对每台服务器的手动配置的工作量。 和当前的自动化流程整合很多组织都已经在 IT 基础构架的不同层次使用了自动化部署，例如启动服务器、软件分发包、系统管理软件和用来运行日常任务的定制化脚本等技术。但是这些自动化技术都是针对于某一个子系统或者局部
19、的，在部署整个系统的过程中还是需要很多的人工介入来完成。云计算平台并不会完全替代现有的这些技术，而是依赖于这些自动化技术和流程来实现更高层次的、全局性的自动化管理。 结束语 在本文中，我们从当前 IT 的发展现状出发，结合 IBM 2008 全球 CEO 调查结果，分析了全球企业所面临和急待解决的问题，讨论了相应的应对方法 - 建设全新企业级数据中心 （NEDC） 的必要性，并介绍了 NEDC 的概念，特征及其发展阶段。在明确了 IT 优化在 NEDC 建设过程中所起到的作用之后，我们分别针对进行 IT 优化需要采用的四个架构模式 - “物理整合”、“虚拟化”、“灵活的 IT ”和“将 IT 作为服务”，从技术上进行了深入浅出的探讨。
