在过去的2、3年里我做了大量的性能优化和成本优化项目，也从中总结出了一些经验和方法论。受本人技术能力所限，本文不会涉及太多高深技术。
本文分上下两篇，上篇主要讲一些方法论，下篇会列举一些具体的优化方法。
优化的目的
当然是为了KPI。归根究底，无非三个原因：
如果一次性能优化没有达到任何上述目的，那将毫无意义。其中，缩减成本往往是最重要的，也是非技术背景的老板们最关注的。
优化的时机
很多人都知道一句话：不要过早优化。但有一些人错误理解/滥用了这句话，把它当作自己写垃圾代码的理由。你对他指出：“这段代码性能太差了”，他怼道“又不是不能用，不要过早优化懂不懂”。
但现实情况是，这里烂一点，那里浪费一点性能，久而久之，代码变成了屎山，系统性能也可能会超出常理地差。
我对“不要过早优化”这句话的理解是：在不明显拉长工期的前提下尽可能保证代码质量，在自身现有技术能力的范围内尽可能写出高性能的代码；但不要为了这个目的强行花大量时间去研究与学习，甚至拖慢项目进度。即代码质量 - 开发速度 - 性能 之间的均衡。
充分了解系统的性能与成本
进行优化的第一步，首先要对整个系统进行性能与成本的分析, 对整个系统与业务有一个全景的认识。需要至少了解清楚如下问题：
- 业务场景对系统性能的要求
- 整个系统的架构拓扑、交互方式、高可用和扩缩容机制
- 用到的机器数、机型、各计费项的计价方式和单价，也包括不同计费方式下的折扣等
- 系统内各组件主要性能指标的负载情况
- 主要程序的代码结构
- 主要程序进程内的CPU与内存占用分布
- ...
服务器的计价方式和单价也是很多人在成本优化时容易忽略的一点。如果在这方面缺乏经验，可能会得到一些反直觉的结论。比如网络费用居然占比这么高，怎么还有这么多奇奇怪怪的收费项目，某个付费服务怎么多付了这么多钱等等。
而且在不换用其它家云服务，不大改系统的前提下，有时仅仅通过换成该服务商的其它类似服务或修改计费方式，就能在性能不变甚至更好的前提下降低成本。
根据优化目的指定计划
现在有了全景的信息，我们知道了哪一部分消耗的性能最高，但如果要制定优化的优先级计划，还需要回到自己这次优化的目的上来。
举个例子，如果这次优化的目的是优化响应时间，那么能影响响应时间的部分才是高优先级的。这时哪怕有某个部分可以优化出大量服务器成本，由于它不是我们本次优化的重点，其优化级也不能太高。可以排到后面，或先记下来等下次立项做成本优化时再做。
制定优先级也要综合考虑实现难度。比如有一些小的代码细节，积累下来可能也只能优化1% 2%的CPU，但不改变业务逻辑，且随手就能实现，优先级就可适当提升。
做好数据记录
立项分析、每一步的分析过程、优化的成果等等，每一步都需要做好数据积累，记录到团队公共文档中。这样的好处很多：
- 在与业务团队argue排期优先级时可提供充足的数据支撑，
- 是自己工作成果的证明，汇报、晋升时用得上
- 为团队积累下来的知识
- 在自己优化的过程中也充当备忘录
许多人整天埋头写代码，但忽视了对成果的记录，最后可能加班没少班，还要被怼一句“你这个季度都做了些什么”
业务优化 > 技术优化
对于一个已经高速迭代了几年的老业务系统，业务逻辑的优化空间往往比纯代码的空间大。比如直接砍掉某个又耗资源又没用的业务。近几年好多互联网大厂在裁员，但裁员时往往优先裁边缘部门，也是这个道理。
成果对外输出
很多人做了很厉害的成果，却不注重对外的成果输出。但很现实的问题是，在一些中大厂里，成果输出这一步往往和实际做事一样重要。因为对你的晋升或述职进行考核的人往往不是本部门的，不知道你具体做了什么，他们甚至可能不是做服务端的，或甚至不是技术岗。这时，如何让他们知道你做的东西有多牛逼就至关重要。
一句话核心指标
可能你做的优化项有很多，但最终输出时，需要有一句简短有力的话来概括你的全部优化。这一句话可以是自己晋升PPT的第一页，也可以是季度总结的
这时就需要选用一个合适的指标表达自己的核心成果。可以自己造一个适合表达的指标。
比如你的系统是个只有一个接口的微服务，而你优化的核心目的是降低成本，可以自造一个“单位请求服务器成本”，即单位时间内的总请求数/这段时间整个系统产生的服务器费用。最终的核心指标就是“单位请求的服务器成本降低了xxx%”。
类似的，如果是一个API服务，而你的核心目的是降低时延，最终的结果可以类似于“接口处理耗时P95从xxx ms降至yyy ms, 降幅为zz%”。
最终都要落到“钱”上
老板最关心的只有一件事：你为他赚了多少钱，省了多少钱。因此，如果你性能优化成果能清晰地转换为“省了多少成本”或“提升了多少收益”， 请把它放在最前面最醒目的位置 。这也是无论是否有相关的技术背景，都能看懂的。
不同的目的，不同的侧重点
要知道自己这份成果报告是给谁看的。
如果明确是给全公司，或给老板看的，请忽略里面一切技术细节(只在必要的地方补充)，拿尽可能多的篇幅来写成本、效率上的提升。各种数据也尽可能转化成一个大家都能理解的指标。比如优化了CPU性能，可转化为需要的CPU总核数减少，再转化为需要的机器数减少，从而得到对应的“预期成本降低xxx/月”
如果是给有技术背景的leader们看的，请在必要的地方补充一些自己用到的技术关键词，这样方便那些已经很久不写代码的技术leader们自己去查资料来了解你做的东西。但也不要太详细，他们没有那个耐心看太多字。
如果是作为技术团队内部的技术分享，这时才需要把自己的详细方案列出来。
========
下篇会简单列举一些具体的优化手段
