谈面向服务的运维设计

　　不管是ITSM理论还是实际IT服务中，都一直存在一个问题，就是如何设计运维，一个开发项目如何顺利的交接到运维团队的手中，这也是一个比较让人头痛的课题，在ITIL V2、ISO20000一开始就谈怎么样运维，好象业务就一直就是存在的一样，尤其是ITIL V2中这种问题更加明显，它的假设是我们已经完成了运维设计或者说服务设计，只需要考虑怎么做服务就可以了，但大家一直以来就无法跳到那个场地上，因为大家不知道怎样才能到达或建设一个这样的场地，这从根本上让许多人与公司只对服务支持有一些认识，而无视服务交付的部份，事实上我们从市面的一些ITSM的书上也可以有意思的发现，介绍ITIL，一般是从服务台、事件管理这些服务支持端开始的，反而是服务交付是放在后面讲解，这给大家一个错觉，服务支持为先，服务交付为后，但事实并非如此，只要把理论置入实际的业务场景，假设一个客户丢一个IDC运维合同给你，让你去帮他运维，对照ITIL的方法论，你会发现你难以下手，连先做什么先操作哪一个流程都不知道，如果没有服务交付的部份，服务支持的流程是难以聚焦的，或者说缺乏战略的，因为服务交付在前，服务支持在后。ITIL V3在大的视角上，在一定程度上解决了这一个问题，独立了服务设计这一过程，但是它又制造了一些其它的问题出来，而且它的解决更多只是哲学概念的，它过于玄思了，缺乏实操指引意义，难以有业务案例进行推演，事实上到现在，我觉得ITIL的流程框架设计问题挺多，它的概念与逻辑并不清晰，而且相互交互重叠过多，流程的概念在实际业务过程中缺乏严谨，主体的框架更是缺乏美感，可能负责开发ITIL的团队，既缺乏业务的经验，又缺乏哲学家的思维，这里的批评暂切放下，日后有机会单独写一篇这方面的文章。

　　　 言归正传，目前的ITIL的理论与业务之间，还存在一个断层，就是明确的指导如何进行服务设计，这就是我试图说明的内容，运维设计这个课题断断续续也前后思考过两年了，一直也没有多少突破，运维设计的结果有了比较确切的定义与约束，也纳入体系之中了，但生成这个运维设计的过程的方法与步骤是没有的。正好前段时间公司在做一个比较大的项目的运维设计，在作业过程中，对这一块的想法有了一些突破，但可惜无法验证整个方法与模版细节是否可行，因为时间来不及，只能暂且写下来了。　　　 以前，我们只知道当一个项目转运维时，我们知道要监控要搞备份，于是整理出这一块的计划出来，但是缺乏严谨的推理演绎过程，我们只知道去做监控与备份，而不知道为什么要做，或者怎样做才是最佳的方式，每一个主机要监控什么，它的阀值是怎样定义的，为什么备份是一天一次，为什么是凌晨的时刻进行，最终我们成为完全依靠常态的经验去决定一个系统怎样运维，我们最终一直只知道做，而从来不会去分析与设计，于是我们经常会发现一些很荒唐的情况，与业务不直接关联的对象我们没有监控或备份，不管是处理器密集型还是内存密集型又或者是输入/输出密集型的服务器，我们一视同仁的设定阀值。最后这种没有个性化与针对性的监控导致异常过多，运维人员最终淹没在其中，不再对监控信息敏感，等到狼来了时，我们重新开始一个轮回。所以到今天，我相信大多数公司的IT运维是没有分析与设计的，几乎所有的系统在规划设计时是不考虑运维方案的。我们也是只知道运维设计最终要产出一些什么，但并不确切知道那个产出的生产过程是怎样的，我想许多公司的许多系统在开始运维之初，是并没有方案的，而是在故障与问题的锻炼下渐渐成型。去渐渐的理解运维设计或者说服务设计的作业过程，这就是我想探讨的。　　　　首先要破斥的第一个观念是，一个开发项目并不等于一个运维项目，经常会一些大型项目，会包括若干个系统，由一个团队负责，最后完成后，交给运维团队时，运维团队也通常把它等同于个运维项目，我非常不认同这种做法，不管是实际作业过程，还是ISO20000的理论，我们都非常清楚的知道我们的管理单位，什么才是一个管理单位，为什么要定义成一个管理单位，到今天我们仍然不理解什么“服务”，我们需要明确服务，一个开发型项目交付给我们时，可能包括多个服务，从过去的经验看，应用系统独立做为服务运营时最容易控制质量与保障资源的，所以运维需要根据自已的管理需求，重新打包项目，有可能一个开发项目等于多个运维项目，也有可能一个开发项目根本不算一个运维项目，比如我们经常会去把一些重大的新功能增加或扩容做为开发项目操作，最后这种项目结束后，我们只会把原有的运维项目做变更，而不产生一个新的运维项目。所以在运维设计时，第一步也就是最重要的是明确定义服务，将服务独立看成一个运维项目去管理运营。　　 当我们定义好服务后，需要找出跟这个服务相关的所有组件，即服务对象。到底什么是我们的服务对象，要依据公司的配置管理颗粒度来，如果有CMDB则更简单了，看CI的分类体系，CI的分类决定了配置管理的广度与深度，有一些属于公用的服务对象，需要考虑好归属问题，比如一个服务器上有两个业务系统的数据库实例，再比如一些公共的存储设备，要么放置在一个相对重要的服务中，要么归属于公共的服务之中（如公共存储服务或机器托管服务、安全服务等等），这样可以首先保障对象不能遗漏，这非常重要。　　　在确定好每一个服务的所有服务对象后，形成一张服务对象清单与统计表，然后基于每一个对象做组件分析，要知道与记录每一个服务对象的：可用性：该服务对象存在哪一些可用性的风险持续性：当这些风险发生时，需要多久时间修复能 力：服务对象的子能力有哪一些项次，对服务人员有哪一些能力要求安 全：服务对象的安全缺陷有哪一些文 档：服务对象的专属文档有哪一些　　　以上这些可以用一张表格集中记录下来，每一行是一个服务对象，做完这个过程后，对整个服务的服务对象就比较清楚了，同时还会理出两个层面的事务出来，首先是清楚了服务人员要做哪一些培训，比如学习业务系统的业务功能及操作配置，或者一个全新的操作系统，其次清楚了要开发移转的所有文档，这两个方面的事情是运维团队永远的痛，开发团队从来不会正规的对运维团队进行培训讲解，也不会完整而正确的交付出开发文档，把这两个事务理清楚后，可以做为专顶进行管理，这样即便我们不清楚什么服务设计，把文档整正确了，人员抓起来了，一个系统的运维就有了扎实的基础。　　　　在分析完所有的服务对象后，我们就知道了现状。下一步提出的观念是面向服务的运维设计，我们需要定义这个服务的客户是谁，即服务主体，它到底是哪一些公司的哪一些部门的哪一些人员。其次是我们需要定义这个服务有哪一些内容，即服务目录，到底哪一些是我们做的，哪一些不是我们做的，这对理清统一用户的心理预期与我们的认知有非常重要的意义，然后需要定义这个服务做到什么的水平，即服务级别，最后才是定义这个服务在什么时间才提供，即服务日历。我认为目前绝大多数的IT服务的客户们，是难以清楚表达他们的服务要求的，你不能要求一个Iphone的用户说清楚要有怎样的话务服务，你不能要求一个KFC的客户说清楚要有怎样的餐饮服务，苹果公司与KFC应比用户更加理解什么是服务，所以IT部门不能因为IT服务的用户或客户们没有提出更全面而细致的要求，就认为没有要求，这是组织的自我限定与封闭。当我们知道了服务主体、服务目录、服务级别、服务日历，也就意味着我们知道了目标，前面的系统分析让我们知道了现状，这两者的差距，就形成我们要做的，也就是我们运维时到底要做什么。　　　　 我们根据可用性与持续性的现状，结合客户的服务级别要求，可以知道我们为了知道可用性的情况，需要做监控以掌握可用性信息，在一旦发生不可用时，要设计怎样的持续性计划，而持续性计划需要一系列的物资与数据准备，事实上数据备份的主要目的是为了支撑持续性计划，这两者有高度的关联性。当我们知道了安全方面的缺陷，我们需要设计加固或控制措施，这些措施或改进也就是信息安全作业计划，它会在一个相当长的时间内指导我们的安全工作。能力方面，我们知道了有哪一些资源子能力，就需要进行阀值定义，并监控它，我们同样需要知道客户未来的业务能力，以了解资源能力与业务能力之间的函数关系，同样的我们的服务能力需要做怎样的提升与保障，。所以的这些最终都形成作业计划，这是既定的要做的，这些要尽可能有手册编制，所以运维的作业之中在部份是既定的，它需要完全有计划进行管理，有手册进行指导，当服务日历开启时，还会有不既定的，如事件、变更之类的触发性事务，这些事务的数量是可以预测的，每一个对象可能的事件、变更的数量也是需要估算的，这个数字与服务主体的数量也是成正比，这些事务清楚后，我们要考虑需要怎样专业的人员去完成它，用怎样的体制去管理这些人员，这就是服务体制，此时我们就可以测算出服务成本，最后需要考虑最终用怎样的方式去记录或分析整个服务的状况，也就是服务报告的设计。　　　　至此，整个服务设计工作才真正结束，剩下的就是跟客户推销你的服务设计方案，通过后就是发布执行它，然后在服务周期结束时，根据服务方案进行服务审计，看当初的设计是否得到执行落实，进行总结分析后，可以在第二个服务周期开始前，对服务设计方案进行调整，再评审发布出去。