应急预案，是指在系统出现故障时，为了保障核心业务能够持续可用，而提前准备的指导手册。这个手册可以用来告诉我们：在遇到什么样的问题后，做什么样的操作能最大化地降低对业务的影响，将被动响应变为主动防御。
故障也有积极意义 在复杂系统中，故障是必然的，无法彻底避免。从定性的角度来看，并非所有的故障都是坏事，有些故障是有正面意义的，比如说通过一个线上的小故障发现了一个大隐患，或者是某次故障中相关人员的意识和应急预案都很到位，但是由于故障的原因非常特殊最后仍然造成了较大的影响等等，类似这样的故障都要找出其中的亮点。 所以，我们要用辩证的眼光去看待，避免大家“闻故障色变“。为了往这方面引导，我们在规章制度方面也做了很多设定，因此在我们的故障管理制度上，我们也是鼓励快速恢复(对于快速恢复的故障定级比较低)、鼓励通过演练发现更多的线上问题(对于由于演练导致的故障有一定的豁免权)等等。但是，大家也应该充分意识到我们对故障的理念：即偶尔的系统失效是可以容忍的，人为的犯错是要严肃对待的，比如说不符合高可用规范的系统设计模式、强弱依赖设计不合理、由于人员意识不到位带来的故障处理时间较长、值班人员未及时接通oncall、由于对线上系统不够重视带来的变更隐患、不遵守变更三板斧规范等等。
负载均衡是分布式系统里最常用的能力，实现方式有很多，轮询、随机、加权轮询、一致性hash等文章很多，今天要讲的是遇到的一个真实的生产问题。 公司内部的ES访问架构一般是，Java应用--->SLB(域名)---->ES ingest node (no data) --> ES data node，其中ingest节点是对外暴露的，供Java应用访问，承担了一个纯client角色，不提供数据存储和倒排索引检索服务。这其中SLB是为了方便起到一个域名和负载均衡的功能，绑定后端的n个client节点，并且做到对业务透明，但是毕竟还是有开销的，多了一次网络rpc的转发(尽管很快)，同时也是多花了一份钱。所以在930的时候我们把SLB去掉了，并且进行了验证完全没有问题，这其中还要得益于es本身就支持ip配置列表，并且自身实现了负载均衡的功能。 更改之后的访问链路，Java应用--->ES ingest node -->ES data node。
哈啰好物商城中，存在大量的长列表数据，例如下图列出的商品瀑布流、特卖会场列表等。用户滑动到页面底部，则加载新的数据进来，页面上的DOM节点越来越多，容易导致页面卡顿，交互不流畅。针对这种长列表的场景，我们可以采用虚拟列表来做优化。
调度是将稀缺资源分配到一定时间内的不同任务上的决策过程，目的是优化一个或多个目标。两轮车调度场景是指通过预测未来用户的骑行需求，决定各站点车辆的调配任务，并将这些任务分配给合适的运维人员来执行，从而满足用户的骑行需求。在这个调度场景里会涉及三个对象，一是车辆，目标是用户需求满足率高，移车成本低，车辆翻台高。二是运维，目标是运维效率高，运维人员体验好。三是用户，目标是用户体验好。
中台化建设不是简单的技术建设，整个运营、产品、技术团队的组织架构划分都会影响中台化建设。中台化建设最重要的是实现能力的灵活复用和扩展的成本最小化。由此会带来的中台臃肿导致的稳定性问题，环境资源竞争问题会在中台化建设中凸显。
在 html5 提供的video组件实现上采用了Shadow DOM技术，Shadow DOM 技术是Web Components 核心套件之一，还有像input、select 也都采用了这个技术，具体什么是Shadow DOM 会在下文中给出解释。
随着公司业务快速发展，数据库中数据量猛增，访问性能变慢。关系型数据库本身比较容易成为系统瓶颈、单机存储容量、连接数、处理能力有限。当单表的数据量达到1000W或100G以后，由于查询纬度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。 方案一：通过提升硬件来提高数据处理能力，比如增加存储容量、CPU等，这种方案成本较高，并且瓶颈在数据库服务本身，通过提高硬件得到的提升有限; 方案二：分库分表，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。
