延迟是服务器完成请求所花费的时间。关于存储，这是指满足单个存储块的请求所花费的时间。存储块或块存储是将数据存储在卷中的块。纯延迟不受吞吐量影响，但是如果单个块请求很大，则应用延迟可能会随着吞吐量的增加而偏离。
另一方面，电子邮件服务器可能需要大量存储，低延迟和良好的吞吐量，但它可能不需要非常苛刻的IOPS配置文件。并且，存储管理员应该决定应该为哪些存储分配什么资源。因此，在组织中运行着成千上万的服务时，对基础存储的管理超过了人们进行明智更改的能力。而且，这就是AI算法派上用场的地方。
这里的墙不只是组织架构隔阂所带来的障碍，还包括三个领域关注点的不同。比如开发需要关注可测试性和可运维性，这些东西将会深刻地影响应用的架构设计和开发实现，如果开发同学没有充分考虑到代码的可测试性，那么交给测试同学就会造成很大的问题，比如如何实现故障注入和精细流控，这都需要在开发时就考虑清楚。
目前，主流的云计算产商的产品体系也正在迅速地 Serverless 化，这并非是对于未来的预测，而是实际正在发生的事实。下图中的数据是基于对于AWS、微软和阿里云的产品所发布的新功能或者新服务形式的统计，可以看到绝大多数的新服务都在呈现Serverless 化。
然而代码分析往往需要耗费大量的时间和资源，当用户请求某个语法服务（如查看定义），后端需要克隆代码，下载依赖包，解析语法，构建索引（类比一下IntelliJ Idea初始化工程的场景），编辑器场景用户已经习惯于这样的方式，等待几分钟或许问题不大。
每次分支索引构建成功，我们都会在数据库中记录分支对应的版本号，当该分支有了一次新的提交后，在生成lsif.json后，系统会比较两个分支的Diff，获取到变更文件和变更类型，通过变更文件来进一步提取索引受到影响的文件（引用或定义的坐标信息变更），分析出所有受影响的文件和对应的ES增删操作后，完成增量索引上传。这个增量的过程平均能减少45%的分支构建时间。
接触更多的人和事，用新方法解决新问题。这个很关键。不能只看代码看一个月，要找真实的业务方，你的上游，你的下游，你的合作伙伴。比如说做双11，我是2016年12月份到业务平台，我花了整整三个月，跟每年双11的大队长、重要人去聊双11。
要将技术的先进性转化为业务的先进性，忘掉屁股。这个“忘掉屁股”就是你做很多事情不是你一个人能搞定的，复杂、越大的事情是要协同更多的人。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
在 XA 协议的设计中，有两种角色：
• 事务管理器（Transaction Manager，TM）：负责发起事务的提交，失败时处理事务异常，在 PolarDB-X 中这个角色由计算节点（CN） 承担
