中国IDC圈1月7日报道，1月5-7日，第十届中国IDC产业年度大典（IDCC2015）在北京国家会议中心隆重召开。本次大会由中国信息通信研究院、云计算发展与政策论坛、数据中心联盟指导，中国IDC产业年度大典组委会主办，中国IDC圈承办，并受到诸多媒体的大力支持。

中国IDC产业年度大典作为国内云计算和数据中心领域规模大、具影响力的标志性盛会，之前已成功举办过九届，在本届大会无论是规格还是规模都"更上一层楼"，引来现场人员爆满，影响力全面覆盖数据中心、互联网、云计算、大数据等多个领域。

上海绿岸运维总监叶俊强出席本次大会并发表主题为《运维思考沙发》的精彩演讲。

上海绿岸运维总监叶俊强

以下为叶俊强演讲实录：

容器这块给运维提供了很好的发展机遇，在容器这块的使用大大简化了运维的工作包括标准化的事情。下面的演讲主题是运维的思考沙发，什么是运维，我们在运维这块做了三件事情，我们要保证他稳定安全好玩，工作要好玩产品要好玩，产品好玩才有付费，工作好玩大家才有激情，大家如果天天干同样的事情显然是不好玩的。

现实跟理想是有差异的，我们经常说运维是搬运工，这是比较残酷的现实，对于运维人员来说，这真的是不好的，大家都不想做不专业的事儿，这给运维招聘带来很辛苦的活，我们去校招运维这块很少有简历，IDC为这块的参差太大也是很残酷的事情，好的运维很难招，我现在在考虑，是不是要招运维，我们公司招运维做什么，他在组织结构中的定位是什么，我们对运维的KPI是什么，运维的工作是不是可以外包，招来这些人需要什么技能，比如一个创业企业，只有三五台机器，三五个设备或者十几个虚机，一般运维人可以支持了，这个业务不需要很多技能支撑这个业务。运维是一个服务，在云时代，运维既服务是不过分的，如果说我们需要在云时代可以花钱购买到运维远远比我们管理几个运维人员更低一点，也会更专业。如果是创业公司，像手游游戏开发团队没有运维，这是一个趋势，不是所有的公司都需要运维。做产品开发，比如游戏公司，把内容怎么做的更好玩，放在产品上也许更成功，运维这件事，通过服务的方式购买会更好。传统运维跟云运维还有一些区别，其实传统运维里面做的六见事情，我们说部署监控安全备份排障和调优，其实在运维这件事上，运维跟开发不能分家，我一直觉得不会网络的开发不是好运维，这也是运维招聘的一个难点，我们招聘一个JAVA开发，我需要你懂JAVA开发技能，你要招运维，你要跟他们说我需要一大堆的东西，人家就蒙掉了。所以招运维是一个非常痛心的事情。

我们看看国外公司对运维是怎么定的，谷歌对运维定义是HRE，作为HRE有几项职能，这里我不具体说了，刚刚讲到六项技能里，在谷歌做上线前的准备要求，服务的调度，但要保证我的服务可用性，他不做业务的上线部署，我们在传统运维部署这件事跟他们没有关系，他不会做开发，运维在未来的趋势越来越远离底层，靠近基础的架构，应对企业的变化。DaoCloud的分享我们可以看到，运维不会涉及到服务器虚拟机，管的是应用，更偏业务层。我这里讲下培养，我总结了一些小经验，我们招一个人过来他什么都不会做，他学着做，他应该知道要怎么做这个阶段通过流程规范标准，每个公司有自己的运维手册操作方案给他们，这个关键很多运维工程师在第二步死掉，他知道怎么做，但是不知道为什么要这样做，他不知道为什么这么做就不清楚底层问题，所以产品出现问题，他就解决不了，这是我们碰到50%-60%的运维死在这件事上。当我们明白为什么要这么做，我们要关心别人是怎么做的，谷歌是怎么做的，国内是怎么做的，国内运维做法跟谷歌的差异很大，国内运维普遍偏向于小蚂蚁的工作。知道别人怎么做，要上升到另外一个阶段，我们还可以怎么做，谷歌的做法不是最终结论，当我们把工作抽象出来分成不同的知识体系以后可以做更多事情，考虑好了再做行动，我是一个比较懒惰的人，我觉得运维的最佳状态是拿着咖啡听听音乐收收数据，出现问题服务器可以自动调度，我认为懒人才能有创新，才可以让我们的工作的高度提高一下。

目前国内还没有员工做到什么都不做的地步。我们现在引入正题，需要一些思考，运维的工具，我把面向对象编程引入进来，我们所有的业务都是属于对象，我们要理解业务思考业务，把复杂的业务变的相对简单进行拆分，拆分以后要流程化标准化，对好每个业务的接口，为什么要对接口，如果你要做自动化必定有接口当你的服务在更多的机器上五台十台都有接口，他要有不同的状态才能做其他的业务，我们要把业务接口之间的关系，拆开以后定义层次，服务跟服务之间是不是存在关系，A宕了需要把B关掉再把C关掉，通过在这种情况下现有的应用架构，都不是所有的业务，我这个进程崩溃掉了，把他做起来就行了，这是我们要流程化的关系，我们需要将做的业务模型，这个前面的过程没有涉及到我们做什么编码工作，我们把这个到实际业务上操作，如果跟我们的设想一样要进行自动化的过程，我们在前面进行编码和完成运维，让他从小蚂蚁解脱出来，然后看我们的预期，如果没有完成预期可以进行修整，我们可以交付给运维人员进行使用，把部署交给业务，业务操作的更快。比如一些服务器的开服，我们直接把这个交给运营人员做，他们比我们更熟悉业务，你点点鼠标就可以解决了。把所有业务拆分变成相对简单的模型。

后面要讲的便是领域，什么是领域？领域是开发里的一个概念，为什么要提到运维里，一个游戏运维电商运维和社交软件运维是不同理念的，他是有边界的，他的业务虽然各有各的不一样，但是总体也是一样的，领域是边界的抽象只是反应业务的本质。我们开发跟运维产品沟通，我们各用各的语言，开发的说我Java怎么写，运维就蒙了，我该怎么说，这里面帮助开发、运维、业务人员有一个沟通的共同话题。第二，他不是主观的，他只是参与的角色，不是把人划到里面，那样会失去客观性。在不同的领域里解决问题的方式被打破，比如游戏行业的运维，做进度行业运维或者电商行业的运维，他以前的方案会被打破，你这个想法不行，因为开发运维和业务部门需要共同沟通需要共同语言。云计算需要不同的领域做挑战，比如阿里云做电商和游戏，如果不能运用各个行业的挑战那就不适用了，比如在做运维这块经常被投诉，说你的服务太慢这样的问题。我对这样的关系理解是横向和纵向，如果没有业务积累的情况下，要做这个事情是不太靠谱的。比如说我做电商，我就从零开始，我需要借这个领域里的支持才能做更多的事情，云计算这块事情是一个利好消息，他可以把开始讲的水平相对较差的运维人员淘汰掉，大部分的公司将不太需要运维这个岗位，你也不需要抓IDC不需要做网管和路由，只需要管理好自己的业务。

我们在运维招聘这块，开发的目标很明确，运维为什么难招，不知道自己要干什么，所以他很少投这个简历，国内的运维大多数就是一个网管，工作没有太大挑战，所以运维要解决招聘的问题需要一个体系的培训，同样运维要给自己证明你不是网管，你的工作有价值和有意义的。后面讲到DevOps，我觉得DevOps需要大量的实践才能获得赞誉，前期需要对多种技术掌握，需要有一定的经验，不懂网络的开发不是好运维，这个事情是一体的，如果单独把开发网络切成不同的工种是深度，线上的业务出了问题你不能找开发帮你看是什么问题，自己肯定要做一些鉴定。架构设计，一个好的架构是演化出来的，第一句话叫是有之以为利，无之以为用，我们盖房子不是以住的人需求去盖，而是按照一个通用的标准，这给用户一个很好的使用体验。所以架构是被设计者根据规律设计而来的，设计者的思想是通过实践演化而来的，要做一个合理的架构要有大量的实践。