序

请各位读者耐心地看完下面的内容，这些内容是阅读本书之前必须了解的，可以让你们更清楚地理解本书想要表达什么，而不应只把本书当作一个方法论的实践手册。另外，下面也会告诉大家为什么笔者使用“高性能之道”作为本书的书名。

众所周知，SRE工程师有几类重要职责：延迟优化、性能优化、效率优化、稳定性优化、容量规划、应急响应等。随着SRE在国内的流行，很多运维团队开始转型，包括一些架构师、后端工程师、系统工程师也纷纷加入其中。在这个SRE实践日渐丰富的情况下，笔者想讲两件事情：一件坏事，一件好事。

第一件事情：互联网行业现状对技术的影响。几年前，或者说给人留下深刻印象的2011-2019年，互联网平台百花齐放，团购、电商、游戏、聊天软件等，基本上日常的生活方式都走进了互联网。也正是因为互联网发展迅猛，我们选择使用IT成本、人力成本交换时间，代码质量不高、架构设计不佳等问题都通过投入更多的成本暂时得到了解决。虽然这样做可以解决大部分性能问题，甚至隐藏不稳定的架构风险，让业务继续往前推进，但留下了很多技术债。

那段时间其实已经出现了SRE角色，虽然国内的SRE起步较晚，但也不断地发挥出了价值。那几年，SRE工程师的核心职责中保障稳定性、效率是高于优化成本和性能的，或者说成本和性能也需要优化，但相比其他目标，被降低了优先级。但在2020年后，互联网行业出现了明显的疲态，这对我们互联网技术人来说，是一件坏事。这时大多数公司面对“寒冬”开始开源节流，成本优化被反复拉上日程，甚至有云厂商专门为云产品客户提供了专业的成本优化方案。大幅度地优化成本，如果只是单纯地缩减使用效率低的机器，将无法满足公司迫切节约成本的需求，而且一旦服务器资源减少，曾经性能不好的代码和架构问题都会浮出水面，甚至会导致辛辛苦苦节约的成本被一次偶发故障就抵扣了，得不偿失。因此，成本优化往往要伴随着架构优化、代码重构，甚至业务逻辑优化，简而言之就是性能优化。面对这种突然发生的改变，SRE工程师如何从容面对？

第二件事情：国内的SRE工程师大多从运维工程师转型而来，对性能优化、延迟优化缺乏经验，很难发挥出SRE工程师应具备的各项能力（当然很多公司也没有对团队的SRE工程师提出这样的要求）。部分有独特见解的团队，在成立SRE团队时，除了运维工程师，也引入了业务开发人员、基础架构师、系统工程师等有较强高并发开发经验和系统底层认知能力的成员，他们对性能的要求是极致的，为服务的SLA达标，设计更精妙的架构，而这些不是传统运维人员可以达到的，国内的SRE已经开始向更高阶的路线发展。虽然这又增加了SRE的技术难度，但是是一件好事，让我们可以拥有更全面、更有深度的技术。

下面举几个常见的例子。

（1）业务开发人员开发了一些动态接口，其实可以适当配置1～2分钟的CDN缓存，但并未配置，导致回源请求量高、带宽成本高，响应速度和性能也未达到最佳。

（2）NoSQL使用场景少，过度依赖MySQL，成本高，响应速度和性能也未达到最佳。

（3）客户端请求数据太多，实际应用中，只使用了部分数据，浪费了带宽，数据太多甚至意味着可能存在太多的数据处理操作，响应速度和性能也未达到最佳。

（4）在页面渲染过程中，部分数据是不需要提前加载的，但前端工程师设计了大量预加载任务，导致了大量无效计算和网络开销，响应速度和性能也未达到最佳。

（5）业务开发人员对某个接口设置了1分钟的Redis缓存，但根据业务场景，这个接口的缓存其实可以设置为10分钟，这导致请求量减少得不多，响应速度和性能也未达到最佳。

诸如此类，各种问题累加在一起，极大地增加了系统的资源开销，这会影响成本优化，也会影响服务性能，而高性能可以提升成本优化的效果，也可以优化业务架构、延迟等现象，帮助我们更好地提升用户体验。

基于这两件事情，笔者使用“高性能之道”作为书名，本书会从SRE工程师的职责进行讲解，通过实践让读者更好地理解，这些职责在工作中是相辅相成的、共同发挥作用的。这几年互联网行业“内卷”严重，但也正是全面发挥SRE工程师职责的好机会。寒冬闭关苦修，静待春风到来！