©2016-2024 Matools All rights reserved,
粤ICP备17059708号
在设计系统技术架构的时候，我会思考，这个技术架构能给企业或者市场带来什么价值，技术架构能像其他产品那样卖钱吗？我也经常会听到类似于“这个架构很牛X”，“这个架构很先进”以及“这个架构能抗万级并发”这样的评价，再回到市场角度想想，这个“牛X”或者“先进”有哪个老板真正愿意买单？“能顶住千万级并发”是不是每个企业的核心需求？多年的工作经验告诉我：
绝地有，且不在少数。
多年下来吧，找上门的客户很多都是十万火急地想找一个牛X、先进和稳定的技术架构，有一些并不是什么互联网公司或科技企业，但他们的信息化建设问题已经严重影响了企业的核心业务，甚至这个问题已经上升到了他们企业最顶层的紧急事务。原因并不是他们没有技术团队做支撑，而是因为他们使用了所谓“牛X且先进”的技术架构，而被迫让“技术架构”成为企业当前的“核心需求”。
“我听说微服务架构很先进，你们公司正好有这样一个研发框架，而且还有千万级用户和上万级并发量支撑的案例验证过了，能否卖给我们”。我很能理解他们的困境，但曹老板说过：“做人要真诚和善良”。所以，我很诚恳地表达了简单地买套代码是没有什么效果的，甚至还有可能变本加厉，最终用不好，砸坏的可是我自己的招牌。
这些领导或企业管理者对微服务架构的渴望无非就是对提高企业竞争力利益最大化的渴望。处于这样一个信息化时代，就算企业没有“互联网”或“科技”字眼，但他们始终都离不开信息化建设这个基石，因为信息数据化的优势太大了。所以，从市场角度看，一个好的技术架构真正能给企业带来的核心价值是
“增效降本”
。再结合前面的问题，“牛X”和“先进”是不是等同于“增效降本”？这个问题留给大家去践行思考了。有的企业声称自己使用了大型互联网公司级别的技术架构，但到头来成本却越来越高。据我对他们的了解，原因很多，但最为突出和迫切的，还是他们缺少一个与之匹配的技术组织架构，这是他们没能真正“牛X”起来的直接原因。
作为一个“增效将本”的企业内部组织，首先，最基本要确保的是给企业所带来的价值必须大于自身组织的投入成本，这也应该是技术员工最基本的价值观念。但能真正遇到具备这种价值观的技术人员不多，他们更多地是埋头对“牛X技术”的追求，忘记了技术的本质。其实，这个现象跟目前的行业状态有关，那些什么“青春饭”、“35岁危机论”等迫使他们必须在短时间内赚取足够的金钱，而IT行业最能赚钱的手段就是跳槽，而跳槽最容易涨身价的就是保持自己拥有“牛X”的技术。所以他们心里不会想太多如何帮助自己当前所在的这个企业能赚多少钱，更多是借助在这个企业的短暂时光练练自己牛X的技术技能。所以很多应聘者都会问“你们公司用的是什么技术”而不是问“你们是如何通过技术手段去帮助公司增效降本”。以上所描述的技术人员不限于技术高管，所以企业很难有一个稳健且可持续发展的技术架构以及组织规范。
仗着互联网趋势，技术组织很多时候都自以为是“大爷”级别的，但技术组织本身是一种成本投资，技术组织存在价值的公式很简单：
技术价值=为企业整体利益的增效-自身技术组织的成本
。技术能增效，主要还是根据企业价值链结合业务架构和技术架构的搭配去提高企业自身的市场竞争力，所以现在很多企业会有业务架构师一说。而技术组织的成本控制不在于自己使用了多牛X的技术，还是那句老话：要发展，先自知，没有最好，只有最合适，做人做企业亦是如此。
以自己所在公司为例，从2011年5月我还没正式毕业就进入公司接手技术管理以来，一切都是从零开始。随着移动互联网的发展趋势，迫使我们必须进行架构改造，从2014年开始我们进入“服务化V1.0”模式，也就是我们现在微服务架构的前身。这些技术发展史都能从我以前的文字中找到，但对于我们自身组织的描述得不多，但技术架构本身不会独立存在，跟组织架构还是有很密切相关，所以，我觉得还是有必要介绍一下。这仅仅只是一个经验分享，并不代表我们就是成功的榜样或标准。
● 技术员工
从上图的技术与组织架构对比可以知道，组织技术员工好比技术的物理服务器，都是架构的基建，一个员工的品质好比服务器的质量，并不是说有了上层对基础资源的统一管理，淡化了每一个独立个体的重要性就不代表不需要好的员工或服务器了。当然，好的东西都贵，但性价比高的还是值得不断去追求的。
● 技术部门
技术部门好比LaaS，是对所有独立个体的统一管理和协调，最对资源效能最大化的手段。部门有企业级别的实践方针和指南，结合企业的目标定制了一套最适合自己的组织与技术管理办法，这些规章制度并非一成不变，是站在企业的角度跟随市场不断去完善和修正的。所以，组织并非一成不变，既然技术与架构是相互的，那么技术架构的稳健、灵活、易扩展等特性应该同样要应用于组织架构。
● 研发小组
研发小组跟PaaS一样，是技术组织效能的“加速器”，增加了上层的业务或应用的灵活性和增加快速适应市场的能力。我们研发小组的贡献主要集中在两个层面。一方面是不断完善和提高自己组织的内部效能，主要体现在我们当前自主研发的“统一工作台”，这个统一工作台主要是结合我们各种职能流程和软件工具（如SVN，Docker等）打造的一个统一规范工作流平台。另一方面是不断通过业务驱动积累我们研发的业务产品（如我们“微服务应用中台”的服务沉淀），为企业增效，提高市场竞争力。
● 职能小组
我们部门的人员架构是一个“矩阵型”架构，横向为技术职能小组，纵向为以项目经理带领的项目小组（下面会介绍）。按职能维度，整个部门划分为项目经理组、需求组、UIUE组、前端组、后端组，测试组、实施维护组等职能小组。有点类似于微服务架构里面的服务一样，分工合作，独立部署独立运行。职能小组内部会根据规模而进一步细分小小组。这些小小组会随企业发展而又有可能归类为事业线小小组或业务领域小小组。组员到组长一层层向上按自己领域范围的技术规范和项目质量负责。
● 项目小组
项目小组是我们“矩阵型”架构的纵向划分维度，由各职能小组成员组成，由项目经理以业务为统筹和主导。在纵向维度，职能会存在一个“项目职能负责人”，确保自己的职能价值在项目中最大化体现。哪怕项目再小，职能只需分配一个人或半个人，而那个人就默认充当了这个“项目职能负责人”的角色。就像微服务架构一样，有了我们“微服务应用中台”的支撑，顶层的应用场景可以更加灵活、高效、快速地实现。我们的项目小组在职能小组明确分工的基础上，同样也能灵活、高效、快速组件出打造顶层应用场景的项目团队。
看到这里，可能有人会有疑问，我们只是一个小企业，那有这么多人。其实问这个问题的人，等同于问“微服务是否只能适用于大型系统”的问题一样。我在《小型系统如何“微服务”开发》中也做过介绍，微服务是一种方法，适用于任何应用和项目，跟项目规模没有关系，哪怕我目前只有一台物理服务器，或者我只有一个技术人员，都完全能按照我们以上的“技术与组织结构”方式去运行和操作。要明确一点的是：方法跟规模没有关系。当今在技术圈比较流行的一个词叫做“DEVOPS”，其实就是一种“降本”手段。我们的组织架构是跟人数没有关系的，更多是我们的管理办法，因为做事情需要顶层方法去引导我们更好地执行。就算我们技术组织只有我一个人，也不妨碍我属于研发人员，同时又兼容前端、后端、测试、实施、维护的职能，以及作为项目经理主导自己去开发项目。
方法还只是属于“虚幻”层面的东西，具体还是要考自己的实践去验证和发展，就算我说得多牛X，如果不亲自去体会、感受和总结，我们持续实践了千万级用户数应用平台近10年的时间，以及我们所开发的应用系统足足比别人降低数倍乃至数十倍的时间和金钱成本，都不关你们的事，这是我们每个同事通过汗水和努力所换来的成效。但我们的不足还很多，没事，时间还很漫长，一步步主动去学习、改变和完善就是了。
热门工具 换一换