devops简介

1.DevOps的概念

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。 

 换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。

2.DevOps对程序发布的影响

 在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。

然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

(1)减少变更的范围

与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。

由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

(2)加强发布协调

靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；

采用电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

(3)自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

 与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。

3.实现Devops需要什么

硬性要求：工具上的准备

上文提到了工具链的打通，那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下：

• 代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
• 构建工具：Ant、Gradle、maven
• 自动部署：Capistrano、CodeDeploy
• 持续集成（CI）：Bamboo、Hudson、Jenkins
• 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
• 容器：Docker、LXC、第三方厂商如AWS
• 编排：Kubernetes、Core、Apache Mesos、DC/OS
• 服务注册与发现：Zookeeper、etcd、Consul
• 脚本语言：python、ruby、shell
• 日志管理：ELK、Logentries
• 系统监控：Datadog、Graphite、Icinga、Nagios
• 性能监控：AppDynamics、New Relic、Splunk
• 压力测试：JMeter、Blaze Meter、loader.io
• 报警：PagerDuty、pingdom、厂商自带如AWS SNS
• HTTP加速器：Varnish 消息总线：ActiveMQ、SQS
• 应用服务器：Tomcat、JBoss、IIS
• Web服务器：Apache、Nginx
• 数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库
• 项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

软性需求：文化和人

DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。

并且协作也存在在业务人员与开发人员之间。出席了ITV公司在2012年就开始落地DevOps，其通用平台主管Clark在

2016年伦敦企业级DevOps峰会接受InfoQ了采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品

中实现什么，工程师们就按需交付，不做多余工作。这样，工程师们使用通用的平台（即打通的工具链）得到更好的

一致性和更高的质量。此外，DevOps对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。