为你的“架构”安排定期体检吧！

一、架构治理的必要性

架构设计不是一项临时性工作，既非架构设计阶段完成，架构方案宣讲结束之后，架构设计的工作就随着而结束；也不是系统上线之后，架构设计就一劳永逸了。与之相反，架构设计是伴随系统全生命周期而存在的。再完美的架构设计方案，结合最优秀的落地，也无法确保系统在经历若干版本和业务运行之后，架构方案仍然有效。

因此，架构沟治理是一项持续性活动，主要原因有以下几点。

（一）业务容量超出设计预期，导致原设计失效

随着业务的有序开展，业务规模持续积累，可能达到某个水平线之后，超出原架构方案所能支撑的业务容量，时间越久，架构的不足之处便会开始以不同的形式彰显，而且严重性越来越高。常见的表现形式有：客户操作时响应时间越来越长，一个操作经常需要十几秒的时间才能处理完成；并发数开始下降，相同的硬件资源下，逐渐出现客户反映系统打不开，或者经常出现莫名其妙的出错；原本运行平稳的系统，逐渐出现服务器异常、内存告警、CPU 告警等技术性问题......这些错误的产生，会导致客户体验急剧下滑。

因此，最有效的方案是预防于未然，即周期性开展容量分析和估算，在出现容量瓶颈之前，提早进行架构方案升级，系统系统所能支撑的业务规模，从而可以从容的支撑和应对业务的增长。

（二）业务特征发生改变，导致原设计失效

系统所承载的业务也可能跟着市场情况的变化而变化，从而业务特征发生改变。而架构设计主要考虑因素之一就是业务特征。一旦业务特征发生变化，与之锚定的架构方案自然需要重新评估，确定是否仍然能够适应新的业务特征。假设对于佣金发放业务，原本的业务方案是用户发起提现申请之后，客户会进行审核，通过之后，，将同一个用户的提现申请进行合同，然后固定某个时刻逐渐将合并后的订单传递给系统；而如今客户不再审核，用户发起提现之后，直接请求系统进行处理。假设该客户是行业头部，日活跃用户数在 1 亿左右。前后一对比，就会发现，系统所要承受的并发量发生了逆转，原本的低并发转变为高并发。

显然，原本的架构方案很难支持新的业务特征，架构升级是顺理成章之举。

（三）更具业务价值的新技术出现

技术行业的发展是永不停息的，科技人员的创造力也是十分让人崇敬。一般每隔 3-5 年行业便会不自主地进行一番技术升级，新的框架被接收并逐渐普及；新的理念也逐渐渗透。

总体而言，新的技术往往伴随着新的价值。譬如支持更大规模的并发和数据处理，让原本花费几个小时才能完成的数据，现如今只需要几分钟即可完成，从而带来更为敏捷的业务反应；更统一的开发体验、更少的关注度，使得技术人员可以减少关注点，将精力聚焦在自己最核心的事项上，从而获得效率和质量的双重提升；要么就是研发管理理念的升级，最典型的莫过于敏捷开发、精益开发、DevOps 运动等，旨在让业务价值更快的呈现，用更短的时间、更便捷的方式、更低廉的成本、更可控的风险以及更低门槛的协作，来实现从想法到产品再到商业变现的整个过程。

毫无疑问，这样的理念是符合市场经济供需双方的诉求的，毕竟在双方都短时间内无法清晰地理解自身以及对方的需求时，与其空洞的交流，用最小的成本呈现一个看得见的产品，或许是最为明智的捷径。

综上所述，作为架构方案还能无动于衷吗？答案自然是否定的，紧随技术浪潮，时刻贴近业务价值的前线，是架构方案的重要使命。因此，架构师们必须时刻保持警醒，以及对新技术新理念的极大热情，并推动架构方案与时俱进，成为业务成功的重要引擎之一。

（四）谨防技术债务滋生，最终吞噬系统

与其他事物一样，熵增效应在 IT 系统中也是司空见惯的事情。首先，技术团队的人员并非一成不变，伴随着新成员的加入，很容易带入新的习惯，或者因为对现有架构方案和标准约束的不熟悉，造成对规范的冲击，时间越久，产生的不合规现象越来越多，日积月累之后，债务丛生，导致最后所有人都是心有戚戚焉，系统最终不得不另起炉灶。其次，人的天性决定，松懈是容易的，而持之以恒却需要非凡的自律，所以，系统上线之后，技术团队对于架构方案的要求也会逐渐松懈，因此也需要持续开展家沟治理，防微杜渐，确保团队始终严格按照规范从事。

（五）依赖项的变化，导致架构需要重新评估

系统正常运行往往不全是自包含的，换言之还依赖其他系统的能力。而其他系统同样会面临上述问题，同样也会进行升级。如此一来，作为依赖方有时候也需要进行更新，当然这样的更新并非全是徒劳，有时候或许可以获得更好的业务体验。譬如原本依赖的系统缺乏通知机制，需要通过定时任务轮询获取处理结果，现在对方提供了通知机制，显然，如果系统升级以对接通知，可以避免轮询所带来的无畏资源损耗，并获得更加及时的业务结果，于业务也是大有裨益的。

综上所述，架构治理是非常值得去开展的，无论是应对技术债务，还是拥抱新的变化，都具有它实际的意义。

二、架构治理的工作过程

那么该如何开展架构治理呢？

（一）回顾架构目标

架构方案的制定，都是综合考虑企业使命愿景和价值观，同时遵循组织总体的战略规划，服从具体产品的商业规划，此外，兼顾各类风险、趋势和规律，在各种约束之下，多方权衡的产物。因此，架构治理的第一步，自然就是对各种约束、目标的重新审视。

（二）罗列目标的变化

随着时间的推移，有些架构目标是相对恒定的，譬如组织的基因信念，战略方向虽然也会变化，但相对不会一天一个样，而产品规划却很可能不断更新。尤其是新的试点性产品，本身处于各个方向的探索阶段，自然会频繁地变更功能、流程、模式、甚至客户群体等。架构治理需要对这些因素一一盘点，分析前后变化，找出变更点，作为下一步的重要信息输入。

（三）判断架构执行效果与目标的偏差

回顾完目标，并且对目标的前后变化进行梳理之后。接下来我们需要将目标回归到现有架构方案的执行情况。判断架构的实际执行结果对于目标的支撑情况。

（四）分析偏差出现的原因

一旦我们找出偏差，接下来更重要的是分析出现偏差的原因。可能的原因有以下几点。其一、原本的架构因素分析不准确，导致架构目标本身就与实际情况不符合，这可能有解，也可能无解，有解的是因素分析更加具体化、多样本化；无解的是总是存在不确定性。其二、原本的因素分析大体正确，架构目标也基本合理，但是执行过程中因素发生了变化，导致出现偏差。假设原本预估目标市场的容量是 2000 亿，用户群体是 4 亿，但是因为突如其来的政策发文，导致市场瞬间坍塌，客户群体也大规模缩水，自然业务目标也就萎缩了。原本支持大容量的架构方案自然不再适用，因为成本过于高昂，运营过于复杂。其三、架构因素基本维持，架构目标也相对可靠，但是执行层面出了问题，并没有严格按照架构设计落地，导致业务体量一上涨，系统瓶颈逐渐暴露。

（五）制定新的架构或者推动现有架构的深入执行

分析了出现偏差的原因之后，对症下药似乎就变得容易一些了。如果是因为原本预估的因素不正确，或者过程中因素发生了变化，最终导致架构方案无法支撑实际情况，那么只需要进行合理的架构方案升级即可；如果是因为执行层面导致良好的设计方案被走样了，那么需要挖掘出不执行的原因，并进行执行流程上的整改，确保后续架构方案可以原汁原味的执行。

（六）决议通报

做完上述动作之后，还需要开展一个宣传工作，即将治理结果进行通报。如果结果是产生新的架构方案，那么借此机会让大家明白新的方案是什么，后续该如何执行；如果是调整了架构管控的流程，也应当让相关群体了解背后的流程性漏洞，和因此产生的严重后果，并借此引发大家的重视。让每一次架构治理，不仅仅是架构上的升级，更希望尽可能地升华到团队认知、协作流程上的进步，从而扩大此次行动的战果。

三、架构治理的意义

架构治理就好比例行体检，可以及时主动发现架构上的不适，尽早介入，尽早处理，避免积累成为沉疴。

同时，架构治理也是一次很好的复盘之旅，让相关团队对于设计之初的各种预估重新做一次回顾，也许可以发现预估方案的缺陷，帮助后续产品预估尽可能的精确。

最后，架构治理还是一次练兵运动，通过相关岗位的参与，让更多的群体深刻体会到架构设计的理念、原则、考虑因素，从而促进团队成员认知的提升，技能的进步，最终团队获得发展。