古人云：“知己知彼，百战百殆”

容量预估

  对于电商大促场景一般都需要进行容量规划及故障演练。容量规划，就是通过对复杂业务场景的分析，应用一定的技术手段，如压力测试、来实现对资源合理扩容、有效规划的过程。

  对于电商而言，一般的核心链路就是交易链路，简易描述就是用户能够成功登陆、然后能通过浏览商品详情页进行下单订购，或者先将意向商品先加入购物车，之后通过购物车进行订购结算，在这期间会进行各种优惠的价格处理、库存判断等，最后还要能够支付成功，这样一个交易支付流程才算完成。

 当然，当大促的峰值时刻时，场景又有可能不同，因为绝大部分用户早已将意向商品加入购物车，且各种优惠券也已经申领成功，就等着那个时刻下单了。

之前进行传统的预测方式一般是在测试环境下，针对场景进行数据模拟，需要开发、测试、运维等人员根据线上的场景，评估可能出现的情况，这种方式更依赖于人的经验。常用的工具包括Apache Benchmark、LoadRunner（收费）、Jmeter等，这种做法非常不准确，很难模拟出接近prod环境的场景和数据。

    现在中大型的互联网公司普遍采用全链路压测的方式，如京东的ForceBot、阿里巴巴的全链路压测平台（其对应的云产品PTS，价格还是蛮贵的）。一般全链路压测平台在接入层的请求入口进行真实流量复制（如网易开源的TCPCopy），这样开源简化模拟数据带来的成本，将复制的请求引入压测环境，对压测环境的服务进行施压。另外若要加大压力，开源通过调节TCPCopy的参数，将流量先蓄积（如通过MQ工具）。在DB一侧通过影子库及影子表进行隔离，影子表和生产表建立相同的表结构，通过打tag进行区分，便于隔离删除。

  一般全链路压测需要注意什么呢？

  1.找到核心流程。做全链路压测还是需要巨大的成本，不可能做全，遵循80/20原则，这是压测的目标

  2.选择隔离方式。一种是进行环境的独立隔离，但资源成本高，另一种是和prod混合，这种方式真实性更高，节省资源，但隔离性不好

  3.缩小依赖服务范围

故障演练

 说起故障，运维们都想起了背锅侠，开发及运维同学都害怕故障，有的公司虽然制定了应对策略，但是这些策略在没有测试的情况下谁也不敢轻易启动，害怕引起更严重的故障。

  XX互联网公司因为网络原因导致大规模故障，中断几个小时，是因为没有灾备吗？可能不太可能。虽然他们做了灾备，但是因为很长时间没有测试过了，所以不敢切换。故障演练正式为了解决“不敢切换”的问题。

  另外不是有了故障演练敢切换，而且还要结合应急预案及应急指挥中心。

  Netflix开源了Chaos Monkey，Chaos Monkey是一个在生产环境随机选择并关闭服务的工具。随后，阿里巴巴也开始进行了故障演练，阿里也有一个故障演练工具，叫：MonkeyKing，为每年的双11 活动做准备，不过现在都基本不维护了，MonkeyKing可以模拟硬件故障、API故障、分布式故障、数据库故障灯

   当然故障演练不仅开源检验业务应用处理失败的能力，也可以用户处理失败的能力，也可以用于当故障发生时，如何快速有效地发现并定位故障，通知相应运维人员进行处理，更重要的是，完善我们的应急预案，避免有类似情况发生。

最后，容量规划及故障演练是一件非常重要的事宜，不是一个人承担，有时需要整个开发团队、运维团队、DBA、测试灯、甚至还有运营团队等一起参与讨论，同时制定应急预案，成立应急指挥中心（例如阿里的全球运行指挥中心GOC）