16、SRE工作中的系统简化与工作平衡之道

SRE工作中的系统简化与工作平衡之道

系统重写的经验教训

在系统开发过程中，有时会面临对现有系统进行重写的决策。以Borg和Omega的开发为例，Borg在Omega开发期间持续演进，这使得Omega始终在追逐一个不断变化的目标。早期对改进Borg难度的估计过于悲观，而对Omega的期望又过于乐观。从Borg迁移到Omega的难度远超预期，数千个服务中的数百万行配置代码，以及众多SRE团队，意味着迁移在工程和时间成本上都极高，且迁移可能持续数年，期间还需同时支持和维护两个系统。

最终的决策是将Omega设计过程中产生的一些想法反馈到Borg中，同时利用Omega的许多概念启动了开源容器管理系统Kubernetes。从中得到的教训是，考虑重写系统时，要思考整个项目生命周期，包括针对不断变化的目标进行开发、制定完整的迁移计划，以及预估迁移期间可能产生的额外成本。拥有大量用户的广泛API很难迁移，不要将预期结果与当前系统简单对比，而应对比在投入相同努力改进当前系统后的样子。虽然有时重写是最佳选择，但一定要权衡成本和收益，且不能低估成本。

系统简化的方法与重要性

系统简化工作大多是从系统中移除元素。简化方式有直接和间接之分，直接简化如移除对从远程系统获取的未使用数据的依赖；间接简化则可能需要重新设计，例如系统的两个部分需要访问相同的远程数据时，更简单的做法是只获取一次数据并转发结果。

领导必须确保简化工作得到认可和明确的优先级。简化意味着效率，它节省的是工程时间和认知负担。应像对待有用的功能发布一样对待成功的简化项目，平等衡量和庆祝代码的添加与删除。例如，谷歌的内部网络会为删除大量代码的工程师颁发“僵尸代码杀手”徽章。

简化