微服务性能调优03

近期遇到一些技术问题,记录如下:

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数据返回时就被防火墙直接拦截了。

解决:
提单,开墙,解决问题

微服务性能调优02

在各项目组努力下,终于达成了几个目标:
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出现了问题,自己组成了一个新的集群

微服务性能调优01

近期遇到一些技术问题,记录如下:

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

一次技术中台升级记录

由于历史原因,我们有两套技术架构:
基于SpringBoot1.X的老框架、老技术中台、老数据中台。
基于SpringBoot2.X的新框架、新技术中台、新数据中台。

老技术中台研发的时候,整个生产环境都是我们自己搭建的,很多功能需要自研。
到了新技术中台时,已经迁移到了集团的云上,之前设计的很多功能也就用不到了。
而且,随着时间的推移,老中台人员都去参与了其他项目,长期处于支持维护状态,无论研发、运维还是安全同事,都感到压力山大。
由于云端环境时不时会做调整,运维同学都不敢轻易重启老中台服务,怕一重启,就再也起不来了。
安全扫描策略也不断升级,扫描出来的问题一次比一次多,很快就千疮百孔了,但大家也只能缝缝补补。

之前由于业务压力异常巨大,大家一直在忙着做各种新的业务功能,虽然一直想升级,但一直没有狠下心来。
到了今年四季度,遇到了几次生产事故后,大家痛定思痛,决定还是干吧,把老中台下掉。

整体步骤大体如下:
1、找了两位对老技术中台比较熟悉的同事,对全部服务进行了梳理
2、各技术团队,也对老中台的依赖关系重新进行了梳理
3、大家坐下来,对服务进行了分类
A、对于网关类服务,按领域拆分
B、对于调用中转类服务,已经不符合当前要求,改为K8S的微服务直连
C、先看调用量小的服务;没有调用量的服务及接口,尽早下线
D、其余调用量很少的服务,与业务方沟通,能下线下线,不能下线合并等待下线
E、新老技术中台都有的服务,新中台进行适配,下线老中台服务
F、老中台有,新中台没有的中台类服务,功能迁移,下线老中台服务
G、非中台类服务,拆分到业务系统,下线老中台服务
H、其余服务,一事一议
4、对新老平台都保持的数据,进行数据治理,统一数据标准
5、在服务迁移改造的过程中,要求按新框架规范,将服务升级到SpringBoot2
6、由于没有业务上的直接收益,所以整个改造周期排了很久,各团队根据实际情况,在每次迭代中把工作量消化掉
7、及时与测试同学沟通,确保每次测试覆盖到
8、与运维同学沟通,服务全部升级完成后,切换nacos到最新版本(之前受限于SpringBoot1,无法升级nacos)
9、这样框架、技术中台就升级完毕了,后面每半年升级一次框架就可以了
10、数据中台的小伙伴,因形势所迫,直接抛弃了原有技术栈和工具,拥抱了新技术栈,最后技术债务居然是最小的。

任务已排期,各团队都表示坚决支持。但你以为这样就能顺利推进吗?我感觉比较难哦。
过半年,再续写一下,推进情况究竟如何,敬请期待。

秒杀及大促系统关键点

一、电商秒杀场景
0、尽早做好各相关团队的沟通,做好活动动员工作
1、搭建单独的秒杀系统,与核心交易系统隔离
2、做好静态资源缓存:浏览器、CDN、服务器缓存
3、通过JS,动态下发大促页面,大促抢单URL到秒杀时刻后才能下发
4、网关随机刷掉大部分用户,小部分进入到服务器,每台服务器只处理前N条数据,后续用户秒杀失败
5、redis分布式锁确保不会超卖
6、秒杀成功后,请求发送至核心交易系统
7、做URL验证,防止刷单
8、网关控制同IP流量,屏蔽部分云服务器IP段,防止部分刷单行为
9、提前做好性能测试及压力测试

二、电商大促场景:
0、尽早做好各相关团队的沟通,做好活动动员工作
1、业务上分时段大促,不同商品分流,缓解服务器甚至快递小哥压力
2、做好静态资源缓存:浏览器、CDN、服务器缓存
3、根据过往流量、商品浏览量、购物车商品数量,估算大促流量
4、做好扩容和运维保障工作:服务器、带宽、数据库根据预测流量,进行弹性扩容,而且要有一定比例的富余量
5、大促商品信息提前加载redis缓存
6、引入MQ,异步处理订单,消除业务峰值
7、做好PlanB,限流、降级、熔断,保证核心业务稳定
8、网关控制同IP流量,屏蔽部分云服务器IP段,防止部分刷单行为
9、提前做好性能测试及压力测试

打车软件功能拆解

一个打车软件,基本需要以下功能:

一、乘客:
1、行程管理:乘客叫车、行程取消、历史行程查看
2、乘客上车引导
3、乘客与驾驶员聊天功能
4、乘客与驾驶员虚拟电话沟通功能
5、行驶轨迹展示、规划行驶路线展示
6、目的地修改
7、乘客支付
8、打赏功能
9、驾驶员评价功能
10、投诉功能
11、消息通知
12、紧急联系人,一键报警,行程分享

二、驾驶员:
1、车辆开始接单,车辆停止接单
2、车辆实时位置信息推送
3、抢单、订单查看、订单取消
4、车辆到达确认
5、驾驶员与乘客聊天功能
6、驾驶员与乘客虚拟电话沟通功能
7、乘客上车确认,开始计费
8、结束计费
9、乘客评价功能
10、收入查看、提现
11、申诉
12、消息通知

三、平台:
1、地理信息系统与车辆网格划分
按GeoHash将城市划分为多个网格,收到车辆位置后,将车辆更新到各个网格;
2、平台派单
根据乘客起始地点,在乘客所属网格,就近派单;
考虑用户习惯,价格、车况等;
不能让乘客长久等待,适时给驾驶员奖励;
给同一驾驶员单子要有好有坏;
不同驾驶员要雨露均沾,不能造成饥饿状态;
不同业务要用派单或抢单模式;
3、行驶路线规划
4、等待时长预估
5、计费规则设置、计费功能
6、车辆位置采集,车辆轨迹记录
7、车辆在线时长统计,车辆收入及行程数统计
8、发票管理、行程单管理
9、客服系统,客诉处理,工单系统对接
10、消息通知:
短信、微信、APP
11、信用系统:
乘客信用
驾驶员信用
黑名单
车辆信息审核
驾驶员信息审核
12、标签系统:
乘客标签及画像,个人乘车偏好
车辆标签及画像
驾驶员标签及画像
13、行驶安全:
驾驶员疲劳管理;
防疫信息管理;
行程录音取证分析;
AI自动分析异常情况,识别争吵、车辆路径偏离,车辆长期不移动等情况;
紧急情况处理,安全人员及警方及时介入,通知乘客安全联络人;
14、基础数据管理
用户、权限、角色、组织、城市、车辆管理、驾驶员管理
15、外部对接API
订单接收,订单确认或取消,行程推送,行程状态同步,计费推送,费用结算

四、业务扩展:
1、市场营销:卡券管理、优惠活动
2、增值业务:保险售卖、加油卡售卖
3、在专车之外,可以开展出租车、顺风车、拼车、预约用车、代驾、企业用户等业务
4、入口从APP扩展到公众号、小程序、其他打车平台、电话

为何技术人员要懂业务



为何技术人员要懂业务
By NEOHOPE

公司是脚,业务是穿鞋的场景,技术是鞋子。

先考虑技术,再考虑业务,往往会导致削足适履,让你怎么穿都别扭;
不考虑技术,只考虑业务,会导致打赤脚或穿草鞋,让你天天肉痛。
两者一起考虑,才能找到合适你的跑鞋、登山靴或轮滑。

不懂业务的技术人员,很难设计出一双适合用户的好鞋子;
不懂技术的业务人员,至少知道用户要一双什么样的鞋子。
所以,你不懂业务,技术再牛,也要听懂业务的。

一句话,除非你是搞理论研究或专业分工的,否则,脱离了业务说技术都在是耍流氓,脱离了业务谈架构同样是在耍流氓,脱离了业务天天扯一堆前沿名词就是大流氓。

工作笔记001

Hansen的工作笔记001

最近,根据工作安排的调整,参与了部分售前支持工作,发现了工作上的一些不足之处:
1、个人对公司产品的理解不够深入,对用户的最关心的痛点理解过于肤浅,对行业态势了解滞后,对竞争对手了解太少。
2、公司产品的相关文档太少,苦了售前、实施各位大哥大姐。
3、沟通时,技术性仍然太强。回想起来,用户、售前和销售人员居然表示可以理解,也太难为他们了。后面要做到,对方不懂技术,也可以讲明白。
4、有时候,过于急躁,看到自己写的“戒骄 戒躁 戒懒”的便利贴,还是脸红了一下。

改进措施:
1、多学习。就像前面和杨荣聊的,人懒了,放弃学习了,也就掉队了。你做软件,做不到35,除了自己谁也别怪,只能怪自己。
2、多沟通,多讨论。沟通和讨论,是一个很好的可以帮自己系统梳理思路的好方式,关键是不累心。
3、知识组成要多元化。团队成长到一定阶段,即需要专精人才,也需要综合性人才。要及时找到适合自己的路子。但即使你走专精的道路,也要让自己的知识构成多元化一些,才不至于闭门造车。
4、搭建了OpenKM,替代了没人用的Wiki。希望可以发挥一些作用。感谢陈燕婷的大力支持。
5、要逼着各位产品经理、技术经理补充缺失的文档。相信对他们也有很多好处。
6、加强个人非技术的沟通技巧,文档写的要让非开发人员可以读懂。