DevOps的定义

在还没有DevOps这个字出现之前，这样的概念早就成形，当时 人们使用这些名词：Agile Operations and Infrastructure、Agile System Administration、Dev and Ops Cooperation。 在2009年的Velocity研讨会上， Flickr的两位工程师John Allspaw和Paul Hammond发表了一个演说《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》，分享Flickr内部开发人员和维运人员合作的实例，让他们可以在一天内做完十次的部署。这也是DevOps第一次向世人展示出它的威力。维基百科引用了2009年Rajiv的解释和一张经典图例来定义DevOps： 『DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程式/软体工程） 、技术运营和质量保障（QA）部门之间的沟通、协作与整合。』

这个定义翻成白话来解释，就是「不同的团队一起合作」。相信这个神逻辑大家早就知道了，但DevOps不只是这样而已。它真正的重点在于，必须让沟通、协作、整合的「文化」根植在组织内部，并落实到每个人的日常工作上。 从系统开发到维 运上线都是DevOps可施力之处，通常可以包括以下范畴：

·         程式部署

·         效能监控

·         日志管理

·         版本控管

·         备份管理

·         各种环境的建置

·         各种测试

·         问题追踪

没有自动化，迟早肝硬化

尽管有这么多的工作要执行，老板并不会因此加派人手，所以落实DevOps，必须尽一切可能做到：自动化，自动化，自动化，因为很重要所以要说三次。如果没有自动化，迟早会得肝硬化。 DevOps的目标是「借由工作自动化，来提升团队工作效能，减少错误，进而缩短产品交付周期」。必须尽量把重复性高的工作自动化，因为重复性的工作交给人工去做，不但没有效率，而且容易出错，以下举两个例子来说明自动化的优点。

·         程式的部署常常需要重复执行，而且环境配置可能很复杂，如果交由人工执行，若某人前晚打电动太晚睡，部署时突然晃神，少执行一个步骤，程式部署可能就失败了，如果交由程式自动执行，比人工有效率且可靠得多。

·         使用者回报正式环境发生严重错误，团队收到问题之后，通常要花大半天的时间追查问题，再花更多的时间修正问题。如果可以在系统发生错误当下，自动把错误日志以简讯方式发送给工程师，工程师收到错误日志后，可以很快知道问题的根本原因，进而修正问题，然后新版程式再依循持续交付和自动化测试的程序，很快就可以部署到正式环境。

自动化的迷思

然而自动化不是万灵丹，并非没有缺点或限制，以下是工作自动化的过程中，需要考量的部份：

自动化的工作通常没有弹性

一般的自动化程式是以脚本方式人工编写完成，然后由机器按步骤依序执行，通常只会有最基本的例外处理。自动化程式的设计通常不会有多大的弹性，如果临时因为某个特殊需求，需要增加额外步骤，只能修改程式。然而，根据成本效益原则，自动化程式用于处理80%足够多的工作，不必为了20%的例外状况去做特殊设计，如果要做到100%有弹性的自动化程式，不如去研发自动化产品。

不是所有工作都要自动化

也是因为成本效益原则，不是全部的工作都要自动化，某些稀少或久久执行一次的工作，人工执行就好，不需要全部的工作都做到自动化。例如某些只有1%发生机率的测试案例，人工测试可能还比较有效率。

不能太依赖自动化程序

如果太过于依赖自动化，万一自动化程序出问题，工作就会停摆，因为工作已经习惯交给自动化程序去做了，大家都不去学习如何用人工完成工作，所以没有人有足够的知识和经验来完成这份工作。这就像你坐在Google电动车里，在高速公路上Google电动车的自动驾驶功能坏了，会开车的人可以切换成手动驾驶模式继续行驶，而你不会开车，只好在高速公路上等待救援。

工作不会因为自动化而被机器取代

不要害怕自动化后工作被取代，机器不会取代工作者的工作，反而可以减轻工作者的负荷，让他们有机会可以从更高的层次去管理工作。例如QA测试人员不会因为测试自动化后就被裁员，他们可以把平日繁琐的测试工作交由机器去执行，而有更充裕的时间撰写测试案例，及思考与学习如何运用有效的测试策略来测试系统。（来自DevOps社区）

DevOps的定义

在还没有DevOps这个字出现之前，这样的概念早就成形，当时 人们使用这些名词：Agile Operations and Infrastructure、Agile System Administration、Dev and Ops Cooperation。 在2009年的Velocity研讨会上， Flickr的两位工程师John Allspaw和Paul Hammond发表了一个演说《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》，分享Flickr内部开发人员和维运人员合作的实例，让他们可以在一天内做完十次的部署。这也是DevOps第一次向世人展示出它的威力。维基百科引用了2009年Rajiv的解释和一张经典图例来定义DevOps： 『DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程式/软体工程） 、技术运营和质量保障（QA）部门之间的沟通、协作与整合。』

这个定义翻成白话来解释，就是「不同的团队一起合作」。相信这个神逻辑大家早就知道了，但DevOps不只是这样而已。它真正的重点在于，必须让沟通、协作、整合的「文化」根植在组织内部，并落实到每个人的日常工作上。 从系统开发到维 运上线都是DevOps可施力之处，通常可以包括以下范畴：

·         程式部署

·         效能监控

·         日志管理

·         版本控管

·         备份管理

·         各种环境的建置

·         各种测试

·         问题追踪

没有自动化，迟早肝硬化

尽管有这么多的工作要执行，老板并不会因此加派人手，所以落实DevOps，必须尽一切可能做到：自动化，自动化，自动化，因为很重要所以要说三次。如果没有自动化，迟早会得肝硬化。 DevOps的目标是「借由工作自动化，来提升团队工作效能，减少错误，进而缩短产品交付周期」。必须尽量把重复性高的工作自动化，因为重复性的工作交给人工去做，不但没有效率，而且容易出错，以下举两个例子来说明自动化的优点。

·         程式的部署常常需要重复执行，而且环境配置可能很复杂，如果交由人工执行，若某人前晚打电动太晚睡，部署时突然晃神，少执行一个步骤，程式部署可能就失败了，如果交由程式自动执行，比人工有效率且可靠得多。

·         使用者回报正式环境发生严重错误，团队收到问题之后，通常要花大半天的时间追查问题，再花更多的时间修正问题。如果可以在系统发生错误当下，自动把错误日志以简讯方式发送给工程师，工程师收到错误日志后，可以很快知道问题的根本原因，进而修正问题，然后新版程式再依循持续交付和自动化测试的程序，很快就可以部署到正式环境。

自动化的迷思

然而自动化不是万灵丹，并非没有缺点或限制，以下是工作自动化的过程中，需要考量的部份：

自动化的工作通常没有弹性

一般的自动化程式是以脚本方式人工编写完成，然后由机器按步骤依序执行，通常只会有最基本的例外处理。自动化程式的设计通常不会有多大的弹性，如果临时因为某个特殊需求，需要增加额外步骤，只能修改程式。然而，根据成本效益原则，自动化程式用于处理80%足够多的工作，不必为了20%的例外状况去做特殊设计，如果要做到100%有弹性的自动化程式，不如去研发自动化产品。

不是所有工作都要自动化

也是因为成本效益原则，不是全部的工作都要自动化，某些稀少或久久执行一次的工作，人工执行就好，不需要全部的工作都做到自动化。例如某些只有1%发生机率的测试案例，人工测试可能还比较有效率。

不能太依赖自动化程序

如果太过于依赖自动化，万一自动化程序出问题，工作就会停摆，因为工作已经习惯交给自动化程序去做了，大家都不去学习如何用人工完成工作，所以没有人有足够的知识和经验来完成这份工作。这就像你坐在Google电动车里，在高速公路上Google电动车的自动驾驶功能坏了，会开车的人可以切换成手动驾驶模式继续行驶，而你不会开车，只好在高速公路上等待救援。

工作不会因为自动化而被机器取代

不要害怕自动化后工作被取代，机器不会取代工作者的工作，反而可以减轻工作者的负荷，让他们有机会可以从更高的层次去管理工作。例如QA测试人员不会因为测试自动化后就被裁员，他们可以把平日繁琐的测试工作交由机器去执行，而有更充裕的时间撰写测试案例，及思考与学习如何运用有效的测试策略来测试系统。（来自DevOps社区）