AWS领导力原则解读（四）-一一网

正确决策

正确抉择在我看来需要经过以下几个过程：

搞清问题本质

我们一定要对问题有个准确的定义，搞清楚它的root cause。比如对一个线上的问题，要分析它是每天固定时间产生还是随机产生，使用户误操作还是潜在的bug，是平时就会有还是高并发环境下才会有。当然这个过程还要配合各种日志分析和工具诊断。比如应用系统本身日志，操作系统日志，对于java来说通过jstack等工具来辅助分析，另外还有系统的监控等。通过这一系列的分析我们一般情况下能拿到root cause的。如果有人问如果做完各种分析还是不知道root cause怎么办？像这种问题一般都是性能问题，我也遇到过，当时就采取了定时重启的方式，当然这是建立一种高可用架构上的，也就是说不会在某一台server重启过程中整个系统都不可用。当然，这种方式有它的局限性，比如何时去重启最合适等。

群策群力

孔子说过，三人行必有我师。单靠个人即使经验再丰富也有想不到的点，而这些点很可能就隐藏着一个巨大风险。

对于一般的问题，通过自身积累的经验并配合网上类似问题的答案，我们是可以快速解决的。但是对于重大问题，比如会影响整个架构的问题，这个时候要群策群力。群策群力的形式很多，拿我自己来说，一般情况下我会call a meeting,involve直线领导，其他资深架构师来一起讨论。有时比如遛弯时跟其他同事咨询一下，很可能别人的一句话就真的点醒梦中人了。

要有兜底措施

即使我们前期考虑的再全面，执行再细致，实际过程中还是会出现这样那样的问题。所以此时我们一定要有个兜底的措施。一般来说就是要为最坏情况设置应急措施，比如电商网站采用的服务降级的方案。在天猫“双十一”或者京东“618”这几天，并发量会非常大，如果真的出现并发问题，一定要保证核心业务不受影响。比如坚决不能影响用户下单，但是物流信息可以暂时做降级处理，用户可能在活动期间无法及时刷出物流信息。

决策失败的例子

有一次做实时数据传输的项目，因为之前刚做了一个类似的，而且成功上线了。所以这次拿到需求后心里还是很有把握的。对于实时数据传输，我们的重点要保证数据在传输过程中不丢，不重，不乱序以及实时性。所以当时重心还是放在了传输本身这块。但是却忽视了需求中的一句话：支持用户灵活定制报表。其实这句话当时也看到了，但是没有引起足够重视，觉得用户要求的定制度没那么高，可在跟用户进行原型沟通的时候发现我们自己开发的界面远远不能满足用户的定制化需求。所以我们下来又紧急开会，寻找替代方法。最后我们找了个第三方的专业报表组件，组件找到又发现另外的问题，就是它要求的数据格式我们提供的不一样，所以我们又开发一个适配器来做转换。虽然最终满足了用户需求，但是这段时间搞的很狼狈，给客户造成的感觉也不是很好。这个案例其实就是对问题考虑的不够全面。