企业IT架构团队组建方案Word文档格式.docx

企业IT架构团队组建方案Word文档格式.docx

《企业IT架构团队组建方案Word文档格式.docx》由会员分享，可在线阅读，更多相关《企业IT架构团队组建方案Word文档格式.docx（9页珍藏版）》请在冰豆网上搜索。

开篇说一下架构团队的定位，亦或者说职责范围。

注意：

下图的职能很多可以做归并，只当参考。

非本文的论点。

笔者关于架构团队的职责定位明确为以下几个方面。

扩展性预期

确保系统的架构和设计可以随着业务的发展而扩展，需要在"

业务需要"

发生之前就想好，远在业务部门的预测超过平台的容量之前，就已经对如何扩展系统深思熟虑了。

软件的整个生命周期中，开发交付其实只是一小部分，后期的需求变更、维护升级、重构优化才是主旋律。

那么多考虑软件的扩展性和未来预期是很有必要的，作为架构师至少看得到半年后的规模扩展吧？

标准规范

负责各项标准、规范、流程的设定和推行。

这是架构团队的一个重要职能，也是最容易被忽视的。

技术手段并不是所有的问题的最佳解决方案，很多场景通过推行标准规范就可以达到不错的预期效果。

比如编码规范，可以通过投入大量人力来开发IDE/代码库的插件进行代码规范的自动检查，再需要不断的测试来验证这个插件的可靠性。

通过编程考试或者平时的review来强化这一规范的落地，再加上编程规范的不断宣导可以达到至少八成的效果，何乐而不为，最后那两成效果就放到公司真到一定的级别了考虑技术实吧。

再比如架构组研发了统一的基础日志组件，可以规范日志格式、掩码敏感信息、自动截取/压缩超长日志报文等功能，这种组件就应该作为标准全员推广。

拆解抽象

在参与业务迭代的过程中，能够抽丝剥茧（拆解），发现需求、编码、测试、发布等环节中的痛点、共性点或未来瓶颈点等进行抽象、实现并最终推广全员。

在代码层面也适用，拆解交织繁杂的代码逻辑，抽象出基础公共模块。

都是架构团队的基本技能。

举例来说，架构师经常会参加各种各样的评审，对那些常见的reviewcomments，五花八门的自造轮子，一旦发现就要有这种敏感度需要制定标准规范或者研发统一的组件了。

技术宽度

架构师需要足够的技术宽度，从软件到硬件，从语言到操作系统，从编码到测试，从运维到安全，从拥抱开源到自造轮子都要有所涉猎。

有个比喻，说架构师需要具备某种上帝视角，来俯视软件产品的诞生、成长、重构整个生命过程。

而且架构师要有空杯心态，若学习的技术越多，就觉得自己的水平越高，那基本不会是一个合格的架构师；

实际应该是越学习觉得自己不懂的越多。

另外，特别要有面对疑难杂症的自信和能力，为业务团队提供强力的技术输出。

因为疑难杂症的最后一关就只有架构团队。

协调领导

架构团队绝对不是偏安一角写写基础组件，既然要制定标准，推行规范，那就必须与其他团队进行协作，需要征得他们的合作态度，才能顺畅的推行，这个靠架构团队在技术和业务上的影响力来驱动协调基本可以办到。

但在某些情况下，需要一些强制的手段，比如设计文档的强制评审，那就必须赋权给架构团队一定的权力，或者在一些矩阵型组织里架构师就是拥有技术的绝对权威，这个就是领导力。

深入业务

技术的存在就是为业务服务的，脱离业务的架构都是耍流氓，99%的情况下这句话都没毛病。

有些技术人有严重的重技术轻业务思想，这种人除非真的是钻研技术的一把好手，可能不善言谈不善沟通（笔者本人是可以接受的），但是架构团队里这种人不能多。

后文我们会详细讨论下架构团队和业务团队的协作问题。

创新突破

架构团队在IT内部必须是第一生产力，不管是单兵作战还是团战能力。

除了过硬的基本功外，不断的学习和寻求技术上的突破，是贯穿架构团队始终的一个Object。

前人已经累计了很多经典优秀的平台、框架或思想作为传承，我们可以继承但绝不能守旧。

在学术研究中，“创新”一词用来表示团队有增加值的产出。

而有些创新调研项目很多时候并不会有实际的产出，甚至更糟糕些，会产生许多沉没成本，但这都不是阻碍创新的借口。

创新是架构团队延续生命力的最佳营养品和必要条件。

可以想象没有创新突破，架构团队完全可以就地解散。

《架构即未来》《架构真经》两本经典架构书里都对架构的原则展开了很多，但都是偏向技术层面的。

这里我要另辟蹊径，说的不只是架构本身的原则，还有架构团队如何玩得转的原则，跟上文架构团队的定位是戚戚相关的：

1.可抽象的有基础组件面相的实现尽量由架构统一实现，然后推动各系统使用通用的基础框架，而不是每个系统写。

比如加解密，比如HTTP客户端，并不是所有人对加密的填充、编码、提供者都有清晰的认识，也并不是所有人对HTTP客户端里的超时时间、DEFAULT_MAX_PER_ROUTE、SSL配置等都了解，专业的事情交给相对更加专业的人去实现。

2.《架构即未来》里提到一条“要使用成熟的技术”，个人延伸一下：

不仅如此还要使用尽量统一的技术，尽量统一的代码层级结构（起码有一些约定俗成的层级）。

有人用Gson,fastjson，jackson的比比皆是，hibernate/mybatis也是各有所好。

都是成熟的技术，但是不统一，导致了不管是矩阵式还是敏捷式团队，同一个人维护不同系统时，必然会有一些不适应，需要思维的跳跃，无形的增加很多非必要成本；

再者不同技术的引入可能会增加更多的BUG或管控风险和排障的难度。

常见的代码层级结构controller->

business->

service->

dao，在一些人的项目里business变成了handler,service变成了proxy，怎么都会让人无所适从吧？

3.微服务体系内的单体系统必须做好自我保护，这是架构团队理应对IT产品做出的承诺。

服务提供方根据需求说明设计并承诺了一个服务接口定义，如果调用方只管调用服务方只管实现，一个不慎就会把接口设计成一颗雷。

比如会员系统提供用户基本信息的查询接口，这个接口提供的用户信息“基本”的边界在哪里，单表查询也就罢了，如果需要多表连接查询呢？

有些人喜欢把这个接口做的大而全，很灵活，比如在最基础的用户信息之上，会附加一些其他字段如QQ号，工作单位，年收入等等算不上基本信息的信息，只要调用方多传入一些参数即可。

确实感觉灵活了，但为此服务方不得不做各种的入参判断和SQL拼接，最差的情况可能需要关联用户的所有相关表，性能差到冰点不用说，对系统本身的吞吐量和并发能力都会有特别大的影响。

这就是系统没有自我保护好。

因为并不是说系统有什么BUG，但是因为这个灵活度引入了极大的性能隐患。

再比如用户列表的查询，服务使用方传入参数作为WHERE条件进行过滤，如果使用方什么都不传，这个查询接口基本等同于全表查询的脱库了。

这时候必挂无疑，那么是不是应该加上分页，或者最大结果集的限定条件进行自我保护呢？

4.架构团队的任何框架、组件级别的需求，都应该做好充分调研，不能闭门造车自己臆想需求。

技术人很少能做到乔帮主似的，对方不知道自己想要什么由我来告诉你应该用什么；

再者如果臆想的实现最终发现并不适用又耗费了大量成本，或多或少总会被别的团队看轻吧，身为架构师如何能忍？

而且把需求调研沟通清楚，未来推广也会得到大家的支持，很简单，因为需求是大家一起提出来的。

5.任何的标准规范的推行、框架组件的立项、实现和发布需要获得高层的充分授权，也需要与重要干系人（比如团队或职能部门负责人）提前沟通好，减少推动阻力，获得推行计划的承诺。

比如为了线上系统的监控和排障考虑，需要有健康检查、规范的日志格式等，这些业务需求之外的任务势必会增加业务团队的负担，如果没有从上至下的强制性推动，很难有实际进展。

架构团队万勿把自身置为其他团队的对立面。

6.在迭代周期内的重要环节都需要有架构团队（或架构评审委员会,后文会详说）的深度参与，包括需求调研，接口/数据库设计评审，代码评审，上线评审等。

这个对于创业公司起步阶段特别有益，因为在规范和标准没有在IT内部形成一种文化驱动的高度，同一个事情被不同的人做出来完全是千人千面，那对于一个组织来说，这种不可控是很危险的。

特别注意，这些参与绝对不能以俯视批判挑毛病的角度展开，而应该以合作共赢建议的方式展开。

当然如果是无法妥协的双方起冲突的问题必须通过授权来强制修正。

7.《架构及未来》把监控设计放在15条原则的第4条，它也是笔者推崇的一个重要原则。

监控可以把我们整个系统的健康度清晰的展示出来，两眼一抹黑只是另一种形式的掩耳盗铃。

监控的颗粒度细化到什么程度需要视团队成熟度有所不同，不在本文讨论范围。

重要的是，监控设计应该在系统的初期概要设计期间作为非功能性需求就考虑进去。

再做个提醒，监控可以视作运维工作的一部分，所以在前期做架构设计的时候，一些运维工作也应该记录Involve进来。

文件传输到底选择FTP还是接口传输，有没有考虑运维带宽、断点续传、CDN等问题呢？

8.尽量通过工程化来替代人工。

工程化就是Engineering，软件工程化是个比较抽象的概念，就是把软件按照工程的方式进行开发维护。

这里我们说的工程化可以简单理解成工具化，自动化的动手文化。

当然这里的“动手”不是打架，而是敲代码，Justshowmethecode。

我们的自动化运维、实时监控告警、自动化发布、智能排障，都是工程化手段来解放人力。

这也是驱使团队不断进步的一种方式，不能陷在一些重复劳动的舒适区里，要不断的想办法改进工作效率和质量。

9.架构团队出品的任何产品、流程必须建立最严格的标准，比如代码质量、性能指标、监控指标、高可用性、可扩展性等。

在一个大的组织架构里建立信任是个很慢的过程，但是失去信任却可能是瞬间的。

“架构出品，必属精品”应该是架构团队的一块金字招牌，必须保护好。

Besides,架构团队要有比较优秀的宣传能力，能够把自己的产品包装成一个高附加值的优秀作品，好像你不用就会懊恼一辈子似的，当然这一切都是必须是真实的不能盲目夸大。

因为笔者是实实在在看过不少架构师撰写的产品发布邮件，写的不痛不痒，平平淡淡，完全激不起想要试用一下的冲动，还何谈推广。

10.线上系统特别注意惊群效应的影响。

比如缓存失效后，如何解决惊群效应带来的数据库或者微服务化链路尾端服务的压力骤增的问题。

这个是技术问题。

比如秒杀场景下会有平时百倍千倍万倍的流量打进来，服务器资源会被瞬间消耗殆尽导致崩溃和瘫痪，这就不仅仅是技术问题了，还有与前线业务方协调沟通的问题，这种活动必须提前通知到IT。

来自维基百科：

Thunderingherdproblem惊群问题是计算机科学中，当许多进程等待一个事件，事件发生后所有这些进程被唤醒，而只有一个进程能获得CPU执行权，其他进程又得被阻塞，这造成了严重的系统上下文切换代价。

C10K/C10M问题都与这个相关。

还有两个类似的术语一并介绍下：

“Slashdoteffect点杠效应”这个词指的是当著名新闻网站Slashdot在一篇有趣的文章里报道了一个网站后许多人纷至沓来把它几乎挤爆的现象。

后来被列入其他著名网站后所发生的类似现象也用这个词来称呼了。

这个词和Flashcrowd这个更一般性、更合适的词对应。

“Flashcrowd突发访问拥堵”这个词是1973年LarryNiven在他的短篇科幻小说FlashCrowd中生造出来的。

小说预言了廉价的瞬移技术会使得一大群人都会传送到有趣的新闻故事发生的地方从而导致拥堵。

20年后，这个词在互联网上被广泛用于指当网站有了能吸引许多人