Visio画图

其实超融合这一块，放在云计算IT基础设施里面，不算是完全合适。你说它是分布式存储，但是它同时又是硬件服务器与存储；你说它算硬件，但是它又离不开分布式存储软件。

传统的IT基础设施架构，主要分为网络、计算、存储三层架构。但随着云计算与分布式存储技术的发展以及x86服务器的标准化，逐渐出现了一种将计算、存储节点融合在一起的架构--超融合架构。超融合将三层的IT基础设施架构缩小变成了两层。

2019年11月的Gartner超融合产品魔力象限中，领导者象限有5家：Nutanix、DELL、VMware、CISCO、HPE。（其中DELL vxRail一体机里面用的分布式存储软件也是VMware的VSAN，而VMware提供的则是VSAN纯软件的解决方案）

Nutanix能够成为超融合领导者中的领导者，自然是经过市场的充分验证，得到市场的认可。而且由于其公开资料（Nutanix 圣经）比较齐备，因此我们可以通过Nutanix一窥超融合的究竟。

这边就不搬运了，可以直接搜索引擎搜索“Nutanix圣经”或“Nutanix-Bible”，可以找到相应的官方文档。

引用自NUTANIX圣经 -“Nutanix解决方案是一个融合了存储和计算资源于一体的解决方案。该方案是一个软硬件一体化平台，在2U空间中提供2或4个节点。

每个节点运行着hypervisor（支持ESXi, KVM, Hyper-V）和Nutanix控制器虚机（CVM）。Nutanix CVM中运行着Nutanix核心软件，服务于所有虚机和虚机对应的I/O *** 作。

得益于Intel VT-d（VM直接通路）技术，对于运行着VMware vSphere的Nutanix单元，SCSI控制（管理SSD和HDD设备）被直接传递到CVM。”

个人总结： 从以上官方文档可知，2U的空间可以安装2~4个Nutanix节点（每个节点相当于1台物理服务器），所以设备装机密度非常高。每个节点都安装着虚拟化软件，并且在虚拟化层之上再运行着一台Nutanix的控制虚机（CVM），该虚机主要负责不同的Nutanix节点之间控制平面的通信。单个节点中配置有SSD硬盘与HDD硬盘，替代磁盘阵列作为存储使用，单个节点有独立的CPU与内存，作为计算节点使用。

1、基础架构

以3个Nutanix节点为例，每个节点安装有Hypervisor，在Hypervisor之上运行着客户虚拟机，并且每个节点有一台Nutanix控制器虚机Controller VM，配置有2块SSD与4块HDD，通过SCSI Controller作读写。

2、数据保护

Nuntanix与传统磁盘阵列通过Raid、LVM等方式作数据保护不同，而是与一般的分布式存储一样，通过为数据建立副本，拷贝到其他Nutanix节点存放，来对数据进行保护，Nutanix将副本的数量称作RF（一般RF为2~3）。

当客户虚机写入数据“见图上1a）流程”，数据先写入到本地Nutanix节点的SSD硬盘中划分出来的OpLog逻辑区域（相当于Cache的作用），然后执行“1b）”流程，本地节点的CVM将数据从本地的SSD的OpLog拷贝到其他节点的SSD的OpLog，拷贝份数视RF而定。当其他节点CVM确定数据写入完成，会执行“1c”流程，给出应答写入完成。通过数据副本实现对数据的保护。

数据从SSD中的OpLog写入到SSD以及HDD的Extent Store区域，是按照一定的规则异步进行的，具体详见下面的部分。

3、存储分层

Nutanix数据写入以本地落盘为主要写入原则（核心原则）。

当客户虚机写入数据是，优先考虑写入本地SSD（如果SSD已用容量未达到阀值），如果本地SSD满了，会将本地SSD的最冷的数据，迁移到集群中其他节点的SSD，腾出本地SSD的空间，写入数据。本地落盘的原则，是为了尽量提高虚机访问存储数据的速度，使本地虚机不需要跨节点访问存储数据。（这点应该是与VSAN与其他分布式文件系统最大原理性区别）

当整个集群的SSD已用容量达到阀值（一般是75%），才会将每个节点的SSD数据迁移到该节点的HDD硬盘中。

SSD迁移数据到HDD，并非将所有数据全部迁移到HDD，而是对数据进行访问度冷热的排序，并且将访问较少的冷数据优先迁移到HDD硬盘中。

如SSD容量达到95%的利用率，则迁移20%的冷数据到HDD；如SSD容量达到80%，则默认迁移15%的冷数据到HDD。

4、数据读取与迁移

Nutanix圣经引用-“ <u style="text-decoration: none; border-bottom: 1px dashed grey;">I/O和数据的本地化（data locality），是Nutanix超融合平台强劲性能的关键所在。所有的读、写I／O请求都藉由VM的所在节点的本地CVM所响应处理。所以基本上不会出现虚机在一个节点，而需要访问的存储数据在另外一个物理节点的情况，VM的数据都将由本地的CVM及其所管理的本地磁盘提供服务。</u>

<u style="text-decoration: none; border-bottom: 1px dashed grey;">当VM由一个节点迁移至另一个节点时（或者发生HA切换），此VM的数据又将由现在所在节点中的本地CVM提供服务。当读取旧的数据（存储在之前节点的CVM中）时，I／O请求将通过本地CVM转发至远端CVM。所有的写I／O都将在本地CVM中完成。DFS检测到I/O请求落在其他节点时，将在后台自动将数据移动到本地节点中，从而让所有的读I/O由本地提供服务。数据仅在被读取到才进行搬迁，进而避免过大的网络压力。</u> ”

个人总结： 即一般虚机读写数据都是读本地节点的硬盘，如果本地节点硬盘没有该数据，会从其他节点先拷贝过来本地节点硬盘，再为本地虚机提供访问，而不是虚机直接访问其他节点。即要贯彻本地落盘的核心思想。

5、Nutanix解决方案的优缺点

Nutanix方案优点：

1） 本地落盘策略，确保虚机访问存储速度：虚机写入的数据都在本物理节点的磁盘上，避免跨节点存储访问，确保访问速度，减轻网络压力。

2） 采用SSD磁盘作为数据缓存，大幅提升IO性能：

见上表数据，从随机的读写来看，SSD的IO及带宽性能比SATA的性能提升了约1000倍。而结合Nutanix的本地落盘策略，虚机数据写入，仅有本地的2块SSD硬盘作为数据缓存负责写入数据。

但由于单块SSD硬盘的IO比传统阵列的SATA高出1000倍，IO性能大幅提升。（相当于要超过2000块SATA硬盘做Raid，才能提供近似的IO性能）。

3）永远优先写入SSD，确保高IO性能

数据写入HDD不参与，即使本地SSD容量满了会将冷数据迁移到集群其他节点SSD，然后还是SSD进行读写，确保高IO。后续异步将SSD冷数据迁移到HDD。

4）数据冷热分层存储

冷数据存放在HDD，热数据保留在SSD，确保热点数据高IO读取。

5）设备密度高，节省机房机架空间

2U可以配置4个节点，包含了存储与计算，比以往机架式/刀片服务器与磁盘阵列的解决方案节省了大量的空间。

Nutanix方案缺点：

1）本地落盘及SSD缓存方案确保了高IO，但是硬盘的带宽得不到保证。

传统磁盘阵列，多块SATA/SAS硬盘加入Raid组，数据写入的时候，将文件拆分为多个block，分布到各个硬盘中，同个Raid组的硬盘同时参与该文件的block的读写。通过多块硬盘的并行读写，从而提升IO与带宽性能。

而Nutanix的解决方案中，单个文件的读写遵循本地落盘的策略，因此不再对文件拆分到多块硬盘进行并行读写，而只有本地节点的SSD硬盘会对该文件进行写入。

虽然SSD硬盘的IO与带宽都是SATA/SAS的数百上千倍，但是SSD对比SATA/SAS硬盘在带宽上面只有2~3倍的速率提升，而传统Raid的方式，多块硬盘并行读写，虽然IO比不上SSD，但是带宽则比单块/两块SSD带宽高出很多。

因此Nutanix的解决方案适合用于高IO需求的业务类型，但是因为它的读写原理，则决定了它不合适低IO、高带宽的业务类型。

三）行业竞争对手对比：

VMWARE EVO RAIL软件包：VMware没有涉足硬件产品，但EVO: RAIL 软件捆绑包可供合格的 EVO: RAIL 合作伙伴使用。合作伙伴转而将硬件与集成的 EVO: RAIL 软件一起出售，并向客户提供所有硬件和软件支持。

而EVO:RAIL的核心，其实就是VSphere虚拟化软件+VSAN软件的打包。

但VSAN与Nutanix最大的一个区别，就是不必须完全遵循Nutanix的本地落盘的策略。可以通过设置条带系数，将本地虚机的数据读写设置为横跨多个节点的硬盘，默认条带系数为1，最大可设置为12个，即一个虚机的数据写入，可以同时采用12个节点的SSD硬盘并行读写。

通过这种方式，VSAN可以一定程度的弥补了Nutanix方案不适用于带宽要求高，IO要求低的业务类型的缺点。

但是这种横跨物理节点的访问流量，在虚机数量众多的情况下，肯定会给网络带来压力，网络带宽可能会成为另一个瓶颈。

其次VSAN可以集成在Hypervisor层，而不需要像Nutanix在Hypervisor上面运行一个控制虚机CVM。

再次，Nutanix支持KVM、Hyper-V、ESXI等多种Hypervisor，而VSAN仅支持自家的ESXI。

其他待补充：由于暂时未对VSAN进行实际部署测试，仅停留在对其原理的研究，因此，关于VSAN的部分待后续平台上线测试完成后继续补充。

优酷 视频：运维就是一场没有硝烟的战争

最近在优酷上在线看了老男孩的“如何撰写优秀系统运维架构解决方案及推动实施案例分享”(一场没有硝烟的战争)的视频，非常有感触。随着业务和应用的发展，公司的IT架构和系统运维架构都是需要不断进行调整的，而作为运维人员在确保线上稳定的情况下还需要不断去深挖系统架构中存在的不足和潜在的问题，而系统架构的调整通常会面临风险，从这个角度上说运维就是一场没有硝烟的战争，这场战争背负着运维人员的价值和企业IT的自身发展和跨越。

一、运维人员的成长与价值

引用 老男孩 的一段话“在企业的实际工作中，大多数朋友在遇到工作中的架构、系统等等问题或缺陷时，起初都会主动和领导说，我们的系统，架构有什么什么问题，但是你和领导说完话后，领导经常会一笑置之，或者不以为然，杳无音信，甚至给你泼一盆冷水。你的积极主动的心态就这样日复一日的被磨平，加薪升职的机会也就变得遥远甚至无望。如果遇到比较好的领导，则会指引你，例如：让你写解决方案，并用数据说话，你可能苦于不会写方案或者撰写的方案太烂，导致最终没能达到推进改进工作中问题的目的，也因此错失了提升自己技能和发展的机会。”

他的这段话道出了大部分企业或公司里的现状，运维或IT人员通常被领导看做专业服务人员  ，IT部或运维部也通常被认为是成本部门而不是创造价值的部门，你做好是应该的，而出了问题就是你的责任，所以大部分运维人员提出的问题或系统缺陷不能引起领导的重视。但是作为一个运维人员，只知道按部就班的处理问题和解决故障，在企业里是很难得到重视和加薪升职的。

如果你要成为一个积极主动的优秀的运维工程师，就需要在完成本职工作的同时还能自己主动去研究一些问题，发现系统架构中的缺陷和不足，并最大限度的实现改进公司系统架构等问题，从而才能体现自身的创造工作价值，从而加快自身成长及获得提升的空间。

二、方案的撰写和演讲能力的培养

  很多运维工程师包括技术很牛的运维工程师，处理问题和解决故障很有能力和水平，但是却写不出一份优秀的技术方案，结果不能数据说话，也不能被领导了解和信服，这样无形中错失了很多表现和提升自己的机会；再或者遇到架构、系统等方面的问题或缺陷，自己知道但也不能写出一份优秀的解决方案，最后没能得到大家的认可，自己提出的建议没能被公司采纳并实施，自己也觉得很郁闷，久而久之失去了激情和创新的勇气。

   老男孩在这个分享的视频中，以一个线上性能问题的自然暴漏产生的一个具体的需求为例，去分析架构不合理存在的潜在隐患，并以一个具体实用完整的方案（包括架构图、硬件状况、业务分析）为例步步引导大家如何去撰写优秀的系统运维架构的调整解决方案并说服领导者以身推动方案的实施，教会大家在企业中如何做。这个案例非常具有典型性，也对正在成长的运维工程师们是个很好的启发和教育。

   初级运维是解决问题，中级运维是提出问题，而高级运维是发现问题并引领问题的解决。要写出一个优秀的系统运维架构解决方案，必然是对当前的系统架构非常熟悉，关注到问题并发现潜在的问题，并通过测试得到可信的数据，下一步通过开会讨论让大家信服并得到领导的认可，继而推动方案的实施，最后确定方案具体的实施人员和部门协作，成功完成方案的落地和实现，可以说每一个细节老男孩都说到了，发自肺腑啊。

   开会讨论环节，优秀的运维人员应该有非常好的演讲能力。一个优秀方案的提出，肯定是经过你细致认真思考的，对可能出现的问题都有经过你的测试并且有数据来支撑你的想法和观点，所以表述的时候你应该充满自信，这样大家自然会相信你，选择你的解决方案。同时要注意做两套方案，可供老大参考和决策，让老大做选择题而不是问答题，如果大家认可和接受了你的方案，自然风险大家同担，出了问题也不会都怪罪到你头上。那么演讲能力的培养，大家也不用担心，一回生二回熟，什么都是练出来的，好东西就要讲出来，自己应该最有信心才对。

三、新技术的关注和运用

 运维人员另一个创造自己价值、加快自我成长的方法就是要加强对新技术的关注和应用。举一个例子，某公司的小李是一名普通的运维工程师，在公司里工作两年后一直没有什么提升和加薪的好机会。但是他非常喜欢和关注虚拟化技术，经过认真学习研究一段时间后，花半个月写了一份优秀的虚拟化解决方案，针对本公司目前的开发测试的快速部署和迭代需求，从虚拟化的节省成本、快速部署、实时迁移、资源动态分配等角度完整全面的分析了存在的问题并经过自己测试得到的数据验证了自己的构想和解决方案。当他把这份报告提交到领导那里后，经过开会讨论，领导采纳了他的虚拟化解决方案，并提升他为虚拟化架构主管开始负责实施部署和应用。小李成功的从普通运维工程师转变为虚拟化主管，实现了个人价值的提升。当然我们身边这样的例子不少，相信大家都会有感悟，更知道该怎么做。

  运维是一场没有硝烟的战争，面对不断变化的系统和架构，学习技术的同时更要学会发现、思考和成长，我想这正是老男孩告诉我们的。

网友看了老男孩老师的视频感悟，很棒。

来自：>

附件是我从百度文库里下载的，不多

其实这些图标就是一个收集的过程，比如其他方案里刚好有Visio源文件，就可以把一些图标收藏起来，或者跟同行的人要这些图标，又或者自己去网上搜

业务架构说明的是商业组织和流程，主语是组织和人，句子都是做什么业务，输出什么。

功能架构说明的是IT系统将流程里面某些任务自动化，主语都是系统，比如系统前端呈现什么，系统后台处理什么，罗列了系统里的功能。

系统架构说明的是IT系统由什么硬件软件模块来实现，比如有数据层，处理层，Web前端，微信前端等；有的系统架构也包含部署架构：比如数据库跑在一台机子上。

技术架构的定义比较宽泛，按你的问题，往小里面考虑，就是我这个应用到底用什么“软件”技术来实现，比如Java的SSH？还是SSO？

应用架构，按你的问题，也要往小里说，可以说你应用里用了写了写什么组件。比如爬虫系统+内容管理系统+用户前端=商业情报系统。

DCIM (Data Center Infrastructure management) 也就是数据中心基础设施管理，将IT（信息技术）和设备管理结合起来对数据中心关键设备进行集中监控、容量规划等集中管理。通过软件、硬件和传感器等，DCIM提供一个独立的管理平台，对数据中心IT设备和基础设施进行实时监控和管理。就是在基础的机房动环监控之上发展的更为专业，更为细致，更为全面的一套系统吧。目前一个项目正在对接深圳 计通的DCIM，宣讲会上了解的

host-base：基于主机

lan-base：基于局域网

lan-free：基于SAN

server-free：基于SAN

LAN-FREE

环境：RS6000+FASTT700+3583带库,所谓LAN-free，是指数据不经过局域网直接进行备份，即用户只需将磁带机或磁带库等备份设备连接到SAN中，各服务器就可把需要备份的数据直接发送 到共享的备份设备上，不必再经过局域网链路。由于服务器到共享存储设备的大量数据传输是通过SAN网络进行的，局域网只承担各服务器之间的通信(而不是数 据传输)任务。

LAN_FREE是专门用于SAN环境下的备份,可以使备份的数据直接通过SAN的链路从备份客户端(AIX主机)到备份设备(磁带机,支持光纤),有别 于传统通过LAN链路的备份方式,这样可以不占用以太网络的带宽,一般要求硬件设备支持光纤存储(磁带机,阵列),需要通过SAN交换机(2109等)设 备将这些设备连接起来,软件要求TSM,和TSM对LAN_FREE支持的AGENT数据库可用TDP。

下图展示了Lan Free备份的方案架构图:

在这里插入描述

SERVER-FREE

SAN Server-Free备份 LAN Free备份对需要占用备份主机的CPU资源，如果备份过程能够在SAN内部完成，而大量数据流无需流过服务器，则可以极大降低备份 *** 作对生产系统的影响。SAN Server-Free备份就是这样的技术。

在这里插入描述

一、备份的概念

备份顾名思义，就是将数据以某种形式保存下来，备份的根本目的在于恢复，在这些数据丢失、毁坏和受到威胁的时候，使用数据的备份来恢复数据。虽然备份的定 义可能很简单，不过具体实施存储系统的备份却可能是一份艰巨的任务，其中包含了许多可以预见的以及不易预见的需要考虑的因素。

二、备份与拷贝、归档的区别

备份不能仅仅通过拷贝完成，因为拷贝不能留下系统的注册表等信息；而且也不能留下历史记录保存下来，以做追踪；当数据量很大时，手工的拷贝工作又是何其麻 烦。备份=拷贝+管理。管理包括备份的可计划性、磁带机的自动化 *** 作、历史记录的保存以及日志记录等等。正如生命周期理论将在线数据分级为在线和近线数据 一样，离线数据亦可分为备份与存档数据，以降低投资和运维成本。

存档的目的是将需要长期备查或转移到异地保存/恢复的数据存放到可移动存储介质上。严格意义上讲，存档的目的不是为了保障数据安全，而只是为了实现数据仓 储。如果说备份相当于桌头的字典，工作时会经常翻用，存档则好像日常工作中生成的一些具长期保存价值的文字资料，被转移到书架上或档案馆里备查。

三、常规备份的实现方式

通常一套完整的备份系统包含备份软件、磁带机/磁带库、和备份服务器，具体的备份策略的制定、备份介质的管理以及一些扩展功能的实现，都是由备份软件来最 终完成的。在备份服务器上安装备份软件的服务器端，在应用服务器端安装备份软件的客户端代理，如果是数据库应用还需要相应的数据库接口程序，客户端代理软 件和服务器端软件协调工作，按照预先制定的备份策略自动或手动的将数据备份到磁带上。然而一个具有一定规模的数据中心的数据备份要涉及到多种UNIX平台 和不同的数据库类型，可以想象每天的备份工作对于管理员来说都是一个挑战。

备份策略制定是备份工作的重要部分。一般来说需要备份的数据存在一个2/8原则，即20%的数据被更新的概率是80%。这个原则告诉我们，每次备份都完整的复制所有数据是一种非常不合理的做法。事实上，真实环境中的备份工作往往是基于一次完全备份之后的增量或差量备份。

完全备份很好理解，即把所有数据进行一次完整的备份，当进行恢复的时候只需要一盘磁带；

增量备份是只有那些在上次完全备份或者增量备份后被修改了的文件才会被备份，如下图，优点是备份数据量小，需要的时间短，缺点是恢复的时候需要多盘磁带，出问题的风险较大，

差量备份是备份那些自从上次完全备份之后被修改过的文件，如下图，因此从差量备份中恢复速度是很快的，因为只需要两份磁带（最后一次完全备份和最后一次差量备份），缺点是每次备份需要的时间较长。

备份窗口是在进行备份 *** 作时，应用系统可以接受的最长备份时间，对于某些5X8类型的非关键应用备份窗口可以很大，但是对于7X24小时的应用备份窗口就会很小。

四、LAN Free和Serverless备份

所谓LAN Free Backup顾名思义，就是指释放网络资源的数据备份方式。

在SAN架构中，备份服务器向应用服务器发送指令和信息，指挥应用服务器将数据直接从磁盘阵列中备份到磁带库中。在这个过程中，庞大的备份数据流没有流经 网络，为网络节约了宝贵的带宽资源。在NAS架构中，情形十分类似，磁带库直接连接在NAS文件服务器上，备份服务器通过NDMP协议，指挥NAS文件服 务器将数据备份到磁带库中。细心观察之下会发现，这两种方式虽然都节约了网络资源，但却增加了服务器的工作负荷，缺点是价格非常昂贵，大多数备份软件的 LAN Free功能选项都需要用户付出高昂的价格。

Serverless Backup技术是以全面的释放网络和服务器资源为目的的，技术核心就是在SAN的交换层实现数据的复制工作，这样备份数据不仅无需经过网络，而且也不必 经过应用服务器的总线，完全的保证了网络和应用服务器的高效运行。但是现实情况却没有这么理想，Serverless Backup技术目前只能停留在纸面上，实际实施效果很差，完全不需要主机干预还不现实。

存储基础知识（八）：备份技术（下）

一、主流备份软件

备份软件厂商中头把交椅当属Veritas公司。这家公司经过近几年的发展和并购，在备份软件市场已经占据了四成左右的份额。其备份产品主要是两个系列 ——高端的NetBackup和低端的Backup Exec。其中NetBackup适用于中型和大型的存储系统，可以广泛的支持各种开放平台。NetBackup还支持复杂的网络备份方式和LAN Free的数据备份，其技术先进性是业界共同认可的。

Backup Exec是原Seagate Soft公司的产品，在Windows平台具有相当的普及率和认可度，微软公 司不仅在公司内部全面采用这款产品进行数据保护，还将其简化版打包在Windows *** 作系统中，我们现在在Windows系统中使用的“备份”功能，就是 OEM自Backup Exec的简化版。2000年初，Veritas收购了Seagate Soft之后，在原来的基础上对这个产品进一步丰富和加强，现在，这款产品在低端市场的占用率已经稳稳的占据第一的位置。

Legato公司是备份领域内仅次于Veritas公司的主要厂商。作为专业的备份软件厂商，Legato公司拥有着比Veritas公司更久的历史，这 使其具有了相当的竞争优势，一些大型应用的产品中涉及到备份的部分都会率先考虑与Legato的接口问题。而且，像Oracle等一些数据库应用干脆内置 集成了Legato公司的备份引擎。这些因素使得Legato公司成为了高端备份软件领域中的一面旗帜。在高端市场这一领域，Legato公司与 Veritas公司一样具有极强的技术和市场实力，两家公司在高端市场的争夺一直难分伯仲。

Legato公司的备份软件产品以NetWorker系列为主线，与NetBackup一样，NetWorker也是适用于大型的复杂网络环境，具有各种 先进的备份技术机制，广泛的支持各种开放系统平台。值得一提的是， NetWorker中的Cellestra技术第一个在产品上实现了Serverless Backup的思想。仅就备份技术的先进性而言，Legato公司是有实力可以挑战任何强大对手的。

除了Veritas和Legato这备份领域的两大巨头之外，IBM Tivoli也是重要角色之一。其Tivoli Storage Manager产品是高端备份产品中的有力竞争者。与Veritas的NetBackup和Legato的NetWorker相比，Tivoli Storage Manager更多的适用于IBM主机为主的系统平台，但其强大的网络备份功能觉对可以胜任任何大规模的海量存储系统的备份需要。

CA公司是软件领域的一个巨无霸企业，虽然主要精力没有放在存储技术方面，但其原来的备份软件ARCServe仍然在低端市场具有相当广泛的影响力。近年 来，随着存储市场的发展，CA公司重新调整策略，并购了一些备份软件厂商，整合之后今年推出了新一代备份产品——BrightStor，这款产品的定位直 指中高端市场，看来CA公司誓要在高端市场与Veritas和Legato一决雌雄。

二、带机、带库厂商及产品

备份设备的生产厂家很多，每个厂家都有着较长的产品线，由于篇幅所限，我们不可能一一列举。这里主要介绍那些国际知名的、国内有影响力的带机和带库原厂商 及其主打产品。目前，带机正在朝快的数据传输速度和高的单盘磁带存储容量方向发展，具有主流驱动技术的带机厂商包括Quantum、Exabyte和 Sony等。

Quantum带机在中档产品中占据了市场大部分份额，但其中很大一部分走了OEM的销售渠道。其自动加载机SuperLoader可将多个备份目标集中 到一个共享的自动系统中，降低处理成本，而基于磁盘（备份介质是磁盘）又具有磁带海量特性的近线备份设备DX30可显著缩短备份与恢复时间。

Exabyte的磁带驱动技术包括8mm Mammoth和VXA技术，VXA是定位低端的新的磁带技术，它以包的格式读写数据，并可对磁带上的数据记录区进行无空隙扫描，具有高质量、高可靠性、低成本等性能特点。其中VXA－1带机专为苹果机设计的存储方案；VXA－2同样具有较高的性价比，并具有12MB/s传输速率及160GB容量，与VXA－1向下兼容。

这里我们有必要讲一讲Sony的基于AIT技术的带机产品：AIT－1、AIT－2和AIT－3，其中AIT－3是高性能和大容量的新存储方案，容量（未 压缩）为100GB，速率为12MB/s，而且能够与AIT－1、AIT－2完全读和写逆向兼容，并具有分层磁头、创新性的磁带内存储器(MIC) 驱动器接口系统等多项专利技术，提高磁轨密度和存储速度。

磁带库厂商相对品牌较多，用户的选择空间也更大一些。目前主流的磁带库厂商主要有STK，Quantum，Exabyte和IBM等。

在带库厂商中，市场份额最大的当属美国存储技术公司（StorageTek，STK）。STK目前最主要的产品线是L系列，包括L20、L40、L80、 L180、L700、L5500，从最小20磁带槽位到最大5500磁带槽位。在其入门级产品上，支持LTO、DLT和SuperDLT等开放技术，只有 在高端产品上才同时支持其自身拥有的9840、9940驱动技术。

Quantum拥有DLT、SuperDLT技术，其用户基础和发展前景都很好。其P系列的主打产品P4000和P7000分别可以支持几百槽位和十几个 驱动器，适合于企业级用户；M系列是模块化的产品，可根据用户系统需求的增长灵活扩展带库的容量和性能，M1500可从20槽位扩展到200槽 位，M2500则可从100槽位扩展到300槽位，非常适合于那些快速发展的中小企业。美中不足的是，ATL对超大容量的解决方案不是非常理想，在这一部 分市场上的竞争力较弱。

8mm是安百特（Exabyte）公司的独立技术，具有速度快、容量大、可靠性高、价廉、体积小等特点，主要用于带库，其8mm带库的智能机械臂系统可任 意存取磁带，采用模块化设计，产品线全，从VXA自动化/驱动器产品系列AutoPak230/115/110、VXA-1/1到Mammoth Tape自动化/驱动器产品系列X200/80/430M/215M/EZ17、M2/Mammoth/Eliant 820，容量从单盘（非压缩）33GB到整库12TB，涵盖由低到高的用户市场，可实现无人值守自动数据存储管理，适用于服务器备份、网络备份、自动归 档、分级存储管理及图形图像等领域。

IBM，众所周知，生产和销售所有IT类产品，当然也包括带库产品。IBM的带库和带机产品大体可分2个系列：用于IBM环境的和用于开放环境的。如 IBM的3494、3575等带库只支持其专用的驱动器，开放性差，虽然这些带库产品也支持HP、SUN等主流服务器平台，但实际上几乎只用在IBM环境 中。随着SAN技术的普及，追求开放性和互联性成为存储行业的潮流。结合LTO驱动技术的投产，IBM为其开放存储系统解决方案推出了新的带库系列—— 3583和3584。

三、备份技术新趋势

D2D2T是Disk to Disk toTape的缩写，即数据备份从磁盘阵列到磁盘库到磁带的过程。传统的磁带备份总是会带给用户以下苦恼：

1、备份速度慢，备份窗口冗长

2、备份的根本目的在于恢复，而磁带的恢复速度很慢，对于TB级的数据恢复等待时间过长

3、磁带介质受灰尘、温度、湿度影响很大，难以保证已经离线保存的磁带在需要的时候可以正常工作

4、磁带库的机械手等物理设备的故障率和磨损率相对电子元件较高

相信长期从事磁带备份工作的管理员（尤其是大数据量关键应用的磁带备份）对以上几点都会深有感触，尤其是当在线数据受到破坏，需要依靠磁带备份来恢复正常生产的时候，大家都会为能否顺利恢复数据捏一把汗。

有什么办法可以解决磁带备份固有的劣势呢？随着磁盘容量的增长价格的下降，使用磁盘备份作为磁带备份的补充甚至替代都成为可能，当然磁带体积小，便于归档 等特点是磁盘设备不具备的，因此D2D2T即磁盘到磁盘到磁带备份方式有效地中和了磁盘备份和磁带备份的优点，在线数据保存在高速磁盘阵列，备份数据首先 保存在性价比较高的SATA磁盘阵列中，然后定期将磁盘备份的数据保存到磁带上，这样既缩短了备份窗口又增强了数据恢复的可靠性。

作者介绍

常红平， IT职场老兵，在做过除用户体验设计师外的所有软件研发团队中的角色后，于10年前开始专注于管理。爱技术、爱敏捷、爱读书、爱分享。现在IBM CIO中国实验室作为IBM全球软件和云服务销售系统负责人，领导IBM年交易量数百亿美金的核心系统的研发和运维工作。近年来，他还带领跨国团队成功实施了一系列敏捷转型、技术革新、和组织文化转型。

随着数字化时代全面到来，组织的敏捷转型已经成为必然。

2017年中国开发者调查报告显示，在彼时已有456%的开发者声称采用了敏捷开发模式。但如果详细了解这些开发团队，事实上很多还是在用新瓶装旧酒，甚至只是把原有的流程换个新名词而已。

时至今日，国内除一些互联网大厂和顶尖外企能够做到 极致的敏捷 外，大量的传统研发组织还处在敏捷转型的进程中，而小型初创公司也仍需要将原来粗放的研发管理转向精细化、规模化。

比如最近好几个业界同行在咨询我敏捷转型应该怎么组建团队：

仅关于敏捷组织架构的问题就包罗万象，所以我想还是有必要把这个话题详细聊聊。毕竟一个合适的敏捷组织架构是组织敏捷转型成功的最基本条件之一。

会者不难，在一个高效敏捷组织中司空见惯的事情，放到非敏捷组织中会被认为不可思议。今天就先聊聊一个极致的敏捷组织或者敏捷转型成功后一个组织大概会长成什么样子。

当然敏捷的组织架构只是敏捷实施成功的因素之一。但因篇幅有限，本文暂不涉及敏捷流程、实践、文化等部分。

简单起见，我们从小往大讲。假设你现在加入了一家初创公司，全权负责公司的IT部分。你拥有了一个响亮的头衔叫做研发总监，但手下其实也就有十来个人，你要怎么组建团队呢？

一、初创研发团队

你最先想到的一定是 全功能 ，也就是团队中要具备各种必需的角色：业务分析、开发、测试、运维，等等。无论大小，一个非全功能团队基本无法做到端到端的从需求分析到系统上线到运维的工作。

再有就是角色之间要 比例协调 。全栈工程师当然好，但是在你的小初创公司里养不起样样精通的牛人，全栈只是因为缺钱不得已而为之的选择。那只好让大家尽量一专多能，每个人有专长，必要时能互相帮个忙。

此时你还没有必要拆分团队。团队从上到下、从业务到技术都是你一把抓。你只好工作996，还勉强能应付。

二、小型研发团队

公司业务发展还不错，你的团队要扩张了。这对你来说是个happy problem，你一个人肯定管不过来了，必须要有人帮你。于是你把一个你一手培养起来的得力干将提拔起来做一线经理。但因为研发团队就你们两个经理，于是你俩决定各分管一摊儿，但你总体负责就好。

既然是各分管一摊儿，两个部门最好都能独立运行，之间的交互除了必须的系统集成等必要的沟通外，互相依赖越少越好。所以你们决定在每个部门都复制全功能团队的做法。

但怎么把原来一个大团队拆成两个小部门呢？你俩决定还是按功能模块拆。这样两个部门之间的耦合最小。什么？一个部门开发，一个部门测试？马上2020年了，难道你们还在用瀑布式开发吗？对不起，如果是的话，这个故事我根本编不下去了，你的小公司根本活不到A轮好吗？

部门拆分造成了一段时间的混乱。职责不清、互相指责、踢皮球的事时有发生。原来的单体软件架构之前本来运行得好好的，因为模块间的严重依赖关系更加剧了职责划分的难度。几次严重的发布失败和系统宕机后，你俩一边改进软件架构，一边梳理研发流程，终于在部门职责划分上达成下面几个共识：

1、面向资产： 资产可以是模块、应用程序、服务、平台等等。每个部门所负责的资产范围都要清晰，避免扯皮。如果不面向资产而是面向跨资产的业务功能、特殊技能等等划分团队，会造成大量跨部门的沟通。比如当两个部门在基于同一个模块开发时，会有大量代码耦合甚至冲突的问题。这时必须要在技术层面进行模块拆分和解耦。而当一个部门基于多个资产开发时，因为要学的东西太多，新人很难培养起来，所以当出现问题或者研发进度受阻时，团队成员之间无法互相支持。

2、端到端负责： 首先是需求分析、开发、测试、部署的端到端，自己部门的事情自己从头到尾负责，尽量不求助于其他部门。其次是开发和维护的端到端。谁开发的功能，谁就应该维护。谁出的bug谁负责。这样保证各部门内沟通更加内聚，也跟其他部门降低耦合。

3、稳定的： 各部门成员应该是相对稳定的，不经常被调动，以保证团队不总是跟新成员磨合。部门中每增加或减少一个人，团队都要经历一整轮的组建期、激荡期、规范期、和执行期（Forming, storming, norming and performing），这对团队的发布速率是有很大负面影响的。当然出于团队成员职业发展的需要，应该给团队成员定期轮岗的机会。但这种轮岗不应过于频繁。

4、专注的： 各个部门应该有清晰的工作范围，并专注在这个范围内工作，而不是总要求去做很多团队职责范围之外的“杂事“，即使它很重要很紧急。这样既能保证团队的工作效率，又能培养团队在某项或某类任务上的专长。你们捋了一下团队经常抱怨的“杂事”后，发现其实很多事情在更高层面看也很重要，所以你们决定把这些事情划分到相关部门的正式工作范围内，并尽量在项目计划阶段考虑进去。

这样的共识达成之后，部门间合作顺畅了不少。

但随着公司的发展，每个部门的人也越来越多，你又觉得有些管不过来了。有了上次拆分的成功经验，你们决定尝试把这个做法也应用到部门内部——把部门内成员再划分成几个小团队。毕竟长期996之后你身体也开始有些吃不消，你希望团队有些事自己能自组织地做起来，而不是都依靠经理。

经过一番调整尝试，你梳理了部门内各个小团队的文化和规模，最后又得出几个关于小团队的最佳实践：

1、小的： 你发现5到9个人的小团队规模是比较合适的，因为小团队成员之间的沟通基本靠喊。虽然面对面沟通效率很高，但因为这是所有人对所有人的广播式、全渠道沟通，当团队变大时，沟通成本会呈指数级提高，造成效率急剧降低。而当团队太小时，保证全功能又比较困难。当然在某些特殊情况下，把团队控制在5-9个人可能有实际困难，但是4-12人是底线了，再多再少都不好了。

2、每个队员为整体团队负责： 这个团队文化你在团队扩张之前就一直在强调了。大家都是兄弟，出了事自然应该一起扛。但是在团队扩张之后不知为何这个文化就慢慢没有了，是因为新人太多冲淡了原来的文化？后来你才知道并不是。你悟出了组织架构是组织文化的基础。扩张每个团队那么大，职责不清楚，即使大家想为整体团队负责，也有心无力。当团队变小、份内的职责变清晰后，大家才更容易做所谓份外的事情，整体团队才更容易实现。

这样在部门内拆分出小团队后，即便每个小团队都不再设小队长的职务，但因为他们可以相当程度的自组织，你们两个部门经理一人带2-3个小团队感觉轻松了许多。既然日常研发管理方面压力小多了，你俩也可以专注在部门发展，人才培养、目标管理、客户关系等更重要的事情上了。

好了，现在你的小型团队终于可以比较高效的运转了。你突然发现你的每个小团队自然演进的结果居然和业界著名敏捷公司Spotify组织架构中的 小分队（Squad） 模式很像：

研发效率上去了，公司业务再次爆发式增长，你俩的happy problem又来了，团队规模要再扩张一倍。怎么办呢？

三、中型研发团队

你俩决定复制之前成功经验。部门既然可以一生二，就可以二生四，将来四生八，实现传说中的指数级增长。

但是好像事情并没那么简单。现在是4个研发经理了，团队也快涨到100号人了。每个经理的日程表都被排得满满的。原来两个经理有事情商量插空就可以做，但现在必须提前好久约大家时间开会。整个团队项目计划时就更痛苦了。即使各个部门间耦合度已经很低了，但完全没有是不可能的。既然有耦合依赖关系就需要协调工作，但有那么多团队要协调起来导致会议又多又长、还低效。研发人员写代码的时间被严重挤占了。

于是在又一次长达数个小时的管理层会议后，你们总算想到了一个解决方案。能不能在小团队层面做一些聚合，或者在整个研发组织层面做更高层次的拆分呢？

说干就干。你们把现有的小分队都拿出来重新分了几个大组，每个大组都像小分队一样遵从高内聚、低耦合、全功能的原则来划分。每个大组负责一个大的或者一组紧密相关的资产，并且能独立完成所负责的资产的端到端的研发工作。每个大组之间的耦合尽量小，所有事务都尽量在大组之内完成，尽量避免跨大组的沟通。

每个大组内的几位一线经理中会选出一个总负责人，作为各大组间的沟通接口和大组内事务的总协调员，由大组内最资深的经理来兼任，你自己作为资深经理之一也开始兼任大组负责人。

上面的组织变革自然又少不了一番软件架构上的调整，系统拆分、解耦、等等。毕竟技术债是要及时还的，留多了到必须连本带利还的时候恐怕就想还也还不起了。

好了，改造完之后，现在整个研发组织的沟通被拆分成了大组之间的沟通。成本一下子就降下来了。原来随时可以开的管理层碰头会终于在大组内又想开就能开了。团队的各种沟通协调在大组内也容易做得多。大家终于又可以把时间用在愉快地撸代码上，而不是冗长的会议上了。

各个大组都是以各个大业务模块划分的，所以根据各模块所需要的人数不同，各大组的人数也不尽相同。这没关系。但你观察发现，一般一个大组最好控制在50人以内，或者是包含2-5个小分队。当人数超过这个之后，大组内小分队间的沟通成本会急剧升高。

大组内个小分队间的沟通还是挺多的，毕竟他们所负责的资产都紧密相关。这样协调工作是少不了的。原来这都是部门经理一把抓，但是组织大了，系统复杂了之后经理就必须放权让员工负责了。托从大公司高薪挖来的HR**姐的福，公司的管理和技术岗位的双线职业发展路线也弄清晰了，是时候在组织内培养一些专职技术人才了。

本来各个部门甚至小团队都有架构师、业务分析师等，现在基于大组内各小分队间协调工作的需要，你开始设立总架构师、总业务分析师等等。他们的职责范围在大组内不但是跨小分队的，也是跨部门的。当然你还有一些角色像用户体验设计师、系统管理员等等，他们也是在大组内被小分队共享的。

中型团队的组织架构终于组建差不多了。你突然想起应该参考下Spotify的组织架构图，你惊喜地发现你们所构建的大组很像Spotify中的 部落（Tribe） 。你自己所兼职扮演的角色叫做部落带头人。

但部落带头人是个兼职角色，你除了要把自己的各个小分队带好外，部落内事务要协调，部落外沟通也要做。你发现自己连996都快搞不定了，简直在向007发展。

你又发现部落内的关键角色，像总架构师，总业务分析师等等也跟你一样忙得焦头烂额。更可怕的是，除了他们，其他人好像并没有那么忙。

在公司强制规定的996的上班时间里，很多人工作根本不饱满，你甚至发现有员工在边工作边摸鱼了！与其这样，大家都提高工作效率把工作时间改成正常965不好吗？

你知道这些问题不解决，别提公司进一步发展壮大、上市、出海，就连生存都有危险了。

到底根源在哪里，怎么迈过这个坎呢？再大型的组织怎么搞，传统组织怎么办？

四、突破瓶颈

到底问题在哪里呢？自己漏掉了什么重要的细节吗？你回过头重新查看Spotify的组织架构图，赫然发现自己确实漏掉了一个细节—部落带头人应该是轮值的。

中部分内容源于spotifycom

之前怎么没想到呢？轮值最不济可以让自己隔段时间休息下啊。你有点儿不怀好意地笑了。当然你猜轮值的主要目的是分享转播知识和技能，培养后备人才。那除了部落带头人，是不是其他关键角色也应该轮值呢？试试就知道。

于是你力排众议开始执行轮值制度——所有部落内关键角色必须定期轮值，保证任何关键角色必须有备份。关键角色既包括几位部落带头人（包括你本人），也包括部落中的关键共享角色。轮换周期为半年到一年不等。

通过定期轮值制度，经过一段时间的阵痛后，组织内的瓶颈和单点故障终于慢慢消除了。原来分散在各个关键人物头脑中的知识被强制地文档化和分享。通过轮值，你发现其实组织中还有很多有能力的人才，只不过在没有轮值之前他们根本没有机会表现出来。

后来你才知道，这些有能力的人才里有人曾经因为遇到职业天花板悄悄地计划过离职，但是因为轮值制度让他们看到了希望，学到了新东西，他们最终选择留了下来。

那些原本是瓶颈和潜在单点故障员工，并没有因为自己变得不那么重要了而沮丧。相反他们非常高兴。他们的工作生活变得平衡了，而且仍然有机会展现自己的能力。当他们有机会向上发展时，他们的经理不会因为团队对他们的过分依赖而不敢放手，反而会帮他们赢得机会，哪怕是部门之外的。这不是传说中的服务型领导吗？

通过轮值，组织中变得人才济济。你发现那些关键总控角色慢慢变得不再需要了。于是无论是总架构师还是总业务分析师，你开始尝试让他们回归到小分队，这样其实连轮值都不需要了。大家在需要讨论跨小分队架构或业务需求时聚到一起共同决定下就好。

有意思的是，你发现虽然轮岗后关键人才回归了到了基层小分队，但真正的人才其实有没有那个头衔都会发光的。老外管这个叫Leadership without position power。大家虽然都是平级，但是真正的人才不需要级别比别人高就能展现影响力，大家也很愿意听他/她的意见。这样的人才走到哪里都是Thought Leader——思想领袖。你也发现自己主导了这么多改进后，虽然仍然是一线经理中的一员，你也变成了一线经理中的Thought Leader。你知道你离晋升应该不远了，如果公司能继续发展，你自然就是那下一个被任命的人。

五、大型研发团队

机会总是会留给有准备的人。而且对于有准备的人，机会永远不缺。现在它就来了。因为研发团队支持业务快速发展，公司业务蒸蒸日上，现在研发团队规模再次扩张，真的实现了指数级增长。

你名片上“研发总监”的头衔虽然没有变，但是你已经从一线经理晋升为二线，开始管理多个部门了。

你发现团队越大，团队间自组织沟通就变得更重要。但是这次你学聪明了，与其每次都自己摸索踩坑，不如先看看业界最佳实践是什么。翻开Spotify的组织架构图，你发现里面果然有这样的正式虚拟组织。它叫做 行会（Chapter） 。

你看到行会一般是一个部落内部相同角色组成的虚拟组织。它的组成可以是为了项目需要，也可以是为了职业发展或兴趣。你立刻想到各个小分队中的架构师经常聚在一起讨论整个部落级别的架构；各个小分队中的业务分析员也经常聚在一起讨论跨小分队的需求。这不就是事实上的架构师行会和业务分析师行会嘛？！

于是你鼓励小分队中的所有角色都建立自己的行会。开发人员组成了开发者行会，测试人员组成了测试者行会。这些行会都自己行动起来，制定代码规范、测试覆盖率提升计划、学习新语言、新技术等等，搞得热火朝天。

行会是部落内部的，跨部落的虚拟组织也有，在Spotify里叫 公会（Guild） 。公会比行会更加松散，多是一些兴趣小组，当然必要时也可以是临时的项目委员会。毕竟跨部落的耦合度再低也是有的。

一开始时的行会和公会还是你要求员工组建的，后来大家气氛活跃起来了，就开始自己组织行会和公会了。大部分行会或公会自己都运行得很好，但也有少数不好的就逐渐自生自灭了。

你开始悟出作为管理者其实只要帮团队搭建一个良好的环境和平台，为他们指明方向，然后在必要的时候助推一下，团队可以自组织运行得很好。

Spotify的组织架构中还要求，一线经理应该是行会的带头人而不是小分队带头人担任。但这对团队的自组织能力的要求极高。这要求每个小分队都能完全自组织地端到端地完成从需求分析到发布的工作，而不需要小分队有个带头人协调解决问题。你认真地评估了下自己团队的自组织成熟度，离完全自组织还有一段距离。所以你决定暂时还是让一线经理端到端地负责各个小分队。但你知道培养团队自组织的道路还是要持续走下去。

六、跨国研发团队

公司终于在纳斯达克上市，业务成功出海，要在国外也建立研发团队以支持当地业务了。

于是你的团队中开始有外国团队了。你知道你应该遵循的团队组队原则仍然是高内聚、低耦合、全功能。因为时差的原因，跨国团队合作沟通自然没有本地团队顺畅，所以你尽量让每个部落都各自集中在一地。如果实在因为特殊原因不能在一地，至少是应该在一个时区、或者使用同一种语言。

有一个特例是支持型的团队，比如客户支持、平台运维支持等。因为要提供跨时区7乘24小时的服务，他们就必须要零散地分布在不同的时区。这样的成员至少应该和部落中某个小分队在一起，以便很容易地在部落间共享知识。

你在公司挑选的重点国家都建立了研发中心。你自己也从二线研发总监晋升到管理多个研发总监的全球研发副总裁。你努力保证组织的扁平性，每个研发总监大概有10个左右的一线经理向他们汇报，你自己有10个左右的研发总监向你汇报。你知道扁平的组织架构是服务型领导的组织架构基础。当某个一线或二线经理所管理的人数太多或太少时，你就把他们进行拆分或合并，保证他们所负责的业务量和团队规模是类似的。

你把高内聚、低耦合、全功能的组队原则活学活用后，惊奇地发现你的研发组织架构居然和几何学中的 分形 暗暗相合。

把你的组织放大分成数个部分后，每一部分都（至少近似地）是整体组织缩小后的形状。就像一颗大树拆分成枝杈，再拆分成树叶、再拆分成叶子上的脉络，每次拆分后的形状都和整个大树的形状相似。你的每个研发总监的组织架构和你的大组织架构也是类似的。你知道你即使以后做到高级执行副总裁去管理整个跨国公司的研发组织，它的架构也应该大致长成这个样子。

七、传统组织怎么办？

故事讲完了。故事中的主人公虽然是虚构的，但他/她所构建的组织架构在现实中确是真实存在且高效运转的。如果你所在的公司恰好正经历故事中从小到大的扩张，也许你可以借鉴一下其中的团队组建方法。

但是，现实中的大多数问题其实来自于已有的传统研发组织的转型过程。

传统研发组织的转型是个更大的话题。传统组织因为 历史 原因欠债太多——组织债、文化债、技术债等等，转型的难度远比初创公司在发展过程中遇到的大得多。这些 历史 欠债还会纠结在一起互为因果，在转型过程中单纯地去还其中任何一个债都无法让转型成功。这需要组织变革者像抽丝剥茧一样地一层层地改造。这个话题我们放到后面有机会讲。今天只聊纯组织划分过程中的原则。

上面故事中的团队是一个逐渐生长壮大的过程。但不要误认为组织架构设计是自底向上搭积木的过程。正相反，即使在组织成长期，组织架构的搭建也是自顶向下不断拆分和解耦的过程。这与敏捷流程和实践的改进和创新不同，它们应该是自底向上不断演进的。作为组织领导者，在组织架构设计时，应该先根据自身业务特点划分出业务领域、业务子领域、然后是部落和部落中的小分队。

但问题是从哪里入手做拆分和解耦。在一个传统组织架构中，各个系统和团队间可能都是紧密耦合的。系统间的边界很难被识别。

这时候该用到康威定律了。根据康威定律， 设计系统的架构受制于产生这些设计的组织的沟通结构 。说人话就是 你想要什么样的系统，就建什么样的团队 。就是说组织设计者可以按照期望的系统架构先搭建组织。在新组织架构运行一段时间后，系统会自然会像组织相同的结构演进，从而促进组织间的解耦。

你想要什么样的系统我不知道，但一个好的系统大概率应该是可以按业务功能端到端发布的。从业务需求上看，各业务领域的变更频率通常是差别很大的。这就要求各业务领域之间能保持低耦合并且可以独立发布。这也是拆分和解耦的目的。通过拆分，减小批量大小；通过解构，减少领域之间依赖，从而达到加快价值交付的目的。所以我们在识别部落时应尽量以业务领域划分，而不是技术、职能等。

例如，在传统的单体企业应用架构中可能有展现层，中间件层，和基础架构层。如果团队按照这三层划分，很有可能的结果是所有业务模块在各层都高度耦合，而任何业务领域或业务模块的需求都不能被独立发布。

现代的微服务架构则是以业务为边界的，且每个微服务都是端到端发布的。团队如果按照业务领域划分，实际上会帮助跨领域的服务间保持松耦合。

随着中台技术的兴起，系统架构会分为前台，中台，基础平台等等。中台又可以分为技术中台，业务中台，数据中台等等。不同于传统单体架构的中间件层，中台本身也是具备业务能力的资产，应该被单独测试，单独上线。而因为前、中、后台的上线频率相差甚远，所以按平台来划分团队是合适的。

八、结束语

总结一下，本文讲述了组建敏捷研发组织架构的一些原则和在Spotify框架内的一些实践。无论是小型团队还是大规模敏捷，组队的核心原则都是 高内聚、低耦合、全功能 。

组队的方法是将整个组织按业务领域或平台自顶向下不断拆分，直到拆成一个个小分队为止。理想情况下每个负责发布功能的小分队都能独立完成从需求分析到发布的端到端的工作。跨小分队和部落的必要沟通通过行会和公会来自组织地进行。

无论是小分队还是部落，作为一个团队，它的组织架构是骨肉，但团队 整体负责，荣辱与共 的文化和实践才是灵魂。它让团队能够整体优化，而不是局部优化。如做不到这一点，这个团队只能被称之为一群人而已，而不能被称之为敏捷团队。如何在能力建设、敏捷实践和激励机制的保障下真正做到团队的整体负责，荣辱与共，我们有时间单独聊。

作为组织管理者，构建一个好的组织架构和组织文化也只是让组织高效运转的最基础的条件。在此之上还要为组织创建 健康 的环境、进行有效的目标管理、绩效管理、和人才培养等工作。团队管理本质上是让团队成员协同工作达到效率最大化。而团队中绝大多数的协同问题都不是成员的态度问题，而是上述各种管理没做到位，或团队生产关系没有设计到位。

看到这里，我相信上文开头提到的几个问题大家心中都已经有答案了。掌握团队组建原则之后要有能力 活学活用 。这里再给大家留个问题思考下——DevOps团队应该如何构建呢？是每个DevOps工程师都分散到各个小分队里，还是作为部落的共享角色，亦或是所有DevOps工程师单独组队？

而平台运维负责的是共享基础设施本身的管理，如系统级安全监控、容量管理、服务治理等，与软件功能发布无关。所以平台团队一般会单独组队。当然也有以谷歌为代表的很多公司，将狭义的DevOps和平台运维的工作合并后且赋予更多的管理职责，组成了网站可靠性工程师（Site Reliability Engineering）团队。

> > > >

参考资料

以上就是关于【理论研究】漫谈云计算IT基础设施05-超融合技术全部的内容，包括:【理论研究】漫谈云计算IT基础设施05-超融合技术、如何撰写优秀系统运维架构解决方案及推动实施案例(一场没有硝烟的战争)、Visio画图等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！