“运维与开发”是一个老生常谈的话题。前几天和一个运维人员聊天，他说有些公司的运维岗位是不公开招聘的，这对很多运维人员来说有多尴尬？运维岗位真的饱和了吗？合适的运维人才难找吗？还是有其他因素？带着这些疑惑，记者特地采访了【WOT2016互联网运维与开发者峰会】特约讲师、芒果TV平台部技术团队负责人彭哲夫，看看这位专业又专业的开发者是如何有丰富的项目经验，对运维有兴趣。人们有什么期望？【受访者介绍】芒果TV平台部技术团队负责人彭哲夫芒果TV平台部技术团队负责人彭哲夫主要负责Docker和RedisCluster相关的基础设施开发。原豆瓣AppEngine核心程序，原金山快盘核心程序。有系统工程经验。***彭知识丰富，功底扎实，语言幽默。知乎、简书上有很多***鹏的精彩杰作和回复。只有有丰富项目经验的人才可以做评估。第一次见到彭哲夫，印象一般。***请问，您在最初的开发过程中有遇到什么困难吗？他果断地说，没有。狐疑的看着他，他用这么一段话，让我觉得这家伙还有狂妄的资本。他说：“其实我是科班出身，基本上小学六年级就开始从事计算机行业，参加过奥林匹克比赛，上过大学再到现在。所以打下后打了这么多年的基础，很多问题都已经解决了，心里有一个概念，所以走的弯路相对少一些，遇到问题有自己的方法论，所以也知道如何从一些资料中找到解决问题的方法或源代码。”彭哲夫在采访中提到了三个项目，金山快盘、豆瓣APPEngine、芒果TV容器调度编排系统，在介绍这三个项目的过程中，能体会到他的豪情，金山快盘是中国第一家云存储。由WPS在线文档演变而来，后来开发了java做的数据中间件和纯C++写的存储层，主要处理文件分片和文件复用，之后彭哲夫加入豆瓣开发APP引擎，因为豆瓣的技术需要一些改变来支持更好的业务发展，解决单位硬件成本高于人工成本的问题。完成APP引擎后，主要可以提高内部生产力和整个在线业务的效率。芒果TV容器调度系统可以说是彭哲夫提出并开发的，最初的芒果TV更像是一个比较传统的手工作坊，包括在线、离线、测试和源代码管理。他觉得从业务层面到技术到测试再到最后落地的沟通成本非常高。开发一个系统会降低开发成员的工资成本。只要有标准，就按照标准来做，不需要太多沟通。只有实践过，才能发现问题，知道芒果TV容器调度编排系统需要改进的地方。从零到在业务中使用，我们经历了很多困难，在实践中也会遇到大大小小的问题。彭哲夫一直竭尽全力推出业界领先的解决方案，以提升芒果TV的系统性能，降低运维成本。其负责的平台部核心技术团队目前主要致力于基于Docker的调度平台和整个公司的基础设施。他们在没有参考任何其他调度和编排系统的情况下，开发了自己的调度和编排系统。现在这套系统驱动芒果TV的Redis集群，实现了毫秒级的扩缩容，保证了4个9的可用性和6个9的数据可靠性。至此，芒果TV容器调度编排系统实现了线下线上混合业务（binary/script）。对于资源，尤其是CPU资源，实现了自由维度（0.1、0.01、0.001等）的弹性分配，使用Redis作为数据总线对外发布消息，动态感知其中所有Container的状态集群并监控其各种数据。此外，基于Docker的ImageLayer特性与Git版本的结合，实现了自动化的构建/测试流程，统一了线上部署环境。同时解决Runtime的污染问题，让业务快速扩缩容。不是每个人都可以成为运维人员。操作和维护人员必须受过良好教育。当被问及你认为什么级别的运维人员可以维护芒果TV容器调度系统时，彭哲夫表示，“目前纯运维和纯开发的意义不大，因为有了容器之后out，运维和开发的界限在很大程度上已经模糊了，希望运维本身有一定的开发基础来弥补开发，因为之前的开发提供了相关的机器，相关的文档网络交给运维，运维就可以工作，现在运维是面向平台层面的运维，与上层的开发完全隔离。运维平台级别的运维需要高一些，最简单的需求是协议栈，它控制协议、虚拟网络和磁盘数据。这时候运维面对的可能不是磁盘，可能是块设备，也可能是分布式存储系统。从发展的角度，我希望运维自己提升，而不是传统的纯粹简单的运维。”作为专业出身的资深开发人员，彭哲夫举了个例子表达了对运维人员的期望。如果把传统的运维比作汽车的保养功能，就是让汽车开得更久、更好。当然，在现在的技术发展趋势下，运维不仅仅是要有维修的功能，至少要做一个车工，造出更好的车，让车跑得更久或者跑得更好。如果传统运维是一个加油站，也是跑500公里加油5次，而这5次加油都是由运维来完成的。现在，运维可能会参与到新车的开发中，可以自行行驶500公里。在这种情况下，效果是一样的，但是成本却完全不同。运维本身需要充分理解为什么有平台这个东西，为什么要隔离产品，产品开发和运维之间有这么一个模糊的区域。写在***：彭哲夫在接受采访时说，运维和开发的侧重点是不一样的，没有谁高人一等。开发将专注于需求的实现和落地。运维会专注于监控等整个平台层面，但是监控也会包括开发，毕竟生命周期不一样。如果说整个部署运维的抽象，以前是基于机器，现在是基于进程。
