背景： 饿了么业务快速发展，对技术带来了海量请求和高并发、微服务的挑战，同时开发团队快节奏的版本迭代和服务的快速上线的要求也驱动我们提供稳定、高效的运维服务。2017年5月初我们成功实现了主站多活切换，到如今我们已经在生产实践了数十次故障以及切换演练。分享将从业务发展以及多活后的技术运营保障，结合具体案例，展示我们在运维方面的探索以及实践经验。 要点： 1、国内超大体量、发展迅猛、实时性要求高的复杂业务场景 2、多活的前因后果，以及运维在多活中的挑战 3、具体案例分享 4、未来如何更好的做到自动化、智能化 听众受益： 1、对国内为数不多的多活场景及业务形态的了解 2、了解超复杂场景下的多活运维及挑战 3、了解饿了么在技术+运营思路下的运维探索

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