Learn and share.
快速成长的必备软技能08————完成
中国有一句话，叫做完事开头难，所以国人都喜欢开启新任务，喜欢多任务并行
但其实，在当下环境中，能够优雅的完成和结束一个任务，却是一个收益更高的技能
有时候，完成一件事情，比同时开始十件事要更有价值
比如，
张三同学能力强，积极性高，受到重视，同时参加了5个项目，齐头并进
每个项目都很紧急，张三如果在这5个项目均匀用力，就会发现，每个项目都会开始对他不满
因为他成为了项目最大的“堵点”
还不如，
张三在这5个项目中，选择最多2个最有价值，时间精力还能兼顾的项目
先把精力投在第一个项目中，完成这个项目相关任务，余力再投入第二个项目
当第一个项目完成时，再去选择新的高价值项目参与
最后每个项目都能按时交付，每个团队对他评价都会很不错
没有“完成”意识的人，有时候很努力，评价却不高，贪多嚼不烂
有“完成”意识的人，同时参加的项目并不多，但善于选择有价值的项目，不断去完成，反而可以在多个项目中，反复横跳，获取更高收益
当然了，我们说的完成，是要保质保量的，按时完成。
快速成长的必备软技能07————多维
如果问一位开发人员，你5年后、10年后想做什么呢？
我听到最多的答案：架构师、资深开发
嗯，这是个不错的想法。
但大家有没有想过，100位开发，最终能产生多少专职架构师呢？
又有没有想过，在国内，有多少开发人员，可以一直靠写代码吃饭到50甚至60呢？
乐观一些，百不存一
确实很残酷，很少有技术人员，能单纯靠写代码，可以获得一个长期的好的发展，至少当前国内很难
那大家是如何做的呢？
答案是：多维度发展
以开发人员为例，可以走“编程+X”的路线
编程+业务
编程+管理
编程+产品
编程+测试
编程+安全
编程+运维
编程+项管
编程+XXX
当这些能力组合起来，就会发现，可以步入一个或多个新的领域
如果再扩展维度呢
编程+业务+管理
编程+业务+产品
编程+安全+测试
又会组合出很多新的领域
这样，根据自己的实际情况，有计划的增加新的维度，加强优势维度，一个人未来的职业路线就越来越宽了
快速成长的必备软技能06————算账
在职场上，很多时候，大家都在算账，但名称各异：有时叫个人成长、有时叫团队贡献、有时叫项目投产、有时叫产品毛利
很多人都有日常记账的习惯，甚至会记录到每顿饭花了多少钱。
但很多人并不会为自己的职业生涯记账，当然这个记账指的并非是你今年赚了多少钱。
我有一个习惯，就是每个季度，都会算一次账：
1、我成长了吗？哪些地方进步了，哪些地方要改进
2、我为公司和团队创造了什么价值，有没有把成本赚回来
3、我管理的部门和团队，创造了什么价值，有没有把成本赚回来
4、我所在的BU，有没有赚钱
5、我所在的公司/集团，有没有赚钱
6、那为了增加自己、团队、项目、部门、BU、公司的收益，下一个季度要如何调整呢
有空算算帐，会帮你做很多决策
从学校进入职场，有一个明显的变化。
学校中有考试，可以用量化的方法，让大家定期清楚自己的学习情况，搞清楚自己的不足
但进入职场之后，其实并没有此类的方法，我们应该通过算账，定期检视一下自己的情况，适时的做出调整
快速成长的必备软技能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、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本