在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险却很低。目前开发人员对于DevOps的认识深浅不一，本期请到了亚马逊架构师代闻来为我们实例解析DevOps。

01/DevOps简介和适用场景

DevOps是一个软件开发的方法，目的是为了提高内部运维能力，也就是说，DevOps是运维的一个方式，只不过通过软件实现了更高的自动化。DevOps一词，Dev是形容词，Ops是主体，DevOps的兴起，并不是技术人员自娱自乐，而是业务需求推动的结果。

传统的瀑布式开发，周期长，风险大；现在的初创公司推崇的是敏捷开发、快速迭代

但是敏捷开发仅解决了软件开发的问题，如果集成、部署、平台搭建没有做相应的调整，Ops将会是整个流程的短板。

当然，这里面涉及到另一个话题，就是微服务。当软件开发的各个团队负责各自服务，彼此通过约定接口调用实现松耦合，软件集成和部署就可以细化到各个服务，然后通过工具和平台实现持续的集成、部署、平台构建，平台的敏捷程度就会大大提升。其中，通过代码、脚本来加速集成、部署和平台构建的过程，可以成为DevOps。

DevOps需要关注的方面很多，主要有两个重点：

第一，文化和组织

关于DevOps文化和组织，听起来比较虚，但却是DevOps应用的核心。

传统公司里，开发和运维之间有既成组织架构的界限，向DevOps转型需要付出很多努力

初创公司负担少，更容易接受DevOps。

DevOps要求开发和运维之间互相协作，以业务为共同目标，实现快速迭代，平台的feature从设计、开发到交付的整个流程，都有担任ops角色的同事（也可能兼开发）参与，确保程序在设计初始就已经考虑到基础架构的优化，以及后续的内部OP事宜。

同时，担任DevOps角色的同事的技能要比以往更多一些，除了基本的服务器、网络、存储知识，还需要有代码或脚本能力。

综合下来，可以看到三种模式：

1）开发兼运维：这是在初创公司最常见的模式，5人以下的团队很多是这样的；

2）每个产品团队有OP同事，但没有运维Team。这是开始发展的公司，需要有专人做OP，但是op还是在研发的team；

3）独立的OP Team，适用于已经有一定规模的公司。比如，在AWS的用户里，我常看到80人以上的技术团队，一半都会有考虑将基础架构管理独立出来。

但无论哪种模式，都要求Ops同事除了基本系统管理以外，能够有脚本或代码的能力，能够有基于云做平台架构的能力。

云计算将最底层的数据中心运维做完了，基于云做DevOps和架构设计也就成了自然而然的事情。比如，在猎豹移动，海外运维团队10人以下，管理着上万的VM，以及各类平台服务，DevOps是必须的。

另外，如果组织发展壮大后，在DevOps过程里有一些需要仲裁的事情（如上线时间和方式），或者有些标准需要制定（如版本、平台环境等），建议有一个技术委员会（如果组织小，也许就一两个人）来作仲裁。在Netflix，这个委员会叫CORE Team，大家可以Google以下Re:invent 2015大会上Netflix的分享。

第二，工具和平台

既然DevOps是以软件开发的方式来解决运维自动化，先看看软件开发的工具和平台。首先最底层的Platform就是服务器和操作系统，操作系统有API是一切的基础，然后操作系统的API包装成系统编程的SDK，再然后才有高级语言和解释型语言运行的框架，最上面一层是代码，同时，代码也可以越过封装，通过Native调用的方式来调用更底层的接口。

02/AWS DevOps介绍

公有云对DevOps的支持，其实是一个原理。以AWS为例，Platform就是底层的基础设施，AWS通过技术平台实现了基础设施虚拟化，并提供API，这是最核心的部分，没有API，一切无从谈起。这个API就是Restful API，这也是Amazon Web Services的由来，因为Restful API就是web services，AWS做了很多的工作，把restful API包装成java、python、php、ruby等sdk，到这里已经可以通过编程的方式控制基础设施了，但是为了更加易用，AWS提供了各类的service来作为自动化框架，如基于Chef的opsworks，快速部署的Elasticbeanstalk，将基础设施代码化的cloudformation等。

通过这一层的搭建，用户只需要在配置文件或模板或脚本里指定资源，就可以完成部署和控制，因为Framework具备执行和验证的逻辑。

这是使用python sdk （名字叫boto）启用二次

启用EC2的代码

逻辑和行文需要自己控制，已经很好用了，比如你要启用20台，每台的参数可能会有不同，就可以通过写python脚本的方式，快速搭建，但是行文是自己控制的。

这是一个cloudformation模板，里面也是启用一个instance，但是，这里面只有资源描述，具体的操作逻辑是cloudformation这个服务来进行的。

通过框架服务，在自动化的基础上，可以进一步实现标准化。

这个图是AWS的DevOps服务在开发运维整个生命周期的支持情况。

三个黄色的框，分别是CodeCommit、CodePipeline和CodeDeploy。

CodeCommit是一个托管的Git仓库，用于托管代码，好处是AWS托管服务，高可用，完全支持git。

CodePipeline是一个集成编译和测试的工作流服务，可以联合源代码仓库、编译服务器（如genkins）、部署服务（如codedeploy）工作，将部署流程可视化，并能管理复杂的条件分支。

CodeDeploy是一个代码部署服务，通过在EC2虚拟机上部署Agent，可以实现分批和滚动部署，并可以通过配置文件实现部署前后的检测和验证脚本执行。

以上三个工具都可以和第三方工具集成，在部署（deploy）、平台构建（Provision）和监控（Monitor）方面，AWS服务很多。

Cloudformation其实是通过json描述的模板来实现基础架构的搭建，你可以把cloudformation模板也存入Git仓库，每一次基础设施修改都是通过修改cloudformation模板，然后应用来改动（cloudformation可以自己判断差别和资源依赖，实现最小化变更范围）。然后再存入git的时候，在注释中写明更改原由。cloudformation可以做到基础架构代码化，非常重要。

监控方面，Cloudwatch可以监控AWS各类服务的数据，比如EC2的CPU、网络、存储IO，ELB的连接数、排队数、溢出数，数据库服务的IO、延迟等等。

AWS Opswork和ElasticBeanstalk都是完整覆盖三个阶段的服务，不同之处是，Opswork偏运维，控制粒度细，基于Chef来实现平台和应用部署，基于AWS API来实现底层搭建。

熟悉Chef的同学会很容易喜欢上Opsworks。

ElasticBeanstalk更加适合研发背景多一些，或者不喜欢做很多运维工作的同学，ElasticBeanstalk可以自动化搭建底层基础设施和平台环境（如tomcat、python、ruby等），同时，ElasticBeanstalk的命令行可以和git命令协同工作，git commit之后，一条eb deploy命令可以完成部署。但是ElasticBeanstalk的平台环境版本不可以随意修改，对底层资源的修改也需要修改通过elasticbeanstalk来作。

ECS全程EC2 Container Services，是AWS的docker 集群管理服务，这里就不详细展开了。

值得一提的时，ElasticBeanstalk和ECS也可以联动，如果ElasticBeanstalk提供的环境不能满足要求，你可以把你的自定义环境打包到docker Image，ElasticBeanstalk支持docker部署。

03/猎豹DevOps案例分享

最后，分享一下猎豹DevOps的一些情况。

各项服务的频繁开启与维护: 自动化运维开发
代码快速迭代: 基于ansible的发布配置管理
各业务成本控制: 基于tags的成本核算
服务性能监控: zabbix监控

上面四项是猎豹移动在海外运维中遇到的问题的解决办法。

猎豹移动增长非常迅猛，现在使用了几乎所有的AWS商用Region以服务全球用户。

是内部运维平台的架构图，基于Boto（aws api的python sdk）来构建，猎豹自己开发了一个资源申请流程系统，内部用户可以在网页上申请资源，后台通过boto来控制aws资源

此外，更复杂的一些运维和部署，通过ansible来做。

对于初创公司，可以通过sdk控制，也可以通过aws命令行来实现自动化。Ansible也是一个非常不错的工具，不需要agent，支持aws api.

这是ansible快速部署ebs存储卷的一个例子。

总结下要点：

首先，DevOps是个方式，要建立正确的文化，开发与运维互相协作，运维技能需要从单点系统扩展到架构设计和脚本自动化。

第二，选用正确的平台和工具，诸如SDK、运维框架等平台和工具，尽量选用已有和比较成熟的，然后直接使用或进行二次开发。但即使二次开发，也是结合业务流，而不是重新做已有平台的事情。

第三，完整考虑各个环境，包括开发、编译、测试、集成、部署、平台构建、监控等，从软件设计之初就考虑到最终的基础架构支持和优化部署，通过微服务演化加速继承和部署，DevOps在其中至关重要。

第四，从哪里上手？第一步，AWS命令行和SDK（比如基于python的boto或boto3）；第二步，使用AWS基础设施服务，如cloudformation；第三步，结合使用场景使用高级服务，如ElasticBeanstak、Opsworks等提高运维规范和敏捷度，CodeCommit、CodePipeline、CodeDeploy优化CI/CD流程。

04/Q&A

Q1：在 DevOps 环节中是否需要专门的安全人员？如何解决安全问题？

安全是贯彻始终的，在初创公司，最好是大家形成安全意识，使用工具、平台和服务，也都积极了解安全方面的功能和保障。在AWS上做DevOps，要留意数据存储和传输时候加密，数据的访问权限设置，部署避免使用静态秘钥绑定等等。

Q2：Devops只适用于敏捷开发团队，还是也使用其它开发周期？

如果不做敏捷开发，那么DevOps更多的是自动化部署、降低人为错误、提高运维标准化方面。比如，虽然研发依然是瀑布式开发，但是运维Team内部可以做自动化，基础架构代码化，但是有业务驱动的话，动力一般更强，对不对。

Q3：国内团队如何选择选择云厂商？

AWS的API和SDK是最全面的，在一个比较全面的平台上可以专注自己的平台构建。首先，AWS的基础服务功能很全面，比如VPC，现在还没有看到一个级别的；第二，AWS的PaaS服务可以简化运维，如数据分析类（EMR、Redshift、Kinesis）、数据库类（RDS、DynamoDB）；第三，在同一平台上向先驱学习，比如Netflix、SuperCell、小米、猎豹、MobiVista、Camera360等等。

大家Google一下Netflix的OSS，有很多开源的好工具，便于大家在AWS上自动化运维、做大数据分析、提高架构可靠性。

Q4:如何利用 Docker 实现 DevOps 自动化、做好应用持续集成、持续交付有什么好的案例。

Docker革命性地改变了开发和部署，改变了持续集成和交付的流程，研发和运维之间的交付从代码编程了DockerImage（或者Code+DockerFile），运维只需要关注底层资源自动化。但是，DockerImage封装的平台环境要有内部的标准，虽然隔离后可以多环境，但多环境还是要有标准，方便管理。

另外，底层平台的自动化依然需要编程或脚本来实现自动化提供，这点没有变。

现在业界有一个误区，就是把Docker的集装箱特性和高动态特性没有分场景去谈，如果是你自己用，更多是关注Docker的集装箱特性，如果你是用Docker做一个PaaS，那才需要关注和实现在集群里提供高动态。（代闻原创）

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险却很低。目前开发人员对于DevOps的认识深浅不一，本期请到了亚马逊架构师代闻来为我们实例解析DevOps。

01/DevOps简介和适用场景

DevOps是一个软件开发的方法，目的是为了提高内部运维能力，也就是说，DevOps是运维的一个方式，只不过通过软件实现了更高的自动化。DevOps一词，Dev是形容词，Ops是主体，DevOps的兴起，并不是技术人员自娱自乐，而是业务需求推动的结果。

传统的瀑布式开发，周期长，风险大；现在的初创公司推崇的是敏捷开发、快速迭代

但是敏捷开发仅解决了软件开发的问题，如果集成、部署、平台搭建没有做相应的调整，Ops将会是整个流程的短板。

当然，这里面涉及到另一个话题，就是微服务。当软件开发的各个团队负责各自服务，彼此通过约定接口调用实现松耦合，软件集成和部署就可以细化到各个服务，然后通过工具和平台实现持续的集成、部署、平台构建，平台的敏捷程度就会大大提升。其中，通过代码、脚本来加速集成、部署和平台构建的过程，可以成为DevOps。

DevOps需要关注的方面很多，主要有两个重点：

第一，文化和组织

关于DevOps文化和组织，听起来比较虚，但却是DevOps应用的核心。

传统公司里，开发和运维之间有既成组织架构的界限，向DevOps转型需要付出很多努力

初创公司负担少，更容易接受DevOps。

DevOps要求开发和运维之间互相协作，以业务为共同目标，实现快速迭代，平台的feature从设计、开发到交付的整个流程，都有担任ops角色的同事（也可能兼开发）参与，确保程序在设计初始就已经考虑到基础架构的优化，以及后续的内部OP事宜。

同时，担任DevOps角色的同事的技能要比以往更多一些，除了基本的服务器、网络、存储知识，还需要有代码或脚本能力。

综合下来，可以看到三种模式：

1）开发兼运维：这是在初创公司最常见的模式，5人以下的团队很多是这样的；

2）每个产品团队有OP同事，但没有运维Team。这是开始发展的公司，需要有专人做OP，但是op还是在研发的team；

3）独立的OP Team，适用于已经有一定规模的公司。比如，在AWS的用户里，我常看到80人以上的技术团队，一半都会有考虑将基础架构管理独立出来。

但无论哪种模式，都要求Ops同事除了基本系统管理以外，能够有脚本或代码的能力，能够有基于云做平台架构的能力。

云计算将最底层的数据中心运维做完了，基于云做DevOps和架构设计也就成了自然而然的事情。比如，在猎豹移动，海外运维团队10人以下，管理着上万的VM，以及各类平台服务，DevOps是必须的。

另外，如果组织发展壮大后，在DevOps过程里有一些需要仲裁的事情（如上线时间和方式），或者有些标准需要制定（如版本、平台环境等），建议有一个技术委员会（如果组织小，也许就一两个人）来作仲裁。在Netflix，这个委员会叫CORE Team，大家可以Google以下Re:invent 2015大会上Netflix的分享。

第二，工具和平台

既然DevOps是以软件开发的方式来解决运维自动化，先看看软件开发的工具和平台。首先最底层的Platform就是服务器和操作系统，操作系统有API是一切的基础，然后操作系统的API包装成系统编程的SDK，再然后才有高级语言和解释型语言运行的框架，最上面一层是代码，同时，代码也可以越过封装，通过Native调用的方式来调用更底层的接口。

02/AWS DevOps介绍

公有云对DevOps的支持，其实是一个原理。以AWS为例，Platform就是底层的基础设施，AWS通过技术平台实现了基础设施虚拟化，并提供API，这是最核心的部分，没有API，一切无从谈起。这个API就是Restful API，这也是Amazon Web Services的由来，因为Restful API就是web services，AWS做了很多的工作，把restful API包装成java、python、php、ruby等sdk，到这里已经可以通过编程的方式控制基础设施了，但是为了更加易用，AWS提供了各类的service来作为自动化框架，如基于Chef的opsworks，快速部署的Elasticbeanstalk，将基础设施代码化的cloudformation等。

通过这一层的搭建，用户只需要在配置文件或模板或脚本里指定资源，就可以完成部署和控制，因为Framework具备执行和验证的逻辑。

这是使用python sdk （名字叫boto）启用二次

启用EC2的代码

逻辑和行文需要自己控制，已经很好用了，比如你要启用20台，每台的参数可能会有不同，就可以通过写python脚本的方式，快速搭建，但是行文是自己控制的。

这是一个cloudformation模板，里面也是启用一个instance，但是，这里面只有资源描述，具体的操作逻辑是cloudformation这个服务来进行的。

通过框架服务，在自动化的基础上，可以进一步实现标准化。

这个图是AWS的DevOps服务在开发运维整个生命周期的支持情况。

三个黄色的框，分别是CodeCommit、CodePipeline和CodeDeploy。

CodeCommit是一个托管的Git仓库，用于托管代码，好处是AWS托管服务，高可用，完全支持git。

CodePipeline是一个集成编译和测试的工作流服务，可以联合源代码仓库、编译服务器（如genkins）、部署服务（如codedeploy）工作，将部署流程可视化，并能管理复杂的条件分支。

CodeDeploy是一个代码部署服务，通过在EC2虚拟机上部署Agent，可以实现分批和滚动部署，并可以通过配置文件实现部署前后的检测和验证脚本执行。

以上三个工具都可以和第三方工具集成，在部署（deploy）、平台构建（Provision）和监控（Monitor）方面，AWS服务很多。

Cloudformation其实是通过json描述的模板来实现基础架构的搭建，你可以把cloudformation模板也存入Git仓库，每一次基础设施修改都是通过修改cloudformation模板，然后应用来改动（cloudformation可以自己判断差别和资源依赖，实现最小化变更范围）。然后再存入git的时候，在注释中写明更改原由。cloudformation可以做到基础架构代码化，非常重要。

监控方面，Cloudwatch可以监控AWS各类服务的数据，比如EC2的CPU、网络、存储IO，ELB的连接数、排队数、溢出数，数据库服务的IO、延迟等等。

AWS Opswork和ElasticBeanstalk都是完整覆盖三个阶段的服务，不同之处是，Opswork偏运维，控制粒度细，基于Chef来实现平台和应用部署，基于AWS API来实现底层搭建。

熟悉Chef的同学会很容易喜欢上Opsworks。

ElasticBeanstalk更加适合研发背景多一些，或者不喜欢做很多运维工作的同学，ElasticBeanstalk可以自动化搭建底层基础设施和平台环境（如tomcat、python、ruby等），同时，ElasticBeanstalk的命令行可以和git命令协同工作，git commit之后，一条eb deploy命令可以完成部署。但是ElasticBeanstalk的平台环境版本不可以随意修改，对底层资源的修改也需要修改通过elasticbeanstalk来作。

ECS全程EC2 Container Services，是AWS的docker 集群管理服务，这里就不详细展开了。

值得一提的时，ElasticBeanstalk和ECS也可以联动，如果ElasticBeanstalk提供的环境不能满足要求，你可以把你的自定义环境打包到docker Image，ElasticBeanstalk支持docker部署。

03/猎豹DevOps案例分享

最后，分享一下猎豹DevOps的一些情况。

各项服务的频繁开启与维护: 自动化运维开发
代码快速迭代: 基于ansible的发布配置管理
各业务成本控制: 基于tags的成本核算
服务性能监控: zabbix监控

上面四项是猎豹移动在海外运维中遇到的问题的解决办法。

猎豹移动增长非常迅猛，现在使用了几乎所有的AWS商用Region以服务全球用户。

是内部运维平台的架构图，基于Boto（aws api的python sdk）来构建，猎豹自己开发了一个资源申请流程系统，内部用户可以在网页上申请资源，后台通过boto来控制aws资源

此外，更复杂的一些运维和部署，通过ansible来做。

对于初创公司，可以通过sdk控制，也可以通过aws命令行来实现自动化。Ansible也是一个非常不错的工具，不需要agent，支持aws api.

这是ansible快速部署ebs存储卷的一个例子。

总结下要点：

首先，DevOps是个方式，要建立正确的文化，开发与运维互相协作，运维技能需要从单点系统扩展到架构设计和脚本自动化。

第二，选用正确的平台和工具，诸如SDK、运维框架等平台和工具，尽量选用已有和比较成熟的，然后直接使用或进行二次开发。但即使二次开发，也是结合业务流，而不是重新做已有平台的事情。

第三，完整考虑各个环境，包括开发、编译、测试、集成、部署、平台构建、监控等，从软件设计之初就考虑到最终的基础架构支持和优化部署，通过微服务演化加速继承和部署，DevOps在其中至关重要。

第四，从哪里上手？第一步，AWS命令行和SDK（比如基于python的boto或boto3）；第二步，使用AWS基础设施服务，如cloudformation；第三步，结合使用场景使用高级服务，如ElasticBeanstak、Opsworks等提高运维规范和敏捷度，CodeCommit、CodePipeline、CodeDeploy优化CI/CD流程。

04/Q&A

Q1：在 DevOps 环节中是否需要专门的安全人员？如何解决安全问题？

安全是贯彻始终的，在初创公司，最好是大家形成安全意识，使用工具、平台和服务，也都积极了解安全方面的功能和保障。在AWS上做DevOps，要留意数据存储和传输时候加密，数据的访问权限设置，部署避免使用静态秘钥绑定等等。

Q2：Devops只适用于敏捷开发团队，还是也使用其它开发周期？

如果不做敏捷开发，那么DevOps更多的是自动化部署、降低人为错误、提高运维标准化方面。比如，虽然研发依然是瀑布式开发，但是运维Team内部可以做自动化，基础架构代码化，但是有业务驱动的话，动力一般更强，对不对。

Q3：国内团队如何选择选择云厂商？

AWS的API和SDK是最全面的，在一个比较全面的平台上可以专注自己的平台构建。首先，AWS的基础服务功能很全面，比如VPC，现在还没有看到一个级别的；第二，AWS的PaaS服务可以简化运维，如数据分析类（EMR、Redshift、Kinesis）、数据库类（RDS、DynamoDB）；第三，在同一平台上向先驱学习，比如Netflix、SuperCell、小米、猎豹、MobiVista、Camera360等等。

大家Google一下Netflix的OSS，有很多开源的好工具，便于大家在AWS上自动化运维、做大数据分析、提高架构可靠性。

Q4:如何利用 Docker 实现 DevOps 自动化、做好应用持续集成、持续交付有什么好的案例。

Docker革命性地改变了开发和部署，改变了持续集成和交付的流程，研发和运维之间的交付从代码编程了DockerImage（或者Code+DockerFile），运维只需要关注底层资源自动化。但是，DockerImage封装的平台环境要有内部的标准，虽然隔离后可以多环境，但多环境还是要有标准，方便管理。

另外，底层平台的自动化依然需要编程或脚本来实现自动化提供，这点没有变。

现在业界有一个误区，就是把Docker的集装箱特性和高动态特性没有分场景去谈，如果是你自己用，更多是关注Docker的集装箱特性，如果你是用Docker做一个PaaS，那才需要关注和实现在集群里提供高动态。（代闻原创）