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

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

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

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

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

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

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

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

不仅如此，他们始终相信，我没经验，就没法开展，至于什么未来规划，更是无稽之谈。也许这是遮掩自己的不足，找准时机展露自己是救世主的一种另类方式，但事实证明他们把自己定义为一名消防队员，而不愿意为成为一名规划者。

有人说了，架构的发展多半来自于业务的需要，现在业务放缓，现有架构也满足当前需求，那我还需要主动规划吗？我觉得，不仅需要，而且要加大投入，为什么呢？

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

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

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

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

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

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

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

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

按之前的方式，是否可以把某某年度的 OKR 定义成 “必须达成 A 系统 P0 级事故 3 次，并导致 10 台以上服务节点宕机。”，为啥这么定？逻辑很简单啊，事故级别越高，服务节点宕机数越多，架构设计的驱动力越大呀，哦耶！

如果技术负责人的脑子没被驴踢的话，不可能这样设定 OKR，那该怎么解决这个矛盾呢？

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

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

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

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