同时，要深度分析优化方案的可执行性。因为优化往往不是一个人在做，而是一个团队在做，如果方案本身就不可执行，那浪费的是一个团队的时间。而且，要找准关键的点在哪里，根据自己业务的瓶颈来做，不要盲目跟着别人的方案来做。事先清楚和找准后，再去进行深度的方案讨论。
然后，是要尽量避免过渡优化。怎么理解？在做优化方案的时候往往会有很多很多方案，有些提升的比例可能没那么高，比如从98%提升到99%，但带来的人工和维护成本非常大，这个时候就要考量用户的比量，确定是否值得投入。
2、常见优化方案
每个团队所用的技术、方案都不太一样，所以在优化上面也会有所差异。在此，针对常见的3种方案进行优化分析：
前后端分离：最初的大部分的业务应该都是前后端分离的方式，前端就聚焦在前端上面，后端专注于后端的一些接口、数据的调用。这时要怎么去优化？首先，随着业务越来越复杂，前端要做分层处理、模块化，以便维护。同时， 要重点做前端资源加载的优化，因为后端只是在做数据拉取，只要能够抗住量，就没有太大问题。而且，要清楚每个资源、数据在异常情况下带来的影响。举个列子，你的业务可能有很多很多的资源，当第一个资源失败，会带来什么结果，第二个资源失败，又会带来什么结果，这些都要非常清楚。否则，当用户把问题反馈过来时，很难第一时间发现问题所在。此外，网络场景要去细分，了解用户的重点是在哪里，是在4G网络，还是在WIFI网络，优化重点要进行偏重。
重前端MV*：随着前端的发展，前端MV*框架愈加常见，很多业务、团队都有在用。这种情况下的前端更重，就需要考虑前端并发，不能让用户去等待很多很多的信息。同时要去做同步渲染降级，让用户快速看到。还要考虑在业务里面的SEO，对于浏览器来讲，当它拉的信息都是一样的，它会认为页面的更新非常低，搜索引擎很难抓取并更新。
Node全栈研发：在发现诉求越来越多的时候，就需要有一个能同时聚焦到前后端的工具，刚好Node就能帮我们做很多事情。这和前后端分离有点像，但又不完全一致。可以看成，前者是前端一个人后端一个人，但更好的情况是能前后端只有1个人，这样他会更清楚前后端的逻辑，而且这些逻辑要尽可能的在前后端复用，这个时候就要考虑前后端的复用体系。Node本身很强，但还需要注意更深入的一些东西，比如TCP/UDP协议的解析。因为你后端的数据是来源于它的后端的一些数据调用，如果这个时候能够用node解决，那是最好的，前提是node能撑住这个量的场景。
3、效率至上
优化的同时，要对团队的效率进行掌握。效率至上来做优化，才是合理的。对于效率，可以从以下几个方面去看：
第一个是刚才讲的复用体系，前后端复用体系怎么去复用；
第二个就是需要有完整的构建工程体系，现在其实有很多构建工具，在此不做列举，能用工具解决的事情都不要去用人力去做，哪怕是一个简单的更改。因为工具解决不会出问题，但人力解决难免会出问题。
第三个是需要有完整的研发技术栈，研发技术栈决定了团队的统一性，能够帮助新人快速融入和业务的交接。
4、研发生态
虽然说效率至上，但也不能只讲效率，还要有所有工具体系的一个生态闭环。它能不能自动更新、自动维护，能不能有一个方式去迭代。比如说其中的一个组件，它可能会升级、会改变，升级的方案是什么？升级后怎么快速的能够跑起来、用起来，不出问题？这就是生态，生态会有很多方面，把业务里面的生态建立起来后，团队的优化才是最高效的。
三、直播优化实践
确定了方案，下一步就要应用到业务中实践。同样，每个业务的情况都不一样，这里还是以直播的业务来举例。
1.1、监控——加载监控体系
首先，要知道你的业务瓶颈，这就是通过业务的监控分析出来的。没有监控是很难知道业务的瓶颈在哪里。那到底要监控哪些点呢？可能有人会比较茫然，那么多业务，哪些点是重点，哪些点是必须要做的点，难道每个都要监控吗？