银行运维
运维从设计开始
从接触ITIL到ISO20000实施，再到ITSM工具的规划与实施，中间经历了一段学习过程，也经历一段较长的思考过程，以前更多是着眼于某个流程的内部设计，然后是各个流程之间的接口设计，渐渐的开始更多想的是一些框架性的问题了，这里头倒也没有一个非常完整与成熟的想法，只是越发为ITIL或ISO20000是不是能真正解决当前IT应用的问题而感到困惑，于是便有了本文的产生，以记录与启迪思考。
ITIL（无论是哪一个版本）、ISO20000、COBIT、ISO27001，这些都是IT服务管理的范畴了，但这些方法论或标准都是面向服务过程的，即根本的一个事实是，当应用这些方法论时，你的服务对象（你可以理解为IT设施，或网络、数据中心、应用系统等等）已经布署完成，这些方法论永远面向是服务对象的后续生命周期，而此时服务对象已经很大程度上固化下来了，这种情况类似于：现在有一个非常成熟的方法论去规范管理汽车的售后服务过程，但汽车的前端过程，比如象设计、制造都没有覆盖到，在这种情况下，汽车的使用与服务能得到最好的保障吗？客户享受到更好的驾驶体验，决定性的是后续的服务过程还是前端的设计制造过程呢？。许多情况下，当服务对象的设计与布署的前端过程中的问题会造成后续服务过程的永远的痛苦与挣扎，许多在服务过程中不断碰到的问题，事实上如果在设计与布署过程中考虑到了的话，会为后续节省更多的资源与成本，服务管理做得再好，在当前的框架内是无法渗透到前端的设计与布署环节的，这就面临着，当服务对象的前端过程做得不好时，服务管理能做的只是“维系”一个现状，甚至无法把服务过程中的知识经验反馈到前端过程，形成一个闭环，这种知识反而是对一个服务主体是最有价值的，比那些事件、问题、变更知识库要有用得多，当前的框架内是没有考虑这些的。尤其当应用系统这种服务对象时，更是如此，虽然有一些小问题可以后续补丁，但有一些根源的问题往往只能忍受着、服务着。
CMMI等方法论，是面向软件类的服务对象的前端过程的，但是CMMI与ITIL或ISO20000等上面无法是理论结构还是着眼点亦或者是流程假设都是没有考虑过相融的，变成CMMI只考虑开发过程中的问题，ITIL与ISO20000只考虑服务过程中的问题，服务对象的两个核心的生命阶段的管理可以说是断层与脱节的，也没有一理论框架来解释指导这一个完整的生命过程。而且CMMI只面向软件类服务对象，事实上当前的服务对象范围要更广，ITIL3.0开始有比较清楚的服务生命周期的概念，但我认为这是不够的，生命周期的概念不应该是面向服务的，而应该是面向对象的。当前世界需要的是一个面向服务对象的规划、设计、布署、服务的完整生命过程的框架与方法论，这个框架需要完成融入ISO27001这一标准，这个框架应该是完全“面向对象”的，它会提出明确的要求来规范在任何过程的服务对象，不管是软件还是网络亦还是IDC，它会要求在每一个过程如何考虑信息安全，这样才不会导致标准的分裂与无法统一作业的现象，实施过CMMI与ISO27001与ISO20000的人会发现，这几个标准作用于同一个组织时，你会无以适从，非常难以调和。这个大的“IT管理”标准，是可以分层级与结构化的，只有一个成熟而全面的服务商才可能完全实施并得到这个完整的认证，而象一些仅仅面向服务过程的只需要实施并得到关于服务管理部份的认证，重点在于一个完整的标准会真正统一规范IT业，让全世界的IT组织与人员有一个全面的平台作业。当然这个标准的整合力度与难度也可想而知，但我个人相信随着服务管理方法论的成熟与发展，在一个不久的周期后，人们会发现这一服务管理标准的局限性，最后一定会碰到“天花板”，因为很简单一个逻辑在于：我们需要是IT应用的效益最大化，服务管理过程并不能从根本上改变现状，甚至不能从根本上决定服务的质量（因为服务的质量很大程度是由前端过程决定了），加上其它的纬度的标准要求，造成框架性的割裂，统一标准的面向整个服务对象生命周期的方法论出现是必然的选择。
上面谈的问题，基本不是一个IT组织或个人可以完成的事情，除非你有IBM与HP这样的资源与理论力量。那么很现实的问题是，在没有一个这样大而全的框架支持的情况下，我们如何做，才能更好的发挥IT应用的效益呢。我们可以从一个IT提供与服务商的角度来看看，看看我们如何可以建立一个小体制来对应框架的缺失，为了避免服务对象的宽泛而无法聚焦说明，我们就以应用软件类的服务对象为例说明
1)在规划设计时考虑运维问题
当在规划设计一个应用系统时，在目前绝大多数的软件型项目中（非套装产品），在软件设计时甚少考虑软件日后的可维护性，也很少会在软件功能设计时为维护提供便利性。事实上合理的情况是，首先要着眼于客户的业务分析，同时要结合日后软件布署、维护、升级、调整。有许多系统设计时连上线布署都未考虑，这样面临的局面是，可能是一个很好的产品，但实施上线非常困难，又或者刚开始上线使用时，功能符合业务的需求，但一旦发生变化，升级变更非常困难，后续的维护工作也异常被动。所以当前仅仅是根据客户需求一方面的信息来规划与设计软件是不够的，需要同时基于后续的服务过程需要来一同规划设计，目前大多数据软件开发型项目，光是前者就很少做得足够好的，国内真正意义上的优秀软件规划与分析人员太少了，同时优秀的合格软件实施顾问亦少，一款功能不是很强大的软件，如果实施顾问足够优秀，事实上可以很大程度上弥补软件不足，因为可以将客户的业务流程与制度做相应的重组与融合，反之亦然。我想这一块领域还有相当长远的路要走。
2)在规划设计时考虑服务目录
在规划设计一个应用系统时，到底在软件实施上线后，可以做哪一些服务，哪一些功能、与接口是需要维护中重点关注的，要用怎样的频度去做日常的检查与维护，多久做一次数据优化，这些目前也是很少被考虑的，某种程度上可以说，这是软件开发商的短视，从利润榨取或商业利益而言，软件的规划设计开发过程的纯利润是不高的，同时是非常短期的，但日后漫长的服务过程，可以为软件开发商提供持久不断的收益。从软件开发商的角度而言，从纯商业的角度而言，除了满足客户的业务需求外，如何在规划设计软件时，设计好后续的服务目录（服务内容），这是非常重要的，如果一款软件完成上线后，软件开发商无法在项目的后续过程中挖掘商业利益，这某种程度是一种商业失败，开发过程相当于种下一个种子，软件开发商在规划设计过程中对服务目录的设计，就取定这颗种子日后到底结出怎样的果实出来，事实上这里面有大量的文章可做的，这同时也十分有利于软件稳定。以当前大多数软件开发商的做法，都是把软件折腾出来后，把款项回收完成，然后根本不太重视后续的服务过程，基本上是客户报障时或有新需求时，才响应做一些服务，而这些服务基本上是没多少收益的，一定要在软件规划与设计时埋好服务的伏笔，在合理的情况下，当软件完成规划设计后，基本日后的服务目录，与服务体制，以及日常的维护手册都是可以出来的，因为在规划之初，设计者是清楚哪一些地方是需要进行经常检查与维护的，服务受体到底有多少人，需要配备多少以及怎样的服务人员，基本上此时就可以大概知道日后的服务收益是多少，做多少服务合同的报价。在现实中经常看到这样的情形，在软件开发合同一般开发商会承诺有一年的免费维护，当软件实施上线后，开发商也可能是不重视服务也可能是为了控制成本，就留下极少的资源对应这个免费的维护周期，这样当免费周期结束后，由于之前的维护过程只投入了很少的资源，客户只给了很低的服务价格，这样就掉入一个循环过程中，事实上对客户与服务商双方都是不利的。
3)在规划设计时考虑信息安全
在软件的规划设计时，信息安全同样是一个需要被考虑的因素，一些高保密性的系统除了需要技术手段外（比如CA认证），还需要考虑管理手段，比如象核心账户的管制，敏感数据的备份、读取、操作。都可以建立起制度出来，目前多数系统都是在系统上线时甚至是维护时，才开始设计配套制度，这是有些晚的，因为信息最充足的情况是在客户处进行业务调研的时候，既软件的规划与设计者们才是信息集中者，他们最清楚系统要做成什么样子，需要一套怎样的管理机制配合，这也某种程度上决定了软件规划设计者同时是一个需要理解“管理”本身的人，而不是现在技术专家们。
4)在规划设计时考虑配置管理
在项目初期，软件规划设计时，基本已确定了核心的配置信息，要布署多少怎样的设备，要用到哪一些组件，要同哪一些系统做接口，相互传递什么信息，要用到哪一段网络，整个系统的拓扑图是怎样的，哪一些设备是热点，需要备机。这些都会相应的完成，即此时CMDB要进入多少个CI是明确的，而且这些CI之间的相互关系是如何的也是明确的。同时从CMDB的角度而言，在规划设计时要尽量避免关系过多，以避免一个故障造成大范围服务中断，尽量形成可插拔式的，故障只形成单点。当这一个过程中完成后，事实我们这个时间非常清楚日后的服务受体（到底是哪一些组织的哪一些用户使用系统），我们也非常清楚日后的服务对象（上述的CI），我们也非常清楚自已的服务主体（我们配备怎样的服务团队），我们还清楚了服务目录（日后需要从事哪一些日常的主动维护活动），这时服务管理就非常容易展开。
5)运维如何促进规划设计
在漫长的运维过程中，我们会发现许多问题，分析下来我们也会知道许多问题是在软件规划与设计时可以避免的，同时运维过程中也会积累大量的业务知识，这些对一个软件的规划设计是非常有帮助的，也对一个软件开发商的开发能力提升意义重大，我们说公司的能力如何如何，事实就是依靠这些知识汇聚而成。这方面是一个比较难的课题，因为当一个软件开发商初具规模后，服务团队与研发团队肯定是不同的部门，要让这两个不同团队的知识可以平滑传递，不然研发能力无以提升，一定需要把运维过程中的经验知识转化为下一次研发活动的输入，这样才能形成闭环，不断提升，服务质量才能更好。
一直以来，国内的公司都忽视了运维的重要性，这里说的重要性是指对业务影响的重要性、管理的重要性、商业的重要性。长久以来运维成了低技术含量，没有多少商业价值的业务。虽然近几年慢慢得以好转，我们也开始慢慢跟着ITIL们的后面小跑了，但真正如何做好运维，怎样做才更具商业价值，还是在跌打滚爬中。这里也有一个全世界大的趋势所在，前面的数十年中，国家与商业组织都在大量的投资IT建设，所以以前建设是焦点，问题是如何做好建设，慢慢的大部份的建设工作完成后，信息化也覆盖到了组织的方方面面了，现在面临的如何管理好这些IT设施，让以前的投资更好的发挥效益以及持续稳定的服务于业务，所以未来运维将成为热点，这里不得不佩服郭士纳在九几年就带着IBM向服务转型的远见，我在这里想说的仅仅是：为了服务质量的真正受控，我们可能需要渗透到整个服务对象的全部生命周期进行管理，最好是有一个统一的方法与标准指导，运维工作不应该只在接手服务对象时就开始考虑，而是在服务对象设计时开始考虑，即：运维从设计开始！
ITIL（无论是哪一个版本）、ISO20000、COBIT、ISO27001，这些都是IT服务管理的范畴了，但这些方法论或标准都是面向服务过程的，即根本的一个事实是，当应用这些方法论时，你的服务对象（你可以理解为IT设施，或网络、数据中心、应用系统等等）已经布署完成，这些方法论永远面向是服务对象的后续生命周期，而此时服务对象已经很大程度上固化下来了，这种情况类似于：现在有一个非常成熟的方法论去规范管理汽车的售后服务过程，但汽车的前端过程，比如象设计、制造都没有覆盖到，在这种情况下，汽车的使用与服务能得到最好的保障吗？客户享受到更好的驾驶体验，决定性的是后续的服务过程还是前端的设计制造过程呢？。许多情况下，当服务对象的设计与布署的前端过程中的问题会造成后续服务过程的永远的痛苦与挣扎，许多在服务过程中不断碰到的问题，事实上如果在设计与布署过程中考虑到了的话，会为后续节省更多的资源与成本，服务管理做得再好，在当前的框架内是无法渗透到前端的设计与布署环节的，这就面临着，当服务对象的前端过程做得不好时，服务管理能做的只是“维系”一个现状，甚至无法把服务过程中的知识经验反馈到前端过程，形成一个闭环，这种知识反而是对一个服务主体是最有价值的，比那些事件、问题、变更知识库要有用得多，当前的框架内是没有考虑这些的。尤其当应用系统这种服务对象时，更是如此，虽然有一些小问题可以后续补丁，但有一些根源的问题往往只能忍受着、服务着。
CMMI等方法论，是面向软件类的服务对象的前端过程的，但是CMMI与ITIL或ISO20000等上面无法是理论结构还是着眼点亦或者是流程假设都是没有考虑过相融的，变成CMMI只考虑开发过程中的问题，ITIL与ISO20000只考虑服务过程中的问题，服务对象的两个核心的生命阶段的管理可以说是断层与脱节的，也没有一理论框架来解释指导这一个完整的生命过程。而且CMMI只面向软件类服务对象，事实上当前的服务对象范围要更广，ITIL3.0开始有比较清楚的服务生命周期的概念，但我认为这是不够的，生命周期的概念不应该是面向服务的，而应该是面向对象的。当前世界需要的是一个面向服务对象的规划、设计、布署、服务的完整生命过程的框架与方法论，这个框架需要完成融入ISO27001这一标准，这个框架应该是完全“面向对象”的，它会提出明确的要求来规范在任何过程的服务对象，不管是软件还是网络亦还是IDC，它会要求在每一个过程如何考虑信息安全，这样才不会导致标准的分裂与无法统一作业的现象，实施过CMMI与ISO27001与ISO20000的人会发现，这几个标准作用于同一个组织时，你会无以适从，非常难以调和。这个大的“IT管理”标准，是可以分层级与结构化的，只有一个成熟而全面的服务商才可能完全实施并得到这个完整的认证，而象一些仅仅面向服务过程的只需要实施并得到关于服务管理部份的认证，重点在于一个完整的标准会真正统一规范IT业，让全世界的IT组织与人员有一个全面的平台作业。当然这个标准的整合力度与难度也可想而知，但我个人相信随着服务管理方法论的成熟与发展，在一个不久的周期后，人们会发现这一服务管理标准的局限性，最后一定会碰到“天花板”，因为很简单一个逻辑在于：我们需要是IT应用的效益最大化，服务管理过程并不能从根本上改变现状，甚至不能从根本上决定服务的质量（因为服务的质量很大程度是由前端过程决定了），加上其它的纬度的标准要求，造成框架性的割裂，统一标准的面向整个服务对象生命周期的方法论出现是必然的选择。
上面谈的问题，基本不是一个IT组织或个人可以完成的事情，除非你有IBM与HP这样的资源与理论力量。那么很现实的问题是，在没有一个这样大而全的框架支持的情况下，我们如何做，才能更好的发挥IT应用的效益呢。我们可以从一个IT提供与服务商的角度来看看，看看我们如何可以建立一个小体制来对应框架的缺失，为了避免服务对象的宽泛而无法聚焦说明，我们就以应用软件类的服务对象为例说明
1)在规划设计时考虑运维问题
当在规划设计一个应用系统时，在目前绝大多数的软件型项目中（非套装产品），在软件设计时甚少考虑软件日后的可维护性，也很少会在软件功能设计时为维护提供便利性。事实上合理的情况是，首先要着眼于客户的业务分析，同时要结合日后软件布署、维护、升级、调整。有许多系统设计时连上线布署都未考虑，这样面临的局面是，可能是一个很好的产品，但实施上线非常困难，又或者刚开始上线使用时，功能符合业务的需求，但一旦发生变化，升级变更非常困难，后续的维护工作也异常被动。所以当前仅仅是根据客户需求一方面的信息来规划与设计软件是不够的，需要同时基于后续的服务过程需要来一同规划设计，目前大多数据软件开发型项目，光是前者就很少做得足够好的，国内真正意义上的优秀软件规划与分析人员太少了，同时优秀的合格软件实施顾问亦少，一款功能不是很强大的软件，如果实施顾问足够优秀，事实上可以很大程度上弥补软件不足，因为可以将客户的业务流程与制度做相应的重组与融合，反之亦然。我想这一块领域还有相当长远的路要走。
2)在规划设计时考虑服务目录
在规划设计一个应用系统时，到底在软件实施上线后，可以做哪一些服务，哪一些功能、与接口是需要维护中重点关注的，要用怎样的频度去做日常的检查与维护，多久做一次数据优化，这些目前也是很少被考虑的，某种程度上可以说，这是软件开发商的短视，从利润榨取或商业利益而言，软件的规划设计开发过程的纯利润是不高的，同时是非常短期的，但日后漫长的服务过程，可以为软件开发商提供持久不断的收益。从软件开发商的角度而言，从纯商业的角度而言，除了满足客户的业务需求外，如何在规划设计软件时，设计好后续的服务目录（服务内容），这是非常重要的，如果一款软件完成上线后，软件开发商无法在项目的后续过程中挖掘商业利益，这某种程度是一种商业失败，开发过程相当于种下一个种子，软件开发商在规划设计过程中对服务目录的设计，就取定这颗种子日后到底结出怎样的果实出来，事实上这里面有大量的文章可做的，这同时也十分有利于软件稳定。以当前大多数软件开发商的做法，都是把软件折腾出来后，把款项回收完成，然后根本不太重视后续的服务过程，基本上是客户报障时或有新需求时，才响应做一些服务，而这些服务基本上是没多少收益的，一定要在软件规划与设计时埋好服务的伏笔，在合理的情况下，当软件完成规划设计后，基本日后的服务目录，与服务体制，以及日常的维护手册都是可以出来的，因为在规划之初，设计者是清楚哪一些地方是需要进行经常检查与维护的，服务受体到底有多少人，需要配备多少以及怎样的服务人员，基本上此时就可以大概知道日后的服务收益是多少，做多少服务合同的报价。在现实中经常看到这样的情形，在软件开发合同一般开发商会承诺有一年的免费维护，当软件实施上线后，开发商也可能是不重视服务也可能是为了控制成本，就留下极少的资源对应这个免费的维护周期，这样当免费周期结束后，由于之前的维护过程只投入了很少的资源，客户只给了很低的服务价格，这样就掉入一个循环过程中，事实上对客户与服务商双方都是不利的。
3)在规划设计时考虑信息安全
在软件的规划设计时，信息安全同样是一个需要被考虑的因素，一些高保密性的系统除了需要技术手段外（比如CA认证），还需要考虑管理手段，比如象核心账户的管制，敏感数据的备份、读取、操作。都可以建立起制度出来，目前多数系统都是在系统上线时甚至是维护时，才开始设计配套制度，这是有些晚的，因为信息最充足的情况是在客户处进行业务调研的时候，既软件的规划与设计者们才是信息集中者，他们最清楚系统要做成什么样子，需要一套怎样的管理机制配合，这也某种程度上决定了软件规划设计者同时是一个需要理解“管理”本身的人，而不是现在技术专家们。
4)在规划设计时考虑配置管理
在项目初期，软件规划设计时，基本已确定了核心的配置信息，要布署多少怎样的设备，要用到哪一些组件，要同哪一些系统做接口，相互传递什么信息，要用到哪一段网络，整个系统的拓扑图是怎样的，哪一些设备是热点，需要备机。这些都会相应的完成，即此时CMDB要进入多少个CI是明确的，而且这些CI之间的相互关系是如何的也是明确的。同时从CMDB的角度而言，在规划设计时要尽量避免关系过多，以避免一个故障造成大范围服务中断，尽量形成可插拔式的，故障只形成单点。当这一个过程中完成后，事实我们这个时间非常清楚日后的服务受体（到底是哪一些组织的哪一些用户使用系统），我们也非常清楚日后的服务对象（上述的CI），我们也非常清楚自已的服务主体（我们配备怎样的服务团队），我们还清楚了服务目录（日后需要从事哪一些日常的主动维护活动），这时服务管理就非常容易展开。
5)运维如何促进规划设计
在漫长的运维过程中，我们会发现许多问题，分析下来我们也会知道许多问题是在软件规划与设计时可以避免的，同时运维过程中也会积累大量的业务知识，这些对一个软件的规划设计是非常有帮助的，也对一个软件开发商的开发能力提升意义重大，我们说公司的能力如何如何，事实就是依靠这些知识汇聚而成。这方面是一个比较难的课题，因为当一个软件开发商初具规模后，服务团队与研发团队肯定是不同的部门，要让这两个不同团队的知识可以平滑传递，不然研发能力无以提升，一定需要把运维过程中的经验知识转化为下一次研发活动的输入，这样才能形成闭环，不断提升，服务质量才能更好。
一直以来，国内的公司都忽视了运维的重要性，这里说的重要性是指对业务影响的重要性、管理的重要性、商业的重要性。长久以来运维成了低技术含量，没有多少商业价值的业务。虽然近几年慢慢得以好转，我们也开始慢慢跟着ITIL们的后面小跑了，但真正如何做好运维，怎样做才更具商业价值，还是在跌打滚爬中。这里也有一个全世界大的趋势所在，前面的数十年中，国家与商业组织都在大量的投资IT建设，所以以前建设是焦点，问题是如何做好建设，慢慢的大部份的建设工作完成后，信息化也覆盖到了组织的方方面面了，现在面临的如何管理好这些IT设施，让以前的投资更好的发挥效益以及持续稳定的服务于业务，所以未来运维将成为热点，这里不得不佩服郭士纳在九几年就带着IBM向服务转型的远见，我在这里想说的仅仅是：为了服务质量的真正受控，我们可能需要渗透到整个服务对象的全部生命周期进行管理，最好是有一个统一的方法与标准指导，运维工作不应该只在接手服务对象时就开始考虑，而是在服务对象设计时开始考虑，即：运维从设计开始！