爱游戏下载:消息宣布
办理体系范例一：开辟运维顺畅协作
这是 DevOps 的“乐园”：开辟团队和经营团队之间顺畅协作，每一个团队都在须要的处所专业化使命，但也在须要的处所同享。
能够有很多自力的开辟团队，但每一个团队又会在一个零丁或半自力的产物组合上使命。我的感受是，范例一的光滑协作模子须要相称大的构造变更来成立它，并且在办理团队须要有较高的才能。
开辟职员和运维职员必须有一个明白有用的配合方针（“高品质托付、疾速迭代”或其余）。运维职员必须与开辟职员停止温馨的协作，把握测试驱动的编码和 Git，开辟职员必须当真看待运维特征，寻觅运维职员以输出日记记实等等，一切这些比拟较曩昔都须要停止相称大的文明变更。
范例一合用性：具备壮大手艺带领范例的构造
潜伏有用性：高
范例二：全嵌入式/同享运维
当运维职员完整融入进产物开辟团队中的时辰，咱们看到了这类范例。Dev 和 Ops 之间的分手很少，以致于一切人都配合高度存眷一个方针，这能够说是范例一的一种情势，不过它也具备必然出格性。像 Netflix 和 Facebook 如许的构造有用地实现了一个基于 Web 的产物，它已实现了这类范例的规划。
但我以为它能够不太合用于狭小产物线形式以外，由于估算限定和多个产物线之间凡是存在高低文切换，这能够会迫使 Dev 和 Ops 进一步分隔（比方回到范例一模子）。这个形式也能够被称为“NoOps”，由于不较着的或可见的运维团队（虽然 Netflix NoOps 也能够是范例三）。
范例二合用性：基于单一 Web 的产物或办事的构造
潜伏有用性：高
范例三：根本举措措施即办事
对具备相称传统的 IT 运维局部的构造，他们没法或不能（充足）疾速作出改变，和对在大众云（Amazon EC2、Rackspace、Azure 等）中运转一切利用法式的构造来讲，将运维作为一个只要供给利用法式安排和运转功效的弹性根本举措措施团队也许比拟有赞助。如许外部运维团队间接同等于 Amazon EC2 或根本架构即办事。而后 Dev 中的团队（能够是假造团队）充任有关操纵特征、怀抱、监控、办事器供给等方面的专业常识来历，并且能够与 Iaas 团队停止大局部相同。
可是这个团队依然是一个开辟团队，遵守诸如 TDD、CI、迭代开辟、指点等规范理论。IaaS 团队规划具备一些潜伏的有用性（落空与 Ops 职员间接协作），以便更轻易实行，能够比范例一更快地取得代价。
范例三合用性：具备几种差别产物和办事、具备传统经营局部或其利用法式完整在大众云中运转的构造
潜伏有用性：中等
范例四：DevOps 即办事
一些构造，出格是较小的构造，能够不资金、经历或使命职员来带领他们的软件运维。开辟团队能够会打仗到像 Rackspace 如许的办事供给商，去赞助他们成立测试环境并主动化其根本举措措施和监控，并就软件开辟周期中实现的各类运维功效供给倡议。
能够被称之为 DevOps-as-a-Service 的应当是赞助小型团队领会主动化、监控和设置装备摆设办理的一种有用务虚的体例。跟着营业的成长和更多的员工插手，能够转向第三类乃至第一类形式。
范例四顺应性：经营经历无限的小型团队或构造
有用潜力：中
范例五：姑且 DevOps 团队
这个范例看起来和反范例 B 有极大的类似，可是现实上其实质企图和久远性是完整差别的。这个姑且团队的使命是使 Dev 和 Ops 更慎密的连系在一路，抱负方针是完整转型成范例一或二。姑且团队成员将在 Dev-speak 和 Ops-speak 之间停止翻译，并引入一些猖狂的点子，比方为 Ops 团队先容站立会和看板体系，另有一些隐恶扬善的细节，比方为 Dev 团队先容负载平衡器，办理 NIC 和卸载 SSL。
若是有充足多的人认识到 Dev 和 Ops 团队连系后将带来的代价，姑且团队将无机会真实的实现它的方针。相当主要的一点是，对安排和出产阐发的持久义务不应当被分派给姑且团队，不然很能够会朝着反范例 B 的倒霉标的目的演进。
范例五顺应性：想告竣范例一的前身，可是要警戒演化成反范例 B 的能够
有用潜力：低至中
总结
事实哪一个 DevOps 团队规划适合一个构造取决于以下几点：
该构造的产物组合：较少的产物会使团队协作加倍轻易，由于按照 Conway 定律，这类环境下的自力谷仓会比拟少。
手艺带领的规模力度和有用性；Dev 和 Ops 是不是有清楚明白的配合方针。
构造是不是具备才能或愿望去该改变它的 IT 运维局部，从“办事器的组建和设置装备摆设”改变成真的能够实现其代价流，和软件研发团队当真看待运维团队。
构造是不是具备才能和手艺去处理运维题目。
