去年我由干了多年的业务部门调岗到目前的技术平台部门已经快1年了,这一年过得并不轻松,遇到很多困难,到目前也没有全部解决,总有一种夹缝中求生存的感觉。

2018年末了,我做了很多思考,技术上的、非技术上的,这里来总结一下:

项目流水账

第一次P0事故

我今年5月份完全接手了公司的一个平台型技术项目,这个项目公司绝大多数的重要业务线都在使用,在内部评定的项目重要程度上,被评为A级。

可就是这样的一个项目,当时接手时的情况是:

  1. 虽然对业务方是一个服务,但是内部实现确有两套,分别是go版本和c++版本,并且两套同时对不同业务方提供服务;
  2. 账目混乱,究竟公司有哪些业务方、使用了哪些资源,没人能说清楚;
  3. 部署混乱,线上机器代码不一致,同一集群机房、地域极度不合理;
  4. 开发环境混乱,项目代码分支众多,分别都能上线部署;
  5. 文档匮乏,基本上只能从代码中看;
  6. 报警无数,加入报警组第一时间,手机就成了蜂鸣器;
  7. 交接仓促,基本上没和我说什么

当时每天找我查问题的业务部门很多,而且还有新需求开发,我就在这种情况下逐步熟悉项目。

过了没多久,线上出现了事故。由于我对代码很不熟悉,所以恢复的十分慢,最后采用了在线上调试代码才找到问题所在,最终完全恢复花了1天的时间,这就是第一次的P0事故。

第一次P0事故后

这次事故后,我对go和c++这两个版本的系统的了解深入了很多,也发现了两套系统各自的很多致命问题,简要说明如下:

go版系统

  1. 部署维护复杂,组件众多,且组件间有很严重的依赖关系
  2. 存在致命组件,简单说,就是集群中的任何一台机器的这个组件挂了,想完全恢复服务,需要把整个集群的服务重启

c++版系统

  1. 依赖的核心组件存在bug,会导致程序运行时意外崩溃,原因未知,组件很老,项目使用上由于非接口实现,所以完全替换成本很大;
  2. 业务逻辑也使用c++实现,简单的需求开发成本也很高

制定的改造方案

  1. 首先梳理清楚账目,搞清每个业务放都在用哪个集群的服务,控制服务入口
  2. go版由于架构问题,重新调整架构和推倒重来差不多;
  3. c++版架构上清晰合理很多,但代码实现问题很大;
  4. 基于c++版的架构,重新设计实现,另外,改进架构中高可用不足的问题

这样,我开始实施了。差不多花了1个多月的时间,完成了如下工作:

  1. 账目清晰了,重点业务也单独划分了出来;
  2. 入口服务重构完成,业务使用情况数据统计很清晰;

然后,我重新设计了一版新的架构和实现方案:

  1. 架构中充分考虑高可用
  2. c++实现系统所需要的底层高性能组件
  3. go实现业务逻辑

开发被迫中断

可惜事与愿违,我的开发无法正常进行下去,被各种事情打断:

  1. 有业务再次私自使用go版服务,服务无法满足他们的要求,但由于业务很强势,所以要配合他们调整;
  2. 公司年底要下线两个旧机房,但go版服务都在这两个机房,所以要做服务迁移

就在这两个事情进行中时,第二次P0事件发生了:

第二次P0事件

这次事故的原因很简单,就是go版那个核心组件的单机问题,有台机器挂了,所以集群服务需要完全重启。

由于服务故障发生在高峰期,我重启虽然很快,但业务那边的实现也有问题,恢复花了很长时间,导致用户投诉很多。

这次事故后,我自己好好的总结了下,也作出了一些调整,具体请看:https://www.jianshu.com/p/16eaf97f62cf

矛盾

上面这些流水账,可能很多开发人员都遇到过类似情况,也是很无奈,感觉作为一个开发人员,通常也就只能这样了。

也正是因为这样,这么多年过去了,我看到很多人都灰心的离开,离开时都有很多不甘心。

前几天还和一个同事聊天,也说到了这些问题,感觉很多混乱的地方,这里我说下自己对这件事情的看法:

很多技术项目,由于存在了多年,新功能开发很少,所以上面认为它属于维护期项目,自然不会认同资源的投入,会更倾向于做新的事情。

而处于项目中的普通开发人员,通常是有心无力,开发人员本就内向偏多,话语权少,最终经常是忍不了了就走了。

随着核心开发人员的不断离开,项目稳定性越来越差,大爆炸只是早晚的事情而已,由于维护期项目通常会交给新人,则频繁出现新人背锅的事情。

boss角度

公司要发展,资本市场要看的是公司的业务增长,所以公司方面就会很倾向于你做了多少新东西。

所以通常是,你和你的boss说,我把这个东西维护的很好,不出事情,boss只会认为你什么事情都没有做。

开发人员角度

我们都了解很多好的技术项目,就举最常见的几个:Nginx、Mysql、Redis来说,几乎所有大公司都在使用。

这几个项目,单论功能上,其实很多年前的版本依旧满足现在使用上的绝大多数场景了,那么按照boss观点,应该处于维护期了才对,但是这些年依旧在不停开发新版本,而每一版的开发投入,都是无数核心开发人员夜以继日的付出,所以才越来越好。

解决

其实这个矛盾,我想也是各自有理,没有哪一方是完全正确的,所以管理才最重要,只有管理的好,公司才能越做越好,所以我想,更好的管理人才才是最重要的。

我自认自己目前是做不到这一点的,所以如果能有个很好的老大,要特别珍惜啊!

重点技术项目持续投入的重要性

我想再表达下我对重点项目持续投入技术人才重要性的看法:

  1. 越复杂的技术项目,其架构设计在每个阶段都要做相应的调整,这本身需要核心人员的持续参与;
  2. 核心人员在项目中的持续深入思考,会提升技术水平,开阔思路,做新项目时,就会做的更好,不会给人一种重复劳动、止步不前的感觉,这不是简单的去参加几次有排场的会议能收货的;
  3. 不断核心人员的持续投入,重复这个过程,整个部门的技术水平就能得到上升,不会被人诟病能力低下

对核心技术人才储备的观点

最后,我再说下我对于核心技术人才储备上,关于人才培养和人才引进的观点:

人才培养

我个人觉得这是保持团队核心技术竞争力最重要的事情,胜于人才引进,具体说明如下:

  1. 在公司内部通过多年成长起来的技术人,大多对公司有感情,有归属感,不会因为简单的利益得失离开
  2. 通过长期培养起来的内部人才,忠诚度、可靠度都远远胜于外部老油条
  3. 长期培养起内部人才,要做一个重要的项目时,有人可用远远胜于临时现抓人
  4. 有利于长期培养做事情的方法、文化的传承,不会出现混乱的项目

做人才培养,最重要的是如何评判一个导师。一句话说得好:兵怂怂一个,将怂怂一窝。所以负责培养人才的导师才是最重要的,也需要优胜劣汰

人才引进

人才引进也是需要做的,我认为好处如下:

  1. 短期有效提升团队技术能力
  2. 给团队注入新鲜血液,让我们不会固步自封

结束语

2018年就要过去了,希望2019年能再有进步,不忘初心!