构造结构对DevOps的影响
观看完本文后，你将能够识别构造结构怎样影响DevOps，解释康威定律，并描述DevOps团队的最佳构造情势。让我们来看看你的构造结构是怎样影响你采用DevOps的能力的。
要成为一个采用DevOps的构造，首先要做到敏捷，由于敏捷是DevOps的基本准则。
你必须问问自己：“我的构造文化是否真正接受了敏捷思维？” 要记住，敏捷团队必须规模小，这一点很紧张。
假如你有大型团队，又想成功实行DevOps，就需要缩小团队规模。
敏捷团队应该专注。
你不能让团队成员同时加入多个项目，还期望所有项目都能以相同的速率推进，或者指望团队成员长时间专注于任何一个项目。
敏捷团队应该是跨职能的。
我们所说的 “开发团队” 包罗所有负责产品开发的人员。
这意味着软件工程师、测试工程师、运维工程师、业务分析师，无论需要什么角色。
这些人需要在同一个团队中，而不是各自为政，通过票务系统来引起相互的留意。
这些团队需要自我构造。
他们一次只专注于一个冲刺阶段的工作。
让我们从康威定律开始，看看构造架构为什么如此紧张。
早在1968年，梅尔文·康威就指出：“任何设计系统（广义定义）的构造，其产生的设计结构都会是该构造沟通结构的复制。”
例如，假如你让四个团队构建一个编译器，你会得到一个四遍扫描的编译器。
你得到一个四遍扫描的编译器并不希奇，由于你让四个团队来构建它。
假如你有一个用户界面团队、一个应用程序团队和一个数据库团队，你会得到一个三层架构。
你得到一个三层架构并不希奇，由于你让三个团队来构建它。
这就是康威定律在起作用。
假如你想改变构建软件的方式，采用微服务应用架构，就需要围绕你期望构建的架构来重新构造人员。
在一个围绕技能构造的传统机构中，你可能会有一个独立的用户界面团队，负责所有效户界面相关的工作。
无论你在构建什么功能，都需要引起这个团队中或人的留意，并占用他们的时间，来为你的功能添加一个用户界面元素。
这个团队有时也被称为前端团队。
然后是应用程序团队，或后端团队，他们添加应用程序逻辑。
他们不处理前端或数据库模式之类的事变，由于有数据库管理员团队来管理这些。
除非提交工单让数据库管理员（DBA）来处理，否则没人会碰数据库。
当你这样构造时，就会得到一个三层架构。
就像我说的，你得到一个三层架构并不希奇，由于你让三个团队来构建它。
康威定律告诉我们，一个构造产生的设计结构会反映该构造的沟通结构。
这并不希奇。
我们得到的就是我们构造架构所造就的。
这就是为什么特别关注构造架构如此紧张。
围绕业务领域来构造团队会更好。
你可能有一个账户团队，负责管理登录、注册和用户数据。
在这个跨职能团队中，他们具备用户界面、应用程序和数据库方面的技能。
然后是个性化团队。
他们使用人工智能（AI）创建个性化算法。
他们管理自己的用户界面、应用逻辑和数据库。
末了，你可能有一个仓储团队，负责构建与运输、收货和库存相关的功能。
这些是他们从头至尾管理的微服务。
仓储团队在开发功能时，不需要与其他任何团队协调。
他们不需要提交工单来引起其他团队的留意以完成自己的功能。
他们作为一个小型、专注、跨职能、自我构造的团队开展工作。
假如你不围绕业务领域构造团队，就无法充实得到DevOps带来的好处。
你要让团队与业务保持一致。
每个团队都应该有与业务领域一致的使命。
确保他们拥有所需的自主权，让他们感觉像是一个 “小型初创公司”。
他们需要自我构造、跨职能，由5 - 7名工程师组成，但最多不超过10人。
然后，你要赋予团队对其产出的端到端的责任，以此来赋能团队。
他们负责提交、构建、部署、维护和运营自己的服务。
他们掌控一切。
而且你要让他们承担通常围绕单一业务领域的恒久使命。
在打造高绩效团队时，这一点的紧张性再怎么强调都不为过。
假如团队人员不停变动，你就永久无法得到拥有专注于恒久使命的团队所带来的好处，这种团队能够造就对工作的主人翁意识和自大感。
在本文中，你了解到构造必须拥有小型、专注、跨职能、自我构造的团队，才能成功实行DevOps。
康威定律意味着公司的设计成果是公司沟通结构的直接反映。
成功的DevOps团队应该围绕业务领域进行构造。
每个团队都应该有与业务领域一致的使命。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]