2018年的项目思考

去年我由干了多年的业务部门调岗到目前的技术平台部门已经快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年能再有进步，不忘初心！