IPv6 问题
背景
IPv4 地址枯竭
5G、IOT、SDN/NFV、云计算、边缘计算等新兴技术兴起，需要地址的终端设备变多。
NAT 技术无法支持新兴技术。
各大互联网公（国外的Google、AWS、Apple，国内的阿里、滴滴等公司）司要定期推动本公司业务的 ipv6 技术改造，网信办会定期检查，不达标的公司要问责。
改造要点因为IP地址长度从32位变为128，文本格式从十进制数字变为十六进制（见附录1），为支持两种IP地址，包括但不限于以下改造要点:
客户端（手机APP和浏览器）缓存用户IP
后端服务根据IP做判断的业务逻辑， 比如set化、小流量。
用户IP归属地查询。
用户IP白名单、黑名单。
风控使用到IP段的策略。
存储用户IP到DB或者缓存
IPv4是32位，可以转成int或者long来存储。
IPv6是128位，不能使用long或者bigint来计算存储。
在服务接口之间传递用户IP
内网之间传递，典型的是支付、风控等。
外网之间传递，如第三方微信支付等。
日志处理
后端日志落地为IPv6后，是否有通过日志内容处理的业务逻辑。
依赖nginx日志中的 ...
亚马逊工作方法
一、亚马逊14条领导力原则我们的领导力准则不仅仅是非常鼓舞人心的墙帷。这些准则十分有效，就像我们努力工作所取得的成果一样。无论是在讨论新项目的创意、决定应对客户问题的最佳解决方案，还是对求职者进行面试，亚马逊人每天都在使用这些准则。这是令亚马逊独具特色的一个重要因素。
顾客至尚（Customer Obsession）领导者从客户入手，再反向推动工作。他们努力地工作以赢得并维系客户对他们的信任。虽然领导者会关注竞争对手，但是他们更关注客户。
主人翁精神（Ownership）领导者是主人翁。他们会从长远考虑，不会为了短期业绩而牺牲长期价值。他们不仅仅代表自己的团队，而且代表整个公司行事。他们绝不会说“那不是我的工作”。
创新简化（Invent and Simplify）领导者期望并要求自己的团队进行创新和发明，并始终寻求使工作简化的方法。他们了解外界动态，从各处寻找新的创意，并且不局限于“非我发明”的观念。 当我们开展新事物时，我们要接受被长期误解的可能。
决策正确（Are Right, A Lot）领导者在大多数情况下都能做出正确的决定。他们拥有卓越的业务判断能力和敏锐的直觉。
...
微服务相关文献
《提升团队的微服务落地能力》
滚动重启、金丝雀发布、AB testing 和蓝绿部署
本文讨论发布周期（release cycles）里 deployment strategy 的问题，抛开大规模部署的 big bang deployment。
滚动重启、金丝雀发布、AB testing在 martin fowler 的博客里，金丝雀发布和滚动重启和 AB testing 并没有本质区别，都是 phased approach或者 incremental approach，是 ParallelChange 思想的实践。
当我们拥有一个新版本时：
滚动重启（rolling restart）rolling restart 会让新旧版本在环境里长时间共存，逐一使节点部署新版本，这样易于发现问题和回滚。
金丝雀发布（canary release）而金丝雀发布同样允许新旧版本长时间共存，在逐一部署新节点的前提下，逐步利用 LB 之类的基础设施来切分用户，其策略还可以细分为：
先不给新版本，在无流量的情况下在生产环境验证 - 很多大厂的实现都忽略了这点。
尽量让内部用户先使用 - FB 之类的大厂的员工都非常多，使用一个特性开关（名字很多，比如 feature bits, flags ...
部署环境
列举环境根据 wikipedia，工业界总是把开发环境和生产环境分离出来，中间还有若干个 stages。
结构化的发布管理允许分阶段部署（rollout），测试和在遇到问题时回滚（rollback）。
常见的环境有：
4-tier architecture is development, testing, model, production (DEV, TEST, MODL, PROD),
Quality Control (QC), for acceptance testing; sandbox or experimental (EXP)
Another common architecture is development, testing, acceptance and production (DTAP)
Development构造对软件的变动的环境，大多数情况下仅仅是开发者的工作站（workstation）。在这个环境里实验变更和进行单元测试。集成环境有时候也可以被认为是开发环境，在集成环境里专门对 repo 里的源代码 copy 进行构建和单元测试。
Testing执行 ...
CI/CD 方法论
CI/CD 的重要性Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。”
持续集成和持续交付作为敏捷开发的一种最佳实践，通过包括构建、部署、测试、发布流程的自动化，实现质量内建，让质量问题可以快速发现和消除，从而提升软件交付的质量和效率。
基本策略分支模型是CICD落地的源头，研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。
首先划分环境。
划分环境后设计分支，注重开发和发布两个场景。
根据分支设计流水线，验证应该发生在全流水线里。
一般的分支模型
参考文献：《在阿里，我们如何管理代码分支？》《What is Trunk-Based Development?》《提升团队的微服务落地能力》
如何做全链路压测
性能测试压测问题.xmind
性能测试的必要性
营销活动周期首先引入一个营销活动周期的概念，它是一个闭环流程：
PS：1和2之间再加一个步骤。环境改造和基础数据准备。强调必须在生产环境。
压测环境准备：需要复用真实的线上环境，压测结果和问题暴露才都是最真实情况。可通过压测流量全局识别、透传（数据进入影子区域）。
基础数据准备：以电商场景为例，构造满足大促场景的核心基础相关数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤、脱敏，并保持同等量级。
阿里实际上是 2013 年才开始做全链路压测的，现在的压测周期更加智能化。可以在白天由几个人值守进行，包含以下活动：
压测环境改造整个阿里经济体的压测环境，包括双十一压测，全部选择的是线上环境，此时需要评估：
如果要进行全链路压测，是否直接可以使用现有环境。
同一个API多次压测是否会被拦截-容易被忽略。
是否会有脏数据影响、如果有影响应该如何改造避免-必须进行的改造项目：1 识别+ 透传流量标，2 构造影子数据区域。
以上这些问题总结下来即为两类问题：业务问题和数据传递问题。问题比较明确，我们就根据这两类问题来做逐 ...
Redis 笔记之十一-集群 Cluster
背景在 Redis Cluster 方案诞生以前，在 Redis 集群遇到单机资源和流量瓶颈时，有两种常见分布式解决方案：
客户端方案：需要自己处理分区逻辑、路由、故障转移（有时候 Routing、LB 和 Failover是同一个问题，都需要通过 routing 技术来切换流量的 endpoint）。
代理方案：减轻了客户端的职责和压力，架构上的负担过重。
Redis Cluster 的出现，极大地降低了架构师的负担，解放了生产力。
数据分布数据分布理论
分区方式
特点
代表产品
取舍逻辑
哈希分区
离散度好 数据分布业务无关 无法顺序访问
KV型 Redis Cluster Cassandra Dynamo Elastic Search
如果需要平衡地存储大量数据而只有随机访问其中的若干条，则可以使用简单的哈希分区
顺序分区
离散度易倾斜 数据分布业务相关 可顺序访问
表型 Bigtable HBase Hypertable
如果需要存储大量数据且需要支持区间查找，则也需要使用简单的顺序分区，如果要解决负载均衡的问题可能需要不均匀分片以及分裂和压缩算法的支持
...
保险专业基本功
保险行业市场参与者
直保公司（也就是常见的保险公司），如泰康人寿、平安财险。
保险中介（帮直保公司卖保险的机构），如携程保代、慧择经纪、XX银行分行兼业代理。
再保险公司（直保公司将无法独自分摊的风险进行再分摊），如瑞士再保险，中国再保险。
保险公估（帮助保险公司理赔的专业公司），如泛华公估、民太安公估。
保险资管公司（帮助保险公司进行资产管理的公司），如中国人保资产管理。
类目的区别财产险：经营跟财产损失有关的业务，主要是车险。
寿险：经营与人身损失有关的业务，主要是重疾险、健康险及寿险等。
财产险公司及寿险公司均可经营一年期及更短保障期限的健康险及意外险业务，这就是为什么百万医疗虽然是人身相关的保险，但是最早研发推出的是众安在线（一家财产险公司），而支付宝的好医保·长期医疗6年期百万医疗只能由人保健康这类人寿险公司推出。
互联网保险的模式什么是场景保险模式依靠场景销售保险产品，可以是传统的保险产品定制也可以是全新设计的保险产品。
a) 传统的保险产品定制：以携程为代表，机票搭售航意险，以变现为导向。
b) 全新设计的保险产品：以“准时宝”、“退回运费险”为代表，针对互联网场景特 ...
Redis 笔记之十-哨兵 Sentinel
Redis 有若干套高可用实现方案。2.8 开始提供哨兵功能（不要使用更低版本的哨兵，可能有 bug）。
基本概念
主从复制模式的问题Redis 天然就带有主从复制的功能，但主从复制有若干缺点：
需要手工干预，缺乏自动 FO 机制-分布式高可用问题。
单机的写能力有限-分布式容量问题。
单机的存储能力有限-分布式容量问题。
一个经典的高可用场景当一个主从集群的 主节点 失效的时候，经典的恢复步骤如下：
主节点失效。
选出新的从节点，slaveof no one。
先更新应用方的连接。
再让其他从节点换主。
再把恢复好的主节点作为新的从节点复制新的主节点。
3 和 4 的步骤可以互换。这种需要手工介入的运行机制不能被当作高可用的。而 sentinel 的作用是把这些经典步骤从手工实现为自动。
Sentinel 的高可用性Sentinel 方案是在原生的 Master-Slave 集群之外加上一个 Sentinel 集群。
每个 Sentinel 节点会监控其他 Sentinel 节点和所有 Redis 节点。任何一个不可达的节点，它都会将其做下线标识。
如果标识的是主节点，它还会 ...
