vsharing 破子：2007的遐思

这是好几年前的一个想法了，记不清是因为海南的房地产泡沫新闻所引发的思考，还是在深圳时看到公司对面那栋烂尾楼想到的。值得记下来是因为这好象是我第一次真正去思考一个商业机会，而且是独立的想到的。
现在由于各种原因造成的工程烂尾楼，连深圳都有，这些烂尾楼坚立在市中心，严重影响着城市整体的形象，同时造成浪费，造成烂尾楼的原因可以许多方面的，其中以资金与权益相当的纠葛居多，当时在想如果有人在全国的各大城市去收购这些烂尾档，然后加以继续构建，其中应该大有可为的，一方面的政府肯定是举双手赞成的，另一方面包括以前权益者肯定也巴不得转手他人，减少损失，烂尾楼多半也是没有保安措施可言，如果收购者先带工程建筑的技术人员私底下对工程结构与基础进行检测，如果已有的建筑质量上没有问题，再去找所有者或银行或政府进行谈判压价，这样可能包括地皮大内的一系列财产可以收编入囊，同时按原来的业者的创意与设计蓝图进行继建，这样可以免费的得到一个很好的事业，同时又经相对较低的价格收购一个半成品，这样的事情，运作难度虽大，但收益是约对可观的，这可能需要有一个大型公司去用专业的团队收编，全国的一线城市的烂尾楼的总价值相信是一个非常庞大的财产了，这样的大手笔需要一个多大的平台才能进作业，这是我记忆中第一个真正值得写下来的事业思考，果然两年后以经济观察报上已看到摩根财团在开始搞这方面的事情了，但战略上，他们好象没有专业的看待这一市场，只是看到一个楼盘一个项目，而不是以一个新的市场的方式去对待。以前每天下班时，看到中信广场的那坐烂尾楼，心里就感叹，也失落，没有人脉与资源，你能做的就是想加上想，做不了任何事情，干耗着。
基于同样的理念或想法，前段时间江浙的一个叫吴英的女子，集资巨大，同样资金链断裂，事业轰然倒塌，我在想她的那些物业与门面，要是去收编的话，也应该可以捡到一些便宜的，只要出手够快，现在全国的经济大案频发，这里面一定有很大的商机的，因为每一次大的动乱或腐败案，总会伴随着一定的商业机会，无论是烂尾楼还是吴英的物业，是不是只要是追逐那些倒下的公司，盯着他们物业资产，在发案初就同相关的部门进行接触，只要在人们没有意味到其中奥妙时就出手，应该是可以以较大的便宜获得一个不错的资产的。这需要一个长袖善舞而大手笔之人，我是无望了，只是可惜浪费了这一个好的想法。

ITIL两要素： incident, problem

ITIL的本质：以流程为导向的最佳实践集合，用于IT服务管理，并非理论


通常做法：一期先上五个基础模块：事件管理、问题管理、变更管理、配置管理和发布管理——这五个日常管理的流程。

ITIL的两个最核心的基石一个是配置管理，另一个是SLA管理

变更是指在维护过程中对系统或服务所作出的各种改变，包括增补、移除和其他修改。说的再具体一点，变更的对象是两个，一个是IT基础架构，一个是IT服务（包括与流程和文档），

变更管理审批的是要不要做
发布管理审批的是怎么做


变更是指在维护过程中对系统或服务所作出的各种改变，包括增补、移除和其他修改。说的再具体一点，变更的对象是两个，一个是IT基础架构，一个是IT服务（包括与流程和文档），

服务台不是流程，只是职能

事故就是任何标准操作之外的事件，可能会导致服务质量问题。事故管理的要点就是尽快恢复服务，减少事故损失。

问题管理就是解决问题根源，减少和防止事故，强调主动预防。

Incident Management can be defined as :

An 'Incident' is any event which is not part of the standard operation of the service and which causes, or may cause, an interruption or a reduction of the quality of the service.

The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price.


. A 'problem' is an unknown underlying cause of one or more incidents, and a 'known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified

人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会，一方面在“重在参与”精神的感召下，ITIL 在企业用户中迅速普及；另一方面，“更高、更快、更强”的目标激发了参与者的潜能，用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中，CMDB因其对企业ITIL实施效果的决定性作用，被比喻为ITIL的“发动机”。

Service support(侧重于用户as a customer of ICT service) and service delivery(侧重于business as customer of ICT service,包括Service level mgmt,capacity mgmt, Continuity, availa, financial mgmt )

service desk
“配置管理”是对CI进行管理，但更是对CI关系进行管理，所以可以这样说，CMDB中记录的20%是CI项，80%是CI项之间的关系。 (business process can be CI as well)
服务台 事件管理 问题管理 变更管理 日常作业管理 知识库管理

区分服务请求和事件：服务请求 service requests 也可以作为 “标准服务 standard services”。总体来说服务请求是在前期就已经协商好的。需要提供给用户的服务。而事件是临时出现的影响了或是可能影响了业务的事件。

ITIL的核心是服务管理模块，它包括服务支持和服务提供两个流程组：
事件管理、问题管理、配置管理、变更管理、发布管理构成了服务支持流程组。
服务级别管理、IT服务财务管理、IT服务持续性管理、可用性管理、能力管理构成了服务提供流程组。

配置项（CI）是ITIL中所有活动的最基本的支撑，

事件从服务台到事件管理再到问题管理是一个解决力度逐步加强的过程，但也是一个治标未治本的过程。要真正做到防范于未然或者减少事件影响，必须实施一定的变更

第3个问题，什么是配置信息，一个常见的误区是，我们以为CMDB的所有信息就是配置信息，这个观念是大家先天存在的，不能说它错，但是它不精确不全面，因为这里面暗含着一个逻辑是，不在CMDB中的信息就不是配置信息，这会直接导致一个极端，大家只关心CMDB的信息与是否变更与维护，但其实真正的配置信息以现在的CMDB技术发展而言，只有不到20%的配置信息记录着CMDB之中。到底什么是配置信息呢？，CMDB之中记录了一些CI，以及它们之间的属性，加上CI之间的关系信息，但对于现实的IT架构而言，这些信息的技术价值太低了，它在你重建与故障时只能给你有限的指导，我们有大量的配置信息是记录在各种手册之中的，大多数CMDB的做法是把这些手册当成CI，加一个版本属性，我们有更大量的配置信息是记录在架构本身的，比如一个软件的接口关系与访问关系，或者操作系统本身的设置信息，或者数据库的内部结构，所有的CMDB的做法同样是把这些当成一个CI，再加上几个属性了事。有一个设备是什么型号，这是配置信息，有一个软件是什么版本，这是配置信息，但这些都是粗放性，而且是偏管理性质的，真正的配置信息是更深入的，比如网络设备的ACL、软件内部的参数设置，这种层面的配置信息才是核心的，它分布于各种文档与对象本身中，从当前的CMDB而言，弄几个CI，加几个属性与关系，是根本无法将配置信息真正的管理起来的，这也是为什么CMDB一直难以发挥架构的控制与记录作用的关键因素，这是先天性的，这也是为什么所有的工程师最后觉得CMDB对他们的工作没有实际作用的原因，这现在的产品与实施方法都解决不了这一问题，以我目前的认知，只有云计算，才有可能让这一问题从根本上解决，但解决方式是另一个极端。