一文相识微处事的流程和组织

对付大型和伟大的应用措施，微处事架构每每是不错的选择。然而，除了拥有正确的架构之外，乐成的软件开拓还必要在组织、开拓和交付流程方面做一些事变。

图1展示了架构、流程和组织之间的相关：

图1

• 大型伟大应用措施快速、频仍和靠得住地交付软件必要具备几项DevOps要害手段，个中包罗一连交付和一连陈设，小型自治团队和微处事架构

我们已经谈过了微处事架构，此刻来看看组织和流程。

01 举办软件开拓和交付的组织

乐成每每意味着研发团队局限的扩大。一方面，这是个功德，由于人多力气大。可是团队大了往后，正如Fred Brooks在《人月神话》这本书中提到的，雷同本钱会跟着团队的局限呈O(N ^ 2)的速率上升。假如团队太大，因为雷同本钱过高，每每会使得团队的服从低落。想想看，假如天天早上的站会局限到达20人会是奈何?

办理之道是把大团队拆分成一系列小团队。每个团队都足够小，职员局限为8～12人。每个团队都有一个明晰的职责：开拓而且也许也认真运维一个可能多个处事，这些处究竟现了一个或多个营业手段。这些团队都是跨职能的。他们可以独立地完成开拓、测试和陈设等使命，而不必要频仍地与其他团队雷同可能和谐。

• 逆向的康威定律

为了在行使微处事架构时有用地交付软件，你必要思量康威定律，它划定了如下内容：

计划体系的组织……每每被组织的架构所限定，最终计划的功效是这些组织的雷同布局的副本。

——梅尔文·康威

换句话说，应用措施的架构每每反应了开拓它的组织的布局。因此，反向应用康威定律并计划你的企业组织，使其布局与微处事的架构逐一对应。通过这样做，可以确保你的开拓团队与处事一样松耦合。

多少个小团队的服从显然要高于一个单一的大团队。微处事架构使得团队可以实现某种水平的“自治”。每个团队都可以开拓、陈设和运维扩展他们认真的处事，而不必与其他团队和谐。更进一步，当呈现了某个办事情障或没有满意SLA等要求时，对应的责任人(团队)也很是清晰。

并且，开拓组织的可扩展性更高。你可以通过添加团队来扩展组织。假如单个团队变得太大，则将其拆分并关联到各自认真的处事。因为团队疏松耦合，你可以停止大型团队的雷同开销。因此，你可以在不影响事变服从的环境下添加职员。

02 举办软件开拓和交付的流程

回收微处事架构往后，假如仍然相沿瀑布式开拓流程，那就跟用一匹马来拉法拉利跑车没什么区别—我们必要充实操作微处事带来的各类便利。假如你但愿通过微处事架构来完成一个应用措施的开拓，那么回收相同Scrum或Kanban这类火速开拓和陈设实践就是必不行少的。同时也必要起劲实践一连交付和一连陈设，这是DevOps中的要害环节。

Jez Humble把一连交付界说为：

一连交付可以或许以可一连的方法安详、快速地将全部范例的变动(包罗新成果、设置变动、错误修复和尝试)交付到出产情形或用户手中。

一连交付的一个要害特性是软件老是随时可以交付的。它依靠于高程度的自动化，包罗自动化测试。在将代码自动陈设到出产情形的进程中，一连陈设把一连交付晋升到了一个新的水准。实验一连陈设的高绩效组织天天多次陈设到出产情形中，出产间断的次数要少得多，而且可以从产生的任何工作中快速规复。微处事架构直接支持一连交付和一连陈设。

• 快速推进同时不把工作搞砸

一连交付和一连陈设(以及更一样平常地说，DevOps)的方针是快速靠得住地交付软件。评估软件开拓的四个有效指标如下：

• 陈设频率：软件陈设到出产情形中的频率。
• 交付时刻：从开拓职员提交改观到改观被陈设的时刻。
• 均匀规复时刻：从出产情形题目中规复的时刻。
• 改观失败率：导致出产情形题目的改观提交百分比。

在传统组织中，陈设频率低，交付的时刻很长。出格是开拓职员和运维职员凡是城市在维护窗口时代熬夜到最后一刻。对比之下，DevOps组织常常宣布软件，凡是天天多次宣布，出产情形题目要少得多。譬喻，亚马逊在2014年每隔11.6秒就将代码变动陈设到出产情形中，Netflix的一个软件组件的交付时刻为16分钟。

03 回收微处事架构时的工钱身分

回收微处事架构往后，不只改变了技能架构，也改变了组织布局和开拓的流程。归根到底，这是对事变情形中的人(正如之条件到的，情感化的生物)举办的一系列改变。假如忽略人们的情感，那么采用微处事架构将会是一个很是纠结和折腾的进程。FTGO的首席技能官玛丽和其他的打点层，正面对着怎样改变FTGO软件开拓方法的挑衅。

脱销书《Managing Transitions》先容了转型(transition)的观念，个中叙述了人们怎样对变革做出情感化的回响。它包罗以下三个阶段。

1. 竣事、失踪和放弃：当人们被奉告某种变革，这类变革会把他们从舒服区中拉出，这类情感开始滋生和伸张。人们会念叨失去之前的各种甜头。譬喻，当被重组到一个新的跨职能团队时，人们会缅怀他们之前的同事。再好比，对付认真全局数据建模的团队来说，每个处事团队认真本身的数据建模，这对他们是一种威胁。
2. 中立区：处理赏罚新往事变方法瓜代进程中，人们广泛会对新的事变方法无所适从。人们开始纠结并必必要进修处理赏罚新事变的方法。
3. 新的开始：最终阶段，人们开始发自心田地热情拥抱新的事变方法，而且开始体验到新事变方法所带来的各种甜头。

本书先容了怎样打点转型进程中每个阶段的题目，进步转型的乐成率。FTGO显然正在单体地狱中煎熬，火急地必要转型到微处事架构。他们也必要对组织布局和开拓流程做出调解。为了乐成地实现这统统，FTGO必需当真面临这些转型模式和全部也许的情感化回响。

总结

• 单体架构模式将应用措施构建为单个可陈设单位。
• 微处事架构模式将体系解析为一组可独立陈设的处事，每个处事都有本身的数据库。
• 单体架构是简朴应用的不错选择，微处事架构凡是是大型伟大应用的更好选择。
• 微处事架构使小型自治团队可以或许并行事变，从而加速软件开拓的速率。
• 微处事架构不是银弹：它存在包罗伟大性在内的诸多破绽。
• 微处事架构模式说话是一组模式，可辅佐你行使微处事架构构建应用措施。它可以辅佐你抉择是否行使微处事架构，假如你选择微处事架构，模式说话可以辅佐你有用地应用它。
• 你必要的不只仅是通过微处事架构来加快软件交付。乐成的软件开拓还必要DevOps和小而自治的团队。
• 不要健忘采用微处事进程中的人道层面。你必要思量员工的情感才气乐成转换到微处事架构。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!