转载

WOT2016彭哲夫：科班出身开发者对运维人员的期许

“运维与开发”是老生常谈的话题，前几天和一个运维人聊天，TA说一些公司运维岗位都不公开招聘了，这让众多运维人员情何以堪？是运维的岗位真的饱和了？是找到合适的运维人才难？还是有这样那样的因素？带着这些疑惑，51CTO记者特别采访了【WOT2016互联网运维与开发者峰会】特邀讲师、芒果TV平台部技术团队负责人彭哲夫看看这位科班出身有丰富项目经验的开发者，是对运维人员有怎样期许？

【受访人简介】

彭哲夫·芒果TV平台部技术团队负责人

彭哲夫，芒果TV平台部技术团队负责人，主要负责 Docker 和 Redis Cluster 相关的基础设施开发。前豆瓣App Engine核心主程，前金山快盘核心主程。在系统工程方面经验丰富。彭首席，知识丰富，功底深厚，语言幽默风趣，知乎上、简书上有不少彭首席的精彩大作和回复。

有丰富的项目经验才能去做评价

初见彭哲夫印象不怎么好，觉得就这是个屌丝，还挺高傲。第一问题，做开发起初有遇到过哪些困难吗？他果断的说，并没有。看到我持怀疑的眼光看这个他，他用这样一段说，让我觉得这个家伙还是有高傲资本的。他说：“其实我是科班出生，小学六年级就基本上开始搞计算机这行，参加过奥林匹克竞赛，一直到大学然后再到现在。所以说这么多年的基础打下来，很多问题上面其实早就心有概念，所以走的弯路算比较少。遇到问题，我有自己方法论，所以也知道怎么从一些信息或源码上去找到解决问题的方法。”

彭哲夫在采访中提到了三个项目分别为金山快盘、豆瓣APP引擎、芒果TV容器调度编排系统，在介绍这三个项目的过程中，我能够体会到他的那份骄傲。金山快盘是国内第一个云存储，是从WPS在线文档演进过来，之后开发是用java做的数据中间件，纯C++写的存储层，主要应对文件分片，文件复用等问题。彭哲夫在这个项目中担任数据的分发层、数据中间件、Java层的主程。在彭哲夫加入豆瓣APP引擎时候，豆瓣的技术已经和业务脱轨，与其用技术还不如直接用人力节约成本。但一年后，自动化的统一的流畅的开发流程正是上线了。在彭哲夫离开时候，整个引擎已经能够支撑起豆瓣的所有业务了。在这个项目中，彭哲夫的提交量是所有人之和。芒果TV容器调度编排系统可以说是彭哲夫提出并带头开发的，最初的芒果TV更像是一个比较传统的手工作坊，包括上线、下线、测试，包括源码管理。他觉得如果是纯粹由这种业务层面开始到技术到测试到最终落地，沟通成本很高。开发一个系统就会降低开发成员的薪资成本，只要有标准，按照标准走，不需要过多沟通。

实践后才能找到问题知道哪里该需提升

芒果TV容器调度编排系统从零到用于业务中，经历了很多的困难，在实践中也会遇到大大小小的问题。彭哲夫一直在尽自己最大的努力，引入业界优秀的解决方案来提升芒果TV的系统性能，降低运维成本。由他的负责平台部核心技术团队，目前主要是在做基于Docker的调度平台以及整个公司的基础设施。他们在没有参考任何其他调度编排系统的情况下自行研发了调度编排系统，现在这个系统驱动了芒果TV的Redis集群，实现了毫秒级的扩容和缩容，保证4个9的可用性和6个9的数据可靠性。

到目前为止，芒果TV容器调度编排系统可以混编Offline和Online的服务(binary/script)，对于资源尤其是CPU资源实现了自由维度(0.1、0.01、0.001等)的弹性分配，使用 Redis 作为数据总线对外进行消息发布，动态感知集群所有的 Containers 状态并监控其各项数据等。此外，把基于Docker的Image Layer特性和Git version结合起来，实现了自动化的 build/test 流程，统一了线上部署环境。同时解决了 Runtime 的污染问题，使得业务能快速地扩容和缩容。

不是谁都可以做运维运维人员要有素养

当问及您觉得什么程度的运维人员能够维护芒果TV容器调度编排系统时，彭哲夫这样说，“目前来讲，纯粹的运维和纯粹的开发是没有多大意义的，因为容器出来之后，很大程度模糊了运维和开发之间的边界。更希望运维本身有一定开发基础去弥补开发的东西，因为以前开发提供一个文档给运维，然后有关机器、有关网络运维就可以工作。现在来看，运维面对的是平台层面的运维，它和上层的开发是完全隔离的。平台层面的运维对运维就有要求了，这个要求最简单的就是协议战，对协议、对虚拟网络，对磁盘数据的管控，面对的可能不是磁盘，可能就是快设备，可能是分布式存储系统。这些东西可能都会有些要求。这是从我目前来讲，我可能希望运维更加的往上走一点，而不是纯粹的。”

作为科班出身的资深开发者，彭哲夫举例表明了自己对运维人员的期许。如果把传统运维比作汽车保养功能，其就是为了使汽车可以开的更久，开的更好。当然目前这种技术发展趋势下，运维不光是具备保养功能，至少要做一名车工人，去造更好的车，让汽车跑的更久或者更好。如果传统运维就是加油站，同样跑500公里加5次油，这5次油都是运维做的。现在来讲，可能运维会参与到全新汽车开发，它本身就可以开500公里，那这样的话，效果是一样，但是成本完全不一样的。运维本身要完全理解为什么会有平台这个东西，为什么要隔离产品，就产品开发和运维之间这么一个模糊的地带。