这是一个补丁修补版本。我的名字也第一次出现，感谢Michael的帮忙，没有你我可能迟迟发不上去这个翻译。完整的release notes见 http://otrs.org/releases/3.0.11

Related posts:

1. OTRS FAQ 1.5.3 : you have six reasons to use it
2. OTRS::ITSM期待中的开源ITIL工具
3. OTRS.ORG，it is time to check it out；不得不：）

原帖：ITIL、OA、ERP三者的共同点和区别？
在做项目的时候客户都会问到三者的区别，谁能给详细的解释一下，谢谢！！！

我的回帖：

OA：实现无纸化办公而已，说好听点是信息化建设，说难听点，有OA可以少砍几棵树！
ERP：往往是企业运作的核心，从研发、生产、销售等等环节都需要跟踪记录，越大的企业越需要，否则管理者就成了盲人和瞎指挥的人，企业战略无法实现。

前两者都是生产力的工具，能通让业务流程得到有效的管控，从而达到企业的战略目标。

ITIL是方法论，是偏学术的东西，不过它是前人管理经验的总结，这是它与科学的区别。不过也有相似之处，好比数学和物理学科里的各种定律和公式，能放之四海而皆准。
例如：万有引力定律
定律内容：
自然界中任何两个物体都是相互吸引的，引力的大小与两物体的质量的乘积成正比，与两物体间距离的平方成反比。
公式表示：
F=G*M1M2/（R*R） （G=6.67×10^-11N•m^2/kg^2）
F: 两个物体之间的引力
G: 万有引力常数
m1: 物体1的质量
m2: 物体2的质量
r: 两个物体之间的距离
依照国际单位制，F的单位为牛顿(N)，m1和m2的单位为千克(kg)，r 的单位为米(m)，常数G近似地等于
6.67×10-11次方N·m2㎏-2次方
（牛顿米的平方每千克的平方）。
可以看出排斥力F一直都将不存在，这意味着净加速度的力是绝对的。（这个符号规约是为了与库仑定律相容而订立的，在库仑定律中绝对的力表示两个电子之间的排斥力。）
适用范围:
两个可以视为质点的物体之间，或者是两个均匀球之间。

类似的 》》》事件管理流程：
定律内容：尽快恢复正常的业务运作并将事件对业务运营的负面影响减少到最小，从而确保维持服务质量和可用性的最高水平。
适用范围：可以使用与IT基础架构的管理，IT业务服务支撑，其他行业的服务管理，甚至于酒店的日常运营管理。你是不是最希望你们小区的物业也上事件管理呢？呵呵:)

ITSM是把ITIL用于IT管理的特指，是说用ITIL的理论来管理IT的服务，服务可以包括IT的基础架构服务或者IT业务服务。一个合理的比喻是ITSM是IT的ERP项目。

ITSM项目做的最差劲或者最初级的水平是把ITIL流程电子化，消灭以前报修和变更的手工纸质单子，有些客户做了ITSM项目时说，原来如此，ITSM也就是一个IT的大OA。

在此引出另外一个话题：我看到有些项目中，把流程的落地，做盲目的实施，实施的结果是流程的电子化，把有些流程生硬的做成电子表单。其实偏离了该管理流程的本意和根本需要达到的目的，更糟糕的是，各种流程单之间居然是不集成和相关联的。例如：最配置管理流程，生生的做出一堆的配置数据维护流程单，也加入审批，分派，复核等过程。这种节外生枝的东西，其实反过来阻碍了配置数据维护者及时有效的维护CI数据。结果可能是管理员宁既不做这些垃圾配置维护单，更不去修改CI数据。合理的做法可能是把配置管理流程的数据维护活动从有形化为无形，把这些活动揉入其他流程中，特别是变更管理流程。

Related posts:

1. ITIL v3 术语表
2. ITIL v3 MindMap脑图
3. ITIL V3 Study Notes (2)

上图显示了Overloay对象的地位和功用，我们都是工作在BMC原厂的开箱即用的程序对象层面上，所有安装程序首次安装到系统上的应用的所有对象都是Base对象。在这个基础之上我们做定制和开发，定制和开发出来的对象有两种，一种是Overlay对象，中文翻译为叠加对象，这种叠加对象并不会对原有的Base对象进行修改，而是覆盖在其之上的，两者是和谐共存的。另外一种对象就是纯客户化的对象，即以前没有，开发人员新加入的对象，这种对象和其他两种对象是没有冲突的。

Overlay可以是Base对象保持原状有什么意义？最重要的一点就是对升级有好处，以前我们开发的所有Remedy应用系统，大家都不敢做升级，当客户或者BMC的support要求要升级的时候，我们都会抵制或反对，这里的原因相信大家心里都知道。那么以后大家就不必这样了，只要在开发定制的过程中合理的使用Overlay对象做定制开发，方能保证定制后的系统对补丁和升级来者不拒。

那么如何使用到Overlay对象呢？在Dev Studio中选中需要修改的对象，点右键选择create overlay，你就能在原厂的对象上做一个叠加对象了。这里提出一个7.6.04 Dev Studio的错误做法：默认登录到Dev Studio以后，你可能会发现在默认的最佳实践模式下，你不能向以前一样任意修改东西，发现在切换到另外一个模式（好像是经典模式）之后又什么都能修改了，所以你就认为找到了修改的方法，其实这种操作恰恰是绕过了Overlay功能。在这种模式等于在以前旧版本产品的模式下开发做。

老外如是说：What the overlay feature does is to simply allow you to do the following:

1) Add new items that are identified as custom items you have added.  They are flagged as custom items in the displays.  You can easily sort by and get a list of custom items.  And it is COMPLETE.  You don’t have to worry if you are missing one or if you forgot about something you added.
2) Update existing items by leaving the original definition there and updating a copy of that definition with your changes.
a) all the benefits of #1 are present AND your changes have the exact same name/identification as the original
b) you can at any time see your version vs. the original to see exactly what has changed from out of the box
c) Not have to deal with “ripple changes”.  By this I mean that if in the past you copied a filter to a new name (to avoid overwrite at upgrade), you had to copy any guide that included it and then any workflow that called the guide to use the new name.   The fact that the items are the SAME ITEM means that there is no need to change other things.
d) When an upgrade occurs, the definitions in the base layer are changed but NOTHING about the items you have overlaid (or added custom) are changed. So, your changes are not overwritten.  In fact, your changes continue to be the overlay and continue to sit on top of and override the definition that was newly imported with the same name/id.
e) After the upgrade, you can again compare your overlay with the new out of the box definition to see if there is anything that should change.  Maybe the out of the box does the right thing now and you should remove your overlay or maybe there is an extended set of actions and you need to pick up one or more of the new actions in your overlay.

The key is that it provides an automatic and inherent layer that is YOUR layer that sits over the out of the box definition and allows you to safely, clearly, and cleanly adjust or augment the defintions if needed for your environment.

This is a feature that allows you to gain further and tighter control over your environment.  It is something that provides you with the ability to better understand what is stock and what is custom and what is changed about the solution.  It is one that preserves all changes you have made across upgrades with a layer of independence and yet links so that changes stay tied into the solution without the change you have made being updated by the upgrade itself.

突然想讲这样的一个故事，如果曾经发生在你身上，就当是个笑话吧。Remedy ITSM套件就好比是一个精装别墅，BMC一般会告诉客户，那里面有世界上最豪华的设施和装修，直接拿着行李入住就行了，事实如此！不过客户往往没有先看进屋看个究竟（其实往往用户没有这个机会，因素复杂，我不说你懂得），就找来施工队，提出我是有这样那样生活习惯和品位的，这都是对此房子的期望和需求，我的上帝客户啊！东西你都买了为啥就不先试住一下呢？尝试新鲜事物的精神您有木有？接着施工队的工人（也就是我们的Remedy程序开发人员）被工头（项目经理）带着就进屋了，说我们就是专业干这个的，能保证按时上线，您就等好吧！客户在院子里站着，瞧着施工队拿着需求分析书和开发工具进进出出，在屋里叮叮当当紧着忙活，几个月之后，项目经理过来说，我们可以做上线培训了（或者试运行/或者UAT测试了），这下客户才真的走进屋，客户开始纳闷了，心里直嘀咕，这真的是别墅么？好像有点糙啊！项目经理说，我们正式按照您的指示，已经把它做成中式风格了，老美的东西怕您用不惯。就这样客户茫然的也就入住了，其实客户可能只也住在了别墅某一层的一间屋里。通往其它房间的门都被封了，并且贴上了壁纸，或者被新打的大衣柜给挡住了，每次回家都是从窗台爬梯子上去。

对任何项目而言，在原厂产品上的定制开发是必须的，但是往往是项目的无底洞，那么如何规避这种风险？怎样让Remedy ITSM产品开箱即用的功能发挥到最大化？无疑对产品已有能力的挖潜和利用也要花时间精力成本去研究，这个时间和开发定制的工作时间是冲突矛盾的。那么：让客户先试住，在逐步装修，可能才是平衡矛盾的关键。客户也应该把项目实施和开发的资金做一个规划，切勿在前期投入太大，项目的前期，应该是学习产品和适应最佳实践的过程。实施方应该想方设法的让客户先进屋看清楚，和客户一起住一段时间，之后在去开工装修，这个过程应该是项目美好的蜜月期。

Related posts:

1. BMC Atrium CMDB 类定义迁移
2. BMC Atrium CMDB CI数据迁移
3. 在Oracle上备份和恢复 Remedy ARS数据库

那么如何持续改进Remedy的性能？首先是硬件环境的准备情况，是否能在项目开始的第一天，就把开发，测试，生产环境统一装好。而不是到上线的前夕才去动生产环境。甚至于有条件的情况下，可不可以直接在生产环境上做开发，这样做的好处：让生产环境上性能优化的时间周期和机会尽可能的多，尽可能的长。当然这种机会毕竟不多，那么是否可以做到生产环境和开发环境的尽早的同步，也就是说：在开发到了一个小的阶段的时候，生产环境就可能就绪，就可以使用，这样把未成型的系统先部署上去，以便有机会做多次的生产系统性能调优。比较生产系统的性能最优化是项目的一大目标，不能等到最后才去仓促应战。曾经听说某行流程平台上线的第二天就挂了一次，这都是血淋淋的教训。总结一下：尽早的建设生产系统，优化生产系统，把开发好的那部分程序尽早迁移到生产上，长期的追逐系统性能，甚至于在生产环境上对此系统做压力测试。这些工作如果能够做的话，我想在上线日我们一定不会紧张。

如何追逐测试系统的性能。可以使用Web profiling工具如Fiddler。使用这种工具对某些特定操作持续的测试，把每次的测试结果保存下来，把时间记录到一个表格中。可以考虑测试如下内容：用户登录、打开事件控制台、创建一个事件单、搜索事件单等等，其他流程也类似。保证每次点击的次数都相同。其实从Fildder的分析数据中也可能得到很有价值的数据，如：那个Web调用的时间消耗最长，那些Web资源的请求出错。找出时间消耗做多的调用，就可以有针对性的优化应用了。总之：使用一种工具，在开发的整个过程中持续测试和优化，记录所有测试结果，这样在上线前对系统的性就能有客观参考依据。

另外要注意Remedy系统是一个标准的3层架构应用，你需要在系统调优的时候，有这样几种人的帮助：压力测试工具高手、JVM调优专家、数据库调优专家和Remed性能调优专家。还需要参考下列的参数配置。

Mid-tier优化参数建议

关于Mid-tier的一点建议，目前普通使用的Java应用服务器都是Tomcat，我一向是开源软件的粉丝，但是，还是建议如果有条件的话，还是上商业的产品，如Weblogic或者Websphere。这样可以获得能多一点的支持。
鉴于大多数系统还都是用的BMC的产品自带的Tomcat，下面是一些建议的参数配置。

1-HTTP keep-alive

Keep-alive count: infinite (minimum 5000)
Connection timeout:90000 ms (minimum 60000 ms)

2-JVM settings

JVM heap：-Xms1024m –Xmx1024m
MaxPermSize：-XX:MaxPermSize=256m
以Windows系统为例，可以使用Tomcat的配置界面工具，配置这两个参数。

3-Threads configuration of the application server hosting the mid tier

maxThreads：500
acceptCount：100

关于1和3的 参数文件：tomcat dir/conf/sever.xml 的实例代码：

<Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="90000"

maxHttpHeaderSize="8192" maxKeepAliveRequests="-1" maxThreads="500"

port="80" protocol="HTTP/1.1" redirectPort="8443"/>

以上参数配置并不是万能的，只是给出一个优化配置的基础，以此为起点调起来可能会更靠谱。

Fine tuning the mid tier

Mid tier parameter or service： Recommended value
Enable Cache Persistence：Always on for a production environment
Prefetch or preload service： Use prefetch only when a specific set of AR System forms are known. Otherwise, use preload (recommended).
Recommended preload procedure： 1.Turn on Enable Cache Persistence. 2.Turn on preload. 3.Allow preload to finish preloading all user facing AR System forms. 4.Turn off preload (allowing statistical service to take over).
arsystem.formhtmljs_expiry_interval 和 arsystem.resource_expiry_interval： Set both parameters to the same value to reflect how often you want the browser to check with the mid tier for updates. In a deployment environment where the AR System applications are not modified, set to 604800 (1 week) or higher. The minimum recommended value is 86400 (1 day). For the new values to take effect, restart the mid tier.
Definition Change Check Interval： In a deployment environment where the AR System applications are not modified, turn this off. Otherwise, map this to the frequency of your AR System application modification. For example, if you push changes out every Sunday, set this frequency to 604800 (1 week).
arsystem.log_level： Severe. This can also be set through the Mid Tier Configuration Tool

ARS优化参数建议

打开ar.cfg参考一下参数，修改后重启ARS服务。

Delay-Recache-Time:300
Max-Entries-Per-Query:2000
Next-ID-Block-Size:100
Server-Side-Table-Chunk-Size:1000
Allow-Unqual-Queries:F
Cache-Mode:0
Debug-mode:0
Submitter-Mode:1
CMDB-Cache-Refresh-Interval:600

数据库优化参数建议

数据库方面一定要依靠有经验的DBA，靠他们帮你搞定下面这两条：
• Configuring your AR System database server for optimal performance
• Diagnosing and resolving issues.
另外如果你是Oracle11g的数据库，可以自己动手搞定下面这一条：
Oracle 10g/11g database settings are recommended: Cursor_sharing = FORCE
在数据库上做如下操作：

alter system set cursor_sharing=FORCE scope=both;

然后在ar.cfg里面加入这个参数。
Oracle-Cursor-Sharing: FORCE
然后重启ARS服务即可。

以上参数配置部分参考了BMC的官方文档《BMC Remedy AR System Server 7.6 Performance Tuning for Business Service Management 199037.pdf》，感兴趣的话可以去官方站点的文档下载里下载，该文章对以上参数有详细的解释。

Related posts:

1. Remedy ITSM 7.6.04 套件快速安装
2. How to deploy mid-tier to tomcat 7
3. Remedy ARS 开源工具知多少

什么情况下使用这个安装方式？

A）POC的情况下
B）客户的生产环境满足下面的需求：
• Microsoft Windows Server 2008 (64-bit) (Standard, Enterprise, or Datacenter) with Microsoft SQL Server 2008 (64-bit) (Standard or Enterprise)
• Oracle Solaris 10 with Oracle 11g (64-bit) (Standard, Enterprise, or RAC)
• Red Hat Enterprise Linux 5 (Update 5) (64-bit) with Oracle 11g (64-bit) (Standard, Enterprise, or RAC)
• Microsoft Windows Server 2008 (64-bit) (Standard, Enterprise, or Datacenter) with Oracle 11g (64-bit) (Standard or Enterprise)
Note: The BMC Remedy ITSM Suite Precongured Stack installer supports only Unicode database servers

这种方式安装了什么组件？

BMC Remedy AR System server version 7.6.04

AREA LDAP Directory Service Authentication

ARDBC LDAP Directory Service Data Access

Web Services Plugin

Simple Network Management Protocol (SNMP) Configuration

Full Text Search (FTS) Configuration

Approval Server

Assignment Engine

Email Engine

Flashboards

Mid-Tier

BMC Remedy AR System clients

BMC Remedy User

BMC Remedy Alert

BMC Remedy Developer Studio

BMC Remedy Data Import

BMC Remedy Migrator

Crystal Reports

ODBC

BMC Atrium Core

BMC Atrium CMDB version 7.6.04

Product Catalog version 7.6.04

Atrium Impact Simulator version 7.6.04

BMC Remedy ITSM Suite

BMC Remedy Asset Management version 7.6.04

BMC Remedy Change Management version 7.6.04

BMC Remedy Incident Management version 7.6.04

BMC Remedy Problem Management version 7.6.04

BMC Remedy Service Desk 7.6.04

BMC Service Level Management version 7.6.04

BMC Remedy Knowledge Management version 7.6.0
如果你真的不需要安装以上所有组件，请不要使用此安装方法。

需要什么硬件？

System requirements for Microsoft Windows and UNIX®:
• Minimum 12 GB free disk space for the installation directory
• Minimum 8 GB free space for local database and remote database
• (For Red Hat Enterprise Linux® only) Minimum of 2.5 GB free space in the /tmp directory or /tmp file system.
• (For Oracle® Solaris only) Minimum of 2.5 GB free space in the /var/tmp directory or the file system.
• 3 GHz dual processor
• Minimum 3 GB RAM during installation; 8 GB RAM during runtime; 8 GB main memory for optimal performance
• (When 6 GB UNIX systems are used) Make sure that a minimum of 6 GB Swap Space is congured within the system.
如果您的硬件真的低于以上需要，请不要使用此安装方法，否则安装完之后系统可能不能正常运行。

需要什么人参与？

需要操作系统管理员和数据库管理员参与
以Linux+Oracle为例，可能需要如下环境变量

export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=remedy
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
export NLS_LANG=en_US.UTF8
export LANG=en_US.utf8
export PATH=$PATH:$ORACLE_HOME/bin

需要什么安装文件？

以Linux+Oracle的安装为例，需要如下文件：

linux.x64_11gR2_database_1of2.zip
linux.x64_11gR2_database_2of2.zip
jdk-6u25-ea-bin-b03-linux-amd64-27_feb_2011.bin
BMCRemedyITSMSuitePreconfiguredStack7.6.04.Linux.tar.gz

需要安装多长时间？

大约1.5个小时左右，是的没有夸张，这个时间是在一个DELL E6400（64位，8GB内存）的笔记本上测得的，如果你有更好的硬件，相信可以更快，这应该是史上最快的Remedy ITSM套件安装速度，如果你也成功通过此方式安装，请留下评论留下下你的安装时间和系统配置情况。

参考以下操作步骤

安装之前需要根据网卡的MAC地址先申请一个Lic，接着基本上都是点Next，即可完成安装

Snap1

◄ Back

Next ►

Picture 1 of 21

Related posts:

1. Remedy ITSM 7.6 installation Tips
2. 让Remedy飞一会
3. 在Oracle上备份和恢复 Remedy ARS数据库

众所周知Remedy ARS上运行的所有程序代码都是在数据库中存储的，几乎所有的程序代码和相关数据都是存储在后端的数据库里的。基于这种特性，我们可以很方便地从数据库层面实现对ARS系统的备份和恢复。所谓基于数据库的备份和恢复就是指数据库的全库导入和导出。在这方面Oracle做的很好，他所提供的imp和exp命令行工具能很好的完成此项任务。

When you may backup BMC Remedy ARS system Database

Remedy ARS系统数据库全备份可能会发生在下面的几个时间点：

1. 在安装过程中，Remedy ITSM套件的安装都是从ARS开始一个模块一个模块增加安装的，可以在安装每个新模块之前，做一个数据库备份，用于安装失败情况下的现场恢复

2. 在系统上线前，当系统需要做升级/代码更新等等大规模操作之前可以考虑做一次数据库的导出备份

3. 在做系统迁移的情况下，我们甚至可以生产库迁移到开发机上进行问题的重现，或者代码的修改，或者测试，完成之后再导回生产系统（如果生产系统再次期间处于维护状态的话）

How-to

下面是我总结的相关操作步骤参考。

备份ARSystem数据库

exp aradmin/ar#admin@itil file=c:\before-patch7.dmp log=c:\exp.log compress=n statistics=none

参数解释：
aradmin/ar#admin  是ARS系统默认的用户名和口令
@itil 是ARSystem数据库所在的数据库实例名
file=c:\before-patch7.dmp log=c:\exp.log  是导出的数据库文件和日志文件路径

删除ARAdmin用户数据

drop user aradmin cascade;

创建和授权ARAdmin用户

CREATE USER ARADMIN
IDENTIFIED BY ar#admin#
DEFAULT TABLESPACE ARSYSTEM
TEMPORARY TABLESPACE ARTMPSPC
PROFILE DEFAULT
ACCOUNT UNLOCK;

GRANT ARADMINROLE TO ARADMIN;
ALTER USER ARADMIN DEFAULT ROLE ALL;
ALTER USER ARADMIN QUOTA UNLIMITED ON ARSYSTEM;

导入备份的数据文件

imp ARAdmin/AR#Admin@ars file=c:\CMDB2010-12-13_13.dmp log=c:\imp.log  fromuser=ARAdmin touser=ARAdmin ignore=y

Credit to：以上操作步骤由神州太岳工程师李成旗协助编写和测试.

Related posts:

1. BMC课程通知: BMC Remedy AR 7.5 管理员培训
2. Remedy ARS 开源工具知多少
3. Remedy ITSM 7.6.04 套件快速安装

Information about customer needs, the technical composition of services, and service performance are fundamental to effective service management.  Service modelling is a structured approach to utilizing this information to improve the way services are delivered.  Consistent application of service modelling provides the automation of processes and timely access to information.

Service Modelling: Principles and Applications

Service Modelling presents a comprehensive, up-to-date overview of the topic, presented in the context both of business processes, and of requirements stemming from the need to manage network resources. Vilho Räisänen delivers a justification for service modelling, and explains state-of-the-art concepts, frameworks and standards in detail.

Service Modelling:

• Provides a complete and illustrated overview of state-of-the-art concepts for service modelling, covering requirements and frameworks.
• Includes industry initiatives, conceptual frameworks, and the work of standardisation bodies.
• Discusses different modelling approaches, and the positioning of modelling of services in service management and in the wider operational context.
• Sets the modelling framework in the context of business drivers and modelling paradigms.
• Illustrates principles with real-world use cases, providing both fixed Internet and mobile network examples.
• Relates concepts to the work of TeleManagement Forum, giving practical examples throughout.

Service Modelling: Principles and Applications is an invaluable guide to service modelling for telecommunications and data communications professionals, including vendors, operators, consultants, training organizations, service and content providers, system architects and engineers for IP-based services.  Educational organizations, advanced undergraduate and graduate students on telecommunications and networking courses will also find this text invaluable.

本书的已经翻译为中文版本，本书中包含了针对电信行业的实例模型和介绍，图书内容介绍如下：

《服务建模:原理与应用》主要内容简介：服务技术的发展，不仅彻底改变了人们原有的生活方式，更从本质上促进了当代社会经济发展方式的转变。《服务建模: 原理与应用》以服务建模为主题，共分4部分：第1部分介绍了服务建模所需解决的问题，第2部分分析了实际应用中的服务建模框架，第3部分列举了使用服务建模的案例，第4部分则对《服务建模:原理与应用》的中心内容进行了总结，并提出了未来服务建模值得研究的一些领域。
《服务建模:原理与应用》可作为高校信息技术、管理和经济类相关学科电子服务方向的教学用书。也可以作为现代服务企业进行服务建模方面研究的工具书或参考书。

Related posts:

1. ITIL V3 Study Notes (2)
2. Stop to build CMDB for your IT – CMS是怎样炼成的？
3. 资产CI的一生

二、配置管理的目的：
1. 确定、控制、记录、报告、审计、验证服务资产和配置项包括版本、基线、组成成分、属性和相关关系。
2.通过服务生命周期管理保护资产完整、配置项等账户。确保只有已授权的组件被使用和已授权变更被执行。
3.通过服务生命周期保护服务资产、配置项的完整性。为了建立和维持一个准确和完整的配置管理系统，确保资产和控制服务、IT基础设施的配置需求的完整性。

三、资产、配置管理的活动

1、规划
2、识别
配置项识别过程：
A) 定义和制定标准文件来选择配置项和他们的组件构成
B) 依据标准选择配置项及其组件并记录他们
C) 给配置项分配唯一的标识符
D) 指定每个配置项相关属性
E) 确认每个配置项是受配置项管理来管理
F) 确定每个配置项的责任人
3、控制
必须有效控制信息以维持配置管理数据库(CMDB)的及时更新。一旦某项活动改变了配置项已记录的特征或配置项之间的关系，则必须在配置管理数据库 (CMDB)中记录该项变动。需注意的是：只有变更管理才有权批准对配置项的特征进行变动，事件管理只能改变某个现有的配置项的状态来反映现实状况。
配置管理负责控制组织接收到的所有IT 组件并需确保这些组件被记录在系统中。硬件可在其已订购或已交付时进行记录，而软件则通常在其被纳入DML时进行记录。
4、记录
组件的生命周期可被划分成多个阶段，每个阶段都可以分配一个状态代码，但具体分成几个阶段则取决于公希望记录IT 基础设施的哪些特征。保持对每次状态变化日期的记录可以提供关于一个产品的生命周期的有用信息，如订购时间、安装时间以及所需的维护和支持。组件的状态决 定了可以对其进行操作的余地。
5、审核和报告
执行审计是为了核实配置管理数据库(CMDB)中记录的信息是否仍然反映了当前的现实状况。这些信息可用来检查和更新配置管理数据库(CMDB)。
在下列情形下需要执行审计：
A) 在建立了新的配置管理数据库(CMDB)之后；
B) 建立配置管理数据库(CMDB)一段时间之后；
C) 重大变更之前或之后；
D) 灾难恢复之后；
E) 其他任何方便的时候。
审计也可以随机地或在配置经理认为配置管理数据库(CMDB)中的信息不正确时进行。如果配置管理系统与审计工具之间存在关联，则可以每天生成针对某个相 关领域的审计报告。在发现差异时，不应该允许审计工具自动更新配置管理数据库(CMDB)。所有的差异都表明变更管理流程可能被忽视了，所以应该对这些差 异进行调查并通过变更管理对这些差异进行追溯性处理。
三、配置管理管理报告
配置管理流程的管理报告可能包括下列信息：
a) 有关流程质量的信息；
b) 在审计中发现的记录与实际情形不符的次数；
c) 发现未经批准的配置的次数；
d) 出现已记录的配置不能被找到情形的次数；
e) 审计中发现的有关配置项属性详细程度方面的差异；
f) 处理信息记录请求所需的时间；
g) 超过给定事件或变更次数的配置项的列表；
h) 有关 IT 基础设施的结构和组成的统计信息；
i)  有关 IT 基础设施发展情况及其他方面的信息；
j) 有关改进措施的总结、报告和建议，例如，针对由于业务、技术、市场价格和其他相关变化所导致的配置管理追踪记录的配置项的范围和详细程度的变更所提出建议；
k) 有关实施流程所耗费的人力成本的清单。

四、配置管理的绩效指标指标
a) 闲置许可数量;
b) CMDB错误导致变更失败的数量;
c) 未授权配置数量;
d) 配置项文档错误导致变更失败所引起的事故数量;
e) 因为CMDB错误导致违反SLA的数量;
f) 无相应配置项刷新的变更请求数量;
g) 不精确配置项百分比;
h) 客户满意度 ;

五、与其他流程的关系

转帖学习一下。

From http://blog.amteam.org/standard/A1159174.html

Related posts:

1. MartinMarks for 29th August
2. 规划CMDB数据填充-002
3. ITIL v3 术语表

版本的确认：所有操作系统，JVM，JDK，数据库，数据库客户端，和以上软件的位数都需要查明，都需要在Remedy的兼容文档中一一确认。

AIX操作系统的字符集：需要同时安装中英文的UTF8字符集。安装方法smitty，需要有操作系统的安装盘，安装完成之后，locale -a ，需要能看到 ZH_CN, ZH_CN.UTF-8,EN_US, EN_US.UTF-8 这四种字符集缺一不可。否则无法以中文方式安装成功，也无法让操作系统已中文utf8来启动AR服务。

XManager需要安装在于AR同一网段的Windows服务器上，例如Mid-tier可能安装在Windows上，并与AR在同以网段，那么安装程序最好在该服务器的Xmanager的客户端中安装，从哪里连接AIX服务器并运行安装程序。如果不在同一个网段，安装程序很有可能安装了一半或者无名的消失，安装进程会立刻中断，需要把系统推到重来。

AIX系统上font server的安装：使用netstat -na|grep 7100， 如果没有结果则需要从AIX的光盘中在AIX的服务器上安装font server和相关的包，并且启动它。如果不装的话，remedy安装程序可能界面显示不正常，或者不显示。

Oracle上众多僵尸进程：如果在安装CMDB或者ITSM套件的时候，安装界面挂死或者消失，这会是Oracle服务器上产生上百个僵尸进程，这些进程会吃光Oracle服务器的所有物理内存。我们的oracle服务器的16GB内存被吃光之后，ITSM安装界面几乎停止，20~30分钟才能安装完一个定义文件。解决方法是：随时监控Oracle服务器的内存使用情况，当出现内存被僵尸进程吃光的情况，可以考虑使用IT行里无人不知的无敌重启方案，重启Oracle服务器的操作系统，从启动Oracle数据库实例，重启ARS服务，然后再次安装Remedy ITSM。

Remedy安装之备份：如果是在AIX+Oracle的数据库上安装。Remedy还是非常绿色的软件，需要在安装完AR，CMDB，ITSM套件后各做一个Remedy安装文件目录的备份，在AIX上可以把这个文件夹tar起来备用。Oracle数据库还是非常容易备份的，使用imp和exp命了就可以搞定，具体语句咨询DBA。切忌在安装CMDB和ITSM之前一定要对Remedy系统的安装文件和数据库做备份，一旦安装失败，可以恢复文件，恢复数据库，排错后重新再来。

Related posts:

1. Remedy ITSM 7.6.04 套件快速安装
2. BMC提供ITSM洋快餐
3. Remedy ITSM 7.6 installation Tips

For as long as there have been computers, operating systems and business critical applications, there has been monitoring of these items to make sure they were working (available) and performing well for their constituents. In the early days of the computer industry (through about 1982) computer systems were vertical monoliths where a customer would buy “an accounting system” and that purchase would include hardware, systems software, and applications software. All of this usually came from one vendor so there was one throat to choke when it did not work.

Starting with the delivery of the PC, then Ethernet LAN’s and Novel Netware, and finally Windows Servers and the Internet, the industry reorganized along horizontal dimensions. A computer system was now a multi-layer cake and you could buy each cake from one of many vendors whose products were largely interchangeable with each other, and compatible with adjacent layers. So you could buy an Intel based server from one of N vendors, put either Linux or Windows on it, but a Java applications server from one of N vendors on that and then buy applications from thousands of different vendors.

This horizontal layering of the industry was heavily promoted by Microsoft and Intel (who “owned” two key layers of the cake), and also ushered in the tremendous innovation and price competition that continues to drive our industry today. Moore’s Law says that microprocessor performance doubles roughly every 18 months or so, and with those increases in price/performance come the more for less mentality that we have all become accustomed to.

With this freedom of choice at every layer of the cake however came problems. The first problem was complexity. There were now too many cooks in the kitchen which meant that there were both too many and not one single throat for the CIO to choke when something went wrong. The management software industry reacted to this by inventing a marketecture, Business Service Management (BSM). The idea behind BSM was to identify the key business services that applications or combinations of applications delivered to users (the ability to enter and order and ship the resulting product is a business service as is the ability of a consumer to transfer funds from one banking account to another), and to then map all of the software and hardware infrastructure that this business service depended upon and to manage that collection of linked resources as an entity.

While Business Service Management sounded like a great idea, it in fact ended up as a miserable failure. The reasons were:

• There were many applications for which it was just too hard to measure their performance (in response time terms). Web applications turned out to be pretty easy, but fat client Win32 applications written to proprietary client/server protocols turned out to be very hard. It turned out that for most enterprises, more than half of the business critical applications were in the hard pile (fat client/Win32) and less than half were the easy web applications.
• Many BSM frameworks relied upon scripts and synthetic transactions to measure response time and end user experience. However this approach failed for many enterprises due to the large number of applications that comprised a business service and how rapidly these applications were changing. For example if synthetic transactions were used to measure the performance of a set of transactions, and a company had 500 business critical applications (not a very high number – some companies have thousands), and each application was updated once a year, then that would translate into 10 updates a week for the monitoring scripts.
• The same is true for most passive monitoring approaches that rely upon templates to identify transactions in applications protocols. There are many products that can measure the response time of transactions from the perspective of the web server by attaching physical or virtual appliance to a span port on the switch that services the web server. However all such products require configuration to understand what set of granular http request/responses combine to create a transaction of interest. Maintaining these configurations across hundreds of applications and thousands of transactions proved to be a major impediment to instrumenting their service level in any kind of a broad and systematic manner.
• It turned out to be a nightmare to identify the hardware and software that supported each business service. This gave rise to the need for Configuration Management Databases (CMDB’s) that were supposed to get populated with the hardware and software assets and their relationships to each other. The effort to put in place a CMDB and to maintain it turned out to doom the CMDB projects and the associated BSM projects at many companies.
• The BSM vendors were unable to evolve their products at the same rate as the innovation of the vendors who contributed products to the layers in the cake. New devices (laptops that were not always connected), new protocols (ICA, VOIP), new operating systems (Linux), new languages (Java, C#), and new user interfaces (first the browser and then rich Internet applications) all occurred at a pace that no one vendor could keep up with.
• When the BSM vendors got overwhelmed by innovation, vendors of point monitoring solutions stepped in to monitor the newest layer or item in a layer.  This lead to a proliferation of monitoring tools which were not integrated with each other.
• When a problem occurred even if one had a BSM product and a CMDB it still horribly difficult to know exactly what path the failed transaction took through the entire hardware and software infrastructure. The BSM tools were rarely aware of every element of the stack and the tactical monitors that had been bought to fill in the cracks were not integrated with the BSM tools nor each other.

In summary we entered the age of virtualization and the cloud with both BSM and their supporting CMDB’s having failed at monitoring and managing a static infrastructure where applications and services largely stayed on dedicated hardware. In other words, before virtualization and the dynamic data center it was impossible for anyone in IT to see a problem and get told in a deterministic manner exactly where the problem was and how to fix it.

The Impact of Virtualization and the Cloud

Since holistic end-to-end monitoring of business services was essentially broken (or not attainable) before virtualization, it is reasonable to assume that virtualization and the cloud will only make this problem worse. This will occur for the following reasons:

1. Virtualization increases workload density and the dynamic operation of workloads. This will require both continuous mapping of application to infrastructure dependencies and more more frequent (near real time) collection of performance data. Just the requirements for real time mapping and real time data completely overwhelm existing monitoring systems. Hyperic has a good blog on this point here.
2. Inferring application performance from resource utilization statistics becomes impossible. This was possible on physical hardware, but on hardware that is shared via virtualization it no longers works. Hence the need for Infrastructure Performance Management solutions that measure Infrastructure Response Time. We expect Infrastructure Performance Management solutions from vendors like Akorri, CA Technologies (CA Virtual Assurance), Virtual Instruments, and Xangati to form the foundation layer of whatever will replace BSM.
3. Application will now get moved from cluster to cluster and ultimately from data center to data center (private cloud – hybrid cloud – public cloud). APM solutions will need to track the applications no matter where they go, and seamlessly work across different IP networks. Leading virtualization aware APM solutions like those from AppDynamics, BlueStripe, and New Relic meet these needs today and will likely form the APM layer of whatever replaces BSM.

All of the above together combine to create one new result for Systems Management. That new result is that in the general case it will be impossible to deterministically do root cause in a dynamic environment. This was explored in detail in this post.

The Significance of the Integrien Acquisition

The Integrien acquisition by VMware is significant because it means that VMware has recognized that only a dynamic, statistical, self-configuring,  and self-learning approach can keep up with the rate of change in these new dynamic IT environments. The self-learning approach simply means that you feed the system the metrics that get collected about the system and it figures out which ones are important, how the metrics are related to each other, and lets you know when anomalies have occurred.

This acquisition is all the more significant because this is not garden variety technology. There have only ever been three companies this this space. ProactiveNet was acquired by BMC a few years ago. Netuitive has been around since the late 1990′s and it took the company until the mid 2000′s before the product had matured into something that really just worked when you plugged it in. Integrien is a fairly recent entry in this field and is now part of VMware – which leaves Netuitive as the only remaining independent player.

The New Dynamic BSM – Service Assurance

Since the old BSM is dead due to a brittle and difficult to update technology approach it is reasonable to ask what will replace it. The answer is most likely a set of Infrastructure Performance Management tools (Akorri, CA Virtual Assurance, Virtual Instruments, Xangati) integrated with a set of next generation APM tools (AppDynamics, BlueStripe, New Relic) vis these self learning technologies. When this occurs, we will have a system that adapts on its own to changing conditions in the environment leaving IT staff available to interpret results (and not raw monitoring data). We will also have taken an important step towards dynamic service assurance which was discussed in detail in this post.

Understanding and Evaluating these Technologies

For most IT professionals either they or someone on their staff can digg in and understand how the technologies that they use work. However unless you have an advanced degree in statistics and/or mathematics you are not going to be able to dig an and decide for yourself based upon how these products work which one you should choose. Rather what you should do is apply the following criteria in making your selection:

1. Decide exactly what you want the product to do for you. These products are extremely flexible. You can feed them every alarm that is generated by all of your monitoring solutions and let them sort out the good ones from the bad ones. Or you can feed them revenue per minute for one key business application and let them figure what causes degradations in revenue per minute.
2. Make sure that the product has connectors to what you already use to collect metrics from your systems. These products are not in the data collection business (with some exceptions). They rely upon other products to collect data from them. They must therefore be interfaced with your existing monitoring solutions.
3. How hands off and plug and play will the product be in practice? This is the key criteria to the long term value of such a solution to your enterprise. Previous attempts at statistical approaches (neural nets) failed because the product had to be “retrained” every time conditions changed. Make sure that the product you select can automatically select and weight the inputs that it bases decisions off of and these these decisions are automatically updated over time. Self-learning needs to be a continuous thing, not just a one time or periodic thing.
4. Make sure that the product can handle time based (time series) as well as event based data. Performance metrics tend to be time based, but many performance problems are caused by configuration changes which are events. Make sure that the product can cross-correlate configuration change events with performance degradations.
5. Carefully assess the scale of the solution. This means how many inputs can the solution take per unit of time. Right now most of these solutions operate at 15 minute or 5 minute intervals. Monitoring a dynamic system may require intervals of 10 or even 5 seconds (or perhaps even real time continuous streams of monitoring data).

Summary

Self-learning performance management solutions like Integrien and Netuitive are going to be absolutely an essential part of the migration to dynamic data centers and IT as a Service. Once these dynamic data centers scale out to the thousands of applications in a typical enterprise, and scale up to address the most performance critical applications, the rate of change in the environment will be too high for legacy tools and manual administration to be able to keep. up. These automated self-learning approaches will be the only way in which IT Operations will be able to stay on top of these new environments while staying within staffing and budget constraints.

Related posts:

1. 图书推荐《服务建模：原理与应用》
2. 让Remedy飞一会
3. 老美真的很扯，一个职位的帖子被顶了22次