运维的边界

8月份的一天，我和一位准备拓展运维服务的经理S君聊过一次天。双方探讨了一下关于运维的的问题。

S君的主要困扰在于，他目前就职于一家大型企业集团，带领集团内唯一成建制的IT技术团队。该集团旗下有多个子机构，每个子机构内都有大量的零散的信息化系统，这些信息化系统的所有者都没有足够的能力来完成独立的运维，不断的向集团抱怨。

另一方面，这些所有者们又不愿意将业务逻辑分享，因为S君所在的部门有足够的开发能力，有独立的运维能力，同时他们也具有对外服务的资格，因此零散系统的所有者担心S君所在的部门在完全了解了他们自己的业务逻辑之后，会变成他们的竞争对手。

集团有意让S君带领他们的团队将集团内所有的零散系统都统一管理起来，不仅满足各个所有者的需求，同事要逐步完成集团内系统的整合。S君本身很喜欢这件事情，他们自身的技术能力保证了他们可以完成IT技术相关的运维，但是S君还希望这些系统所有者派出手里的技术人员参与到这些外包的运维服务当中，甚至于希望各个所有这把他们的运营人员也派过来加入到S君的运维体系中。

这个显然不是系统所有者期待的。

我看到这里就觉得有点混乱。简单的理顺了一下情况，

1. 集团是希望通过从统一运维开始，逐步的完成集团的信息化系统的整合和统建通管
2. 各个子机构有希望有人能帮他们解决运维工作，但是不希望“引狼入室”
3. S这边有能力有意愿来接手运维工作，但是还希望全面介入这部分业务

整个推广工作陷入了僵局，虽然集团通过一系列行政命令来推行这个统一运维的事情，但是依然进展缓慢。我给他出了一个定义运维边界的主意。

       首先，我们需要定义好自身的定位，我们自己到底想要做什么，在这件事情里，显然S最想要借机建立自己的运维团队，并顺利开展统一运维工作。那很好，我们首先可以考虑做好这件事情，那就是我们先把运维团队做起来，将运维的层级划分好，

1. 一级运维做操作系统及以下层次的技术维护，可以将基础架构管理，信息系统安全，应用数据备份等包含进去，尽量解决用户的后顾之忧
2. 二级运维需要在一级运维的基础上增加对于行业软件，中间件等标准件的运维
3. 三级运维需要在二级运维的基础上增加对定制产品的运维，可以是性能调优，配置管理，用户管理等，也可以包含代码级维护
4. 四级级运维就是介入到用户的业务逻辑，提供基于客户业务逻辑的信息化技术技术咨询，架构，规划等
5. 五级就是再进一步，成为客户的合作伙伴，一起参与到业务逻辑的管理，规划，甚至参与到客户的业务当中

      我给他的建议就是现对外宣布1，2，3，三个等级，4可以有限的透漏，但是不要一上来就宣布，这给别人野心太大的感觉。现阶段绝对不要去做5.

      然后，区分好“你”和“我”。不要把客户和自己混在一起。第一层含义就是人员不要混杂在一起，可以接受类似与Product Owner之类的角色，但是一定不要在我们自己的团队里混入客户的人员参与到日常工作中，因为这个不是我们“外派”员工到客户那里，而是我们把业务拿回到我们这边，这两者区别很大；第二层含义是，从工作范围上看，一定要划分出各自需要负责的地方，客户需要负责的我们不要动手，可以有限的协助，但是千万不要去做客户的事情，同时我们的事情一定要自己控制好，不要把我们的工作交给客户，这样可以避免未来各种扯皮，以及用户满意度降低等问题；第三层是明确客户的业务范畴，不要直接参与客户的业务，即使是客户邀请，依然要控制好度。

       接下来，服务过程一定要清晰、明确、简洁。S君这边有一个想法，帮子机构承担呼叫中心的工作，出了问题，子机构内的员工可以找S君的团队来提交工单，S君的团队会在把单子转给该子机构的责任人来执行，如果该责任人不能执行，S君他们会自己来做或者找别人来做。这些是我的简化性描述，实际说的更复杂。这个是S君和一些子机构的IT方面的工作人员讨论后的方案，据说能解决实际问题。但是，考虑到使用或者说享受运维服务的是普通员工，有多少人愿意花时间找一个第三方的人来替他联系坐在隔壁办公室的人来解决问题？有多少人在听完这个流程就已经晕了？所以在设计运维范围的时候，一定要保证一旦这个业务进入到自己的领域范围之后，对于提交问题的人来说，就只有一条路线，我们在解决的过程中肯能需要子机构的人配合调查，或者配合做一些操作，但是一定是我们来主导完成工作。

最后，从阶段目标到业务执行，都把自己作为客户的技术支持，技术服务，技术实施团队，我们只是完成客户在信息化系统内的工作。所有客户的业务开拓之类的不是我们的范畴，我们就是客户在完成自身经营过程中的一个服务承包商，是客户背后的支持者，所言所行都代表客户的意志，而不是我们自己的。

——————————————————————————————————————————

大概两个月后，S君带领他的团队开始在集团内进行新一轮推广，这一次他们只讨论了如何完成技术维护，如何完成维护工作切换等，果然大家的反对意见少了很多，争论的焦点从是否要把运维移交转移到了运维费用上边。