背景
效率和稳定性是我们从工程层面来衡量系统对业务支持能力的两个关键指标。从流程管控上来看，业务效率的提升一定程度上会影响到稳定性，而对稳定性要求过高又会带来对业务效率的影响。从业务的角度来看，成熟的业务会更偏向于稳定性，而新业务更偏向于效率。效率和稳定性兼顾，也就变成了一个巨大的挑战。
我们理解的效率
通常我们提到“效率”更多的是关注开发效率或迭代效率，我们这里称之为“业务效率”。大家通常容易忽视“资源效率”，在阿里集团搜索和推荐现有业务规模下，忽视资源效率的将付出很大的成本。
效率 = 业务效率 + 资源效率
影响业务效率的因素主要有：
- 开发复杂度
- 业务迭代流程
- 业务维护成本
- 稳定性要求
开发复杂度取决于其生态能为业务的开发提供什么支持，包括语言层面和业务领域所在的第三方生态、集团层面的二方生态、以及业务所在平台。迭代流程一方面可以保证业务功能的正确性，同时也可以提升线上系统的稳定性，但是复杂的流程会很大程度上影响到业务的效率。如何降低业务开发复杂度，为业务开发提供更强大的生态支持？如何简化迭代流程且不影响稳定性？如何降低业务的维护成本，提升其稳定性？我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。
影响资源效率的因素主要有：
- 稳定性要求：通常出于稳定性考虑会适当的降低资源利用率的要求，比如为了应对流量高峰我们需要提前准备容量，为了容灾我们需要有一定的容量buffer。
- 资源的管理和分配方式：传统靠人来管理和分配物理机效率低下，所以才有了容器技术以及现在docker的大规模应用，但是没有调度系统的支持docker与传统vm相比并没有明显的优势，并不能有效解决整体资源利用率低的问题。
- 长尾业务：传统人治的方式无法顾及长尾业务，长尾业务由于其业务规模限制必然存在资源浪费。
- 资源采购交付时间：通常采购交付时间从业务的角度来看是不可控的，为了应对业务未来的资源需求，我们通常需要提前1年提预算、提前半年左右时间提交采购。而这里时间的把控完全依赖于个人经验。
提升资源效率最直接的手段当然是让所有业务提升资源利用率。而运动式的做这项工作成本巨大收益也不一定能达到预期，还会极大的影响到业务效率和稳定性。如何用更低的成本、在不影响业务效率和稳定性的前提下，持续的让资源利用率保持在合理的范围内，是否敢于延迟采购交付时间？这是我们的挑战。
我们理解的稳定性
通常我们对稳定性最直观的认识就是不core、没有内存泄露，这也是我们通常稳定性测试的范围。往往大家比较容易忽视稳定性另外一个重要的因素 ——— Robustness（鲁棒性）。我们认为稳定性是在任何情况下都不会出现服务异常中断或资源泄露，同时在非正常输入和非正常压力情况下服务在可接受延迟范围内正确响应率不低于一定比例。