IT运维管理需要注意什么

好奇心与 探索 ——人类进步的阶梯。

19世纪的最后一天，世界上所有的知名物理学家齐聚一堂，准备为经典物理画上一个完美的句号，所以当时的议题是如何消除经典物理这座漂亮大厦上的两朵乌云。这两朵乌云第一朵是经典物理中已知地球的空间中是有空气的，因为声音便是通过空气这一介质传播的，那么宇宙中又存在怎样的介质能够让阳光穿越真空照耀大地的？第二朵乌云则是人们在做实验的时候发现辐射能量很可能是不连续的。

后来的故事大家也都知道，科学家们在好奇心的驱使下提出了各种看似荒诞的理论，例如波尔提出了惊世骇俗的波尔模型、薛定谔提出了薛定谔波动方程……在一个个荒诞的理论的迭代与互补下，第一朵乌云诞生了相对论，第二朵乌云诞生了量子物理，它们共同将完美的经典物理推翻，也一手构建了现在的信息时代、数字时代。

2021年也是不平凡的一年，虽其分量远不及“两朵乌云”，但在疫情这一针猛烈的催化剂下，人工智能、云原生等数字 科技 融合多种技术、多个行业、多个产品，正前所未有地渗透到医疗、自动驾驶、安全等经济 社会 的方方面面，那么近未来有望落地的 科技 趋势是怎样的？

近期，在腾讯 科技 向善创新周发布《2022年十大数字 科技 前沿应用趋势》（后简称“报告”），通过访谈重点领域的科学 探索 奖获奖人、业界权威专家，凝练出了IT重塑、智能世界、虚实共生、网络革命四大领域，数字孪生、量子计算等十大数字 科技 前沿应用趋势。

在解析报告之前需明白一点，数字 科技 化身未来新动能的应用大爆发不是单一技术的突破，而是多种技术循序渐进式的增量与融合的结果。正如腾讯研究院院长司晓在“ 科技 向善之夜”中《离线-在线-在场》的主题演讲所言：“元宇宙等概念本身是一种技术渐进式发展的趋势，就像我们在30年前说信息高速公路，10 年前说移动互联网一样，概念本身叫什么并不重要，它只是一个巨大的技术应用和孵化的池子，任何一项技术单点的突破或炒作，都不会把我们瞬间带入到新时代。”

举个例子，在演讲中司晓表示腾讯计划在深圳大铲湾的一个半岛上，建立一个全新的未来总部——企鹅岛（非正式名称），在“企鹅岛”上，我们有可能看到腾讯在智慧城市上的种种积累和设想。

司晓介绍，“企鹅岛”的设计方案在一款沙盒 游戏 中被复制出来。这个数字孪生一方面体现出 游戏 所积累的AI 、方针等技术在建筑设计等场景的应用，另一方面，在这个虚拟仿真环境下，可以以更低成本来验证一系列交通、能源等系统的规划以及设计是否合理。

其实，刚在前文中提到的数字孪生亦是融合多种数字技术的一个概念池子，例如在数字孪生中拟出真实的智慧城市的交通控制系统，让公交和现实中的一样，等红灯、自动避让、等人上下车，所以在数字孪生城市中引入自动驾驶仿真系统，而这个系统则是基于 游戏 引擎，通过机器学习不断优化，让 游戏 里的载具去真的感知周围的环境，从而最大限度的还原现实生活场景。

也许我们已经在逐渐进入更加智慧的“在场办公”时代。在移动互联网之前，我们是离线办公，工作需要去实实在在的办公室、沟通需要面对面交流或打电话、发邮件；移动互联网普及后，办公方式再次迎来变革，特别是在疫情加速下，基于腾讯会议、Zoom、飞书等在线协作工具大家可以在线办公；而随着XR（混合现实）、感知交互、虚拟仿真等技术发展，“在场办公”未来可期。

在场时代其实并不遥远，例如Meta公司（原Facebook）前不久发布了一款VR虚拟办公室程序Horizon Workrooms，用户使用 Oculus 这样的 VR 设备便能进入这个虚拟办公室进行交互式办公，就好像是在真实的办公室办公一样。而这些随着XR等技术与触觉手套等硬件技术的发展，未来会有越来越多场景与公司从在线时代步入在场时代，即虚实共生。

司晓在演讲中还举到过一个大开脑洞的例子——火星移民。如果未来人类“火星在场”，在远程去往火星上派机器人建基地之前，我们可能会首先实现在虚拟世界中对“火星”在场，也就是给火星建一个超拟真的模型，去模拟各种可能出现的情况。

可以看到，无论是一个智慧城市概念体——企鹅岛，还是星辰大海的火星移民，其都是基于现有数字技术不断进化、融合而来，它们并不会因为某一项技术的突破便将人类带入“未来”时代，正如司晓在演讲中谈到的那样：“元宇宙这些概念本身就是一种技术渐进式发展的趋势，而这个过程需要的技术可能源自于完全不同领域的技术涌现与应用，但这两个应用方向并不必然冲突，甚至有可能是相互依存的。”

前文中提到，“未来”新时代的实现过程必然是不同领域的技术涌现与应用，而在风云诡谲的2021年，我们可以看到人工智能等数字技术在医疗、自动驾驶、安全等领域的应用深入开展，沉浸式媒体、数字虚拟人、虚实集成亦打开了全真数字世界的大门，那么在2022年数字 科技 在IT重塑（云原生、量子计算、云安全）、智能世界（人工智能、复杂机器人、星地协同智能化）、虚实共生（万物孪生、扩展现实）、网络革命（云网融合、能源互联网）四个领域又会有怎样的应用趋势呢？

一、IT重塑

如果说第一次工业革命的蒸汽机把人们带入了蒸汽时代、第二次工业革命的电力应用把人们带进了电气时代，那么第三次 科技 革命IT技术则将人们带入了互联网时代，从PC互联、移动互联到如今万物互联初现雏形，IT正在被重塑。

IT架构被重塑的最直接的表现便是“云化”，随着数字化的普及和深入，海量数据实时、灵活处理的情况日益普遍，传统IT架构越来越难以适应，许多企业都会将自己的网站部署在云端（包括公有云、混合云等），这就是所谓的企业“上云”。而随着上云进程的加快，一种基于分布部署和统一运管的分布式云——云原生开始带领企业进入全云时代（云原生是以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系，可使松散耦合的系统具有d性、可管理性和可观察性，能够更低成本、高效地调用各类云计算资源向业务交付应用）。

首先，无服务器计算（Serverless）兴起，正在成为云原生加速发展的新路径；其次，分布式云将有效拓展云原生业务构建的物理边界，大幅减轻用户多云管理负担；最后，异构计算将促进软硬件相互定义和融合发展，推动云原生基础设施性能持续突破瓶颈。

不过云原生涉及IT体系的整体变革仍面临不少挑战，例如云原生资源的多变性影响IT体系全链条的可观测性、实践过程中迁移和管理复杂度较高，其中数据隐私和安全风险则是影响云原生发展的关键问题。

《报告》认为，新一代网络攻击技术使攻击变得更加隐蔽、快速，攻击范围从个人向企业、基础设施蔓延，造成的攻击损失成指数增长。在此背景下，零信任将重塑云原生的安全新边界，成为远程办公时代有效地安全解决方案；面对攻击更加复杂、赎金不断增长的勒索攻击，云上安全防御将成为最优解；面对快速的网络攻击，全面覆盖网络、 端点以及云基础架构的扩展威胁检测与响应（XDR）升级，将促进更多的组织增强“主动免疫力”。

当前IT被重塑的不仅仅只有架构，还有算力。2021年是量子计算备受瞩目的一年，国际国内均有较为明显的科研成就，《报告》认为2021年量子计算已步入了NISQ(含噪声中等规模量子)时代，同时《报告》还认为2022年将是量子计算继续积蓄力量之年。

在硬件方面，主流量子计算硬件技术（如超导、离子阱、光量子等）将并行发展，两到三年内，量子计算有望突破1000量子比特，届时量子计算与经典计算相结合的混合计算体系或将成为更加有效的应用方案；而软件算法方面，预计在2023年前后，量子计算有希望开始在若干领域(例如组合优化、量子化学、机器学习等)实现具有应用价值的专用量子模拟机，如用于小规模的分子模拟和蒙特卡罗模拟（分子模拟是新药物、新材料开发的基础，蒙特卡罗模拟在金融领域有广泛应用），且量子计算产业链将随科研及应用发展逐步形成。

二、网络革命

IT被重塑的同时，得益于信息通信技术的快速发展，互联网从发端时主要聚焦在科研逐步向消费型网络发展，目前正向生产型网络不断演进，未来网络将从信息传输向产业服务转变，网络将更加智能化、便捷化，即云网融合构建“连接升维”。

在此背景下，当下感知与智能将成为网络技术演进的新趋势。具体而言，一方面，无线通信与无线感知加速融合可实现通信感知一体化，使网络具备原生感知能力，即从连接信息变成连接行为，从交互认知延伸到交互感知，通感一体正塑造全真全感互联；另一方面，新型无线AI网络架构和协议可以高效捕获信道特征、适应未知环境，带来物理层面的性能提升，AI构建智慧化网络已成为行业公认的发展趋势；此外，空天一体化组网（即天基、空基等网络与地基网络在系统层面实现地面与非地面网络的全面一体化）还将实现人联与物联、 无线与有线、广域和近域、空天和地面等的智能全连接，不仅可以在全球实现宽带和物联网通信，为用户提供泛在通信服务，还可以将增强定位导航、实时地球观测等新能力集成到网络系统中。

连接升维除了体现在互联网上，还体现在能源互联网身上，双碳目标正倒逼能源互联网加快发展。随着“碳达峰、碳中和”的提出，我国能源相关产业迎来了从量变到质变突破的发展元年，首先，清洁能源大规模、高比例地接入电网成为必然趋势；其次，大规模储能技术正成为新能源推广和能源革命的基础；最后，分布式能源与储能技术的变革影响着负荷侧的身份转变。

源、荷、储三端的快速变化，带来了对“网”端一体化、数字化的改造、优化需求，这些变化 将给能源互联网发展带来重大变革：在能量层，建设多能互补的综合能源系统以匹配多变的能源供需；在信息层，通过建设电力-交通耦合网络、电力-算力耦合网络等，实现智慧的能源管理和控制；在价值层，能源互联网的建设需要 探索 能源共享经济，引导全民参与，实现共建共享共赢。

三、虚实共生

经济基础决定上层建筑，底层基础技术的重塑与变革也必然会带来了应用层技术的升级与落地，在行业数字化变革进程中，数字孪生作为理解和优化物理实体的中间件，通过融合行业知识和新兴技术，从设备、产线到工厂，从街道、区域到城市，从细胞、器官到人体，正多路径并行演进推动万物孪生。

《报告》认为，研究人员、工程人员、管理人员通过数字孪生，实现对工业设备、城市街道、人体器官等的理解、优化将成为必然趋势。一方面，行业建模工具通过融合多类技术，正向实时化、显性化和友好交互方向演进；另一方面， 游戏 引擎逐步融合行业知识和前沿技术来提升数字孪生的应用能力，凭借其模拟逼真、渲染实时、开发便捷的特点，为行业数字孪生构建提供新型路径。

不过，当前虽然数字孪生应用需求处于爆发期，但其开发应用依赖行业知识沉淀、不同工具的融合协同、以及计算和网络支撑等多类技术条件，对高精度、多尺度、低时延等大场景的支持能力仍较为薄弱，发展仍处于初级阶段，未来还需要多项技术能力的突破和整合去推动数字孪生进一步发展。

当然，作为虚实共生时代双子星（分别为数字孪生与扩展（XR）现实）的扩展现实，在硬件迭代的驱动下也迎来了产业的拐点。在VR领域，随着VR光学、显示、定位和交互等硬件技术发展方向和思路的明确，超短焦的光学设计、Micro-LED、更轻便的交互控制器成为未来趋势；在AR领域，由于光学模组算力、电池限制等硬件限制，短时间内多种技术路线将会并存；值得注意的是，《报告》显示以手机为显示终端的VR 360或全景视频发展迅速，其生态已初具雏形。

总之，扩展现实已跨过了产业拐点。目前，VR在培训、教育、文旅，AR在安防巡检、工业生产等领域已经成为行业标配。《报告》认为，VR和AR作为新一代交互和计算的终端和下一代互联网的硬件入口，将带来新一轮的信息浪潮和产业链格局的重塑。

四、智能世界

IT重塑、网络革命、虚实共生，任数字 科技 与产业如何发生化学反应，人类最终的目的是打造一个智能世界，显然，我们当前正迈入这样一个世界。

首先在赋予世界“智慧”的人工智能上，人工智能已经在一些特定的任务上超越了人的能力，但在大规模应用上仍存在瓶颈，限制了产业的进一步发展。《报告》认为，未来多种人工智能技术将加速演进，且人工智能将与更多的行业深度融合，向更加普适化和工业化的方向迈进。

其一是超大模型，短期内，模型的规模会进一步提升，大模型中的数据类型将不断丰富，由目前文本为主向图像、视觉等多模态方向丰富，进而推动模型准确性和泛化能力的提升；其二是小样本学习技术，通过多任务分割网络和迁移学习，可以实现对大量异质公开数据集的利用，将学习到的知识和特征用于生成目标领域的模型，从而实现知识在不同领域之间的迁移；最后是一站式机器学习平台，通过为开发者提供从数据标注、数据预处理、模型构建、模型训练、模型评估到模型服务的全流程开发支持，可以帮助开发者更快完成业务模型的搭建，大幅降低机器学习的进入门槛，有望成为人工智能研发基础设施，推动模型工业化。

其次，多模态融合将驱动复杂任务服务机器人深入家庭生活。在感知方面，触觉传感技术突破，以及多模态感知融合技术迭代，将提升机械臂工作的精度和准确率，实现对不同材质、形状和软硬性状物品的抓握推举；理解方面，基于计算机视觉和NLP技术的进步，机器人对复杂服务任务和家庭环境的理解将进一步深入；控制方面，柔性、仿生机器人本体技术的持续进展，将显著提升人机互动的体验和安全性。

随着NLP、先进传感器等底层技术实现商用化，叠加新冠疫情加速家庭消费升级，服务机器人智能化程度不断提升，并下探至更为广阔的家用消费级市场，《报告》认为，未来3-5年，家庭服务机器人有望实现更自然的人机交互、完成更复杂的 *** 作任务，逐步成为家政、 娱乐 、教育、陪伴等细分场景的生活助手。

最后，星地协同智能化将开启“大航天”时代。当前，航天业最大的变化便是其发展模式正由国家主导向国家和企业共同推进演化，而造成这一显著变化的核心原因在于航天智能化水平快速提升，这也将成为技术创新与突破的新契机。

《报告》认为，星地智能化协同，一方面将提升卫星海量数据智能化处理能力，通过卫星与地面站协同推理，数据计算精度可快速提升，同时卫星回传数据量大幅减少；另一方面，人工智能技术将助力卫星遥感数据融入千行百业，例如在农业领域，AI算法+卫星数据深度挖掘协助农民开展保险核保、产量预测，有望成为环境、 社会 与公司治理投资的风险预警工具；此外，航天智能化将打开航天商业化的大众服务窗口，太空旅行、空间站商业化、太空**拍摄逐步向大众市场普及，亚轨道旅行、卫星影像私人订制、时空信息数字化等新物种也将加速涌现。

面对疫情和全球产业格局调整带来的不确定性风险，我们更需要加强 科技 预判，瞄准世界 科技 前沿，引领 科技 发展方向。透过报告我们看到数字 科技 正从四大方向、十个领域推动我们进入“新时代”，并正在转化为未来的新动能，推动我国经济与人民生活更高质量发展，正如腾讯研究院院长司晓所言：“ 科技 的发展没有终点，让 科技 融入实体经济促其高质量发展，让生活更便捷、让 社会 更美好才是永恒的趋势。”

8月20日，华为云成功举办TechWave云基础设施专题日，围绕企业上云普遍关心的「 如何规划、技术选型、组网复杂 」等痛点，分享了承载67亿用户的华为终端云服务上云实践，及其背后瞄准「 软硬协同 」与「 边云协同 」实现云基础设施全面升级的华为云擎天架构，并带来 KYON云网络解决方案、云原生技术平台Vessel、升腾转码解决方案 等五大新品。

针对企业上云的痛点，本次专题日不仅带来了华为自身的上云实践分享，还首次提出了「 Keep Your Own Network 」（KYON）的理念，聚焦解决企业上云的复杂组网问题。

下面我们就一起来看看这些令人兴奋的亮点吧。

华为终端云服务上云实践大公开！

「缺乏经验」是困扰大多数企业上云的拦路虎，而传统IDC模式存在的可靠性低、运维成本高、安全防护差、资源无d性、服务种类少等特点，又为企业上云平添了更多阻碍。

为了解决这一难题，华为云公开了终端云服务上云实践。作为承载了67亿+用户、130+开发者、4亿+Push并发连接的华为终端云服务，华为总结出了一套行之有效的企业上云实践经验。包括在云上构建高可靠、高性能、高d性的应用，业务的智能运维/运营等多个方面。

构建高可靠应用 ：依靠华为云在基础设施的冗余设计，如双路供电、网络双平台、AZ间4路光纤互联等，保障基础设施层的高可靠；同时在业务层依靠双活和容灾的设计，保障业务在面临突发灾难时，能够实现业务的连续性。通过真实演练，纯业务切换秒级完成,主Region故障时，20分钟完成容灾切换。

构建高d性、高性能应用 ：华为云ELB可支撑了200万/S新建连接和2亿以上的并发连接，配合华为云秒级千容器，一分钟千台云主机的d性能力，保障了应用的高性能和高d性，成功保障了华为手机应用市场春节15倍流量突发

业务智能运维/运营 ：大数据分析是实现业务智能运维/运营的基础，华为云分布式裸机网关为裸金属服务器提供20Gb带宽保证，同时通过存算分离机制，实现PB级大数据分析并节省了整体成本。

KYON+Vessel，打造极简高速的上云之路

在本次专题日上，华为云网络域总监李义提出了「Keep Your Own Network」的理念（即KYON），并发布「 KYON企业级云网络解决方案 」，聚焦解决上云的复杂组网问题。 KYON在今年7月凭借数项技术创新，斩获“2020可信云技术最佳实践奖”。

在上云过程面临的诸多问题中，网络首当其中，43%的企业应用在混合云场景中遇到了网络连接的问题。造成这一问题的根本原因，就在于组网部署的复杂。正如上文提到，随着万物互联的趋势日益加速，企业组网也变得日趋复杂，如何简化组网、平滑迁移、业务融合，是企业上云的核心诉求。

在这些方面，华为云从云端进行网络进化，构筑企业级特性，缩小和企业网络环境的差异，从而适应企业的复杂应用和场景。 在此基础上，提出KYON的三大优势，即极简规划、敏捷迁移、无缝融合。

极简规划 指的是通过私网NAT网关，实现灵活组网。企业多部门间业务往往存在大量的重复网段（172/192），迁移上云后极易冲突。KYON的私网NAT网关，可以将私网地址映射至大网地址，支持IDC原有组网拓扑整体映射至云上，并进行统一管理。用户可以保留原有组网上云而无需重新规划，极大地简化了IDC上云的网络规划和管理。此外，KYON还可将私网IP映射为指定IP进行接入，以满足行业监管部门对各机构和单位的要求。

敏捷迁移 旨在打破网络边界，实现二层网络体验。企业业务在迁移过程中，大部分的IP都需要更换，但有些IP是硬写入在配置文件中的，难以修改。不仅如此，政务和大企业往往系统庞大，单次迁移无法完成完整业务上云，而多次迁移由于迁移过程中云上云下无法通信，业务不得不暂时中断。KYON通过L2CG打通二层网络，企业可以携带私网IP直接上云，做到IP零修改，让业务敏捷迁移，这一 *** 作大大降低了企业上云的复杂度和成本。

无缝融合 是指共享云上资源，统一负载均衡。虽然上云能给政企带来很多优势，但政企中的大部分场景仍然是采用的混合云模式，即部分应用迁移至云上，部分业务留在数据中心。这样既可以保护云下的数据安全，又可以共享云上丰富的服务能力和d性。

华为云通过VPC Endpoint服务，使企业IDC的应用通过专线/***，可访问和使用公有云上的高阶服务，如数据库，AI等，减少了在本地部署的复杂度和维护成本。此外，ELB 提供IP Target功能，使用公有云上的负载均衡器可同时挂载云上和企业数据中心的虚拟机。从而实现了单点接入和统一负载，云上云下共同承接业务浪涌，同时减少云下负载均衡设备的成本。

KYON是华为将自身和在政企客户的经验复制到公有云上的体现。 华为的IT系统持续演进30年，服务于华为全球十余万员工。 KYON助力流程IT实现了红黄绿区访问策略控制、不同部门的跨VPC协作、构建企业内部大网等能力，实现了百万VM的研发作业流和全场景业务系统上云，打造了KYON助力企业核心业务上云的最佳实践。

不仅如此，从CNCF 2019年年底的调查数据可以看到， 在生产环境中，使用云原生的企业数量是2016年的36倍，达到了84%， 大型政企在中国公有云市场所占份额已达到28%，成为了上云的主力。在企业内部，越来越多的业务系统运行在容器上， 90%的受访企业都已经计划使用云原生服务网络Istio 。除了KYON之外，为了帮助用户构建以云原生为核心，贯穿基础设施、技术平台、业务应用的全栈云原生架构，本次专题日还发布了全新升级的华为云云原生技术平台Vessel。

在基础设施层，Vessel涵盖 容器引擎 、 容器网络 、 容器存储 ；

在技术平台层，则包括应用 网格 、 调度 、 监控 、 治理 、 云边协同 等组件；

不仅如此，华为云基于Vessel还构建了4大解决方案： 第二代裸金属容器、混合云容器、容器批量计算、边缘容器 。这些解决方案，加速了云原生技术与产业价值链的融合，帮助泛互联网、金融、政企、能源、交通等行业用户快速、简单地构建全栈云原生业务。从而实现业务的高效管理、快速创新。

挑战摩尔定律，擎天架构的「两个协同」

在摩尔定律逐渐放缓的今天，通过单纯的增加晶体密度，已无法满足企业业务的发展。 且未来分布式云形态下将带来海量站点间复杂且立体多维的协同挑战。 华为云基础服务CTO李帮清在专题日现场提出， 未来的云基础设施应向「软硬协同」和「边云协同」的方向演进与升级，从而提供更极致的用户体验。 他还在现场首次展示了实现深度软硬协同的关键组件「擎天卡」，旨在通过专用硬件承载存储、网络、管控等功能，并实现硬件加速、硬件级安全可信等能力。

擎天架构「两个协同」的实现背后，要归功于「 软硬协同系统 」和「 瑶光智慧云脑 」两大组成部分。这两个部分就像人类的大脑和四肢协同工作。

「 瑶光智慧云脑 」负责海量站点的全域调度并实现边云协同、边缘自治及服务的按需调度；提供每分钟扩容1000台虚拟机、秒级扩容千容器的极致d性，并可通过资源画像进行预测实现供需平衡，保障大规模批量发放请求。此外，它还像人类的大脑一样具有自学习的能力，通过自学习进行调优，让业务负载运行在最适合的算力上，为客户带来极简体验。 作为面向云、AI、5G时代的分布式云 *** 作系统，「瑶光智慧云脑」可以支撑未来分布式云形态下超大规模集群的资源调度与协同。

而「软硬协同系统」则像人类的四肢一样，与瑶光各自独立又互相配合地完成肢体的各种动作。例如通过擎天卡，把各个程序卸载到专用硬件里来运行，把主机资源释放出来等。通过擎天卡的深度软硬协同，实现全IO路径的硬件加速与安全可信，实现如业界领先的10μs网络时延、低至100μs的云存储时延等。 所以不仅仅是拿擎天卡的资源去换主机资源，核心是通过深度软硬协同能力把一台服务器里面所有资源、性能极致释放，并提升可靠性及安全可信能力。

结语

除了上述新发布之外，这次专题日还发布了其他令人印象深刻的新品及服务，例如 升腾AI视频转码解决方案、竞享实例、新一代极速型SSD云硬盘 等。

通过这些发布，我们不仅看到了华为云在构建从流程到落地全套上云体系中的进展， 更看到了华为云在技术演进方向上的前瞻性， 持续引领业界技术创新。特别的，随着边缘产业的发展，未来50%的计算和70%的数据都将在边缘端产生（Gartner预测），而打造云边端全场景能力，也将是华为云未来发展的重点。

此外，以云原生为流量入口，打造全栈云原生竞争力，也将成为华为云未来的重点方向。

经过几十年的发展，it行业在当前互联网技术的推动下，进入了一个资源高度整合的时代，即系统化和智能化的时代。运行维护服务也将向组织化、标准化、专业化、智能化方向发展。

相比其它相关行业发展来说，IT运维服务的智能化管理更具得天独厚的优势，因为IT系统设计本身问题就是一个基于企业数字化、数据化和网络化的，而这几个方面要素恰恰是一切智能化的基础。

手工——机器——自动化——智能化，这种生产方式的演进，其目的就是逐步用机器取代人工，最大限度地把人从繁复的、非创造性的劳动中解放出来，以提高生产质量、降低生产成本。智能化对于IT运维服务来说，同样具有非凡的划时代意义。它不仅能大幅度地降低服务成本、提高服务质量的稳定性，还为商业竞争构筑越来越高的技术门槛。

在长期的运维管理实践中，人们开发出各种运维管理工具，如信息安全系统、负载均衡系统、上网行为系统、网络监控系统、运维审计系统、日志审计系统等等。越来越多诸如此类系统的出现，标志着运维管理进入类似制造业的机器生产时代。下一个阶段的发展趋势应该是将这些系统在业务流程和数据上进行整合，朝着自动化与智能化方向挺进。以便更大程度地取代人工，消除人工服务所带来的非标准和质量不稳定的隐患，并进一步地提高服务效率、降低服务成本。

智能化是建立在大数据基础上的，首先要解决的是运维数据的智能采集。根据客户单位的业务需求，确定运维服务的总体目标，明确需要收集哪些数据？是怎么收集这些数据的？收集这些数据的方法是什么？如何确定不同类型数据的采集频率？如何分类和存储数据？

其次是大数据挖掘。设计运维数据分析模型，从海量历史数据中准确找出IT系统存在的问题。以监控系统为例，大部分客户都购买了网络监控系统，证明实际工作中存在这样的刚性需求。但实际上，大多数客户并没有很好地使用这个系统，主要是因为这些系统在数据准确性上并不理想，对大数据的分析和提取也比较薄弱。由于营销的需要，监控系统开发商把主要精力都放在新功能的开发和数据的展示上，对数据的准确性及分析挖掘缺乏深入研究，因而使得监控系统的实用性大打折扣。

然后是如何集成各种 *** 作工具和它们生成的数据的问题。如何将各种运行维护管理工具集成为一个智能化的运行维护管理平台，充分发挥其整体价值。对于需要人工干预的事件，还需要与服务流程管理系统进行接口，以实现人机服务的集成，实现服务流程的智能化。与运维的组织化、标准化、专业化一样，智能化运维也是运维服务行业发展的大趋势。 谁能顺应这一趋势，把握这个发展机遇，谁就赢得了未来！

本文摘要节选自来源于

>

专家来了哈哈哈！

软件技术服务外包是信息技术外包（ITO）的重要组成部分。软件技术开发的过程可以分为：需求分析、系统设计、编码、测试、交付和运维服务等不同阶段，软件技术服务外包可以发生在上述开发过程的任何阶段。

市场规模

受益于中国内需市场的增长、国际性厂商与国内软件技术服务外包企业战略合作的加深以及中国企业在产业结构升级过程中外包意识的提升等因素的影响，中国软件技术服务外包行业得到快速的发展。

2018年，我国软件技术服务外包行业收入规模达到了11939亿元，同比增长1389%。预计未来我国软件技术服务外包行业的需求规模将保持增长态势，2020年和2021年市场规模可分别达到14469亿元和15766亿元。

数据来源：中国产业调研网、中商产业研

上游行业情况

软件技术外包属于信息技术外包行业。由于技术的复杂性、多样性、快速变化性，以及企业需要快速将技术应用到业务中的迫切性，使得大部分企业需要把信息技术的研发和方案编写与实施全部或部分外包给专业厂商，而将自己的精力放在核心竞争力的打造上，进而催生了信息技术外包。

上游行业未来发展趋势

1正在从传统的项目化服务走向平台化赋能加个性定制化服务

信息技术外包服务的业务形态正在发展成以云的方式向多客户提供平台化和个性定制的服务，业务模式从收取解决方案制作与项目开发费用的方式转变成收取客户订阅或租赁服务费的方式，项目化的服务和平台加定制化的服务方式会并存。

2信息技术外包呈现出多行业化、多区域性

在快速走向新技术的过程中，需要将大量的IT工作外包给专业的信息技术服务提供商。这种通过借鉴外部优秀 *** 作经验，借助外部专业团队进行企业IT系统建设的方式，越来越多的受到行业认可和采纳。并且随着我国一带一路政策的推进，沿线国家积极推动经济社会的数字化转型和信息化建设。因此，多行业多地区呈现出对信息技术外包的旺盛需求。

未来发展前景

1市场空间巨大

随着金融、互联网、软件、通信等几大行业引领的数字化潮流逐步延伸至房地产、航空物流、制造业、批发零售等众多行业，软件信息技术应用的空间得到空前的扩展，各行业的IT相关支出也将有所增加，这也将给软件技术服务外包行业带来巨大的市场空间。

2国家信息化战略促进软件技术服务外包行业发展

随着“互联网＋”和“中国制造2025”等国家战略的推进，将进一步驱动社会各行业的信息化改造需求。新兴行业如互联网、云计算等在经济转型的大背景下，也将产生大量的信息化投资需求，进一步促进软件技术服务外包行业的快速发展。

3知识产权保护制度日趋完善，对软件价值的认可度提高

随着大众对软件价值认可度的提高，大众对于软件等虚拟产品的付费意愿也不断提高，这将促进软件相关企业加大人才与技术的投入力度，吸引更多高端人才，从而进一步促进软件技术服务企业的良性发展。

4人力资源充足、人力资源竞争力提高

近年来，每年大学毕业生人数超过700万人，其中，理工科毕业生占有相当部分。经过多年发展，我国已经积累了大量软件工程师和相关专业人才，软件技术人力资源充足，这为软件技术外包服务提供了良好的人力基础。

作者介绍

常红平， 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运维服务的智能化更具得天独厚的优势，因为IT系统本身就是基于数字化、数据化和网络化的，而这几个要素恰恰是一切智能化的基础。

手工——机器——自动化——智能化，这种生产方式的演进，其目的就是逐步用机器取代人工，最大限度地把人从繁复的、非创造性的劳动中解放出来，以提高生产质量、降低生产成本。智能化对于IT运维服务来说，同样具有非凡的划时代意义。它不仅能大幅度地降低服务成本、提高服务质量的稳定性，还为商业竞争构筑越来越高的技术门槛。

在长期的运维管理实践中，人们开发出各种运维管理工具，如信息安全系统、负载均衡系统、上网行为系统、网络监控系统、运维审计系统、日志审计系统等等。越来越多诸如此类系统的出现，标志着运维管理进入类似制造业的机器生产时代。下一个阶段的发展趋势应该是将这些系统在业务流程和数据上进行整合，朝着自动化与智能化方向挺进。以便更大程度地取代人工，消除人工服务所带来的非标准和质量不稳定的隐患，并进一步地提高服务效率、降低服务成本。

以上就是关于四大领域、十大趋势，数字科技化身未来的新动能全部的内容，包括:四大领域、十大趋势，数字科技化身未来的新动能、华为云发布五大新品，这个成功实践也首次对外公开、IT运维管理需要注意什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！