<b>1.8 小结</b>
<b></b>
本章的主要知识点是:人们从不同的视角定义devops。例如,运维人员采用敏捷实践,开发人员承担运维责任,以及其他一些视角的定义。但共同目标是缩短一个功能或改进点从业务思路构想到最终部署给用户的时间。
由于文化及技术上的挑战,devops面临着障碍。它可能对团队架构、软件架构、运维的传统方式形成巨大的冲击。我们列出了一些常见的实践,让你对这种冲击有初步的了解。我们将在本书剩余部分详细讲述这些主题。
devops涉及的一些权衡如下:
现在需要支持devops工具了。在对工具进行支持与缩短新功能投向市场的时间之间进行权衡。
把职责从it人员转向开发人员。这种权衡是多方面的,下面是需要考虑的一些方面:
两个团队完成同一个任务的成本。
两个团队完成同一个任务的时间。
两个团队中的人员是否可以投入工作中。
在运行期间发现错误时需要的修复时间。如果部署后很快就发现了错误,那么开发人员还有可以迅速诊断问题所需的背景信息,而如果错误一开始是由it人员诊断的,在把错误交给开发人员处理之前可能需要花费一些时间。
去掉对新功能和部署的监管。这是在开发团队自治与整体协作之间的权衡。开发团队自治的效率必须超出因为没有整体监管而造成的工作量的重复。
总之,我们相信devops有潜力带领it走向激动人心的新领域,带来更高频率的创新、更快的循环周期,以此提升用户体验。我们希望你喜欢阅读本书,就像我们喜欢写作本书一样。