【51CTO.com原创稿件】2017年12月01日-02日，由51CTO主办的WOTD全球软件开发技术峰会将在深圳中州万豪酒店隆重举行。本次峰会以软件开发为主题，数十位专家级嘉宾将带来多场精彩的技术内容分享。届时，饿了么OPS负责人程炎岭先生将在创新运维探索专场与来宾分享"跨越篱笆——饿了么多活运维上下求索"主题演讲，为大家详细阐述分享饿了么公司在运维方面的探索以及实践经验。51CTO诚邀您莅临大会，与我们共享技术带来的喜悦。
以下是采访实录：
51CTO记者：能够请您先概括一下本次演讲的主要内容?
程炎岭：本次演讲主要分享从传统运维跨越那道看不见的“篱笆”，最终实现多活运维，整个过程中带来哪些运维形态上的改变。
演讲主要包含五方面内容，分别为一业务特性，为什么在饿了么可以支持特有的多活;二运维规划，多活前设计上需要考虑哪些运维上面的规划;三对运维体系上会带来哪些复杂性;四运营体系(主要是质量监控和效率)会带来哪些改变;五自动化、智能化任重道远。
51CTO记者：能否先介绍一下饿了么运维工作的主要特点?饿了么的业务发展非常迅速，对运维工作带来的主要压力是什么?
程炎岭：有一组数字可以让大家快速了解饿了么的运维工作量：饿了么目前有4个物理IDC，2朵云，约15000台物理服务器，1600个应用appid，1000名技术开发人员，支撑日均***订单，过去一年内平均日交付服务器60台，日均发布146次，回滚11次，历史上最长全网稳定计数器为135天。
饿了么的运维实际上是运维+运营，其中运维的工作大同小异，主要集中在底层基础设施环境规划、建设、交付以及上层业务的支持工作，目前正在为产研自助方向努力。而运营的思路会很特别，需要运维团队更多对数据敏感如服务质量、CPU利用率、成本分摊、稳定性SLA等。
我认为运维工作感受到的***压力来自于如何跟上业务/技术发展的节奏，用最短的时间提高产研的效率。举个例子：如何一键构造/销毁某一个服务的测试环境，如何一键拉取某一个服务依赖的所有资源，发生故障后各依赖服务如何快速的自证清白等等。我们需要花更多的精力去思考，改进我们的工具产品，而不能仅仅满足于当下的运维状态。
51CTO记者：据了解，饿了么主站多活切换目前运行半年了，现状如何?为什么要做主站多活切换呢?它的好处是什么?主要解决了哪些问题?
程炎岭：今年5月，饿了么主站***次多活切换成功。紧接着在6月底，饿了么启动物流多活项目，9月21日，物流多活改造成功完成，饿了么进入了全站多活时代。
为什么要做多活?因为多活是技术上的一大革命性创新，除了解决达到单机房容量上限外，更多还承担了容灾【兜底】的工作，尤其是关键路径、核心基础设施、核心组件发生各种灾难性、短期不可恢复故障以及外力不可抗拒因素的一种【续命】手段。概括的说，支撑业务扩展，容灾保障是做多活的两大好处，它解决了单机房不可扩容，业务复杂/技术复杂之后怎么快速止损、恢复业务两大难题，效果远比灾备要好。
在全站多活演练成功之前，运维团队包括全公司已经闭关了很久。正所谓“兵马未动，粮草先行”，基础运维团队用了不到一个月的时间完成了上架、调试、部署以及交付。与此同时，DBA团队、中间件团队规划了数据库的改造、接入、运维方案，完成了数百次支持、答疑工作。
在整个过程中，运维团队非常辛苦。很多情况下，工具是滞后的，也没有很好的参考案例可供研究。但即便如此，业务运维团队依然协助产研完成了整个多活测试环境(模拟双zone)的规划，部署，调试，以及参与讨论、实施多次技术改造、部署方案。
51CTO记者：对于运维工作，您还有哪些经验愿意分享?
程炎岭：运维工作有一个话题很火：是要做“救火”式的运维，还是“运营”式的运维?前者可能是大部分公司的做法，后者是大部分公司的愿景。我认为，要达到“运营”式运维需要从五个方面加以考虑。
一是标准化。标准化是自动化的基础，运维的工作(大部分)都很琐碎，也许这会我要去装个机器，那会要去配置个nginx，一会又需要去排查一下为什么日志会丢失，等等，长期下去，效率得不到提高，工作认可度也不高。而对应工具产品也会因为非标准的需求需要去做各种适应，而且做出来的工具还不被认可(为什么这个功能没有!!)，服务核心流程标准化是自动化工具的基础。
二是规划。提前做好规划，比如你要用哪一种机型，统一操作系统，统一部署方式，高可用是双A还是AB，各种接入规范，使用姿势，技术方案，需要提前做好调研、规划。基础设施的改造牵一发而动全身。并且改造大部分忽略小部分说不定哪天就会有坑。
三是效率。运维要去了解业务，了解对方的痛点，尽可能做到一站式去解决一个需求，同时把一些业务不需要关心的内容包装掉。以一个商业化的角度，设定服务的SLA，去把自己的服务做成一个“对方愿意购买”的服务。
四是数据。一个应用创建(上线)或运行过程中产生的任何数据都很宝贵，运维以及运维工作中变更这个数据应该很谨慎，如果一定要去变更，应该问是否是流程没有覆盖，变更是否可以优化。应用资产数据能帮助我们统计依赖关系，一个连接有没有流量来判断业务是否在使用，等等，智能化运维更是依赖这个基础数据，自动化，智能化做不好，往往是数据不准确。
五是平衡。平衡这个词很虚，而且似乎跟技术没多大关系。确实它也不是个技术问题。举个例子，业务发展/技术发展中，尤其是一个不赚钱的业务/一个不确定能否推广的技术，如何去平衡调度资源。你可以吧问题抛给老板，但这也是运维团队需要思考的问题。所以，技术问题相对反而好解决，而往往是一些非技术问题，我们很难决策。
51CTO记者：最近业界很多声音在谈自动化运维，智能运维，可是目前并没有统一的运维标准，您如何看待自动化运维，智能运维的前途?您认为真正的智能化运维内涵是什么?其真正落地还需要哪些条件?
程炎岭：自动化运维，智能化运维必然是潮流，只是运维在不同阶段面临不同的问题。不同的公司重视的角度也不一样，有的公司可能注重成本，有的公司可能注重效率，有的公司可能注重业务，更多的公司是在不同阶段分别重视不同的问题。而这个阶段也没有明确的“临界点”，就很难形成一种业内统一的运维标准。但一定要有一个适合自己公司项目环境、技术文化、自上而下价值观的标准，不能千人千面。
我认为真正的智能化运维内涵是数据，统一的运维价值观，不要迷信方法论，它只是一个行为的准则，是理论。真正的落地还是需要从解决实际问题的角度出发，从而更好的服务用户，服务于业务。
使用双十一特别优惠码[2017WOTD1111]，和我一起去WOTD全球软件开发技术峰会。8折优惠基础上，再减512!详情点击wot.51cto.com
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
