每个季度末，我都会抽出一周的时间与团队核心人员逐一谈心，一来帮助他们舒缓下疲劳的情绪，二来给大伙创造一个吐槽的环境。

在以往的谈话中，我会有意识的避免总结与回忆，多聊一些与畅想未来相关的话题，为什么呢？因为时间是无法逆转的，过去就是过去了，与其强忍尴尬回忆过去，不如试着畅想未来，让气氛变的更轻松，至少这种方式使得整个谈话过程笑声变多了，苦瓜脸变少了。

今天在与某架构师谈话中，他的某些观点却让我感到有些意外。为什么呢？我们都聊了些什么？

我整理了他的内容，大致是觉得系统架构升级的驱动力多半来自于故障，比如2012年11月11日，各大电商风云大战，淘宝网和京东网虽做足准备，但还是由于流量太大导致服务器瘫痪。回望自己，虽说会做一些高可用测试，也确实能在测试阶段发现大量性能、高可用的潜在问题，但基本都浮于表面，我说的不对吗？还记得半年前的机房迁移吗？做足准备了吧，那为什么结果还是被冲了个七零八落呢？

他接着说，说完技术，再来说说人，由于 “客观原因”，我们的架构师在高可用，在分布式，甚至在自动化方面都缺乏经验，除非高薪聘请大咖加入，想要通过自身规划得到稳定、高效的技术架构，几乎没有可能。

这番话很实在，也很直接，让我当场有些措手不及。

仔细想想，有这样想法的架构师，或程序员不在少数，他们坚信自己系统升级的必要性来源于是否出现故障，只要认真且较真的抓住这次机会，修复他，搞定它，让他下次不再发生，我就是棒棒哒，至于那些还未发生的，就是不存在的，既然不存在，我怎么能知道？靠瞎猜吗？

不仅如此，他们始终相信，我没经验，就没法开展，至于什么未来规划，更是无稽之谈。也许这是遮掩自己的不足，找准时机展露自己是救世主的一种另类方式，但事实证明他们把自己定义为一名消防队员，而不愿意为成为一名规划者。
有人说了，架构的发展多半来自于业务的需要，现在业务放缓，现有架构也满足当前需求，那我还需要主动规划吗？我觉得，不仅需要，而且要加大投入，为什么呢？

我觉得，将产线发生故障作为架构升级驱动力的想法纯属鸵鸟思维，有些故障会导致业务一击毙命，还有然后吗？再说了，一般考验系统架构的最好方式是大流量，而有意思的是，流量这东西不仅不好预估，而且不确定性极强。为了应对这样的场景，所以我们常会听到架构师说，“我这东东是带自动扩展的，可大可小，可根据流量快速的自动调整。” 听上去真棒，但当真的 “狼来了"，需要你在产线施展神通之时，咋哑火了呢？仔细一查，原来同时扩展小于十个节点没问题，大于十个节点就触发了某BUG，其他都测了呀，就差这个场景没想到呀，你能怪他没好好测试吗？

所以，请收起那些可笑的想法，将明确的目标与实施路径写入规划，耗费上千次讨论，废弃数套环境，奉献半生精力，去执行，去折腾。

随着宏观经济与金融监管的风云突变，我曾在几个月前写过一篇有关业务增速减缓后如何面对技术管理的文章，而在这样的客观环境下，我们又是如何进行技术架构规划的呢？

寻找目标企业，不耻下问，关注细节

常听见某某人自夸，说自己认识这个，有哪个人的微信，这能证明啥？最多能证明你的社交能力强，人脉广泛，所交流的技术话题也多半偏向顶层设计，或概念构思，对实质性规划没什么太大帮助。

我所采取的是，将目标分拆为不同技术类型，比如分布式中间件，持续集成与交付，DevOPS等，利用这些人脉关系，寻找行业内不同的目标企业进行学习，比如阿里的中间件团队，携程的持续集成与交付，带领小伙伴们登门拜访，不耻下问，关注他们的发展历程、技术选型及用人标准等细节。

每次都有收获，每次都会得到启发，今年许多版本的迭代均得益于这项方式。

构建适合自己的非功能性测试套路

按之前的方式，是否可以把某某年度的OKR定义成 “必须达成A系统P0级事故3次，并导致10台以上服务节点宕机。”，为啥这么定？逻辑很简单啊，事故级别越高，服务节点宕机数越多，架构设计的驱动力越大呀，哦耶！
如果技术负责人的脑子没被驴踢的话，不可能这样设定OKR，那该怎么解决这个矛盾呢？

我所采取的是，建设随机破坏性故障演练系统，并制定模拟性场景演练，比如拔网线、丢包、I/O不规则波动、消息阻塞等，由于曾写过一篇有关随机故障测试系统的文章，在这里就不详细介绍了。

当然，这些看似简单的思路，想要做到，并非易事，毕竟扯淡总是容易的，刷新认知才是最难的。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/j8veJRVJbZeNDDJwkjU50g

创作场景

你的架构升级是靠故障驱动？还是规划驱动？