守株阁

STAR 法则最早用于面试，后来演变为 STARR，最后一个 R 是反思/Reflection。 但 STARR 不仅适用于面试，也适用于工作小结，项目报告等各种场景。 什么是STARR行为面试法？所谓 STARR原则，即 Situation（情景）、Task（任务）、Action（行动）、Result（结果）、Reflection（反思）五个英文单词的首字母组合。 S - Situation - 情景：描述候选人过去经历中某件重要事件背景状况，了解候选人行为背后的动机。我们需要特别关注的是过去行动的背景情况与未来岗位场景之间的相似性。 T - Task - 任务：了解候选人在其背景环境中所执行的任务与角色，从而考察该候选人是否做过其描述的职位及其是否具备该岗位的相应能力。 A - Action - 行动：是考察候选人所担任的角色与执行任务的方式。行动是行为事例（STAR）的核心，因为多个STAR的行为串在一起就能说明候选人是否有某种行为模式。 R - Result -...

修身：以身作则 齐家：relugate 自己的部署 治国：governance 自己的公司 平天下：occupy 占领自己的目标市场 世界上最好的商业模式是，建立一个国家。社会主义和资本主义的区别有很多，其中有一种区别是，不同的治理方式。

为什么要实现插件化架构业务和平台要解耦。业务和平台都是多对多的关系。全链路里既有业务，也有平台。大家应该如何 talk by interface。我们看待复杂组织的业务流程，要线性看，看到很多节点；也要分层看，看到复合的层次。在这种情况下，上层架构域和下层架构域之间怎么实现复杂度的管理？ 如果我们需要构建大规模的泛交易平台，我们需要靠插件化架构把我们的系统组装起来。 插件化架构通常需要一个 runtime 层（或者 boot 层）、core 层。 从业务视角来看，要解决多团队协同的问题因为多个业务域/团队没有把能力用统一的方式透出，所以没有人能够知道统一的技术能力应该怎么串联。进行全链路沟通需要大量的沟通对齐工作。 从业务视角来看，复杂性业务要素包含本业务用例里的各种模型。 从平台视角来看，要解决复杂性管理问题平台要支撑多种业务，业务的复杂性、差异性，以及众多业务需求不确定性，在各平台内部如何管理和支撑？简单的 if-else...

目的 验证故障应急处理能力 验证服务降级及止损能力 验证中间件、存储和服务的稳定性 发现隐患，提升服务可用率 要具备的功能 有环境恢复的能力。 准备演练场景。 感知监控。 权限管理、时间管理。

分类 股票 债券 期权 期指 股票期权 互惠基金 衍生权证 衍生品认识

基础结构LongRangePlan.xmind

前言本书的目的是厘清操作系统的发展脉络。有助于学生了解过去是什么、现在是什么、将来是什么。 无论如何，在试图解决问题时，我们首先要说明最重要的问题是什么。我们在书中明确提出关键问题（crux of the problem），并通过本书其余部分提出的技术、算法和思想来解决。 在许多地方，我们将通过显示一段时间内的行为来解释系统的工作原理。这些时间线（timeline）是理解的本质。例如，从页故障出发，我们可以理解虚拟内存的工作方式。 本书采用最古老的教学方法之一-对话（dialogue）。 我们应当首先呈现抽象，然后介绍具体。抽象是计算机科学各个方面的基础，因此它在操作系统中也是必不可少的。 作业模拟程序具有以下特点，通过提供不同的随机种子，产生近乎无限的问题。 本书使用 xv6 操作系统来编程。 学生很难理解并发问题是如何产生的，也很难理解人们试图解决它的原因。

如何分层按照在线-离线、对时延的要求，可以把数据存储分为： L0：T+0L1：T+0L2：T+1 其中 L1 是 L0 的穿透防御层，但延时会稍微更高。L0 是 10ms 查询层，不是全量数据。L1 是 100ms 查询层，是全量数据，L0 和 L1 都支持轻度分析操作。 L2 是全量数据，可以支持复杂大型查询。 设计 L 的分层要考虑数据的： 是否全量：数据量大小，这要求我们关注我们技术选型的 scale 能力，特别是数据线性增长以后，性能是否线性增长。 是否全维度：这要求我们关注我们技术选型的 schema 建模能力。 延时要求：这要求我们关注我们技术选型的查询执行模型。 查询复杂程度要求：这需要关注我们的技术选型支持的查询语言。 如何迁移数据数据迁移问题 = 制造新从库问题 + 读写切换的问题 寻找一个时间点，使用备份进行冷启动，然后通过类似 binlog 制造新从库的机制进行追踪（对于 update 和 delete，都可以设置简单的幂等机制，insert 的幂等要防异常）。 框架进行数据校验：主键范围查询，md5...

ES 思维导图ElasticSearch总结.xmind ES 的定位 ES 是 build on top of Lucene 建立的可以集群化部署的搜素引擎。 ES 可以是 document store（此处可以理解为文档仓库或者文档存储），可以结构化解决数据仓库存储的问题。在 es 中一切皆对象，使用对象对数据建模可以很好地处理万事万物的关系。 ES 是海量数据的分析工具能够支持：搜索、分析（这一条其实我们很少用到）和实时统计。 ES 的架构有优越的地方： 自己使用 pacifica 协议，写入完成就达成共识。 节点对内对外都可以使用 RESTful API（or json over http）来通信，易于调试。 因为它有很多很好的默认值，api 也是 convention over configuration的，所以开箱即用。 它天生就是分布式的，可以自己管理多节点-它的路由机制是一个方便的，需要优化也可以优化的机制。 ES 的架构ES 是基于 Lucene 的，集群上的每个 node 都有一个 Lucene 的实例。而 Lucene 本身是没有 type...

前言 有意义且具备一致性（coherence）的架构图有助于为不同的利益相关者（stakeholder）澄清（illustrate）事实，并达成共识-反之，图表杂乱无章。 有意义的图表胜过建模（建模指的是With modelling, you're building up a non-visual model of something (e.g. the software architecture of a software system), and then creating different views (e.g. diagrams) on top of that model.），在架构沟通上，visualization 胜过千言万语。 一致性要求我们有足够好的指导原则，让我们知道标准的图元是什么。 “架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。 在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，因为它们是从不同的角度描述问题的。 应该在架构图旁边加上图例（legend），沟通者应该懂得图元（key）是什么。key 和...