饿了么技术往事（中）( 三 )

这个阶段我们还经历了第一次外卖行业的大促——517大促，让大家真切感受到了这个市场的巨大潜力，同时系统的一系列短板也暴露无遗，除了积累了大促的经验以外，更大的收获是让我们看到架构还有很大的升级空间。还收获了一支全链路压测团队，他们在今后架构升级以及系统质量、容量等稳定性保障过程中，扮演了关键角色。
在饿了么技术往事系列文章的开篇，我提到了饿了么的技术体系经历了以下四个阶段：
核心系统 All in one 的早期架构；
以系统领域化拆分、业务系统和中间件等基础设施分离为基础的全面服务化的架构；随着自动化平台、容器调度体系成熟，治理从传统运维向 DevOps 转变的基础设施体系；多数据中心体系基础上的 Cloud Ready 架构成型。
现在我们前两个阶段基本完成了，开始了相对而言最艰难的阶段了……
第三阶段：脆弱的系统，苦逼的运维
这个阶段，我们的业务已经发展到一定规模，系统的长时间抖动或者崩溃，很容易上热搜，尤其是饭点时段。发生事故时候，冲在第一线的除了各业务线的工程师，还有运维团队，他们往往是最先响应，排障冲在第一线的团队。这个阶段说是靠他们生扛顶住了稳定性的压力也不为过：日常基础设施部署、事故发生时的应急响应、事故发生后的基础设施优化和改进措施落地，他们都承担了很多。
事故的教训，也让我们学会了遵循一系列业界积累下来的设计原则，为架构演进到下一阶段打下基础。
业务领域拆分、基础设施和业务系统分别建设后，给业务快速发展解绑了。但是包括稳定性在内的一系列挑战依然需要面对：
基础设施部署的标准化
系统的生命周期怎么管理？每次故障都是昂贵的学费，故障可以避免吗？
复杂性带来的挑战：团队里面几乎没有人面临过这个体量的业务、这个复杂度的系统。快速交付的同时，如何保证系统的稳定和健壮？
我们的系统架构接下来如何演进？
1. DevOps
因为云上资源的灵活性，我们在云上搭建了两个测试环境：alpha作为开发环境，用于软件工程师日常开发调试；beta作为集成测试环境，用于测试工程师完成系统交付上线前的集成、回归测试。费了九牛二虎之力才达成所有团队的共识，推动beta环境的系统和数据的完整性建设。在这里面发挥重要作用的，除了各个业务的开发、测试、运维团队，还有一个就是之前提到的负责发布系统的团队，这个团队不仅仅提供了一个简单的发布系统，基于持续集成和持续部署实现的开发、测试、生产环境相似化，是我们的系统架构继续演进的开端。
技术团队职责细分后，运维团队提供了保姆式的服务，这把双刃剑的另一面，就是开发团队很容易形成惰性，对自己的系统管生不管养，对系统的容量、治理关心不够，因为有运维团队。这就带来很多问题，代码不是运维工程师写的，但是有些团队系统甚至是运维工程师部署的。因为开发团队最贴近业务需求，需求变更可能带来未来的潜在容量风险，他们比较有发言权；而容量水位的现状反过来是运维团队更了解。因为这个时候，很多基础设施运维还没完全自动化，所以难以统一化、标准化，每个运维工程师都有自己的运维风格，日常排障上，有时候需要开发和运维一起才能完成。
此外，只生不养的思维方式，客观上也容易造成算力成本变成糊涂账。这个时候，开发、部署、系统运营（治理）角色的不统一带来的问题就会凸显。
应用Owner要成为名副其实的Owner ，需要有应用的全景视角，对应用生命周期的把控能力。这个阶段，开始推动从虚拟化到容器化的转型，发布系统从一个简单的CI、CD的体系，延伸到了算力和调度的领域。基于一系列运维自动化工具的建设和全面容器化调度的实施，从而带来标准化的运维，才能把开发工程师（应用的Owner）推到应用完整的生命周期运营的位置上，胜任DevOps的角色。这个时候，事实上底层的算力平台，已经具备云上PaaS的雏形了。