技术领导力案例

基础领导力分成倾听，褒奖，授权和决断四个方面。今天主要聊聊怎样做技术决断。

我在之前公司负责的系统是公司对外服务的总出口和总入口。是纯后端的服务，外部直接通过API对接。大家可以想象成微信支付开放平台。因为是支付系统一旦出现问题影响巨大，搞不好就要给科技司，国务院一个解释。而且因为是一个影响力非常大的平台，口碑也非常重要，如果不小心说错话很可能会引起PR事故，登上中央台的新闻也非常有可能。这就需要在出现问题时做出快速而正确的决断。

有一次，运维又在搞事情，推动我们升级Spring的版本。其实在升级前我们做了很多工作:先升级非核心应用，长期观察后，再升级核心应用。核心应用升级后的版本也在线下观察了很久。

我们正式升级时也非常小心，先升级了几千分之一的流量，观察了好多天，没有发现问题。然后升级了六分之一的流量。这时候就出现问题了:我们一个接入方反馈他们系统报错。

如果你是领导，出现了这个问题，下属来请你做决策，你如何处理？

确实是我们升级引发的，并且对接入方造成了影响。是否要立即回滚止损？回滚了不就是相当于跟接入方说我们有问题了嘛，会不会影响我们的口碑？

不回滚最后发现是我们的问题该如何对外解释？特别是人家问你们为什么不回滚怎样的对外话术能解决问题？回滚慢了影响大，问题上升如何处理？

这时候，第一要做的不是给出决策，而是搞清楚情况。有两个问题: 目前影响是多大？接入方那边报什么错误？

得到答案: 目前影响是每分钟有一二十笔报错。报400错误。

得到这个答案其实决策还比较容易:400是客户端参数错误，不是我们服务端的问题。同时，每分钟一二十笔报错也是我们能承受的范围内。

所以决策是：先不回滚，先调查原因。

最终原因定位是由于Spring升级后对一个参数校验更加严格。调用方传入参数不规范导致问题。所以我们最终决策是按兵不动，等待接入方修改完上线后我们再继续更新。

案例讲完了，现在大家来思考一个问题：出现问题，第一件要做的事是什么？

是调查问题原因吗？不是，是评估影响。影响包含已经造成的和将要做的决策可能产生的。这其中就有一个统筹领导者的角色，针对影响合理分配资源，有序处理。

当然，这只是基础领导力，下一级的要求先只简单上一张图：