Learn and share.
快速成长的必备软技能05————换位
我们经常听说，换位思考是一种必要的能力，这件事情说难很难，说容易也很容易。
说这个难，是因为大家一开始尝试换位的时候，经常会变成“如果我是XX，在这个情况下，会做什么”，类似情况包括：
假设我是张三，站在我的立场，知道我的想法，我会怎么想
假设我是张三，站在张三的立场，知道我的想法，我会怎么想
假设我是张三，站在张三的立场，知道我的想法，张三会怎么想
当初步学会这个技能之后，一般能做到
假设我是张三，站在张三的立场，知道我的部分想法（张三知道以及能明确推断出的想法），张三会怎么想
为何要如此呢？
因为不同的人，在相同的事件背景下，面临相同的选项，会做出不同的选择
还有很多时候
不同的人，在相同的事件背景下，面临的选项都是不同的
在换位之后，就可以开始找出大家之间合作的关键点，做好冲突预案，把控事件走向，取得想要的结果
快速成长的必备软技能04————兼听
兼听和我们之前说到的“偷师”有些类似，但兼听重在获取信息：
1、政策信息
2、行业信息
3、公司信息
4、部门信息
等等等等
另一方面，兼听要求大家具备整合这些能力的信息
把信息按要求汇总=》对信息分类整理=》得到对自己有用的答案
其实大家可以考虑这样一个场景：
场景一：大学报志愿
大多数的高中生报志愿的时候，是不知道一个专业要做什么的
但有少部分的高中生，对自己感兴趣的专业却很清楚，甚至提前学习了部分专业课
场景二：留学
有些同学一直到大四，都不知道留学意味着什么，不知道什么流程，不知道该去哪里，不知道如何申请学校
而有些同学，对这些事情十分清楚，可以知道留学能给自己带来什么，很清楚自己要选哪个学校
场景三：工作
有些同学，研究生毕业，都不知道自己专业，有哪些顶级公司，一脸茫然
有些同学，大一大二，就已经通过师哥师姐，到业内顶级公司实习，毕业时去向明确
嗯，长此以往，谁更能把握机会，两类人之间，会有差距吗？
快速成长的必备软技能03————预演
说完复盘，就要说到另外一个技能，预演
复盘是在一个事情完成后，总结提升
预演则想法，是预计某个事情在未来发生，要在心理上、知识上、逻辑上做好应对
很多成功人士，都有预演的习惯
对于普通人，也是如此。尤其是重大事项，会思前想后，考虑各种可能。
但职业人士会有不同，他们会把预演训练成一种习惯。
对任何事情，都会不由的把几种可能都思考一下，然后想想如何应对
于是，我们在职场上，总会遇到这样的人：
任何问题，都能快速应对，就像他都提前考虑过一样
并不是这些人智商比别人高多少，而是他们把很多情况，都提前考虑过了，遇到时自然会有应对
这个技能，在一开始的时候，会很艰难，就像准备一场激烈的辩论赛
但养成习惯后，就会成为一种被动技能，不会有什么明显消耗
快速成长的必备软技能02————复盘
在我们的职业生涯中，有一个特别重要，但又特别不被重视的技能：复盘
其实大家上中小学的时候，很多人都会又一个错题本，时不时拿出来看看，这就是最简单的复盘
但工作之后，很多人反而不喜欢总结和复盘，让同样的错误发生了一次又一次，付出了各种各样的代价
其实复盘只是一种习惯，养成这个习惯后，并不需要付出太多额外精力
我有一位朋友，他就习惯于每天晚上洗澡时，把一天经历的事情快速过一遍，总结经验教训，最后个人提升很快
对个人来说复盘很重要，对组织来说更是如此
一个项目，无论好坏，最好都能定期复盘一下，好的经验可以推广，坏的教训需要防止再次发生。
这样把一个项目的经验，变成整个组织的经验，组织也就成长起来了。
快速成长的必备软技能01————偷师
【最近偶然翻到了多年前做的一些笔记，稍微整理一下，做个小专题，希望对大家有所帮助】
在职场中，我们经常能观察到一个奇怪的现象。
两位岗位相同、职级相同、绩效差不多、在公司年资相同的同事，入职一段时间后，会走向两个极端：
一个极端是，除了自己做的事情，什么都不清楚，我们叫他“常专注”
一个极端是，除了自己做的事情，同组人做什么都很清楚，部门工作重点也很明白，甚至其他部门在推进什么也有了解，我们叫他“包打听”
其他人，多在这两个极端中间，而技术背景出身的人，多数都更像“常专注”
这两类人，都很努力的话，在自己岗位职责内，绩效会差不多。
但如果让他们去负责新的项目、调整去新的领域、去做一件没做个的事情，两个人对新环境的适应能力会千差万别。
每当遇到“常专注”这类人，安排一些新工作，他往往两眼一黑，这个我找谁，流程是啥，咋开始，我没做过不会啊。
总会记起一个故事：
钱师傅是远近闻名的大厨，小张和小王去拜师学艺。
由于是新学徒，在后厨，两人做的都是洗菜、切菜、打扫卫生等体力活。
一年后的某天，特别忙。钱师傅让年纪稍长的小张做几个菜，给酒楼的伙计们做晚饭。
小张一脸懵逼，我只是洗菜切菜，如何做菜师傅您没教过啊。
钱师傅说，这一年，你没注意看各位大厨是如何做菜的吗？你这学艺，成了做苦工，白白荒废了一年时间
小王不同，做完了日常的工作，就去观察别人怎么做菜，甚至还偷偷练过。
钱师傅于是让小王给大家做晚饭。
小王上手，就做了一桌菜，师傅让大家来点评，各位大厨也给出了中肯的建议。
最终结局，比较俗套啦，小王得到了大家的认可，传承了钱师傅的衣钵。继承了酒楼。
近期遇到一些技术问题，记录如下：
1、NAS引起的惨案一
上次说到，大家都在降本，于是我们做了一系列调整工作。但降本总有一个永恒不变的主题：降配。
于是我们和集团的科技，同时开始了惨无人道的降配工作。
在一顿神奇操作后，系统终于区域稳定，好景不长，突然间又出问题了。
表现：
系统部分服务的部分节点，在服务高峰期之后，总是会出现时不时的系统卡顿。
关键这个卡顿很有规律，总是上午10点，下午4点出现，完美错过我们的上下午业务高峰。
原因：
经过技术委员会小伙伴通力排查，大家最终定位到是应用日志写入到归档NAS时，NAS性能十分不稳定，IO时间有时会高达几秒。
一旦遇到NAS卡顿，会阻塞日志，进而阻塞服务。
而且，当前NAS是和兄弟公司公用的，NAS卡顿时，正值他们的业务高峰期。
解决：
应用日志不再输出到NAS，而是输出到日志云。
2、NAS引起的惨案二
平稳度过了几天，周五，问题又来了。
表现：
系统时不时卡顿，没有任何规律，和业务高峰没有任何关系，一切监控都正常。
原因：
经过N个小时排查，我们的小伙伴，终于发现问题还是出现在日志上，只不过这一次，是GC日志。
GC日志同样是在归档NAS上，此时归档NAS更加不稳定，minor gc日志写入，偶尔会遇到NAS IO延时，引起系统卡顿。
解决：
应用日志不再输出到归档NAS，而是输出到中端闪存NAS，花钱买平安。
进一步：
针对当前遇到的情况，重新制定日志规范，尽快推广落地。
3、一次RefreshScope引发的惨案
表现：
使用nacos动态刷新了一个配置，但相关服务突然越来越慢，并有大量的锁等待：sun.misc.Unsafe.park
原因：
初步分析，nacos更新配置后，对应RefreshScope的类需要重新加载配置，从而调用了GenericScope类的destroy方法，在该方法中加了writelock
同时，业务代码在处理请求的时候，同样的用到了GenericScope::LockedScopedProxyFactoryBean的invoke方法，在该方法中加了readlock
先是读锁（多个），再写锁（一个），再读锁（多个），最后死锁了，都无法获取锁，服务就卡住了。问题是，一开始的锁为何不释放呢？
进一步分析，发现是在服务业务代码中，用到了HttpClient的org.apache.http.impl.io.SessionInputBufferImpl.streamRead方法
该方法调用了java.net.SocketInputStream.socketRead，该方法触发了jdk8的一个bug，该native方法无法返回
解决：
升级JDK版本，同时代码改造缩小RefreshScope的范围
4、一次redis引发的惨案
表现：
几分钟内redis内存飙高，直接爆掉。
查看了业务系统日志，没有出现业务激增的情况。
查看redis日志，发现AOF日志不断增大，重写的时候缓存爆掉，导致主备切换。
监控日志反馈存在大量setex操作。
原因：
reids集群出现大量setex操作，导致AOF日志激增，日志重写时落盘速度缓慢（出现了short write），结果AOF日志缓存爆掉，主从切换
解决：
临时升级了内存，后续将日志盘从NAS改为SSD，并好服务的redis主从切换配置
但setex激增的原因暂时还没有查到，补充了一些防御性代码
5、一次jdk引发的惨案
表现：
一个生成表单PDF的微服务会产生大量的临时文件，而且不会自行清理。
原因：
在用到的一个第三方Jar包中，用到了java.awt.Font类，该类用到了createFont方法
//不会产生大量临时文件 static Font createFont(int fontFormat, File fontFile) //会产生大量临时文件，初步判断是JDK的问题 static Font createFont(int fontFormat, InputStream fontStream)
解决：
重写了改Jar包的类，从InputStream切换到了File
6、一次防火墙引发的惨案
表现：
部分用户反馈，无法正常加载微信小程序，需要点击右上角进行刷新才行
原因：
从腾讯后台可以看到，有大约18%的请求会超过60S，其余正常
然后到微服务层，发现有一些请求，在返回数据包的时候，会收到“连结已断开”的反馈，与腾讯后台表现较为一致
然后向前一点儿一点儿的捋，最后发现，需要访问的腾讯IP有5个，之前开墙只开了4个，第5个IP数据返回时就被防火墙直接拦截了。
解决：
提单，开墙，解决问题
在各项目组努力下，终于达成了几个目标：
1、springboot升级到2.x
2、干掉了老技术中台，全部系统对接到新技术中台，实现了技术中台统一
3、填了一波史前巨坑
今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及，实现动态扩缩容
4、日常，继续填历史的技术坑
1、redis调优
数据流：
数据库查询结果-》缓存到redis-》缓存使用者
表现：
bigkey一大堆，单个key存放数据3M多（你咋不把整个JVM塞到redis里去呢），redis服务器所需内存、带宽都特别高
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、改变序列化方式，从jvm序列化，调整为protobuff，调整后，带宽瞬间大幅下降
b、减少序列化的数据内容，只保存真正需要的，调整后，redis内存大幅下架，带宽大幅下降
c、对redis进行拆分，将一个大redis，按领域拆分为多个小redis，性能提升明显
d、对于热数据不明显的低频访问场景，不缓存到redis，大家慢慢优化去吧
2、网关调优
数据流：
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现：
外网网关和内网网关功能一样，而且逻辑超级复杂，性能垃圾的一塌糊涂
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升
3、数据流优化
数据流（大幅简化后）：
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现：
业务逻辑分散到各业务系统，数据来回传递多次，多个系统加工同一批数据，一旦出问题，要多个系统联查，花费很长时间才能定位到问题
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰，用户自己都能初步定位到问题
4、数据修改请求超级多
数据流：
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现：
数据质量差，任务都给到了IT，管理方没有管理动力，数据质量持续差，修改量逐年上升
原因：
分析后发现，各业务条线管控要求很多，不放权，与各地执行机构有轻度脱节
数据生产者，不承担数据质量差的职责，没有提升数据质量动力
总部管理部门，不承担数据质量差的职责，不清楚数据质量哪里差，没有工作重点
解决：
a、分析数据修改工单，归纳前几类修改请求
b、与业务方沟通，对分支机构可以修改的数据，将功能开放给各分支结构，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
c、对于分支结构不可以修改的，开放数据修改功能给总部管理部门，进行统一管控，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升，工单量大幅下降
5、降本
数据流：
应集团要求，降本压力巨大，科技承接了600万降本指标
表现：
科技方压力山大
原因：
一开始几年，没有这么大的压力，大家手都比较松，各条线都存在较大浪费，科技也是如此
最近几年，都是在之前资源上，不断的挤压资源，来满足每年业务快速增长的需要
今年，一方面业务继续快速增加，另一方面要大幅降本，压力山大
解决：
a、第一轮，运维小伙伴拉流量，无流量服务应关尽关，应下尽下，应合尽合
b、第二轮，运维小伙伴拉各类峰值，先统一砍一刀（网络、数据库、主机）
c、第三轮，运维小伙伴看账单，按账单大头，如网络、数据库、主机等逐条应用降本方案
d、第四轮，运维小伙伴看账单，对于不合理的条目逐条检视，逐个逐个扣
e、第五轮，各项目组，结合业务实际情况，各自制定降本方案，限时落地
f、第六轮，技术委员会，对于20%的关键业务进行性能优化，逐步降本
g、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本
1、更换服务器后，出现网络风暴
表现：
老服务器下架，新服务器上线后，出现网络风暴
原因：
逐步排查网口，猜测一根光纤出现问题
解决：
更换了一根光纤
2、老服务器下架后，新服务器重启后，VM集群无法启动
表现：
三台ESXI主机组了VSAN，重启后，网络互通，但服务器2被独立，无法加入1、3集群
VCSA也在VSAN上，同样无法启动。
原因：
故障时，只知道出现了脑裂，三台主机无法
解决：
重启了VPXA、重启了ESXI，没有解决问题
重建VSAN，然后把三个节点加入，问题就修复了
后续发现，其实时服务器1和服务器3出现了问题，自己组成了一个新的集群
近期遇到一些技术问题，记录如下：
1、kafka并发处理量上不去
数据流：
数据生产服务-》kafka-》数据消费服务
表现：
数据消费服务加了很多个实例，但总感觉多数实例不工作
原因：
分析后发现，原来开发小伙伴把所有消息都扔到了同一个topic中，而分区只有3，消费者再多这并发量也上不去啊
解决：
按不同业务，拆分topic，同时增加分区数
同时，建议把一堆操作拆分为多个步骤进行，不要都放到一个方法里全部做掉，宁可多流转几次各司其职
2、数据上报并发处理量上不去
数据流：
DB-》轮询-》HTTP提交数据到数据上报网站【ZF】
表现：
要求4小时上传60W，实际1小时上传5K
原因：
问题很多，主要有两个，一是每次只上传一条数据，二是没有做并发
解决：
一开始准备做很大的调整，但后面项目组怕把开并发把数据上报网站压挂，最后没敢使用
最后，只是改造为批量上传数据，轮询时根据id做了一下简单的并发
数据上报网站，各地接口及要求各不一样，也是各种不容易吧
3、莫名奇妙的403
数据流：
浏览器-》网关-》鉴权服务
表现：
网关偶尔返回403
原因：
一开始日志输出太少，都没有定位到哪里的问题，只能临时在网关补充了一些日志【建议加了开关，定位问题后关闭】
加日志后，发现是一段上古代码，使用信号量进行了并发控制，超出了并发就获取不到用户权限。
而这个Bug暴漏出来，据反馈，居然是升级组件导致的。
遗留系统都是坑啊。
解决：
优化鉴权服务，定位到问题，问题也就解决了
4、无法提升的微服务性能
数据流：
浏览器-》网关-》N个服务来回调用
表现：
服务性能差，有时要几十秒才返回，一堆告警邮件
原因：
微服务拆分粒度太细，形成环状调用链路
开发同学无脑调用微服务，能调用一次的，居然会循环调用N次
解决：
重构，按业务领域合并微服务，微服务数量少了60%，同时干掉环状调用链
评审，找到不合理的循环调用，抓典型，整改
5、批量导出
数据流：
浏览器-》网关-》导出服务-》DB
表现：
批量查询、批量导出性能很差，要按分钟返回的，一堆告警邮件
原因：
数据量太大，DB拉取速度慢，数据回传也慢
解决：
根据业务情况，部分批量查询功能改到只读库查询，大批量导出功能迁移到了数据中台
6、数据批量下发
数据流：
数据中台-》kafka-》数据下发接收服务
表现：
数据中台下发数据，无法更新到下游业务系统
原因：
因安全需求，上游业务系统批量刷新数据库，导致数据中台下发大量数据，数据下发服务处理不及时，积累了大量数据待处理
下游业务系统把一堆业务逻辑放到了接收服务中，处理单条业务数据要按秒计算，数据越积越多
你没想错，kafka并发上不去，和之前原因一样一样的
解决：
接收服务简化，拆分不必要的业务逻辑，服务性能提高了几百倍
优化kafka配置
制定了批量刷新数据库的相关流程，都是泪
历史数据咋处理？和上游系统沟通后，99.9%的数据不必处理，于是忽略了历史积累数据，晚上将0.1%的数据进行了重推，解决了问题
7、Kafka卡顿
数据流：
系统A-》kafka-》系统B
表现：
kafka在半夜性能下降明显，从日志上看，就是工作2分钟，卡5分钟
原因：
kafka的消费者每次取了太多消息去消费，半夜为业务高峰期，部分消费者获取消息无法及时处理完毕，导致kafka会出发rebalance，你懂的
解决：
每次少取一些数据
8、HTTPS通讯失败
数据流：
前置系统A-》云-》云上系统B
表现：
有两家用户的数据无法连通云服务，HTTPS通讯失败
原因：
前置服务的服务器器时间错误，数据包被云的安全策略直接丢弃，被当成重放攻击了
解决：
开启前置服务自动时间同步服务
9、组件升级导致服务性能下降
表现：
系统组件升级后，系统整体服务性能下降，会有部分请求阻塞5S以上
CPU、内存、IO看起来都比较正常
生产环境才有问题，测试环境下无法复现
原因：
通过打印线程信息，发现存在大量网络IO阻塞
后定位到了一个可疑的点，日志同时输出到log文件和命令行时，命令行也发送到了log文件，会有阻塞
解决：
只输出到命令行，有待观察
整体经验：
1、微服务粒度不能太细，也不能一个服务啥都干，最好按业务领域进行拆分。业务量小的领域可以适当合并，业务逻辑复杂的考虑拆分。
2、微服务也应该分层次，不要出现环状调用链路
3、日志要足够判断问题所在，太多影响性能，太少没啥用
4、中间件不能熟练配置，不要随便上生产
5、批量操作要用特殊处理方式，没事别刷库
今年个保法发布了，根据安全团队要求，需要对数据库的敏感字段进行加密处理。
当前数据库连接已经加密了，只需要对数据加密。有两种代价较小的方式：
1、在数据库存储引擎层面加密，这样对全部业务系统是无感的。
2、退而求其次，可以在数据库中间件或在驱动层面做加密，这样全部业务系统修改量也是比较小的。
但由于种种原因，这两种方式都没有能推行。
最后采用的方式是，安全团队提供加解密SDK，各业务系统对接。
业务系统启动，通过加解密SDK从密钥分发服务器获取密钥-》写入数据库前加密、读取数据后解密
加密算法都是国密算法，包括对称加密及摘要算法。
这样全部业务系统都需要改造，而且批量操作效率也比较低。
优点是，即使别人攻破数据库，也拿不到明文数据。
改造过程也很痛苦：
1、注册APP ID，申请密钥
2、研发刷库工具
3、在数据库表中增加加密字段，通过刷库工具，将历史敏感数据进行加密，存放到加密字段
4、基于加解密SDK，研发适用于个团队的切面SDK
5、使用切面SDK，对服务进行改造，读明文，写明文+密文（可跳过）
6、使用切面SDK，对服务进行改造，读密文，写明文+密文（可跳过）
7、使用切面SDK，对服务进行改造，读密文，写密文（可跳过）
8、删除明文字段
整个过程十分痛苦。
稳定性保障：
整个密钥下发服务器，是全局的一个大故障点，必须保障可用性。
密钥分发服务器，用到了密码机，提供了同城容灾及异地容灾环境。
支持DC单独部署，也支持云访问。
对应用系统影响：
1、改造量大，且无直接业务收益，资源投入受限
2、性能下降，尤其是批量加解密时，性能下降较多
3、模糊查询受影响较大，只能通过提前计算的摘要信息进行查询了
4、遗留系统、外购系统，改造难度太大，成本太高，无法承受
对数据中台的冲击：
所有依赖于数据库日志的系统，都会受到影响，尤其是数据中台
有两种方式，一是不使用，二是用同样的key