上午开会，谈到一个问题。前段时间下发的商品信息存在一码多品的现象。虽然最后的原因定在客户那边，但发送条码的动作没法确定。也就是说只能怀疑是客户发错了信息，但没有证据表明是客户发错了。我原本想通过和客户协商，搞一个变更说明或者变更记录，当他们发生大量的变更时能够及时通知或者提供一个事后追溯的依据。但由于客户信息的变更比较频繁，无法做到每一次都会认真做好这些变更记录，再者客户也不可能接受这种方式。既然我们无法从外部进行约束，也无法要求其内部严控，那么我们还有什么办法吗？会上，我在会议记录本上写下一句话：发布需要日志记录。客户的软件是我们提供的，如果每一次的信息发布都有日志记录，记录下发布人和发布内容，那么我们即使无法控制其变更过程，至少我们可以迅速地定位问题和定位责任人。当然，日志是有时间限定条件，可以3个月清理一次。从目前来看，如果发生问题一般也是在短期内会爆发出来，不太可能隔很久才发现。...

在IPRC的课程上，在讲到DSL（最终软件配置库）时对此曾经不以为然。这个需要费时费力去做吗？既然有CMDB，为什么还要搞个DSL和DHL。最近维护发生一件事情让我对DSL的作用有了一个感性认识。门店报修服务器故障，工程师上门维护，第一次上门发现软件未带无法解决。第二天再派人去解决。因为维护分两个工程师隔天解决，客户对此非常不满。在800电话里大发雷霆，事后我们分析工程师未带软件是导致问题无法及时解决，客户不满的主要原因。为什么工程师没有随身携带软件？因为没有明文规定工程师必须随身携带什么工具，工具由谁提供，怎么提供。以前工程师带的软件工具，都是在同事之间随意找一个copy来刻盘解决。没有统一的软件工具管理。可以说是一个管理漏洞。如果我们建立了DSL，那么每一份软件都记录在案，存放有序。并对工程师建立软件工具申请流程和使用规定。使其在需要软件工具时能够明白自己需要带什么工具，向谁申请。而维...

...大部分缺乏标准化流程制定经验的企业来说，这并非易事。幸好，我们有ITIL（IT基础设施库）可以参考，它包含着如何管理IT基础设施的流程描述。它以流程为导向，以客户为中心，通过整合IT服务与企业业务，提高企业的IT服务提供和服务支持的能力和水平。ITIL可引导组织高效和有效地使用技术，让既有的信息化资源发挥更大的效能。基于ITIL思想的补丁管理策略包括4个重要阶段：配置管理、风险评估、变更管理和补丁发布管理。重要阶段１：配置管理对企业现有IT环境的详细了解是补丁升级成功的第一步。如果企业在实行补丁升级操作前不了解企业IT环境的实际情况，企业将无法了解漏洞的存在和危害、补丁程序的影响和风险，也就无法对接下去的补丁升级活动进行计划。企业可以通过配置管理来收集IT环境的相关数据。企业要根据IT架构的配置情况实施配置管理，可以使用数据库或文档记录的方式。一般情况下，企业只须关注系统的标识、技术特征和...

本文发表于《中国计算机用户》 2007年5月14日 第17期 管理栏发布管理和变更管理之间你中有我，我中有你的亲密关系已成为ITIL的共识，但正是这种亲密无间的关系也一直在困扰着很多人。互联网上有人提问“从流程上来看，这两个管理类似，都有提出计划，比如测试计划，实施计划等，但是我不知道这两个的分工具体怎么确定，比如说什么样的任务该由变更管理来处理，什么样的任务该由发布管理来处理？”有人回帖：“变更关心的是从变更发起到变更批准或拒绝之间的流程,变更管理中的内容包含发布管理,比如测试计划,回退计划等，但这些计划内容都在发布管理中执行和制作。”“变更管理中的内容包含发布管理”回帖中的这句话在ITIL中已有描述 “发布管理流程的实施应当在变更管理的控制下进行，发布管理几乎贯穿整个变更管理生命周期”。由此...