这是一个创建于 2390 天前的主题，其中的信息可能已经有所发展或是发生改变。
相信大家一定都（没）有使用过 Facebook 的经验，一定对他的快速改版私毫不陌生，可能早上醒来时发现「赞」的图案突然从实心变从空心，或是开始多了一些缤纷酷炫的功能(像是直播、限时动态..等等)，但你能想像一下吗?在过去十年前，大部份软件服务上的版本更新，都只能像是 Office 每年的一期一会来做推陈出新，但新的功能可能没解决到用户的痛处，反而增添了更多不必要的麻烦。
所以在快速变迁的时代里，这种快速、持续发布新版本的特性，俨然成为了适性生存的不二法则。你能想像 Flicker 每天至少会有 10 次以上的服务发布吗?如果在传统的开发方式，一旦有新功能的释出，如果使用者体验不好需要改进就算了，但如果有 BUG 的话，却需要等待一个月或一整年的时间才能解决，这样的产品你还会想用吗?
所以与传统开发方法那种大规模的、低频繁的发布，敏捷方法为基础的 DevOps，目的就是为了提升了发布频率的速度与效率，从过去的「年」、「季」，提升到「月」、「周」，甚至是「日」。
但快速发布的概念，并非是「开发团队」的步调快速紧凑起来就可以达到的方式，因为每一个新版本的 Release，除了靠开发团队的努力外，也需要「维运团队」、「测试团队」的努力，才有办法相辅相成，但通常在公司里「开发」和「维运」都是隶属于不同的部门的业务，开发目标是推陈出新，但维运部门在乎的是系统稳定性及可靠性，在这样两者恒相冲突的状况下，又该如何透过整合来达到「快速」的目的呢?
所以 DevOps 开发方法最主要改善的是开发团队以及维运团队的关系，并透过 Agile 「敏捷式开发」的概念，让交付可以达到「透明化」、「持续化」以及「自动化」等目标。
关于 DevOps
先介绍一下 DevOps 吧，DevOps 是来自 Development 和 Operations 这 2 个英文字的缩写组合，跟 Agile 一样，他并非是使用特定的工具或技术来做为解决方案，而是一种具备文化、哲学、实务与工具于一身的概念结合，主要目的是提升组织快速交付应用程式和服务的能力，仅管相较于使用传统软件开发的「瀑布式」的管理程序，这种作法能更有效率的快速开发和改进产品，并提供更具竞争力的服务。
但很多文章中会将 DevOps 翻成 「快速交付」 、「持续交付」，但这并非完全正确。因为针对传统端对端开发流程，每一个部门都有可独立切割的功能，开发团队专注软件开发，维运团队做软件发布(或软件部属)，而测试团队就是做上线前后的测试。是当功能被明显切割后，仅管遵循公司开发流程，但团队间讯息上的同步势必会有所影响，例如当开发团队递交的软件，不符合部署环境，或是因功能更改软件规格时，维运团队可能就因为资讯落差而退回交付；又或是开发团队交付功能给测试团队后，却因为不甚熟悉造成测试漏洞，当然也有开发环节测试不过的可能性，但综合以上的案例，就会拖累软件交付速度。
所以 DevOps 最核心的概念就是为了解决跨部门与跨团队间的冲突，透过透明度的提高以及一些机制的导入，来做有效率的整合，来完成提高上限速度的目的。他的核心概念可以用"CALMS"来做解释。
"C"ulture-文化：
因为 DevOps 并非是一种技能或是工具，而应该要三个部门一起对齐的文化，透过同理心的互惠，多位其他部门的人去思考，在着手开发，一来可以解决资讯上的同步问题，更可以解决因为部门落差造成时间成本损失。例如开发团队应该要在程式的设定档上，设计的更易管理..等。透过共识、理解和沟通，进而改善部门间的整合问题，才是"C"代表的真正意涵。
"A"utomation-自动化：
A 通常就是开发团队最重视的问题，像是中间提到每一个容易造成 Delay 的环节，像测试及部属等等，若是都可以透过自动化来做排程，不仅可以减少沟通落差造成的问题，更可以让需求开发及整合上更为快速，想像如果使用自动化测试和自动化部属，那开发完成后的需求，就可以一下进入上线准备，这不就是「持续交付」的真谛吗?
"L"ean-精益开发：
因为 DevOps 也隶属于敏捷式开发上的内容之一，所以也必须套用精实开发上的一些原则，像是消除浪费(eliminate waste)、尽快交付(deliver as faster as possible)等，来符合 Agile 的精神。
"M"easurement-数据分析：
不断的精进是需要依据，而 M 的重点就是在透过数据上的反应，来给团队正向及改进的回馈，例如新功能上线后减少了多少客诉量、缩短多少作业时间等，甚至是每次上线后的 BUG 率及修复率等，都是可以被测量出来的基本指标，来反应出开发者的量与质是否正比。
"S"hare-分享：
既然有了数据，就应该把成效分享给 DevOps 间的所有参与者，来做下次检讨、改进的目标，而分享不仅是文化的根，也是增加团队透明度的好方法。而 DevOps 的好处，就是透过 CALMS 的方式，来达到提高发布速度及可靠性，而透过分享的回馈机制来改进，当这些观念结合在一起之后，才有助于组织可以更有品质及效率的交付产品给客户，而除了武功心法外，在实务概念上还有下列几点：
- 持续交付及持续整合：
持续整合是软件开发实务，在自动化测试及自动化发布的机制建立后，透过自动化流程来让程式码上到测试 /正式环境，因此如果导入 DevOps 开发方法中的自动化部署，便可由开发团队设定部署环境，由工具做自动化部署，减少手动以及传递的时间，且可以避免人为错误，改善软件交付品质。除交付作业可以有效的「持续化」，并透过「持续整合」来更快速的发现及整合错误，进而改善交付品质。
- 服务微型化：
一项产品若是架构过于巨大，不仅在更板上会绑手绑脚，更容易会有签一发而动全身的状况发生，而若是采用 DevOps 概念的产品，为了持续交付和整合，通常化把产品的分工切的更为细微，让纵向的产品变成横向发展，把产品服务从多功取向，变成个别单一的服务(或 API)，而每个服务的用途也尽可能的单一化。从过去大而久的发布频率，变成小而快，这就必须要依赖把服务微型化这个任务了。
- 基础设施即程式码：
基础设施即程式码是透过使用程式码和软件开发技术，来做部属与管理基础设施的实务，例如透过云端服务或 API 的导入，让开发人员和维运人员可以透过程式设计的方式，来和产品及基础设施做互动，来取代过去手动设定的繁杂手续，进而实现持续整合的目标。而这样的好处就是让所有的定义都透过程式码，来标准化作业模式完成快速部属的目标。
而 DevOps 和传统的开发方式，最大的差别就是在实务上是透过更细微的分工切割、更一致性的作业流程，以及更频繁的发布，来取代过去更版不易，耗时后久以及组织平行沟通的问题。透过小而频繁的改进，才有机会让产品更贴近使用者的意见和心声，也可以有效率的让产品进行成长。而自动化的导入更可以减少沟通落差造成的部署问题。
但记得，再多个概念和工具，都是为了弥平资讯流上的误差，以及强化跨部门工作上的整合性，光只有导入机制还不够，还必须透过定期的 review 和改进，才有办法完成适合每一个组织或团队自己的机制，这也才是符合敏捷式开发最重要的精神。
只有「快」还不够，而是要让整个生产机制的效率提高，才是提升团队生产效率的不二法门。
好雨云 xDevOps
好雨云提供面向业务的 DevOps 工作流最佳实践，遵循以应用为中心的设计理念，利用容器技术、微服务架构和软件定义系列技术解耦服务器和应用，清晰界定开发与运维之间职责，企业 IT 将可以零负担落地 DevOps 工作流，通过好雨云独有的“应用级”生产面板和“业务级”运维面板，专注于业务并以以自动或自助方式完成计算资源运维工作，达到降本提效的目的。
进一步了解好雨云 DevOps： https://www.goodrain.com/scene/devops
Select Language