DevOps

DevOps

fir.im持续集成技术实践

运维技术OS小编 发表了文章 • 0 个评论 • 225 次浏览 • 2017-11-15 21:20 • 来自相关话题

互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
场景一:开发了新功能,老功能产生新的 bug;场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;

持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?




从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:




在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。

当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。

拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。




自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。




接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:




Trello 看板;三个环境(类生产环境,测试环境,生产环境);CI 工具(Jenkins/flow.ci)

说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。




多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。




还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?

我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。

整个团队的构建频率可以看下这张图:




本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。




kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
最初阶段:提交代码-自动部署;一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;




这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
测试异常——不仅仅测试正确情况,也要主动测试异常;减少耦合——保证独立的可测试性;功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;

Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。




其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析




说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。





结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!

分享阅读:http://blog.fir.im/firim_ci_practice/  查看全部
互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
  • 场景一:开发了新功能,老功能产生新的 bug;
  • 场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;
  • 场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;


持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:


“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler


如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?
cic.jpg

从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:
ciflow.jpg

在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。


当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。


拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。
cisystem.jpg

自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。
cisystem2.jpg

接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:
Agilefirim.png

  • Trello 看板;
  • 三个环境(类生产环境,测试环境,生产环境);
  • CI 工具(Jenkins/flow.ci)


说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。
gitbranchm.jpg

多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。
fzce.jpg

还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?


我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。


整个团队的构建频率可以看下这张图:
Build-frequency.jpg

本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。
kanban.png

kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
  • 最初阶段:提交代码-自动部署;
  • 一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;
  • 高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;

flow.jpg

这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
  • 测试异常——不仅仅测试正确情况,也要主动测试异常;
  • 减少耦合——保证独立的可测试性;
  • 功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;
  • 测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;


Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。
value.jpg

其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析
view.jpg

说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。
dataview.jpg


结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!


分享阅读:http://blog.fir.im/firim_ci_practice/ 


理解持续集成、持续交付、持续部署

运维技术OS小编 发表了文章 • 0 个评论 • 218 次浏览 • 2017-11-15 00:14 • 来自相关话题

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成




持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付




持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署




持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/  查看全部
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成
xci.jpg

持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付
xcd.jpg

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署
xcr.jpg

持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/ 

谈谈持续集成、持续交付、持续部署之间的区别

运维技术OS小编 发表了文章 • 0 个评论 • 188 次浏览 • 2017-11-14 22:50 • 来自相关话题

经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?




假如把开发工作流程分为以下几个阶段:

编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署

正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。




CI 需要具备这些:
全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;版本控制工具: 如 Git,CVS,SVN 等;自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。
持续集成的优点:
“快速失败”,在对产品没有风险的情况下进行测试,并快速响应;最大限度地减少风险,降低修复错误代码的成本;将重复性的手工流程自动化,让工程师更加专注于代码;保持频繁部署,快速生成可部署的软件;提高项目的能见度,方便团队成员了解项目的进度和成熟度;增强开发人员对软件产品的信心,帮助建立更好的工程师文化。
 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。





试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
快速发布。能够应对业务需求,并更快地实现软件价值。编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;高质量的软件发布标准。整个交付过程标准化、可重复、可靠,整个交付过程进度可视化,方便团队人员了解项目成熟度;更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。
 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。





为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”


实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。

“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。

 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 

分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书 查看全部
经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?
devops-workfollow.png

假如把开发工作流程分为以下几个阶段:


编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署


正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。
CI.png

CI 需要具备这些:
  • 全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;
  • 灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;
  • 版本控制工具: 如 Git,CVS,SVN 等;
  • 自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;
  • 反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。

持续集成的优点:
  • “快速失败”,在对产品没有风险的情况下进行测试,并快速响应;
  • 最大限度地减少风险,降低修复错误代码的成本;
  • 将重复性的手工流程自动化,让工程师更加专注于代码;
  • 保持频繁部署,快速生成可部署的软件;
  • 提高项目的能见度,方便团队成员了解项目的进度和成熟度;
  • 增强开发人员对软件产品的信心,帮助建立更好的工程师文化。

 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。
CD.png


试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
  • 快速发布。能够应对业务需求,并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
CR.png


为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”



实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。


“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。


 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 


分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书


2017 GOPS全球运维大会深圳北京PPT分享

回复

运维技术OS小编 发起了问题 • 1 人关注 • 0 个回复 • 520 次浏览 • 2017-07-30 14:54 • 来自相关话题

DevOps详解

运维技术OS小编 发表了文章 • 0 个评论 • 254 次浏览 • 2017-07-18 00:04 • 来自相关话题

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。
 
但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。
 
最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。
 本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158​  

目录






1. 简介​

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。




开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。
IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:




主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:




此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:




来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
执行实际的部署工作,或修复与部署工作有关的问题
这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
通过自动化部署将目前这种手工任务所需的时间减少31%。通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。
 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。




这些统计告诉我们:
只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。如需手工运行55条命令,成功部署的概率将跌至22%。如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!
成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:




(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。Flickr每天部署10次。Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。
他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 




喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?




下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 




上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
编码:代码开发和审阅,版本控制工具、代码合并工具构建:持续集成工具、构建状态统计工具测试:通过测试和结果确定绩效的工具打包:成品仓库、应用程序部署前暂存发布:变更管理、发布审批、发布自动化配置:基础架构配置和部署,基础架构即代码工具监视:应用程序性能监视、最终用户体验
虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。
最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……恢复时间:一键点击即可恢复生产环境,就是这么简单。确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。
这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。




但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
从实践中学习自动化更频繁的部署
 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:




 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。




那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
对软件组件的开发和平台的供应和设置进行持续集成。TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。软件的持续审计 - 例如使用Sonar。在生产级环境实现功能测试的自动化。更强大的非功能测试自动化(性能、可用性等)。独立于目标环境的自动化打包和部署。
另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
功能开关(Feature Flipping)摸黑启动(Dark launch)蓝/绿部署(Blue/Green Deployment)金丝雀发布(Canari release)
 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end 摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一 查看全部
最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。
 
但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。
 
最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。
 本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158​  


目录


mulu.png


1. 简介​


DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。
woc.png

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。
IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:
devopsharch.png

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:
wofpeople.png

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:
sfd.png

来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
  • 执行实际的部署工作,或修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
  1. 通过自动化部署将目前这种手工任务所需的时间减少31%。
  2. 通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。
gl.png

这些统计告诉我们:
  • 只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
  • 如需手工运行55条命令,成功部署的概率将跌至22%。
  • 如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:
howmuch.png

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
  • Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
  • Flickr每天部署10次。
  • Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 
devops.png

喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?
icc.png

下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 
asc.png

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
  • 可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
  • 生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
  • 恢复时间:一键点击即可恢复生产环境,就是这么简单。
  • 确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
  • 维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
  • 让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
  • 部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
  • 部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
  • 部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

ttr.png

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
  • 从实践中学习
  • 自动化
  • 更频繁的部署

 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:
idmcc.png

 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
  • 首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)
  • 第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。
  • 第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。

change.png

那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
  • 对软件组件的开发和平台的供应和设置进行持续集成。
  • TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。
  • 代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。
  • 软件的持续审计 - 例如使用Sonar。
  • 在生产级环境实现功能测试的自动化。
  • 更强大的非功能测试自动化(性能、可用性等)。
  • 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
  • 功能开关(Feature Flipping)
  • 摸黑启动(Dark launch)
  • 蓝/绿部署(Blue/Green Deployment)
  • 金丝雀发布(Canari release)

 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一

详解微服务实践从架构到部署

运维技术OS小编 发表了文章 • 0 个评论 • 317 次浏览 • 2017-07-17 22:08 • 来自相关话题

前言

前段时间公司事情多,这篇长文写了放、放了写…耽搁了一些进度。各个自媒体的更新也慢了很多,这里给大家说句抱歉了。
 
现如今“微服务”遍地开花,已经成软件架构领域最受欢迎的热门话题之一。网上和书籍中都有很多关于微服务基础和优势的学习材料,但是我们可能会发现这东西在现实世界企业场景中似乎好像没那么普及,真正能跑的微服务资源其实也不是很多,大多是停留在概念和摸索阶段。

在这篇文章里,我打算讲讲微服务架构(MSA)的关键架构概念,以及如何在实践中将这些架构原理应用起来。





前因:单片结构

企业应用,因为服务于众多业务需求,因此会有些特定的软件应用提供许多功能,而一般惯例是把这些功能都堆在单个单片应用中。例如,ERP,CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署,在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。

面向服务架构(SOA)旨在通过引入“服务”的概念来克服以上的限制,“服务”是从应用程序提供的类似功能中提取出来的聚合和分组。因此,使用SOA,软件应用程序就会被设计为“粗粒度”服务的组合。然而,SOA中服务的范围非常广泛,这又引出了复杂而庞大的服务与一大堆操作(功能)以及复杂无比的消息格式和标准(如WS *标准)。




多数情况下,SOA中的服务彼此独立,只不过它们与所有其他服务一起部署在相同的运行时间里(只需考虑将部署到同一个Tomcat实例中的多个Web应用)。和单片软件应用类似,这些服务通过积累各种功而具有随时间推移的习惯。图1是一个非常好的一个单片架构的例子,显示了包括多个服务的零售软件应用,所有这些服务都能部署到同一应用程序。

说了那么多,大家是不是有点不明所以?我总结了一些重点,以下就是基于单片架构的应用程序的一些特性归纳:
单片应用程序被设计、开发和部署为单个单元。单片应用相对复杂,导致维护,升级和新特性困难重重。难以用单片架构来实践敏捷开发和交付方法。想更新某部分,很可能要重新部署整个应用。规模需求冲突的情况下,若想做单点扩展,要做好多倍资源甚至推倒重来的准备(例如,想给A服务更多CPU,B服务可能要重做,也可能要补两三倍memory)可靠性:一个不稳定的服务可以拖慢整个应用性能。难创新:采用新技术和框架非常困难,因为所有的功能必须建立在均匀的技术/框架上。
单片架构的天然特性,直接给微服务架构的异军突起带来了绝佳的机会。
 

后果:微服务架构

微服务架构(MSA)的基础是将单片应用作为一套小型和独立服务来开发,这些服务都在自己的空间独立开发、部署和运行。在微服务体系结构的大多数定义中,它普遍被解释为将巨大的可用服务隔离成一套独立服务的过程。

不过我对这些有自己的理解,微服务的逻辑不仅是将整个大容量服务分为独立服务,关键在于通过查看从整体提供的功能,我们就可以确定所需的业务能力。而这些业务能力可以具体实现为各自独立的细粒度和自包含(微)服务。它们可能在一个技术堆栈上实现,每个服务都处理一个非常具体和有限的业务范围。

因此,上面解释的在线零售系统场景可以通过如图2的微服务架构实现。通过微服务架构,零售软件应用程序被规整为一套微服务。而且从图2最底下一层可以看出,根据业务需求,还多了一个从原始服务组合中额外创建的一个微服务。换句话说,想跟进微服务,要有超大容量服务可能会分裂的准备,不过我相信相比于进步,这点麻烦值得付出。 




所以,铺垫了那么多,现在我们深入了解微服务的关键架构原理,这里重要的是最好带着实践的思路来思考问题。
 

设计微服务:大小,范围和功能

通过Microservices Architecture可以从头开始构建软件应用或改造现有应用程序/服务…无论是哪种方法,正确判定Microservices的大小,范围和功能,都至关重要。我感觉,这可能是在Microservices Architecture实践最初(对的,“最初”这个词用的没错)最难的事了。

现在聊聊关于微服务的规模、范围和功能的关键实践问题和对一些坊间误解的辟谣。
代码行数/团队规模都是坑B指标:这里先引入一个概念,双披萨团队,有兴趣的可以去深入了解。根据实施代码或团队规模,有几个讨论决定了Microservices的大小。然而,这些被认为是非常不切实际和糟糕的指标,即便我们仍然可以使用较少的代码/双比萨团队做规模开发,但这种思路完全违反了微服务架构主体。'Micro'有点误导性的词语:大多数开发人员倾向于认为他们应尽可能的减少服务,这是一个天然的误解。在SOA上下文中,服务通常被实现为具有数十个操作/功能的单片全局。所以,像SOA这样的服务就算命名为微服务,不会给你带来微服务架构的好处。
 
那么那么我们应该如何在微服务架构中正确设计服务?
 

微服务设计指南

单一责任原则(SRP):为微服务提供有限和重点突出的业务范围,有助于我们满足开发和提供服务的敏捷性。在微服务的设计阶段,我们应该找到各服务的边界,并将其与业务能力(也称为域驱动设计中的有界环境 )保持一致。微服务设计要确保敏捷/独立开发和部署服务的丝滑稳定。我们的重点应该放在微服务的范围上,而不是使服务更"小"。服务的大小应该是指所需的范围大小,以促进给定的业务能力。与SOA中的服务不同,给定的微服务应该具有很少的操作/功能和简单的消息格式。随着时间的推移,首先开始具有相对广泛的服务边界,重构到较小的服务界限(基于业务需求),这是一个很好的做法。
在我们的零售用例中,整体功能分为四个不同的微服务,即“库存”,“会计”,“运输”和“存储”。他们正在解决一个有限但重点突出的业务范围,使每个服务彼此完全脱钩,并确保开发和部署中的敏捷性。
 

微服务中的消息传递

在单片应用中,使用函数调用或语言级方法调用不同处理器/组件的业务功能。在SOA中,这种转移趋向于更为松散耦合的Web服务级别消息传递,主要基于不同协议(如HTTP,JMS)之上的SOAP。而具有数十种操作和复杂消息模式的Web服务是Web服务普及的关键阻力。对于Microservices架构,它需要简单而轻量的消息传递机制就行。
 

同步消息 - REST,Thrift

对于同步消息传递(客户端期望从服务及时得到响应并等待到达),在微服务体系结构中,REST是主流标配,因为它提供了基于资源API风格的HTTP请求响应实现的简单消息传递方式。因此,大多数微服务实现都使用HTTP以及基于资源API的风格(每个功能都以资源和在这些资源之上执行的操作来表示)。




另外,Thrift (可以在其中为微服务定义接口定义)可以作为REST / HTTP同步消息传递的替代方法。
 

异步消息 - AMQP,STOMP,MQTT

对于某些需要使用异步消息传递技术(客户端不期望立即响应或根本不接受响应)的微服务场景。多看看诸如AMQP, STOMP或MQTT之类的异步消息协议就好了。
 

消息格式 - JSON,XML,Thrift,ProtoBuf,Avro

决定微服务最适合的消息格式是另一个关键因素。传统单片应用使用二进制格式(习惯了,表示还好不算复杂);基于SOA / Web服务的应用使用基于复杂消息格式(SOAP)和模式(xsd)的文本消息。而在大多数基于微服务器的应用中,简单基于文本的消息格式即可,如JSON和XML,反正就是基于HTTP资源API风格跑起来。在我们需要二进制消息格式的情况下(文本消息在某些用例中可能会变冗长),微服务可以利用二进制消息格式,如Thrift,ProtoBuf或Avro…
 

服务合同 - 定义服务接口 - Swagger, RAML, Thrift IDL

若你把业务能力实现为服务,就需要定义和发布服务合同。传统单片应用几乎找不到这样的功能来定义应用的业务功能。在SOA/Web服务的世界里,WSDL用于定义服务合同。不过众所周知,WSDL不是用于定义微服务合同的理想解决方案,因为WSDL非常复杂且与SOAP紧密耦合。

由于我们在REST架构风格之上构建微服务器,所以我们可以使用相同的REST API定义技术来定义微服务器的合同。因此,微服务更多情况下用标准的REST API定义语言(如Swagger和RAML) 来定义服务契约。
对于不基于HTTP/REST(如Thrift)的其他微服务实现,可以用协议级别的“接口定义语言(IDL)”(如Thrift IDL)。
 

集成微服务(Inter-service / process communication)

在微服务架构中,软件应用程序被构建为一套独立的服务。因此,为了实现业务用例,需要在不同的微服务/流程之间建立通信结构。这就是为什么微服务之间的服务间/过程通信至关重要的原因。
 
在SOA实现中,服务之间的服务间通信通过企业服务总线(ESB)来实现,大部分业务逻辑都位于中间层(消息路由,转换和业务流程)中。然而,微服务架构促进消除中央消息总线/ESB,并将“智能”或业务逻辑移至服务和客户端(称为“智能端点”)。

由于微服务使用诸如HTTP,JSON等标准协议,因此在微服务之间的通信中,与不同协议集成的要求是最小的。Microservice通信中的另一种替代方法是使用轻量级的消息总线或网关,它们有最小的路由功能,并且仅用作在网关上实现业务逻辑的“dumb pipe”。基于这些风格,在微服务架构中不可避免的出现了几种通信模式。
 

点到点风格 - 直接调用服务

以点对点的形式,消息路由逻辑的整体跑在每个端点之上,服务可以直接通信。这里每个微服务器都暴露一个REST API,一个给定的微服务器或外部客户端可以通过对应的REST API调用另一个微服务器。




显然,这个模型适用于相对简单的基于微服务的应用。随着服务数量增加,复杂就会压倒一切的源头。传统SOA实现中使用ESB也是相同的原因,不过是为了摆脱混乱的点对点集成链接。总结微服务通信中点对点风格的缺点:
须在每个微服务级别实现终端用户认证,限制,监控等非功能性要求。由于不可避免的复制一些常用功能,每个微服务实现可能会变得复杂。服务和客户端之间的所有通信都无法控制(哪怕只是监控,跟踪或过滤)。通常直接沟通风格被认为是用于大规模微服务实现的微服务反向模式。
特征说完,总结:对于复杂的微服务用例,可以考虑轻量级的中央消息总线,而不是点对点连接或中心ESB,思路是为微服务提供一个抽象层,并可用于实现各种非功能的能力,这种风格被称为API网关风格,往下看。
 

API网关样式

API网关风格背后的关键思想是使用轻量级消息网关作为所有客户端/消费者的主要入口点,并在Gateway级别实现常见的非功能需求。通常,API网关允许通过REST/HTTP使用受管API。因此,在这里,我们可以将通过API-GW实现作为微服务的业务功能公开为管理API。Microservices架构和API管理的组合,这个算是最佳选择了。




在我们的零售业务场景中,如图5,所有的微服务都通过API-GW公开,这是所有客户端的单个入口点。总结下API-GW风格优势:
能够在现有微服务的网关级别提供所需的抽象。例如,API网关可以为每个客户端提供不同的API,而不是提一个所有类型的API。网关级、轻量级消息路由/转换。非功能性功能(如安全性,监控和调节)的应用能如臂指使。API-GW模式让非功能性要求在Gateway级别实现,微服务得以瘦身。
比较推荐API-GW,我没具体了解过,但这个应该也是应用最广泛的模式。
 

Message Broker风格

微服务还可以和异步消息的场景集成,比如队列或主题的单向请求以及订阅。给定的微服务可以做消息生成,并且它可以异步地将消息发送到队列或主题。那么消费的微服务器可以消耗来自队列或主题的消息。这种风格将消息生成与消息消费分离,中间消息代理缓冲直到消费处理。




消费/生产之间的通信基于异步消息标准(例如AMQP,MQTT等)的消息代理来实现。
 

分散式数据管理

单片架构中,应用将数据存储在单个和集中的数据库中,以实现应用的各种功能/功能。




在微服务体系结构中,功能分散在多个微服务器中,如果我们使用相同的集中式数据库,那么微服务器将不再彼此独立(例如,如果数据库模式已经从给定的微服务器发生变化)。因此,每个微服务器都必须拥有自己的数据库。




以下是在微服务架构中实施分散数据管理的关键方面:
每个微服务器都可以有一个私有数据库来保存实现从其提供的业务功能所需的数据。给定的微服务器只能访问专用私有数据库,而不能访问其他微服务器的数据库。某些业务场景中,可能单个事务需要更新多个数据库。在这种情况,其他微服务器的数据库应仅通过其服务API进行更新,而非直接访问。
非集中式数据管理提供完全解耦的微服务器,以及选择不同数据管理技术(SQL或NoSQL等,按需分配,可能不同数据库管理系统)的自由。再者对于涉及多个微服务的复杂事务用例,事务行为必须使用从每个服务提供的API来实现,并且逻辑位于客户端或中间(GW)级别。
 

权力下放的治理思维

微服务架构倾向于分散治理。一般来说,SOA治理指导了可重用服务的开发,建立如何设计和开发服务以及这些服务随时间的变化。它确定了服务提供商和这些服务的消费者之间的协议,告诉消费者他们期望什么以及提供者有义务提供什么。在SOA治理中,共有两种类型的治理:
设计时治理 - 定义和控制服务策略的服务创建,设计和实施;运行时管理 - 执行期间执行服务策略的能力;
那么,微服务环境中的治理究竟怎么理解?在微服务架构中,微服务通过各种技术和平台构建为完全独立和解耦服务。因此,不需要为服务设计和开发定义一个共同的标准。总结下微服务的权力下放治理能力:
在微服务架构中,管理不需要集中设计。微服务器可以因地制宜,决定其设计和实现。微服务架构促进了共享/可重用服务的共享。一些运行时管理方面,如SLA,节流,监控,常见安全要求和服务发现可以在API-GW级别实现。
 

服务注册和服务发现

在微服务架构中,需要处理的微服务器数量相当高。而且,由于微服务的快速和敏捷的开发/部署性质,他们的位置一般来说也会动态变化。因此,你需要在运行时间内找到微服务器的位置。解决此问题的方法是使用Service Registry。
 
服务注册表:
服务注册表保存微服务实例及其位置。Microservice实例在启动时注册到服务注册表,并在关机时注销。消费者可以通过服务注册表找到可用的微服务及其位置。
 
服务发现:
要找到可用的微服务及其位置,我们要一个服务发现机制。有两种类型的服务发现机制,客户端发现和服务器端发现,来看看这些服务发现机制各原理如何。
 
客户端发现:
在这种方法中,客户端或API-GW通过查询服务注册表来获取服务实例的位置。




这里客户端/API-GW必须通过调用Service-Registry组件来实现服务发现逻辑。
 
服务器端发现:
通过这种方法,客户机/API-GW将请求发送到在众所周知的位置运行的组件(如负载平衡器)。该组件调用服务注册表并确定微服务器的绝对位置。




Kubernetes等微服务部署解决方案提供了服务端发现机制,自媒体里链接不能发就算了。
 

部署

在微服务架构方面,微服务的部署同样起着至关重要的作用,关键要求如下:
能够独立于其他微服务部署/部署。必须能在每个微服务级别做扩展(给定的服务可能比其他服务获得更多的流量)。快速构建和部署。一个微服务的故障不得影响任何其他服务。
Docker提供了一种很好的方式来部署满足上述要求的微服务器,所涉及的关键步骤如下:
将微服务作为(Docker)容器镜像打包。将每个服务实例部署为容器。基于更改容器实例的数量来进行缩放。构建,部署和启动微服务将会快得多,因为我们使用Docker容器(这比常规VM快得多)
Kubernetes通过允许将一组Linux容器作为单个系统进行管理,在多个主机上管理和运行Docker容器,提供容器的共同位置,服务发现和复制控制,从而扩展Docker功能。其实大多数这些功能在微服务环境中也很重要,因此使用Kubernetes(在Docker上面)用于微服务部署已经成为一种非常强大的方法,特别是对于大规模微服务部署。




图11,显示了零售应用的微服务部署概述。每个微服务实例被部署为容器,每个主机有两个容器。同时可随意更改在给定主机上运行的容器数。
 

安全

现实很骨感,无论是不是微服务都应当得到安全方面的保护。在进入微服务安全性篇章之前,我们先快速过一下如何在单片应用层面实现安全。
在典型的单片应用程序中,安全性是关于发现“谁是呼叫者”,“呼叫者可以做什么”,以及“我们如何传播该信息”。这通常在位于请求处理链的开始处的公共安全组件中实现,该组件使用底层用户存储库(或用户存储)填充所需的信息。
那么,我们可以直接将这种模式转化为微服务架构吗?是的,但是这需要在每个微服务级别实现安全组件,该级别正在与集中式/共享用户存储库进行通信,并检索所需的信息。这是解决Microservices安全问题的一种非常乏味的方法。

还有,划重点,我们可以利用广泛使用的API-Security标准(如OAuth2和OpenID Connect)来找到我们的Microservices安全问题的更好的解决方案。在深入了解之前,我来总结下这些标准。
 
OAuth2 - 是访问委派协议。客户端使用授权服务器进行身份验证,并获取称为“访问令牌”的不透明令牌。Access令牌具有关于用户/客户端的零信息。它仅引用只能由授权服务器检索的用户信息。因此,这被称为“副参考令牌”,即使在公共网络/互联网中也可以安全地使用该令牌。OpenID Connect的行为与OAuth类似,但是除了访问令牌之外,授权服务器还会发出一个包含用户信息的ID令牌。这通常由JWT(JSON Web令牌)实现,并由授权服务器签名。因此,可以确保授权服务器与客户端之间的信任。因此,JWT令牌被称为“副值令牌”,因为它包含用户的信息,显然不能在内部网络之外使用它。
 
现在,让我们看看我们如何使用这些标准来保护我们零售业的微观服务。




如图12,这些是实现微服务安全性的关键步骤:
将身份验证保留到OAuth和OpenID Connect服务器(授权服务器),以便microservices成功提供访问权限,因为有人有权使用数据。使用API-GW样式,其中所有客户端请求都有一个入口。客户端连接到授权服务器并获取访问令牌(按引用令牌)。然后将访问令牌与请求一起发送到API-GW。网关上的令牌翻译:API-GW提取访问令牌,并将其发送到授权服务器以通过值令牌来检索JWT。GW将该JWT与请求一起传递到微服务层。JWT包含有助于存储用户会话等的必要信息。如果每个服务都可以了解JSON - Web令牌,那么已经分发了你的身份机制,那你就被允许在整个系统中传输身份。在每个微服务层,我们可以有一个处理JWT的组件,这是一个非常简单的实现。
 

交易

微服务中的交易支持如何?其实,支持跨多个微服务的分布式事务是一个非常复杂的任务。

微服务架构本身鼓励服务之间的无事务协调。这个想法是给定的服务是完全独立,基于单一的责任原则。跨多个微服务器分布式事务的需要通常是微服务体系结构设计缺陷的症状,通常可以通过重构微服务器的范围进行整理。

然而,如果强制性要求跨多个服务进行分布式交易,则可以通过在每个微服务级别引入“补偿操作”来实现这种情况。关键思想是,给定的微服务是基于单一责任原则,如果给定的微服务器未能执行给定的操作,那么我们可以认为这是整个微服务的失败。
 

设计失败

Microservice架构引入了一系列分散的服务,与单片设计相比,增加了在每个服务级别发生故障的可能性。由于网络问题,基础资源不可用,给定的微服务可能会失败。不可用或无响应的微服务器不应玩砸了整个基于微服务器的应用。因此,微服务应该有容错余地,能够在可能的情况下恢复,客户端也必须妥善处理。

此外,由于服务可能随时失败,因此能够快速检测(实时监控)故障,并尽可能自动恢复服务(故障自愈)很重要。在微服务玩家的眼里,处理错误有几种常用模式。
 
断路器
当你对微服务器进行外部呼叫,就可以在每次调用时配置故障监视器组件,并且当故障达到某个阈值时该组件将停止对服务的任何进一步调用(跳闸电路)。在打开状态(可以配置)的一定数量的请求后,将电路更换回关闭状态。

这种模式对于避免不必要的资源消耗,由于超时引起的请求延迟是非常有用,也让我们有机会更积极的监控系统(基于活动的开路状态)。
 
隔板
基于微服务器的应用的一部分的故障不应影响其他应用,隔板模式是关于隔离应用的不同部分,以便应用的某个部分的服务失败不会影响任何其他服务。
 
超时
超时是一种主观加入的合理机制,当你认为结果无法返回,则允许停止响应。

模式这里叨叨完。那么,我们在哪里和如何使用这些模式与微服务?大多数情况下这些模式都适用于Gateway级别,这意味着当微服务不可用或没有响应时,在网关级别,我们可以决定是否使用断路器或超时模式将请求发送到微服务。此外,在Gateway级别实现诸如隔板之类模式也很重要,因为它是所有客户端请求的单个入口点,也因此发送服务中的故障不应影响其他微服务器的调用。

另外,Gateway可以作为中心点,我们可以通过Gateway调用每个微服务来获取每个微服务器的状态和监视。
 
微服务,企业集成,API管理和遐(瞎)想
我们专门研究过微服务架构的各种特点,以及如何在现代企业IT环境中实现它们。但是,我们应该记住,微服务不是灵丹妙药。流行语概念的盲目适应不会解决“真实”企业IT问题。

它微服务是有很多优势,我们也应该充分利用。但是我们还必须记住,解决所有企业IT问题与微服务之间联系不一定就是强相关。例如,Microservices架构促进消除ESB作为中央总线,但是当涉及到现实世界的IT时,现在有很多不是基于Microservices的应用程序/服务。所以,整合是避不开的解决思路,要做集成。

所以,理想情况下,Microservices和其他企业架构概念(如Integration)的混合方法将更为现实。以后再聊了,这个能写的太多。 希望这能让你更清楚地了解如何在企业中使用Microservices。
分享阅读原文: http://dwz.cn/6iVsiQ  查看全部


前言


前段时间公司事情多,这篇长文写了放、放了写…耽搁了一些进度。各个自媒体的更新也慢了很多,这里给大家说句抱歉了。
 
现如今“微服务”遍地开花,已经成软件架构领域最受欢迎的热门话题之一。网上和书籍中都有很多关于微服务基础和优势的学习材料,但是我们可能会发现这东西在现实世界企业场景中似乎好像没那么普及,真正能跑的微服务资源其实也不是很多,大多是停留在概念和摸索阶段。

在这篇文章里,我打算讲讲微服务架构(MSA)的关键架构概念,以及如何在实践中将这些架构原理应用起来。
warch.png


前因:单片结构


企业应用,因为服务于众多业务需求,因此会有些特定的软件应用提供许多功能,而一般惯例是把这些功能都堆在单个单片应用中。例如,ERP,CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署,在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。

面向服务架构(SOA)旨在通过引入“服务”的概念来克服以上的限制,“服务”是从应用程序提供的类似功能中提取出来的聚合和分组。因此,使用SOA,软件应用程序就会被设计为“粗粒度”服务的组合。然而,SOA中服务的范围非常广泛,这又引出了复杂而庞大的服务与一大堆操作(功能)以及复杂无比的消息格式和标准(如WS *标准)。
wss.png

多数情况下,SOA中的服务彼此独立,只不过它们与所有其他服务一起部署在相同的运行时间里(只需考虑将部署到同一个Tomcat实例中的多个Web应用)。和单片软件应用类似,这些服务通过积累各种功而具有随时间推移的习惯。图1是一个非常好的一个单片架构的例子,显示了包括多个服务的零售软件应用,所有这些服务都能部署到同一应用程序。

说了那么多,大家是不是有点不明所以?我总结了一些重点,以下就是基于单片架构的应用程序的一些特性归纳:
  • 单片应用程序被设计、开发和部署为单个单元。
  • 单片应用相对复杂,导致维护,升级和新特性困难重重。
  • 难以用单片架构来实践敏捷开发和交付方法。
  • 想更新某部分,很可能要重新部署整个应用。
  • 规模需求冲突的情况下,若想做单点扩展,要做好多倍资源甚至推倒重来的准备(例如,想给A服务更多CPU,B服务可能要重做,也可能要补两三倍memory)
  • 可靠性:一个不稳定的服务可以拖慢整个应用性能。
  • 难创新:采用新技术和框架非常困难,因为所有的功能必须建立在均匀的技术/框架上。

单片架构的天然特性,直接给微服务架构的异军突起带来了绝佳的机会。
 


后果:微服务架构


微服务架构(MSA)的基础是将单片应用作为一套小型和独立服务来开发,这些服务都在自己的空间独立开发、部署和运行。在微服务体系结构的大多数定义中,它普遍被解释为将巨大的可用服务隔离成一套独立服务的过程。

不过我对这些有自己的理解,微服务的逻辑不仅是将整个大容量服务分为独立服务,关键在于通过查看从整体提供的功能,我们就可以确定所需的业务能力。而这些业务能力可以具体实现为各自独立的细粒度和自包含(微)服务。它们可能在一个技术堆栈上实现,每个服务都处理一个非常具体和有限的业务范围。

因此,上面解释的在线零售系统场景可以通过如图2的微服务架构实现。通过微服务架构,零售软件应用程序被规整为一套微服务。而且从图2最底下一层可以看出,根据业务需求,还多了一个从原始服务组合中额外创建的一个微服务。换句话说,想跟进微服务,要有超大容量服务可能会分裂的准备,不过我相信相比于进步,这点麻烦值得付出。 
asarch.png

所以,铺垫了那么多,现在我们深入了解微服务的关键架构原理,这里重要的是最好带着实践的思路来思考问题。
 


设计微服务:大小,范围和功能


通过Microservices Architecture可以从头开始构建软件应用或改造现有应用程序/服务…无论是哪种方法,正确判定Microservices的大小,范围和功能,都至关重要。我感觉,这可能是在Microservices Architecture实践最初(对的,“最初”这个词用的没错)最难的事了。

现在聊聊关于微服务的规模、范围和功能的关键实践问题和对一些坊间误解的辟谣。
  1. 代码行数/团队规模都是坑B指标:这里先引入一个概念,双披萨团队,有兴趣的可以去深入了解。根据实施代码或团队规模,有几个讨论决定了Microservices的大小。然而,这些被认为是非常不切实际和糟糕的指标,即便我们仍然可以使用较少的代码/双比萨团队做规模开发,但这种思路完全违反了微服务架构主体。
  2. 'Micro'有点误导性的词语:大多数开发人员倾向于认为他们应尽可能的减少服务,这是一个天然的误解。
  3. 在SOA上下文中,服务通常被实现为具有数十个操作/功能的单片全局。所以,像SOA这样的服务就算命名为微服务,不会给你带来微服务架构的好处。

 
那么那么我们应该如何在微服务架构中正确设计服务?
 


微服务设计指南


  1. 单一责任原则(SRP):为微服务提供有限和重点突出的业务范围,有助于我们满足开发和提供服务的敏捷性。
  2. 在微服务的设计阶段,我们应该找到各服务的边界,并将其与业务能力(也称为域驱动设计中的有界环境 )保持一致。
  3. 微服务设计要确保敏捷/独立开发和部署服务的丝滑稳定。
  4. 我们的重点应该放在微服务的范围上,而不是使服务更"小"。服务的大小应该是指所需的范围大小,以促进给定的业务能力。
  5. 与SOA中的服务不同,给定的微服务应该具有很少的操作/功能和简单的消息格式。
  6. 随着时间的推移,首先开始具有相对广泛的服务边界,重构到较小的服务界限(基于业务需求),这是一个很好的做法。

在我们的零售用例中,整体功能分为四个不同的微服务,即“库存”,“会计”,“运输”和“存储”。他们正在解决一个有限但重点突出的业务范围,使每个服务彼此完全脱钩,并确保开发和部署中的敏捷性。
 


微服务中的消息传递


在单片应用中,使用函数调用或语言级方法调用不同处理器/组件的业务功能。在SOA中,这种转移趋向于更为松散耦合的Web服务级别消息传递,主要基于不同协议(如HTTP,JMS)之上的SOAP。而具有数十种操作和复杂消息模式的Web服务是Web服务普及的关键阻力。对于Microservices架构,它需要简单而轻量的消息传递机制就行。
 


同步消息 - REST,Thrift


对于同步消息传递(客户端期望从服务及时得到响应并等待到达),在微服务体系结构中,REST是主流标配,因为它提供了基于资源API风格的HTTP请求响应实现的简单消息传递方式。因此,大多数微服务实现都使用HTTP以及基于资源API的风格(每个功能都以资源和在这些资源之上执行的操作来表示)。
api.png

另外,Thrift (可以在其中为微服务定义接口定义)可以作为REST / HTTP同步消息传递的替代方法。
 


异步消息 - AMQP,STOMP,MQTT


对于某些需要使用异步消息传递技术(客户端不期望立即响应或根本不接受响应)的微服务场景。多看看诸如AMQP, STOMP或MQTT之类的异步消息协议就好了。
 


消息格式 - JSON,XML,Thrift,ProtoBuf,Avro


决定微服务最适合的消息格式是另一个关键因素。传统单片应用使用二进制格式(习惯了,表示还好不算复杂);基于SOA / Web服务的应用使用基于复杂消息格式(SOAP)和模式(xsd)的文本消息。而在大多数基于微服务器的应用中,简单基于文本的消息格式即可,如JSON和XML,反正就是基于HTTP资源API风格跑起来。在我们需要二进制消息格式的情况下(文本消息在某些用例中可能会变冗长),微服务可以利用二进制消息格式,如Thrift,ProtoBuf或Avro…
 


服务合同 - 定义服务接口 - Swagger, RAML, Thrift IDL


若你把业务能力实现为服务,就需要定义和发布服务合同。传统单片应用几乎找不到这样的功能来定义应用的业务功能。在SOA/Web服务的世界里,WSDL用于定义服务合同。不过众所周知,WSDL不是用于定义微服务合同的理想解决方案,因为WSDL非常复杂且与SOAP紧密耦合。

由于我们在REST架构风格之上构建微服务器,所以我们可以使用相同的REST API定义技术来定义微服务器的合同。因此,微服务更多情况下用标准的REST API定义语言(如Swagger和RAML) 来定义服务契约。
对于不基于HTTP/REST(如Thrift)的其他微服务实现,可以用协议级别的“接口定义语言(IDL)”(如Thrift IDL)。
 


集成微服务(Inter-service / process communication)


在微服务架构中,软件应用程序被构建为一套独立的服务。因此,为了实现业务用例,需要在不同的微服务/流程之间建立通信结构。这就是为什么微服务之间的服务间/过程通信至关重要的原因。
 
在SOA实现中,服务之间的服务间通信通过企业服务总线(ESB)来实现,大部分业务逻辑都位于中间层(消息路由,转换和业务流程)中。然而,微服务架构促进消除中央消息总线/ESB,并将“智能”或业务逻辑移至服务和客户端(称为“智能端点”)。

由于微服务使用诸如HTTP,JSON等标准协议,因此在微服务之间的通信中,与不同协议集成的要求是最小的。Microservice通信中的另一种替代方法是使用轻量级的消息总线或网关,它们有最小的路由功能,并且仅用作在网关上实现业务逻辑的“dumb pipe”。基于这些风格,在微服务架构中不可避免的出现了几种通信模式。
 


点到点风格 - 直接调用服务


以点对点的形式,消息路由逻辑的整体跑在每个端点之上,服务可以直接通信。这里每个微服务器都暴露一个REST API,一个给定的微服务器或外部客户端可以通过对应的REST API调用另一个微服务器。
dtd.png

显然,这个模型适用于相对简单的基于微服务的应用。随着服务数量增加,复杂就会压倒一切的源头。传统SOA实现中使用ESB也是相同的原因,不过是为了摆脱混乱的点对点集成链接。总结微服务通信中点对点风格的缺点:
  • 须在每个微服务级别实现终端用户认证,限制,监控等非功能性要求。
  • 由于不可避免的复制一些常用功能,每个微服务实现可能会变得复杂。
  • 服务和客户端之间的所有通信都无法控制(哪怕只是监控,跟踪或过滤)。
  • 通常直接沟通风格被认为是用于大规模微服务实现的微服务反向模式。

特征说完,总结:对于复杂的微服务用例,可以考虑轻量级的中央消息总线,而不是点对点连接或中心ESB,思路是为微服务提供一个抽象层,并可用于实现各种非功能的能力,这种风格被称为API网关风格,往下看。
 


API网关样式


API网关风格背后的关键思想是使用轻量级消息网关作为所有客户端/消费者的主要入口点,并在Gateway级别实现常见的非功能需求。通常,API网关允许通过REST/HTTP使用受管API。因此,在这里,我们可以将通过API-GW实现作为微服务的业务功能公开为管理API。Microservices架构和API管理的组合,这个算是最佳选择了。
apigew.png

在我们的零售业务场景中,如图5,所有的微服务都通过API-GW公开,这是所有客户端的单个入口点。总结下API-GW风格优势:
  • 能够在现有微服务的网关级别提供所需的抽象。例如,API网关可以为每个客户端提供不同的API,而不是提一个所有类型的API。
  • 网关级、轻量级消息路由/转换。
  • 非功能性功能(如安全性,监控和调节)的应用能如臂指使。
  • API-GW模式让非功能性要求在Gateway级别实现,微服务得以瘦身。

比较推荐API-GW,我没具体了解过,但这个应该也是应用最广泛的模式。
 


Message Broker风格


微服务还可以和异步消息的场景集成,比如队列或主题的单向请求以及订阅。给定的微服务可以做消息生成,并且它可以异步地将消息发送到队列或主题。那么消费的微服务器可以消耗来自队列或主题的消息。这种风格将消息生成与消息消费分离,中间消息代理缓冲直到消费处理。
messbroker.png

消费/生产之间的通信基于异步消息标准(例如AMQP,MQTT等)的消息代理来实现。
 


分散式数据管理


单片架构中,应用将数据存储在单个和集中的数据库中,以实现应用的各种功能/功能。
darch.png

在微服务体系结构中,功能分散在多个微服务器中,如果我们使用相同的集中式数据库,那么微服务器将不再彼此独立(例如,如果数据库模式已经从给定的微服务器发生变化)。因此,每个微服务器都必须拥有自己的数据库。
apidb.png

以下是在微服务架构中实施分散数据管理的关键方面:
  • 每个微服务器都可以有一个私有数据库来保存实现从其提供的业务功能所需的数据。
  • 给定的微服务器只能访问专用私有数据库,而不能访问其他微服务器的数据库。
  • 某些业务场景中,可能单个事务需要更新多个数据库。在这种情况,其他微服务器的数据库应仅通过其服务API进行更新,而非直接访问。

非集中式数据管理提供完全解耦的微服务器,以及选择不同数据管理技术(SQL或NoSQL等,按需分配,可能不同数据库管理系统)的自由。再者对于涉及多个微服务的复杂事务用例,事务行为必须使用从每个服务提供的API来实现,并且逻辑位于客户端或中间(GW)级别。
 


权力下放的治理思维


微服务架构倾向于分散治理。一般来说,SOA治理指导了可重用服务的开发,建立如何设计和开发服务以及这些服务随时间的变化。它确定了服务提供商和这些服务的消费者之间的协议,告诉消费者他们期望什么以及提供者有义务提供什么。在SOA治理中,共有两种类型的治理:
  • 设计时治理 - 定义和控制服务策略的服务创建,设计和实施;
  • 运行时管理 - 执行期间执行服务策略的能力;

那么,微服务环境中的治理究竟怎么理解?在微服务架构中,微服务通过各种技术和平台构建为完全独立和解耦服务。因此,不需要为服务设计和开发定义一个共同的标准。总结下微服务的权力下放治理能力:
  • 在微服务架构中,管理不需要集中设计。
  • 微服务器可以因地制宜,决定其设计和实现。
  • 微服务架构促进了共享/可重用服务的共享。
  • 一些运行时管理方面,如SLA,节流,监控,常见安全要求和服务发现可以在API-GW级别实现。

 


服务注册和服务发现


在微服务架构中,需要处理的微服务器数量相当高。而且,由于微服务的快速和敏捷的开发/部署性质,他们的位置一般来说也会动态变化。因此,你需要在运行时间内找到微服务器的位置。解决此问题的方法是使用Service Registry。
 
服务注册表:
服务注册表保存微服务实例及其位置。Microservice实例在启动时注册到服务注册表,并在关机时注销。消费者可以通过服务注册表找到可用的微服务及其位置。
 
服务发现:
要找到可用的微服务及其位置,我们要一个服务发现机制。有两种类型的服务发现机制,客户端发现和服务器端发现,来看看这些服务发现机制各原理如何。
 
客户端发现:
在这种方法中,客户端或API-GW通过查询服务注册表来获取服务实例的位置。
apigwc.png

这里客户端/API-GW必须通过调用Service-Registry组件来实现服务发现逻辑。
 
服务器端发现:
通过这种方法,客户机/API-GW将请求发送到在众所周知的位置运行的组件(如负载平衡器)。该组件调用服务注册表并确定微服务器的绝对位置。
sr.png

Kubernetes等微服务部署解决方案提供了服务端发现机制,自媒体里链接不能发就算了。
 


部署


在微服务架构方面,微服务的部署同样起着至关重要的作用,关键要求如下:
  • 能够独立于其他微服务部署/部署。
  • 必须能在每个微服务级别做扩展(给定的服务可能比其他服务获得更多的流量)。
  • 快速构建和部署。
  • 一个微服务的故障不得影响任何其他服务。

Docker提供了一种很好的方式来部署满足上述要求的微服务器,所涉及的关键步骤如下:
  • 将微服务作为(Docker)容器镜像打包。
  • 将每个服务实例部署为容器。
  • 基于更改容器实例的数量来进行缩放。
  • 构建,部署和启动微服务将会快得多,因为我们使用Docker容器(这比常规VM快得多)

Kubernetes通过允许将一组Linux容器作为单个系统进行管理,在多个主机上管理和运行Docker容器,提供容器的共同位置,服务发现和复制控制,从而扩展Docker功能。其实大多数这些功能在微服务环境中也很重要,因此使用Kubernetes(在Docker上面)用于微服务部署已经成为一种非常强大的方法,特别是对于大规模微服务部署。
dockercon.png

图11,显示了零售应用的微服务部署概述。每个微服务实例被部署为容器,每个主机有两个容器。同时可随意更改在给定主机上运行的容器数。
 


安全


现实很骨感,无论是不是微服务都应当得到安全方面的保护。在进入微服务安全性篇章之前,我们先快速过一下如何在单片应用层面实现安全。
  • 在典型的单片应用程序中,安全性是关于发现“谁是呼叫者”,“呼叫者可以做什么”,以及“我们如何传播该信息”。
  • 这通常在位于请求处理链的开始处的公共安全组件中实现,该组件使用底层用户存储库(或用户存储)填充所需的信息。

那么,我们可以直接将这种模式转化为微服务架构吗?是的,但是这需要在每个微服务级别实现安全组件,该级别正在与集中式/共享用户存储库进行通信,并检索所需的信息。这是解决Microservices安全问题的一种非常乏味的方法。

还有,划重点,我们可以利用广泛使用的API-Security标准(如OAuth2和OpenID Connect)来找到我们的Microservices安全问题的更好的解决方案。在深入了解之前,我来总结下这些标准。
 
  • OAuth2 - 是访问委派协议。客户端使用授权服务器进行身份验证,并获取称为“访问令牌”的不透明令牌。Access令牌具有关于用户/客户端的零信息。它仅引用只能由授权服务器检索的用户信息。因此,这被称为“副参考令牌”,即使在公共网络/互联网中也可以安全地使用该令牌。
  • OpenID Connect的行为与OAuth类似,但是除了访问令牌之外,授权服务器还会发出一个包含用户信息的ID令牌。这通常由JWT(JSON Web令牌)实现,并由授权服务器签名。因此,可以确保授权服务器与客户端之间的信任。因此,JWT令牌被称为“副值令牌”,因为它包含用户的信息,显然不能在内部网络之外使用它。

 
现在,让我们看看我们如何使用这些标准来保护我们零售业的微观服务。
wservice.png

如图12,这些是实现微服务安全性的关键步骤:
  • 将身份验证保留到OAuth和OpenID Connect服务器(授权服务器),以便microservices成功提供访问权限,因为有人有权使用数据。
  • 使用API-GW样式,其中所有客户端请求都有一个入口。
  • 客户端连接到授权服务器并获取访问令牌(按引用令牌)。然后将访问令牌与请求一起发送到API-GW。
  • 网关上的令牌翻译:API-GW提取访问令牌,并将其发送到授权服务器以通过值令牌来检索JWT。
  • GW将该JWT与请求一起传递到微服务层。
  • JWT包含有助于存储用户会话等的必要信息。如果每个服务都可以了解JSON - Web令牌,那么已经分发了你的身份机制,那你就被允许在整个系统中传输身份。
  • 在每个微服务层,我们可以有一个处理JWT的组件,这是一个非常简单的实现。

 


交易


微服务中的交易支持如何?其实,支持跨多个微服务的分布式事务是一个非常复杂的任务。

微服务架构本身鼓励服务之间的无事务协调。这个想法是给定的服务是完全独立,基于单一的责任原则。跨多个微服务器分布式事务的需要通常是微服务体系结构设计缺陷的症状,通常可以通过重构微服务器的范围进行整理。

然而,如果强制性要求跨多个服务进行分布式交易,则可以通过在每个微服务级别引入“补偿操作”来实现这种情况。关键思想是,给定的微服务是基于单一责任原则,如果给定的微服务器未能执行给定的操作,那么我们可以认为这是整个微服务的失败。
 


设计失败


Microservice架构引入了一系列分散的服务,与单片设计相比,增加了在每个服务级别发生故障的可能性。由于网络问题,基础资源不可用,给定的微服务可能会失败。不可用或无响应的微服务器不应玩砸了整个基于微服务器的应用。因此,微服务应该有容错余地,能够在可能的情况下恢复,客户端也必须妥善处理。

此外,由于服务可能随时失败,因此能够快速检测(实时监控)故障,并尽可能自动恢复服务(故障自愈)很重要。在微服务玩家的眼里,处理错误有几种常用模式。
 
断路器
当你对微服务器进行外部呼叫,就可以在每次调用时配置故障监视器组件,并且当故障达到某个阈值时该组件将停止对服务的任何进一步调用(跳闸电路)。在打开状态(可以配置)的一定数量的请求后,将电路更换回关闭状态。

这种模式对于避免不必要的资源消耗,由于超时引起的请求延迟是非常有用,也让我们有机会更积极的监控系统(基于活动的开路状态)。
 
隔板
基于微服务器的应用的一部分的故障不应影响其他应用,隔板模式是关于隔离应用的不同部分,以便应用的某个部分的服务失败不会影响任何其他服务。
 
超时
超时是一种主观加入的合理机制,当你认为结果无法返回,则允许停止响应。

模式这里叨叨完。那么,我们在哪里和如何使用这些模式与微服务?大多数情况下这些模式都适用于Gateway级别,这意味着当微服务不可用或没有响应时,在网关级别,我们可以决定是否使用断路器或超时模式将请求发送到微服务。此外,在Gateway级别实现诸如隔板之类模式也很重要,因为它是所有客户端请求的单个入口点,也因此发送服务中的故障不应影响其他微服务器的调用。

另外,Gateway可以作为中心点,我们可以通过Gateway调用每个微服务来获取每个微服务器的状态和监视。
 
微服务,企业集成,API管理和遐(瞎)想
我们专门研究过微服务架构的各种特点,以及如何在现代企业IT环境中实现它们。但是,我们应该记住,微服务不是灵丹妙药。流行语概念的盲目适应不会解决“真实”企业IT问题。

它微服务是有很多优势,我们也应该充分利用。但是我们还必须记住,解决所有企业IT问题与微服务之间联系不一定就是强相关。例如,Microservices架构促进消除ESB作为中央总线,但是当涉及到现实世界的IT时,现在有很多不是基于Microservices的应用程序/服务。所以,整合是避不开的解决思路,要做集成。

所以,理想情况下,Microservices和其他企业架构概念(如Integration)的混合方法将更为现实。以后再聊了,这个能写的太多。 希望这能让你更清楚地了解如何在企业中使用Microservices。
分享阅读原文: http://dwz.cn/6iVsiQ 

不仅是 Linux 运维最佳实践

运维技术OS小编 发表了文章 • 0 个评论 • 297 次浏览 • 2017-06-30 00:07 • 来自相关话题

我们面对的是一个不断变化的世界,业务需求在变,技术架构在变,开源工具与商业系统异构部署,新工具和技术概念层出不穷,唯有一套科学的技术方法论才能应对这些变化。很多时候,我们在面对新的问题时,会束手无措。因此,在 OSC 第 132 期高手问答中,我们策划了“Linux 运维最佳实践”的主题,并邀请了@xufengnju(胥峰)作为高手嘉宾。

@xufengnju(胥峰),资深运维专家,有 10 年运维经验,在业界颇具威望和影响力。也是盛大游戏高级研究员,2006 年毕业于南京大学,2011 年加入盛大游戏,工作至今,曾参与盛大游戏多款大型端游和手游的上线运维,主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。

自动化运维在近几年一直都是很火热的话题,技术也一直在进步,因此对于技术人员来说,最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求,思想才是运维人员应该毕生修炼的目标!本次高手问答的高手嘉宾对运维服务体系有着深度的思考,因此问答中产生的内容也是十分有质量。

本文从多个角度整理了与运维相关的内容,包括工具的选择、运维中遇到的问题、自动化运维相关等等。
 
Q&A​
 一、工欲善其事必先利其器,如何选择工具? 
1. 对服务器安全和监控,可以推荐一些开源工具吗?监控好像也就 nagios, cacti, zabbix,还有其他可以推荐的吗?安全方面如何监控?

监控工具各有侧重点,zabbix 同时支持 snmp 和自己的 agent,也支持自定义模板,在大部分场景下都是不错的选择。

另外,不要把 zabbix 视为只能监控服务器信息,通过自定义模板,也可以监控业务层面的指标。安全监控分为主动检测,如 Tenable Nessus,以及 IDS、IPS。

2. Linux 运维中,服务器版本都用什么版本?CentOS 5 还是 CentOS 6、Ubuntu?为什么选择这个版本?有做哪些测试?

目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,主要是考虑到它的稳定性以及熟悉程度最高。

3. 对于使用缓存有什么推荐吗?一般就 Redis, Codis。还有那些比较好用的开源软件?

对于类似 session-id 这样的可以非持久存储的数据,可以考虑 memcached,使用一致性哈希算法分布式存储。

4. 做自动化发布,除了 Jenkins 持续集成工具,还有那些好用的工具呢?

目前我所知道的,一般都是 Hudson 或者 Jenkins,后者是前者分支出来的。这些工具都有丰富的插件,灵活使用这些插件是关键所在。

5. 问个 MySQL 问题,三个版本(MySQL(官方版本)、Percona Server 、MariaDB)您建议使用哪个版本,原因是?

我们团队一般使用的是官方版本。主要是考虑到支持和生态。

6. 服务器日志收集和分析有什么好工具推荐吗?ELK 貌似有点复杂,不太会用,有其他的推荐么?

ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本,但还是值得去研究和尝试的。

7. 书里有开源出一些工具和脚本吗,哪里可以下载到?

书上的脚本我正在整理,其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git  

8. 请问你们现在运维都是基于 Ansible 吗?我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火,还没实践用过,请问这个用起来差别大吗?

各种不同的批量管理工具各具特点,根据自己的熟悉程度和实际业务需要选择一个完全掌握即可
目前 IaaS 平台是自研的,基于 KVM

二、绝知此事要躬行,运维中遇到问题?1. LVS 和 HAPROXY 后端服务器规模可以到什么程度,比如有多少个应用,多少台后端服务器?

这个取决于应用的类型,在实际的业务场景下,需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大,可以考虑 LVS 的 DR 模式。一般情况下,负载均衡器不太会成为瓶颈。

负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计?
通过开源的 Zabbix 模板或者自定义模板,这些都不难实现。有没有相关的命令集进行统计,或者详细的统计实例?

针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术,建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm,netstat 等。

2. 对于涉及多个平台(Unix, Linux, Windows)的统一管理(认证,配置,服务)有什么好的解决方案或者思路么?

先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证,可以考虑,这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品,比如 Ansible 或者 Salt。目前我们用的自研系统,思路和 Ansible 类似。

3. 如何监控服务,业务运行状态监控你是怎么做的?

我们的监控系统是自研的,对游戏来说,很重要的一个业务指标是在线人数,它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。

4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本,业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台?

我们批量管理服务器的方式是 ssh,思路和 Ansible 类似。CMDB 提供基础数据的管理,是自研的。

5. 请问有使用过流量镜像吗?就是把线上的流量镜像一份,引到测试环境,用真实的用户数据测试,想了解下从 0 开始实施的过程。

关于流量镜像的原理,可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后,你应该可以自己写一套。我没有亲自实践过,你可以自己关注下 tcpcopy 这个项目。

6. CentOS 6 要如何做系统和网络优化?/etc/sysctl.conf 中的这个参数
net.ipv4.tcp_max_tw_buckets = 6000要如何设置,是越多越好吗?设置成 16000?
net.ipv4.tcp_max_tw_buckets = 16000

对于系统优化来说,要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket,如系统中 timewait 状态较多,可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外,如果使用长连接对于减少该状态的连接数有效。

7. 如果有 100 多台服务器,大部分都是在提供业务的服务器,如何升级呢?除了停机维护,现在有什么比较好的解决方案吗?

如果本身业务切分比较好,例如采用无状态的微服务等架构,可以通过前端负载均衡器进行灰度升级。如果应用做的不好,只有单台的这种,或者集中数据库,就比较麻烦了。

8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念?

你说的 FARM 应该是某硬件负载均衡设备的专有名词,应该是负载均衡组的概念。在 LVS 和 HAProxy 里面,负载均衡组的数量上没有硬限制,但实践中一般不会配置太多,因为这涉及到维护成本以及 HA 环境下主备切换时的开销。

9. 系统是 CentOS release 6.5 (Final), 系统没有自动回收内存,16G,我自己写了个 Shell 脚本,每次执行判断小于 1G 的时候回收内存

可以关注下 sysctl 中 swap 以及 swappiness 的一些配置

10. 请问如果是有很多 ECS/VPS,系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能,但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗? 

在我的这个演讲里面讲到了异构系统的批量管理方法,你可以参考下。

http://www.build.net/greatops/453250.html  。另外,你可以参考下 Ansible 或者 salt。

三、自动化运维相关,工程师思维?
1. 可以说下什么是自动化运维,如何才算服务器做了自动化运维?包括哪些?自动化发布,有问题可以回滚?

运维自动化是一个仁者见仁智者见智的概念。我的理解是,运维自动化要打通从代码开发完到正式上线的所有环节,包括版本构建、打通自动测试、自动化上线以及自动化监控。

在这个大命题下,可以根据自己工作环境和自动化水平的不同,选择一两个痛点开始进行自动化实践。最后形成完整体系。

2. 想请问一下自动化运维怎么做的?需要从那些方面考虑?我所考虑到的有实施运维,日常巡检维护,以及故障自动化处理,和提醒。除了这些请问还要注意那些方面?另外,随着 IT 技术的日新月异,涌现了很多新的应用,请问该如果有一个基本的路子来做运维,或者规律,流程来达到运维需求?例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步,更多的是上线后的运维。更多是想要一种思路,能列举大家遇到过的问题,以及问题如何处理? 

你的问题很好,但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值,但需要结合一些 DevOps 思想来进行适当的改造,融合两者的长处。从拥抱变化开始,以一种开放的态度来进行运维。但不变的一点是,以为业务创造价值为最终目标,这就是运维的目标。

3. 实现运维自动化,最主要就是配置管理、状态管理和变更管理,其中配置管理要如何来做,有什么好的方法分享下吗?

对配置管理,我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。

前者是一般意义上的 CMDB 的范畴,这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配;

对于后者,一方面是系统(例如版本控制系统的结合),一方面是流程(例如和变更管理挂钩)。在我们的实践中,这 2 个方面都有涉及。

4. 请问你主导运维自动化平台的功能设计和实施,是通过 Python 开发管理工具吗?另外,你们是重新开发,还是根据 Saltstack 之类的进行二次开发。

底层使用 SSH 协议建立服务器管理通道,上层使用 PHP 开发管理界面以及封装一些常用操作,比如密码修改、脚本下发和执行等。完全自主开发。

 
四、做好安全措施很重要,安全相关的问题1. 运维离不开安全,服务器的安全也很重要,书中有讲运维安全这块吗,如何把控安全这块?

书中有安全主题。安全是一个庞大的体系,书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题,比如社会工程和入侵检测,可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。

2. Web 安全监控有开源解决方案吗,能否做到在接入层就把一些可能的漏洞拦掉?Suricata?

Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具,你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试,不要出现误判。另外,建议对生产环境进行定期的安全扫描,例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。

 
五、Docker 很火热,在运维中结合使用?1. 在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪,存在什么问题,如何解决?

目前我们在调研 Docker 技术,只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式,要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外,我不是网易公司的,我目前在盛大游戏工作。 

2. Docker 化对运维影响深远吗?

Docker 化对运维有影响,它带来的影响包括:持续交付、微服务以及 DevOps 理念的冲击。作为运维,我们要拥抱这个变化,通过不断学习和实践来迎接这些挑战。

3. 为何国内没有一家成熟的 Docker 方案公布细节呢?

Docker 还是一个新生事物,各家使用的场景和模式有所不同,而且会有一些二次开发的管理系统和调度系统。

 
六、不是所有对比都会产生伤害,工程师想的只是最优方案1. 游戏服务器运维和网站服务器运维以及 APP 服务器运维,有哪些不同点和相同点?

这个问题很有代表性。不同点是,网站和 APP 运维接触的通用开源软件比较多,游戏运维接触的大部分都是自研的程序。

共同点是,都需要掌握操作系统知识、软件硬件以及网络知识,还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。

2. 作为运维人员,Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢?

作为高级编程语言,Python 有非常丰富的库,包括核心库和第三方库,很多时候不需要自己造轮子;

相比 Shell,它有更好的控制力、重试机制,比如对 Socket 设置超时等等。

3. CentOS 比起 Ubuntu 来说有啥优势?为什么服务器大多用 CentOS?

不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,稳定性以及熟悉程度最高。

选择某个发行版时,要考虑它的生态,比如上下游的支持,还有一点,就是运维人员招聘的方便程度,国内熟悉 CentOS 的稍多一些。

4. 想问下只有一台服务器,有多个应用,是用 LVS 做负载好还是 Nginx?差别大吗?

你说的后端应用是基于 HTTP 或者 HTTPS 的吗?如果是的话,并且吞吐量不大的情况下,使用 Nginx 即可;如果非 HTTP 或者 HTTPS 的 TCP 应用,建议使用 LVS;如果 HTTP 或者 HTTPS 吞吐量特别大的情况下,使用 LVS DR 模式。

七、You Need Backup,与备份相关的一些问题1. 1000 台机器规模,备份系统应该要做到什么程度?

1000 台服务器,要区分业务类型,如果类型单一,备份就比较好做。如果类型多,那么要考虑的地方包括:数据库更新的频率(全备+增量备份?还是只使用全备)、数据备份的大小、数据集中归档的要求。

2. 备份是怎么做的?上百 T 的图片、附件有什么高雅的备份方案?

在线备份这一块,可以考虑使用 erasure coding 算法,在增加一定可靠性的能力下,不至于导致备份存储的成本过高。同时要考虑离线备份,比如磁带。

八、路漫漫其修远兮,运维工程师的职业生涯1. 你觉得在未来,运维的核心会是什么,自动化,预判或是其他?

我觉得,未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程,把自己的能力灌输到机器上。当然,理想很丰满,现实很骨感。这需要我们的不懈努力。

2. 作为工作 4 年多的测试工作者,在运维方面也是有一定的涉猎,在公司维护自己的测试环境,有时候也需要一定运维功底,从 Windows Server 到 Linux,学习很多,也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾,后续工作也没时间去实践,目前使用的是 ng 负载,采用 Tomcat 部署方案,工作实在比较忙,很想在运维方面也有一定的提升!不知道从何入手好,求大神指教。

从你的描述来看,目前是兼职运维。我建议是否可以考虑,在搭建环境之外,多多研究下其中的原理,同时用自动化脚本维护这些环境呢。相信你也有一些编程经验,这些对于你后续实践运维也是有帮助的。另外,就是可以多看看别人总结的运维案例,少走一些弯路。

3. 运维技术挺杂的,如何看待这种杂?给人感觉好像什么都会点,对于工作 5-6 年的运维来说,有什么好的学习建议?

如你所说,运维技术要求范围确实蛮广的。我觉得,对于工作了一定时间的运维同学来说,可以考虑的方向有以下几个:
DevOps 实践(加强自己的编程能力,系统学习一门高级编程语言,运维自动化)对自己的技术薄弱点重点学习,比如系统学习网络知识看一些比较好的运维技术书籍,学习别人的干货

4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制,我们这里将运维和 BI 结合在一起。扩展运维工具和架构,将已成熟的 BI 接入运维体系,解放业务专员的工作,常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里,运维从一层平台逐渐变成一种框架,有需要的场景都可以套用。技术一直在变,但最重要的不是技术,而是用技术提供服务的思想。
 
除了和 BI 结合,运维思维还可以和哪些相关业务场景结合,可以在新的方向上产生价值呢?

我很赞同你的想法和实践,“用技术提供服务的思想”。我个人认为,运维的终极目标可能是“没有运维工程师的”自运维,或者叫智能运维,是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然,实现这个目标还有很长的路要走。

5. Devops 对运维有那些改变,能简单说下嘛?

Devops 从概念提出到现在已经有一段比较长的时间了,总体来说,我认为它带来的变化是:持续交付能力需要打通研发、测试和部署运维的整个链路,它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外,对运维来说,就是要拥抱变化,以开放的态度进行协作。

6. 现在哪个版本的 Linux 使用最广泛,还有 Linux 运维,我们需要学习一些语言吗,比如 Python 之类,这样才能算是一个真正的好运维?

不要犹豫了,立即开始学习编程吧,不管 Perl 还是 Python,熟悉哪一种都行。在这里,我不对比 Perl 和 Python 的优缺点。坚持用自己的代码(加上别人的框架和库)来解决重复的运维问题,你会成长的更快。CentOS 用的比较多。

《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容,你可以先看看。如果感兴趣的话,立即开始吧。

7. 请问您写书,是怎么坚持写下来的?是把平时工作重点的问题,记录下来,每天写一点,再总结吗?写书有什么工具软件吗,还是只是用 Word 来写?能分享下写运维书籍的方法吗?

这个问题非常好,也是我想分享的。写书的素材依赖于平时的积累,建议大家平时多写写标准的文档,word 格式可以参考咱们这本书的编排。比较重要的 3 点是:
visio 图要保留下来,不能只存图片,因为可能还要调整排版有些故障现场,尽量记录详细,现象和分析过程、辅助的日志和抓包文件等,建议都保留下来脚本按照分类保存下来,以便查找

有关 Linux 运维最佳实践的问答内容至此结束,各位读者可以转到原帖浏览更多内容。
原文:运维技术干货 — 不仅是 Linux 运维最佳实践 。 查看全部
我们面对的是一个不断变化的世界,业务需求在变,技术架构在变,开源工具与商业系统异构部署,新工具和技术概念层出不穷,唯有一套科学的技术方法论才能应对这些变化。很多时候,我们在面对新的问题时,会束手无措。因此,在 OSC 第 132 期高手问答中,我们策划了“Linux 运维最佳实践”的主题,并邀请了@xufengnju(胥峰)作为高手嘉宾。

@xufengnju(胥峰),资深运维专家,有 10 年运维经验,在业界颇具威望和影响力。也是盛大游戏高级研究员,2006 年毕业于南京大学,2011 年加入盛大游戏,工作至今,曾参与盛大游戏多款大型端游和手游的上线运维,主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。

自动化运维在近几年一直都是很火热的话题,技术也一直在进步,因此对于技术人员来说,最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求,思想才是运维人员应该毕生修炼的目标!本次高手问答的高手嘉宾对运维服务体系有着深度的思考,因此问答中产生的内容也是十分有质量。

本文从多个角度整理了与运维相关的内容,包括工具的选择、运维中遇到的问题、自动化运维相关等等。
 
Q&A​
 
一、工欲善其事必先利其器,如何选择工具?
 
1. 对服务器安全和监控,可以推荐一些开源工具吗?监控好像也就 nagios, cacti, zabbix,还有其他可以推荐的吗?安全方面如何监控?


监控工具各有侧重点,zabbix 同时支持 snmp 和自己的 agent,也支持自定义模板,在大部分场景下都是不错的选择。

另外,不要把 zabbix 视为只能监控服务器信息,通过自定义模板,也可以监控业务层面的指标。安全监控分为主动检测,如 Tenable Nessus,以及 IDS、IPS。


2. Linux 运维中,服务器版本都用什么版本?CentOS 5 还是 CentOS 6、Ubuntu?为什么选择这个版本?有做哪些测试?


目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,主要是考虑到它的稳定性以及熟悉程度最高。


3. 对于使用缓存有什么推荐吗?一般就 Redis, Codis。还有那些比较好用的开源软件?


对于类似 session-id 这样的可以非持久存储的数据,可以考虑 memcached,使用一致性哈希算法分布式存储。


4. 做自动化发布,除了 Jenkins 持续集成工具,还有那些好用的工具呢?


目前我所知道的,一般都是 Hudson 或者 Jenkins,后者是前者分支出来的。这些工具都有丰富的插件,灵活使用这些插件是关键所在。


5. 问个 MySQL 问题,三个版本(MySQL(官方版本)、Percona Server 、MariaDB)您建议使用哪个版本,原因是?


我们团队一般使用的是官方版本。主要是考虑到支持和生态。


6. 服务器日志收集和分析有什么好工具推荐吗?ELK 貌似有点复杂,不太会用,有其他的推荐么?


ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本,但还是值得去研究和尝试的。


7. 书里有开源出一些工具和脚本吗,哪里可以下载到?


书上的脚本我正在整理,其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git  


8. 请问你们现在运维都是基于 Ansible 吗?我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火,还没实践用过,请问这个用起来差别大吗?


各种不同的批量管理工具各具特点,根据自己的熟悉程度和实际业务需要选择一个完全掌握即可
目前 IaaS 平台是自研的,基于 KVM


二、绝知此事要躬行,运维中遇到问题?
1. LVS 和 HAPROXY 后端服务器规模可以到什么程度,比如有多少个应用,多少台后端服务器?


这个取决于应用的类型,在实际的业务场景下,需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大,可以考虑 LVS 的 DR 模式。一般情况下,负载均衡器不太会成为瓶颈。


负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计?
通过开源的 Zabbix 模板或者自定义模板,这些都不难实现。
有没有相关的命令集进行统计,或者详细的统计实例?


针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术,建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm,netstat 等。


2. 对于涉及多个平台(Unix, Linux, Windows)的统一管理(认证,配置,服务)有什么好的解决方案或者思路么?


先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证,可以考虑,这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品,比如 Ansible 或者 Salt。目前我们用的自研系统,思路和 Ansible 类似。


3. 如何监控服务,业务运行状态监控你是怎么做的?


我们的监控系统是自研的,对游戏来说,很重要的一个业务指标是在线人数,它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。


4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本,业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台?


我们批量管理服务器的方式是 ssh,思路和 Ansible 类似。CMDB 提供基础数据的管理,是自研的。


5. 请问有使用过流量镜像吗?就是把线上的流量镜像一份,引到测试环境,用真实的用户数据测试,想了解下从 0 开始实施的过程。


关于流量镜像的原理,可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后,你应该可以自己写一套。我没有亲自实践过,你可以自己关注下 tcpcopy 这个项目。


6. CentOS 6 要如何做系统和网络优化?/etc/sysctl.conf 中的这个参数
net.ipv4.tcp_max_tw_buckets = 6000
要如何设置,是越多越好吗?设置成 16000?
net.ipv4.tcp_max_tw_buckets = 16000


对于系统优化来说,要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket,如系统中 timewait 状态较多,可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外,如果使用长连接对于减少该状态的连接数有效。


7. 如果有 100 多台服务器,大部分都是在提供业务的服务器,如何升级呢?除了停机维护,现在有什么比较好的解决方案吗?


如果本身业务切分比较好,例如采用无状态的微服务等架构,可以通过前端负载均衡器进行灰度升级。如果应用做的不好,只有单台的这种,或者集中数据库,就比较麻烦了。


8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念?


你说的 FARM 应该是某硬件负载均衡设备的专有名词,应该是负载均衡组的概念。在 LVS 和 HAProxy 里面,负载均衡组的数量上没有硬限制,但实践中一般不会配置太多,因为这涉及到维护成本以及 HA 环境下主备切换时的开销。


9. 系统是 CentOS release 6.5 (Final), 系统没有自动回收内存,16G,我自己写了个 Shell 脚本,每次执行判断小于 1G 的时候回收内存


可以关注下 sysctl 中 swap 以及 swappiness 的一些配置


10. 请问如果是有很多 ECS/VPS,系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能,但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗? 


在我的这个演讲里面讲到了异构系统的批量管理方法,你可以参考下。

http://www.build.net/greatops/453250.html  。另外,你可以参考下 Ansible 或者 salt。


三、自动化运维相关,工程师思维?

1. 可以说下什么是自动化运维,如何才算服务器做了自动化运维?包括哪些?自动化发布,有问题可以回滚?


运维自动化是一个仁者见仁智者见智的概念。我的理解是,运维自动化要打通从代码开发完到正式上线的所有环节,包括版本构建、打通自动测试、自动化上线以及自动化监控。

在这个大命题下,可以根据自己工作环境和自动化水平的不同,选择一两个痛点开始进行自动化实践。最后形成完整体系。


2. 想请问一下自动化运维怎么做的?需要从那些方面考虑?我所考虑到的有实施运维,日常巡检维护,以及故障自动化处理,和提醒。除了这些请问还要注意那些方面?另外,随着 IT 技术的日新月异,涌现了很多新的应用,请问该如果有一个基本的路子来做运维,或者规律,流程来达到运维需求?例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步,更多的是上线后的运维。更多是想要一种思路,能列举大家遇到过的问题,以及问题如何处理? 


你的问题很好,但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值,但需要结合一些 DevOps 思想来进行适当的改造,融合两者的长处。从拥抱变化开始,以一种开放的态度来进行运维。但不变的一点是,以为业务创造价值为最终目标,这就是运维的目标。


3. 实现运维自动化,最主要就是配置管理、状态管理和变更管理,其中配置管理要如何来做,有什么好的方法分享下吗?


对配置管理,我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。

前者是一般意义上的 CMDB 的范畴,这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配;

对于后者,一方面是系统(例如版本控制系统的结合),一方面是流程(例如和变更管理挂钩)。在我们的实践中,这 2 个方面都有涉及。


4. 请问你主导运维自动化平台的功能设计和实施,是通过 Python 开发管理工具吗?另外,你们是重新开发,还是根据 Saltstack 之类的进行二次开发。


底层使用 SSH 协议建立服务器管理通道,上层使用 PHP 开发管理界面以及封装一些常用操作,比如密码修改、脚本下发和执行等。完全自主开发。


 
四、做好安全措施很重要,安全相关的问题
1. 运维离不开安全,服务器的安全也很重要,书中有讲运维安全这块吗,如何把控安全这块?


书中有安全主题。安全是一个庞大的体系,书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题,比如社会工程和入侵检测,可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。


2. Web 安全监控有开源解决方案吗,能否做到在接入层就把一些可能的漏洞拦掉?Suricata?


Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具,你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试,不要出现误判。另外,建议对生产环境进行定期的安全扫描,例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。


 
五、Docker 很火热,在运维中结合使用?
1. 在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪,存在什么问题,如何解决?


目前我们在调研 Docker 技术,只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式,要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外,我不是网易公司的,我目前在盛大游戏工作。 


2. Docker 化对运维影响深远吗?


Docker 化对运维有影响,它带来的影响包括:持续交付、微服务以及 DevOps 理念的冲击。作为运维,我们要拥抱这个变化,通过不断学习和实践来迎接这些挑战。


3. 为何国内没有一家成熟的 Docker 方案公布细节呢?


Docker 还是一个新生事物,各家使用的场景和模式有所不同,而且会有一些二次开发的管理系统和调度系统。


 
六、不是所有对比都会产生伤害,工程师想的只是最优方案
1. 游戏服务器运维和网站服务器运维以及 APP 服务器运维,有哪些不同点和相同点?


这个问题很有代表性。不同点是,网站和 APP 运维接触的通用开源软件比较多,游戏运维接触的大部分都是自研的程序。

共同点是,都需要掌握操作系统知识、软件硬件以及网络知识,还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。


2. 作为运维人员,Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢?


作为高级编程语言,Python 有非常丰富的库,包括核心库和第三方库,很多时候不需要自己造轮子;

相比 Shell,它有更好的控制力、重试机制,比如对 Socket 设置超时等等。


3. CentOS 比起 Ubuntu 来说有啥优势?为什么服务器大多用 CentOS?


不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,稳定性以及熟悉程度最高。

选择某个发行版时,要考虑它的生态,比如上下游的支持,还有一点,就是运维人员招聘的方便程度,国内熟悉 CentOS 的稍多一些。


4. 想问下只有一台服务器,有多个应用,是用 LVS 做负载好还是 Nginx?差别大吗?


你说的后端应用是基于 HTTP 或者 HTTPS 的吗?如果是的话,并且吞吐量不大的情况下,使用 Nginx 即可;如果非 HTTP 或者 HTTPS 的 TCP 应用,建议使用 LVS;如果 HTTP 或者 HTTPS 吞吐量特别大的情况下,使用 LVS DR 模式。


七、You Need Backup,与备份相关的一些问题
1. 1000 台机器规模,备份系统应该要做到什么程度?


1000 台服务器,要区分业务类型,如果类型单一,备份就比较好做。如果类型多,那么要考虑的地方包括:数据库更新的频率(全备+增量备份?还是只使用全备)、数据备份的大小、数据集中归档的要求。


2. 备份是怎么做的?上百 T 的图片、附件有什么高雅的备份方案?


在线备份这一块,可以考虑使用 erasure coding 算法,在增加一定可靠性的能力下,不至于导致备份存储的成本过高。同时要考虑离线备份,比如磁带。


八、路漫漫其修远兮,运维工程师的职业生涯
1. 你觉得在未来,运维的核心会是什么,自动化,预判或是其他?


我觉得,未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程,把自己的能力灌输到机器上。当然,理想很丰满,现实很骨感。这需要我们的不懈努力。


2. 作为工作 4 年多的测试工作者,在运维方面也是有一定的涉猎,在公司维护自己的测试环境,有时候也需要一定运维功底,从 Windows Server 到 Linux,学习很多,也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾,后续工作也没时间去实践,目前使用的是 ng 负载,采用 Tomcat 部署方案,工作实在比较忙,很想在运维方面也有一定的提升!不知道从何入手好,求大神指教。


从你的描述来看,目前是兼职运维。我建议是否可以考虑,在搭建环境之外,多多研究下其中的原理,同时用自动化脚本维护这些环境呢。相信你也有一些编程经验,这些对于你后续实践运维也是有帮助的。另外,就是可以多看看别人总结的运维案例,少走一些弯路。


3. 运维技术挺杂的,如何看待这种杂?给人感觉好像什么都会点,对于工作 5-6 年的运维来说,有什么好的学习建议?


如你所说,运维技术要求范围确实蛮广的。我觉得,对于工作了一定时间的运维同学来说,可以考虑的方向有以下几个:

  • DevOps 实践(加强自己的编程能力,系统学习一门高级编程语言,运维自动化)
  • 对自己的技术薄弱点重点学习,比如系统学习网络知识
  • 看一些比较好的运维技术书籍,学习别人的干货


4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制,我们这里将运维和 BI 结合在一起。扩展运维工具和架构,将已成熟的 BI 接入运维体系,解放业务专员的工作,常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里,运维从一层平台逐渐变成一种框架,有需要的场景都可以套用。技术一直在变,但最重要的不是技术,而是用技术提供服务的思想。
 
除了和 BI 结合,运维思维还可以和哪些相关业务场景结合,可以在新的方向上产生价值呢?


我很赞同你的想法和实践,“用技术提供服务的思想”。我个人认为,运维的终极目标可能是“没有运维工程师的”自运维,或者叫智能运维,是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然,实现这个目标还有很长的路要走。


5. Devops 对运维有那些改变,能简单说下嘛?


Devops 从概念提出到现在已经有一段比较长的时间了,总体来说,我认为它带来的变化是:持续交付能力需要打通研发、测试和部署运维的整个链路,它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外,对运维来说,就是要拥抱变化,以开放的态度进行协作。


6. 现在哪个版本的 Linux 使用最广泛,还有 Linux 运维,我们需要学习一些语言吗,比如 Python 之类,这样才能算是一个真正的好运维?


不要犹豫了,立即开始学习编程吧,不管 Perl 还是 Python,熟悉哪一种都行。在这里,我不对比 Perl 和 Python 的优缺点。坚持用自己的代码(加上别人的框架和库)来解决重复的运维问题,你会成长的更快。CentOS 用的比较多。

《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容,你可以先看看。如果感兴趣的话,立即开始吧。


7. 请问您写书,是怎么坚持写下来的?是把平时工作重点的问题,记录下来,每天写一点,再总结吗?写书有什么工具软件吗,还是只是用 Word 来写?能分享下写运维书籍的方法吗?


这个问题非常好,也是我想分享的。写书的素材依赖于平时的积累,建议大家平时多写写标准的文档,word 格式可以参考咱们这本书的编排。比较重要的 3 点是:

  • visio 图要保留下来,不能只存图片,因为可能还要调整排版
  • 有些故障现场,尽量记录详细,现象和分析过程、辅助的日志和抓包文件等,建议都保留下来
  • 脚本按照分类保存下来,以便查找


有关 Linux 运维最佳实践的问答内容至此结束,各位读者可以转到原帖浏览更多内容。
原文:运维技术干货 — 不仅是 Linux 运维最佳实践 。

基于CMDB与SALTSTACK的运维自动化之路

运维技术OS小编 发表了文章 • 0 个评论 • 454 次浏览 • 2017-06-29 01:10 • 来自相关话题

作者介绍​

张延礼,现苏州蜗牛高级运维经理,就职于腾讯多年,熟悉基础架构运维及业务运维,在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现,运维支撑体系规划和执行团队管理等方面具有丰富经验。

正文

本文基于蜗牛从零开始建设运维自动化的一些实践,总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。

一、自动化体系规划

1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块




服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等,处在运维工作的最高层;技术决策主要是为实现管理目标去制定总体方案,实施路径;技术执行则是落地的最后一环,这一环工作往往呈现零散、杂乱、重复、频繁变更的特点,承接的需求量最多,但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题:将大量重复低价值含量的人力实施变成自动化执行,最大化地降低人力依赖,提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维,个人认为首要的是要有建设思路与方法论,以下供参考:









3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化起步的阶段,建议是组建运维开发团队,从整体规划,基于ESB思想,分层建设,让支撑平台从业务逻辑中解耦。比如就业务运维而言,整个操作工作面无非就是对业务运营环境的各种操作、配置,以及对业务应用程序的管理,简单来说就是OS层和应用层。




要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西还需要与应用的研发人员规范相关接口,这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维各类业务流程的纯线上自动化。
 

二、自动化实施路线

业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化;如无统一的标准及规范,运维支撑工作将异常混乱,自动化也难以实施。因此自动化有一个基础:标准化,标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控,流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求,基于以上自动化体系建设思路,前期规划的建设线路如下




1、信息的标准化管理:CMDB

在运维工作中,信息的管理往往是难点,运维侧涉及的信息太多,且也与其他职能部门多点关联,信息流转于整个流程的多个职能部门、多个环节




中小型企业中,手工线下记录的方式居多,线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题,经常出现:
线下表格有,实际位置找不到,或信息不对称不清楚设备状态,不清楚哪个业务在使用一个部门做了变更,其他部门不知情变更一条上联链路,无法及时判断影响范围及程度

根本问题及给运维工作带来的痛点如下




因此我们引入一套基于ITIL体系的配置管理数据库CMDB,旨在为运维团队建立线下与线上一致性的基础信息库,作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化,系统主要功能模块如下图:




系统本身主要功能可归结为2个方面:基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user,除此之外,对于API-user,此系统提供了一整套接口界面与其它任何需要信息的系统进行对接,这也是设计初衷,将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统,而运维需要做的就是维护CMDB本身基础数据的完整性、准确性,CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更,处处同步。




如上为CMDB业务管理模型,作为运维统一信息库,与其他系统平台数据互通,深度整合后实现信息的管理、维护、展现全部线上化。

产品设计过程中涉及的几个关键点:
CI及属性需要贴合实际环境,同时考虑长期的运维规划管理的不仅是CI及其属性,还有CI之间的关系,状态流转机制等等充分考虑扩展性及灵活性,如引入自定义属性来满足未来或暂时不可预见的需求
 
2、通用型作业平台
对于运维执行工作而言,绝大部分的实现均是对运营环境的各类操作,在业务体量上去后,需求导致的运维操作密集度不断增加,如公司内某款游戏业务部署在近上百台主机上,一次维护要对此上百台逐一进行相应的操作,如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是:




我们决定做一个通用型运维操作平台来解决这些问题,为运维人员提供一个可以批量控制和操作大规模主机的通道,运维人员在web界面中可以定制所有的运维操作,指定执行的对象,通过平台下发执行并返回结果,例如 批量shell脚本执行,大量文件传输,发布变更,数据备份等等各类场景。对于产品设计上遵循以下几点:




技术实现上,基于公司运维环境,我们对后端系统有如下需求:
良好的scale-up/scale-out,灵活扩展,支持复杂网络结构轻量级、高效的后端通信机制,成千上万的管理规模跨平台,支持windows、unix-like多平台,无需重复开发

运维门槛低,使用运维熟悉的命令操作及脚本语言即可完成一切作业,无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统;前端系统涉及到的交互逻辑及业务逻辑自主研发,自研部分需实现的逻辑如下:
全网统一的一套基于web的用户界面,将所有操作逻辑通过web层来调用salt-api,web前端提供与直接登录机器操作一样的灵活性和自由度,运维人员在web上完成所有操作。对运维操作进行建模,将其分解为几大原子操作类型,一切复杂的序列化操作逻辑可通过原子的自由组合来实现,给用户提供自由灵活的操作方式基于以上逻辑,再给salt加一层应用接口,便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。




后端salt的逻辑这里不赘述,由于实际网络环境的特殊性,我们采用了二层架构,即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通,可以非常灵活的适应各类业务,各种场景。

如运维人员可以在界面定义好一个版本发布作业:xx业务发布,分解整个发布流程中到每一步骤,并写脚本或调用外部接口来实现具体的操作,最终线上操作只需在页面点击开始执行就可:




当然用户自定义作业可以复用,通过传参的方式实现实例化,避免必要每次发布都建作业。
 
3、建设过程中的问题总结
 
做好产品设计及架构设计
充分解析运维内部需求,各具体平台或产品业务区分明确,产品定位一定要清晰,不要想着让微波炉具备电冰箱的功能,自动化整个体系不是一个产品能解决所有问题,需要自顶向下分层设计,产品之间相互解耦且又对外提供接口,能方便的整合与被整合。

组建运维内部开发团队
运维自动化的建设,最好是组建运维内部团队来进行开发,直接丢给业务研发部门往往做出来的东西不是运维侧想要的,因其不易理解运维侧的需求场景、痛点,操作方式等等;如实在没有运维开发团队,那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽,绝大多数研发人员往往只考虑产品功能实现,而很少关注可维护性设计,导致业务给运维人员带来很大的无价值工作量,更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的,运维侧需形成可维护性标准规范,推动业务开发遵循将非常利于运维自动化的建设。

文章来源:微信订阅号"运维帮"
地址:http://dwz.cn/6c2Yqz  查看全部


作者介绍​


张延礼,现苏州蜗牛高级运维经理,就职于腾讯多年,熟悉基础架构运维及业务运维,在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现,运维支撑体系规划和执行团队管理等方面具有丰富经验。


正文


本文基于蜗牛从零开始建设运维自动化的一些实践,总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。


一、自动化体系规划


1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块
sank.png

服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等,处在运维工作的最高层;技术决策主要是为实现管理目标去制定总体方案,实施路径;技术执行则是落地的最后一环,这一环工作往往呈现零散、杂乱、重复、频繁变更的特点,承接的需求量最多,但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题:将大量重复低价值含量的人力实施变成自动化执行,最大化地降低人力依赖,提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维,个人认为首要的是要有建设思路与方法论,以下供参考:
gui1.png

gui2.png


3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化起步的阶段,建议是组建运维开发团队,从整体规划,基于ESB思想,分层建设,让支撑平台从业务逻辑中解耦。比如就业务运维而言,整个操作工作面无非就是对业务运营环境的各种操作、配置,以及对业务应用程序的管理,简单来说就是OS层和应用层。
osapp.png

要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西还需要与应用的研发人员规范相关接口,这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维各类业务流程的纯线上自动化。
 


二、自动化实施路线


业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化;如无统一的标准及规范,运维支撑工作将异常混乱,自动化也难以实施。因此自动化有一个基础:标准化,标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控,流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求,基于以上自动化体系建设思路,前期规划的建设线路如下
auto.png

1、信息的标准化管理:CMDB

在运维工作中,信息的管理往往是难点,运维侧涉及的信息太多,且也与其他职能部门多点关联,信息流转于整个流程的多个职能部门、多个环节
cmdb.png

中小型企业中,手工线下记录的方式居多,线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题,经常出现:
  • 线下表格有,实际位置找不到,或信息不对称
  • 不清楚设备状态,不清楚哪个业务在使用
  • 一个部门做了变更,其他部门不知情
  • 变更一条上联链路,无法及时判断影响范围及程度


根本问题及给运维工作带来的痛点如下
td.png

因此我们引入一套基于ITIL体系的配置管理数据库CMDB,旨在为运维团队建立线下与线上一致性的基础信息库,作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化,系统主要功能模块如下图:
cmdbmodle.png

系统本身主要功能可归结为2个方面:基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user,除此之外,对于API-user,此系统提供了一整套接口界面与其它任何需要信息的系统进行对接,这也是设计初衷,将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统,而运维需要做的就是维护CMDB本身基础数据的完整性、准确性,CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更,处处同步。
list.png

如上为CMDB业务管理模型,作为运维统一信息库,与其他系统平台数据互通,深度整合后实现信息的管理、维护、展现全部线上化。

产品设计过程中涉及的几个关键点:
  • CI及属性需要贴合实际环境,同时考虑长期的运维规划
  • 管理的不仅是CI及其属性,还有CI之间的关系,状态流转机制等等
  • 充分考虑扩展性及灵活性,如引入自定义属性来满足未来或暂时不可预见的需求

 
2、通用型作业平台
对于运维执行工作而言,绝大部分的实现均是对运营环境的各类操作,在业务体量上去后,需求导致的运维操作密集度不断增加,如公司内某款游戏业务部署在近上百台主机上,一次维护要对此上百台逐一进行相应的操作,如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是:
problem.png

我们决定做一个通用型运维操作平台来解决这些问题,为运维人员提供一个可以批量控制和操作大规模主机的通道,运维人员在web界面中可以定制所有的运维操作,指定执行的对象,通过平台下发执行并返回结果,例如 批量shell脚本执行,大量文件传输,发布变更,数据备份等等各类场景。对于产品设计上遵循以下几点:
ci.png

技术实现上,基于公司运维环境,我们对后端系统有如下需求:
  • 良好的scale-up/scale-out,灵活扩展,支持复杂网络结构
  • 轻量级、高效的后端通信机制,成千上万的管理规模
  • 跨平台,支持windows、unix-like多平台,无需重复开发


运维门槛低,使用运维熟悉的命令操作及脚本语言即可完成一切作业,无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统;前端系统涉及到的交互逻辑及业务逻辑自主研发,自研部分需实现的逻辑如下:
  • 全网统一的一套基于web的用户界面,将所有操作逻辑通过web层来调用salt-api,web前端提供与直接登录机器操作一样的灵活性和自由度,运维人员在web上完成所有操作。
  • 对运维操作进行建模,将其分解为几大原子操作类型,一切复杂的序列化操作逻辑可通过原子的自由组合来实现,给用户提供自由灵活的操作方式
  • 基于以上逻辑,再给salt加一层应用接口,便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。

archflow.png

后端salt的逻辑这里不赘述,由于实际网络环境的特殊性,我们采用了二层架构,即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通,可以非常灵活的适应各类业务,各种场景。

如运维人员可以在界面定义好一个版本发布作业:xx业务发布,分解整个发布流程中到每一步骤,并写脚本或调用外部接口来实现具体的操作,最终线上操作只需在页面点击开始执行就可:
scripts.png

当然用户自定义作业可以复用,通过传参的方式实现实例化,避免必要每次发布都建作业。
 
3、建设过程中的问题总结
 
做好产品设计及架构设计
充分解析运维内部需求,各具体平台或产品业务区分明确,产品定位一定要清晰,不要想着让微波炉具备电冰箱的功能,自动化整个体系不是一个产品能解决所有问题,需要自顶向下分层设计,产品之间相互解耦且又对外提供接口,能方便的整合与被整合。

组建运维内部开发团队
运维自动化的建设,最好是组建运维内部团队来进行开发,直接丢给业务研发部门往往做出来的东西不是运维侧想要的,因其不易理解运维侧的需求场景、痛点,操作方式等等;如实在没有运维开发团队,那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽,绝大多数研发人员往往只考虑产品功能实现,而很少关注可维护性设计,导致业务给运维人员带来很大的无价值工作量,更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的,运维侧需形成可维护性标准规范,推动业务开发遵循将非常利于运维自动化的建设。


文章来源:微信订阅号"运维帮"
地址:http://dwz.cn/6c2Yqz 


使用Ansible会提示UserWarning: Module import pkg_resources

运维技术采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 570 次浏览 • 2017-05-08 23:39 • 来自相关话题

一个成熟的自动化运维系统应具备哪些功能?

运维技术Nock 发表了文章 • 0 个评论 • 548 次浏览 • 2017-04-15 16:47 • 来自相关话题

结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎 查看全部
结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎

浅谈开源工具自动化运维阶段

运维技术Rock 发表了文章 • 1 个评论 • 3143 次浏览 • 2016-01-02 00:48 • 来自相关话题

前言

随着各种业务对IT的依赖性渐重以及云计算技术的普及,企业平均的IT基础架构规模正不断扩张。
有些Web 2.0企业可能会需要在两个星期内增加上千台服务器,因此对运维而言,通过手动来一个一个搭建的方法不仅麻烦、效率低下,而且非常不利于维护和扩展。即使是在传统的企业当中,日常的备份、服务器状态监控和日志,通过手动的方式来进行的效率也很低,是一种人力的浪费。因此,自动化早已是每个运维都必须掌握的看家本领。在不同的企业中,自动化的规模、需求与实现方式都各不相同,因此在技术细节层面,运维之间很难将别的企业的方法整个套用过来。然而在很多情况下,自动化的思路是有共通之处的。

运维自动化前三阶段

[]纯手工阶段:手工操作重复地进行软件部署和运维;[/][]脚本阶段:通过编写脚本、方便地进行软件部署和运维;[/][]工具阶段:借助第三方工具高效、方便地进行软件部署和运维。[/]
 这几个阶段是随着运维知识、经验、教训不断积累而不断演进的。而且,第2个阶段和第3个阶段可以说是齐头并进,Linux下的第三方工具虽说已经不少了,但是Linux下的脚本编写对运维工作的促进作用是绝对不可以忽视的。
在DevOps出现之前,运维工作者在工作中还是以这两种方式为主。

Linux下好用的开源工具

1、预备类工具:
Kickstartkickstart安装是redhat开创的按照你设计好的方式全自动安装系统的方式。安装方式可以分为光盘、硬盘、和网络。CobblerCobbler是一个快速网络安装linux的服务,而且在经过调整也可以支持网络安装windows。该工具使用python开发,小巧轻便(才15k行代码),使用简单的命令即可完成PXE网络安装环境的配置,同时还可以管理DHCP,DNS,以及yum包镜像。OpenQRMopenQRM提供开放的插件管理架构,你可用很轻松的将现有的数据中心应用程序集成到其中,比如Nagios和VMware。openQRM的自动化数据中心操作不但可用帮助你提高可用性,同时还可以降低您企业级数据中心的管理费用。针对数据中心管理的开源平台,针对设备的部署、监控等多个方面通过可插拔式架构实现自动化的目的,尤其面向云计算/基于虚拟化的业务。SpacewalkSpacewalk可管理Fedora、红帽、CentOS、SUSE与Debian Linux服务器。当你的数据中心拥有多台Linux服务器时,手动管理将不再是一个好的选择。Spacewalk就可以管理补丁、登录、更新。 [b]在自动化运维和大数据云计算时代实现预设自动化安装服务器环境、应用环境等不仅可以提高运维效率,而且还能大大减少运维的工作任务及出错概率。尤其是对于在服务器数量按几百台、几千台增加的公司而言,单单是装系统,如果不通过自动化来完成,其工作量和周期不可想象。[/b]2、配置管理类工具:
前浪:
ChefChef是一个系统集成框架,可以用Ruby等代码完成服务器的管理配置并编写自己的库。ControlTierControlTier是一个完全开放源码系统的自动化服务管理活动的多个服务器和多个应用层(代码,数据,配置和内容) 。共同使用的ControlTier包括部署应用程序,控制它们的状态,并运行按需行政工作在多个服务器上。ControlTier是跨平台和工程同样的物理服务器,虚拟机,或云计算基础设施。FuncFunc是由红帽子公司以Fedora统一网络控制器Func,目的是为了解决这一系列统一管理监控问题而设计开发的系统管理基础框架,它是一个能有效的简化我们众多服务器系统管理工作的工具,其具备容易学习,容易使用,更容易扩展;功能强大而且配置简单等优点。Puppetpuppet是一个开源的软件自动化配置和部署工具,它使用简单且功能强大,正得到了越来越多地关注,现在很多大型IT公司均在使用puppet对集群中的软件进行管理和部署。后浪
SaltStackSalt一种全新的基础设施管理方式,部署轻松,在几分钟内可运行起来,扩展性好,很容易管理上万台服务器,速度够快,服务器之间秒级通讯。AnsibleAnsible是新出现的运维工具是基于Python研发的糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。[b]在进行大规模部署时,手工配置服务器环境是不现实的,这时必须借助于自动化部署工具。[/b]
3、监控类工具
NagiosNagios是一款免费的开源IT基础设施监控系统,其功能强大,灵活性强,能有效监控 Windows 、Linux、VMware 和 Unix 主机状态,交换机、路由器等网络设置等。一旦主机或服务状态出现异常时,会发出邮件或短信报警第一时间通知 IT 运营人员,在状态恢复后发出正常的邮件或短信通知。OpenNMSOpenNMS是一个网络管理应用平台,可以自动识别网络服务,事件管理与警报,性能测量等任务。CactiCacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据,使用 RRDtool绘画图形,它的界面非常漂亮,能让你根本无需明白rrdtool的参数能轻易的绘出漂亮的图形。而且你完全可以不需要了解RRDtool复杂的参数。它提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结 构、host以及任何一张图,还可以与LDAP结合进行用户验证,同时也能自己增加模板,让你添加自己的snmp_query和script!功能非常强大完善,界面友好。
Zenoss Core一个基于Zope应用服务器的应用/服务器/网络管理平台,提供了Web管理界面,可监控可用性、配置、性能和各种事件。
Zabbixzabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。用于监控网络上的服务器/服务以及其他网络设备状态的网络管理系统,后台基于C,前台由PHP编写,可与多种数据库搭配使用。提供各种实时报警机制。
GangliaGanglia是一个针对高性能分布式系统(例如,集群、网格、云计算等)所设计的可扩展监控系统。该系统基于一个分层的体系结构,并能够支持2000个节点的集群。它允许用户能够远程监控系统的实时或历史统计数据,包括:CPU负载均衡、网络利用率等。Ganglia依赖于一个基于组播的监听/发布协议来监控集群的状态。Ganglia系统的实现综合了多种技术,包括:XML(数据描述)、XDR(紧凑便携式数据传输)、RRDtool(数据存储和可视化)等。[b]数据监控和业务监控非常关键,及时发现问题,及时解决问题,监控系统主要包括:服务应用监控、主机监控、网络设备监控、网络连通性监控、网络访问质量监控、分布式系统监控、报警预设、监控图形化与历史数据等。[/b]





自动化对运维的意义

自动化就是运维为了减少重复枯燥的工作而建立的流程方法,而除此之外,自动化还能够带来减少人为错误、及时报警与故障恢复、提高业务可用性等好处。运维工作自动化确实包含上述2个方面,归纳总结来其实就是:把零碎的工作集中化,把复杂的工作简单有序化,把流程规范化,最大化地解放生产力,也就是解放运维人员。自动化的技能/意识对于运维工作至关重要。运维工作不是简单的使用工具,这里面还有很多技巧和意识。具体的技巧/意识包括:
[]如何驾驭这些琳琅满目的工具为己所用;[/][]如何根据不同的应用环境来选用不同的工具;[/][]如何根据应用来组合使用工具等等等等。[/]
一定要记住一点:工具只是利用帮助人进行运维的,这中间还需要人的干预和决策,工具不能完全代替全部运维工作。还需要结合实际业务逻辑和业务场景,就像架构一样,并不是淘宝、百度等大公司的架构,一定适合任何公司和业务。

自动化运维范畴

[]安装自动化[/][]部署自动化[/][]监控自动化[/][]发布自动化[/][]升级自动化[/][]安全管控自动化[/][]优化自动化[/][]数据备份自动化[/]
前阶段在自动化管理和安全方面的技术实现,比如说HP和IBM出品的一些ITIL和ITSM产品等,比如HP Openview,IBM Tivoli等等。这些工具都有Linux的版本,与其他同类工具相比的优势应该在于他们的商业应用成熟度,都是老品牌。
现阶段有自动化的一些工具git、svn、Jenkins等等,一些开源的软件!

工具选择

针对不同规模的架构,一个小规模的网站,到百万量级、千万量级的网站,我们选择的工具就有不同。在选择上对于百万量级、千万量级的网站,我们应该考虑选择成熟的工具、性能高的工具、熟悉的工具。而对于小规模的网站,我们应该考虑选择一些开源的、免费的工具。这个原则就是以应用为导向,百万量级、千万量级的网站牵涉的面广、要求高,不成熟的工具往往很难说服领导和公司使用,所以主要是在成熟度方面。

自动化运维规划

自动化的实现不是单纯学习几个工具就能够做好的,甚至于规划不好的情况,自动化不仅没有节省人力,反而带来了更多的问题。
所以运维人员在考虑自动化流程的过程中应该考虑如下几点原则:
[]根据应用选择工具;[/][]对于关键应用,选择成熟度高的工具;[/][]不能过分依赖一种工具,需要进行对比和分析;[/][]对工具的特性做到精通;[/][]是人驾驭工具,人要监督工具,而不是工具来驾驭人;[/][]善于利用脚本实现定制化场景。[/]

自动化经验积累

[]经常逛逛一些不错的IT媒体网站和看看这方面的文章,可以多多涉猎和学习;[/][]针对公司业务场景,选择一些自动化工具,登陆到官网学习和熟悉工作原理;[/][]经常参加一些线下自动化运维的活动和媒体活动,多和一些自动化方面的大拿和资深人士交流。[/] 查看全部


前言


随着各种业务对IT的依赖性渐重以及云计算技术的普及,企业平均的IT基础架构规模正不断扩张。
有些Web 2.0企业可能会需要在两个星期内增加上千台服务器,因此对运维而言,通过手动来一个一个搭建的方法不仅麻烦、效率低下,而且非常不利于维护和扩展。
即使是在传统的企业当中,日常的备份、服务器状态监控和日志,通过手动的方式来进行的效率也很低,是一种人力的浪费。因此,自动化早已是每个运维都必须掌握的看家本领。
在不同的企业中,自动化的规模、需求与实现方式都各不相同,因此在技术细节层面,运维之间很难将别的企业的方法整个套用过来。然而在很多情况下,自动化的思路是有共通之处的。


运维自动化前三阶段


    []纯手工阶段:手工操作重复地进行软件部署和运维;[/][]脚本阶段:通过编写脚本、方便地进行软件部署和运维;[/][]工具阶段:借助第三方工具高效、方便地进行软件部署和运维。[/]

 
这几个阶段是随着运维知识、经验、教训不断积累而不断演进的。而且,第2个阶段和第3个阶段可以说是齐头并进,Linux下的第三方工具虽说已经不少了,但是Linux下的脚本编写对运维工作的促进作用是绝对不可以忽视的。
在DevOps出现之前,运维工作者在工作中还是以这两种方式为主。


Linux下好用的开源工具


1、预备类工具:
Kickstart
kickstart安装是redhat开创的按照你设计好的方式全自动安装系统的方式。安装方式可以分为光盘、硬盘、和网络。
Cobbler
Cobbler是一个快速网络安装linux的服务,而且在经过调整也可以支持网络安装windows。该工具使用python开发,小巧轻便(才15k行代码),使用简单的命令即可完成PXE网络安装环境的配置,同时还可以管理DHCP,DNS,以及yum包镜像。
OpenQRM
openQRM提供开放的插件管理架构,你可用很轻松的将现有的数据中心应用程序集成到其中,比如Nagios和VMware。openQRM的自动化数据中心操作不但可用帮助你提高可用性,同时还可以降低您企业级数据中心的管理费用。针对数据中心管理的开源平台,针对设备的部署、监控等多个方面通过可插拔式架构实现自动化的目的,尤其面向云计算/基于虚拟化的业务。
Spacewalk
Spacewalk可管理Fedora、红帽、CentOS、SUSE与Debian Linux服务器。当你的数据中心拥有多台Linux服务器时,手动管理将不再是一个好的选择。Spacewalk就可以管理补丁、登录、更新。
 
[b]在自动化运维和大数据云计算时代实现预设自动化安装服务器环境、应用环境等不仅可以提高运维效率,而且还能大大减少运维的工作任务及出错概率。尤其是对于在服务器数量按几百台、几千台增加的公司而言,单单是装系统,如果不通过自动化来完成,其工作量和周期不可想象。[/b]
2、配置管理类工具:
前浪:
Chef
Chef是一个系统集成框架,可以用Ruby等代码完成服务器的管理配置并编写自己的库。
ControlTier
ControlTier是一个完全开放源码系统的自动化服务管理活动的多个服务器和多个应用层(代码,数据,配置和内容) 。共同使用的ControlTier包括部署应用程序,控制它们的状态,并运行按需行政工作在多个服务器上。ControlTier是跨平台和工程同样的物理服务器,虚拟机,或云计算基础设施。
Func
Func是由红帽子公司以Fedora统一网络控制器Func,目的是为了解决这一系列统一管理监控问题而设计开发的系统管理基础框架,它是一个能有效的简化我们众多服务器系统管理工作的工具,其具备容易学习,容易使用,更容易扩展;功能强大而且配置简单等优点。
Puppet
puppet是一个开源的软件自动化配置和部署工具,它使用简单且功能强大,正得到了越来越多地关注,现在很多大型IT公司均在使用puppet对集群中的软件进行管理和部署。
后浪
SaltStack
Salt一种全新的基础设施管理方式,部署轻松,在几分钟内可运行起来,扩展性好,很容易管理上万台服务器,速度够快,服务器之间秒级通讯。
Ansible
Ansible是新出现的运维工具是基于Python研发的糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。
[b]在进行大规模部署时,手工配置服务器环境是不现实的,这时必须借助于自动化部署工具。[/b]

3、监控类工具
Nagios
Nagios是一款免费的开源IT基础设施监控系统,其功能强大,灵活性强,能有效监控 Windows 、Linux、VMware 和 Unix 主机状态,交换机、路由器等网络设置等。一旦主机或服务状态出现异常时,会发出邮件或短信报警第一时间通知 IT 运营人员,在状态恢复后发出正常的邮件或短信通知。
OpenNMS
OpenNMS是一个网络管理应用平台,可以自动识别网络服务,事件管理与警报,性能测量等任务。
Cacti
Cacti是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。它通过snmpget来获取数据,使用 RRDtool绘画图形,它的界面非常漂亮,能让你根本无需明白rrdtool的参数能轻易的绘出漂亮的图形。而且你完全可以不需要了解RRDtool复杂的参数。它提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结 构、host以及任何一张图,还可以与LDAP结合进行用户验证,同时也能自己增加模板,让你添加自己的snmp_query和script!功能非常强大完善,界面友好。

Zenoss Core
一个基于Zope应用服务器的应用/服务器/网络管理平台,提供了Web管理界面,可监控可用性、配置、性能和各种事件。

Zabbix
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。用于监控网络上的服务器/服务以及其他网络设备状态的网络管理系统,后台基于C,前台由PHP编写,可与多种数据库搭配使用。提供各种实时报警机制。

Ganglia
Ganglia是一个针对高性能分布式系统(例如,集群、网格、云计算等)所设计的可扩展监控系统。该系统基于一个分层的体系结构,并能够支持2000个节点的集群。它允许用户能够远程监控系统的实时或历史统计数据,包括:CPU负载均衡、网络利用率等。Ganglia依赖于一个基于组播的监听/发布协议来监控集群的状态。Ganglia系统的实现综合了多种技术,包括:XML(数据描述)、XDR(紧凑便携式数据传输)、RRDtool(数据存储和可视化)等。
[b]数据监控和业务监控非常关键,及时发现问题,及时解决问题,监控系统主要包括:服务应用监控、主机监控、网络设备监控、网络连通性监控、网络访问质量监控、分布式系统监控、报警预设、监控图形化与历史数据等。[/b]

gongju.png


自动化对运维的意义


自动化就是运维为了减少重复枯燥的工作而建立的流程方法,而除此之外,自动化还能够带来减少人为错误、及时报警与故障恢复、提高业务可用性等好处。
运维工作自动化确实包含上述2个方面,归纳总结来其实就是:把零碎的工作集中化,把复杂的工作简单有序化,把流程规范化,最大化地解放生产力,也就是解放运维人员。
自动化的技能/意识对于运维工作至关重要。运维工作不是简单的使用工具,这里面还有很多技巧和意识。具体的技巧/意识包括:
    []如何驾驭这些琳琅满目的工具为己所用;[/][]如何根据不同的应用环境来选用不同的工具;[/][]如何根据应用来组合使用工具等等等等。[/]

一定要记住一点:工具只是利用帮助人进行运维的,这中间还需要人的干预和决策,工具不能完全代替全部运维工作。还需要结合实际业务逻辑和业务场景,就像架构一样,并不是淘宝、百度等大公司的架构,一定适合任何公司和业务。


自动化运维范畴


    []安装自动化[/][]部署自动化[/][]监控自动化[/][]发布自动化[/][]升级自动化[/][]安全管控自动化[/][]优化自动化[/][]数据备份自动化[/]

前阶段在自动化管理和安全方面的技术实现,比如说HP和IBM出品的一些ITIL和ITSM产品等,比如HP Openview,IBM Tivoli等等。这些工具都有Linux的版本,与其他同类工具相比的优势应该在于他们的商业应用成熟度,都是老品牌。
现阶段有自动化的一些工具git、svn、Jenkins等等,一些开源的软件!


工具选择


针对不同规模的架构,一个小规模的网站,到百万量级、千万量级的网站,我们选择的工具就有不同。
在选择上对于百万量级、千万量级的网站,我们应该考虑选择成熟的工具、性能高的工具、熟悉的工具。而对于小规模的网站,我们应该考虑选择一些开源的、免费的工具。
这个原则就是以应用为导向,百万量级、千万量级的网站牵涉的面广、要求高,不成熟的工具往往很难说服领导和公司使用,所以主要是在成熟度方面。


自动化运维规划


自动化的实现不是单纯学习几个工具就能够做好的,甚至于规划不好的情况,自动化不仅没有节省人力,反而带来了更多的问题。

所以运维人员在考虑自动化流程的过程中应该考虑如下几点原则:
    []根据应用选择工具;[/][]对于关键应用,选择成熟度高的工具;[/][]不能过分依赖一种工具,需要进行对比和分析;[/][]对工具的特性做到精通;[/][]是人驾驭工具,人要监督工具,而不是工具来驾驭人;[/][]善于利用脚本实现定制化场景。[/]


自动化经验积累


    []经常逛逛一些不错的IT媒体网站和看看这方面的文章,可以多多涉猎和学习;[/][]针对公司业务场景,选择一些自动化工具,登陆到官网学习和熟悉工作原理;[/][]经常参加一些线下自动化运维的活动和媒体活动,多和一些自动化方面的大拿和资深人士交流。[/]

10个强大的DevOps基础设施自动化工具

运维技术采菊篱下 发表了文章 • 0 个评论 • 3038 次浏览 • 2015-12-07 01:45 • 来自相关话题

Devops基础设施自动化的工具

有许多工具用于基础设施自动化。决定使用哪个工具的体系结构和基础设施的需求。下面我们列出了一些伟大的工具,受到不同类别配置管理、编制、持续集成、监控、等。

1、Chef




Chef是一个基于ruby开发的配置管理工具。你可能会遇到“基础设施代码”这个词,这意味着配置管理。厨师烹饪书的概念,你的代码基础设施DSL(领域特定语言)和一个小的编程。chef规定和配置虚拟机根据规则中提到的食谱。代理将会运行在所有的服务器配置。代理将chef主服务器的cookbooks,在服务器上运行这些配置来达到理想的状态。

2、Puppet




Puppet也基于ruby编写的配置管理工具跟chef一样。配置代码编写使用puppet DSL和封装在模块。而chef更以开发人员为中心,puppet是由系统管理员控制为中心。puppet proxy运行在所有服务器配置,它把编译模块从puppet服务器和安装所需要的软件包中指定模块。

3、Saltstack




Saltstack是一个基于python打开配置管理工具。不像chef和puppet,Saltstack支持远程执行的命令。通常在chef和puppet,配置的代码将从服务器,在Saltstack,代码可以同时被推到许多节点。编译的代码和配置是Saltstack非常快。

4、Ansible




Ansible是一个缺少代理配置管理以及编制工具。在Ansible配置模块中被称为“剧本”。剧本都写在YAML格式和它相对容易写相比其他配置管理工具。像其他工具,Ansible可用于云配置。

5、Juju




Juju是由典型的基于Python的编排工具。它已经在你的云环境应用程序的伟大的UI。你也可以使用命令行界面来完成所有的业务流程的任务。你可以配置,部署和使用且具规模的应用。

6、 Jenkins




Jenkins是一个基于java的持续集成工具更快的应用程序。Jenkins必须关联到一个版本控制系统如github或SVN。每当新代码被推到代码库,詹金斯服务器将构建和测试新代码和通知团队的结果和变化。

7、 Vagrant




vagrant是一个伟大的工具为开发环境配置虚拟机。vagrant的上面运行的VM虚拟框和流浪的解决方案。它使用一个配置文件叫做Vagrantfile,其中包含所需的所有配置VM。一旦创建了一个虚拟机,它可以与其他开发人员共享相同的开发环境。vagrant有云配置插件,配置管理工具(chef、puppet等)和docker。

8、Docker




Docker是一个自动化工具之上的Linux容器(LXC)。它工作在流程级别虚拟化的概念。Docker创造了孤立的环境称为应用程序容器。这些容器可以运往其他服务器无需更改应用程序。Docker被认为是虚拟化的下一步。码头工人有一个巨大的开发者社区,它是获得巨大的声望在Devops从业者和云计算的先驱。

9、New Relic




New relic的基于云的解决方案(SaaS)应用程序监视。它支持各种应用程序的监控像Php、Ruby、Java、NodeJS等等。它给你实时的见解关于您的运行应用程序中。new relic的代理应该配置在应用程序中获得实时数据。New relic使用各种指标提供有价值的见解关于应用程序监控。

10、Sensu




Sensu是一个开放源码监视框架用Ruby编写的。Sensu是一个监控工具专门建立云环境。它可以很容易地部署使用工具如chef和puppet。Sensu也有一个企业版的监控。英文原文链接:http://devopscube.com/devops-tools-for-infrastructure-automation/  查看全部
devops_tools.png


Devops基础设施自动化的工具


有许多工具用于基础设施自动化。决定使用哪个工具的体系结构和基础设施的需求。下面我们列出了一些伟大的工具,受到不同类别配置管理、编制、持续集成、监控、等。


1、Chef


chef.png
Chef是一个基于ruby开发的配置管理工具。你可能会遇到“基础设施代码”这个词,这意味着配置管理。厨师烹饪书的概念,你的代码基础设施DSL(领域特定语言)和一个小的编程。chef规定和配置虚拟机根据规则中提到的食谱。代理将会运行在所有的服务器配置。代理将chef主服务器的cookbooks,在服务器上运行这些配置来达到理想的状态。


2、Puppet


puppet.png
Puppet也基于ruby编写的配置管理工具跟chef一样。配置代码编写使用puppet DSL和封装在模块。而chef更以开发人员为中心,puppet是由系统管理员控制为中心。puppet proxy运行在所有服务器配置,它把编译模块从puppet服务器和安装所需要的软件包中指定模块。


3、Saltstack


saltstack.png
Saltstack是一个基于python打开配置管理工具。不像chef和puppet,Saltstack支持远程执行的命令。通常在chef和puppet,配置的代码将从服务器,在Saltstack,代码可以同时被推到许多节点。编译的代码和配置是Saltstack非常快。


4、Ansible


ansible.png
Ansible是一个缺少代理配置管理以及编制工具。在Ansible配置模块中被称为“剧本”。剧本都写在YAML格式和它相对容易写相比其他配置管理工具。像其他工具,Ansible可用于云配置。


5、Juju


juju.png
Juju是由典型的基于Python的编排工具。它已经在你的云环境应用程序的伟大的UI。你也可以使用命令行界面来完成所有的业务流程的任务。你可以配置,部署和使用且具规模的应用。


6、 Jenkins


jenkines.png
Jenkins是一个基于java的持续集成工具更快的应用程序。Jenkins必须关联到一个版本控制系统如github或SVN。每当新代码被推到代码库,詹金斯服务器将构建和测试新代码和通知团队的结果和变化。


7、 Vagrant


vagrant.png
vagrant是一个伟大的工具为开发环境配置虚拟机。vagrant的上面运行的VM虚拟框和流浪的解决方案。它使用一个配置文件叫做Vagrantfile,其中包含所需的所有配置VM。一旦创建了一个虚拟机,它可以与其他开发人员共享相同的开发环境。vagrant有云配置插件,配置管理工具(chef、puppet等)和docker。


8、Docker


docker.png
Docker是一个自动化工具之上的Linux容器(LXC)。它工作在流程级别虚拟化的概念。Docker创造了孤立的环境称为应用程序容器。这些容器可以运往其他服务器无需更改应用程序。Docker被认为是虚拟化的下一步。码头工人有一个巨大的开发者社区,它是获得巨大的声望在Devops从业者和云计算的先驱。


9、New Relic


NewRelic.png
New relic的基于云的解决方案(SaaS)应用程序监视。它支持各种应用程序的监控像Php、Ruby、Java、NodeJS等等。它给你实时的见解关于您的运行应用程序中。new relic的代理应该配置在应用程序中获得实时数据。New relic使用各种指标提供有价值的见解关于应用程序监控。


10、Sensu


sensu.png
Sensu是一个开放源码监视框架用Ruby编写的。Sensu是一个监控工具专门建立云环境。它可以很容易地部署使用工具如chef和puppet。Sensu也有一个企业版的监控。
英文原文链接:http://devopscube.com/devops-tools-for-infrastructure-automation/ 

2017 GOPS全球运维大会深圳北京PPT分享

回复

运维技术OS小编 发起了问题 • 1 人关注 • 0 个回复 • 520 次浏览 • 2017-07-30 14:54 • 来自相关话题

fir.im持续集成技术实践

运维技术OS小编 发表了文章 • 0 个评论 • 225 次浏览 • 2017-11-15 21:20 • 来自相关话题

互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
场景一:开发了新功能,老功能产生新的 bug;场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;

持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?




从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:




在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。

当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。

拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。




自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。




接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:




Trello 看板;三个环境(类生产环境,测试环境,生产环境);CI 工具(Jenkins/flow.ci)

说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。




多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。




还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?

我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。

整个团队的构建频率可以看下这张图:




本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。




kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
最初阶段:提交代码-自动部署;一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;




这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
测试异常——不仅仅测试正确情况,也要主动测试异常;减少耦合——保证独立的可测试性;功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;

Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。




其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析




说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。





结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!

分享阅读:http://blog.fir.im/firim_ci_practice/  查看全部
互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
  • 场景一:开发了新功能,老功能产生新的 bug;
  • 场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;
  • 场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;


持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:


“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler


如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?
cic.jpg

从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:
ciflow.jpg

在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。


当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。


拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。
cisystem.jpg

自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。
cisystem2.jpg

接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:
Agilefirim.png

  • Trello 看板;
  • 三个环境(类生产环境,测试环境,生产环境);
  • CI 工具(Jenkins/flow.ci)


说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。
gitbranchm.jpg

多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。
fzce.jpg

还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?


我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。


整个团队的构建频率可以看下这张图:
Build-frequency.jpg

本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。
kanban.png

kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
  • 最初阶段:提交代码-自动部署;
  • 一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;
  • 高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;

flow.jpg

这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
  • 测试异常——不仅仅测试正确情况,也要主动测试异常;
  • 减少耦合——保证独立的可测试性;
  • 功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;
  • 测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;


Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。
value.jpg

其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析
view.jpg

说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。
dataview.jpg


结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!


分享阅读:http://blog.fir.im/firim_ci_practice/ 


理解持续集成、持续交付、持续部署

运维技术OS小编 发表了文章 • 0 个评论 • 218 次浏览 • 2017-11-15 00:14 • 来自相关话题

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成




持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付




持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署




持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/  查看全部
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成
xci.jpg

持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付
xcd.jpg

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署
xcr.jpg

持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/ 

谈谈持续集成、持续交付、持续部署之间的区别

运维技术OS小编 发表了文章 • 0 个评论 • 188 次浏览 • 2017-11-14 22:50 • 来自相关话题

经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?




假如把开发工作流程分为以下几个阶段:

编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署

正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。




CI 需要具备这些:
全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;版本控制工具: 如 Git,CVS,SVN 等;自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。
持续集成的优点:
“快速失败”,在对产品没有风险的情况下进行测试,并快速响应;最大限度地减少风险,降低修复错误代码的成本;将重复性的手工流程自动化,让工程师更加专注于代码;保持频繁部署,快速生成可部署的软件;提高项目的能见度,方便团队成员了解项目的进度和成熟度;增强开发人员对软件产品的信心,帮助建立更好的工程师文化。
 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。





试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
快速发布。能够应对业务需求,并更快地实现软件价值。编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;高质量的软件发布标准。整个交付过程标准化、可重复、可靠,整个交付过程进度可视化,方便团队人员了解项目成熟度;更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。
 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。





为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”


实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。

“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。

 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 

分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书 查看全部
经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?
devops-workfollow.png

假如把开发工作流程分为以下几个阶段:


编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署


正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。
CI.png

CI 需要具备这些:
  • 全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;
  • 灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;
  • 版本控制工具: 如 Git,CVS,SVN 等;
  • 自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;
  • 反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。

持续集成的优点:
  • “快速失败”,在对产品没有风险的情况下进行测试,并快速响应;
  • 最大限度地减少风险,降低修复错误代码的成本;
  • 将重复性的手工流程自动化,让工程师更加专注于代码;
  • 保持频繁部署,快速生成可部署的软件;
  • 提高项目的能见度,方便团队成员了解项目的进度和成熟度;
  • 增强开发人员对软件产品的信心,帮助建立更好的工程师文化。

 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。
CD.png


试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
  • 快速发布。能够应对业务需求,并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
CR.png


为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”



实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。


“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。


 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 


分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书


DevOps详解

运维技术OS小编 发表了文章 • 0 个评论 • 254 次浏览 • 2017-07-18 00:04 • 来自相关话题

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。
 
但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。
 
最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。
 本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158​  

目录






1. 简介​

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。




开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。
IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:




主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:




此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:




来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
执行实际的部署工作,或修复与部署工作有关的问题
这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
通过自动化部署将目前这种手工任务所需的时间减少31%。通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。
 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。




这些统计告诉我们:
只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。如需手工运行55条命令,成功部署的概率将跌至22%。如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!
成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:




(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。Flickr每天部署10次。Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。
他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 




喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?




下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 




上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
编码:代码开发和审阅,版本控制工具、代码合并工具构建:持续集成工具、构建状态统计工具测试:通过测试和结果确定绩效的工具打包:成品仓库、应用程序部署前暂存发布:变更管理、发布审批、发布自动化配置:基础架构配置和部署,基础架构即代码工具监视:应用程序性能监视、最终用户体验
虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。
最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……恢复时间:一键点击即可恢复生产环境,就是这么简单。确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。
这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。




但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
从实践中学习自动化更频繁的部署
 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:




 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。




那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
对软件组件的开发和平台的供应和设置进行持续集成。TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。软件的持续审计 - 例如使用Sonar。在生产级环境实现功能测试的自动化。更强大的非功能测试自动化(性能、可用性等)。独立于目标环境的自动化打包和部署。
另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
功能开关(Feature Flipping)摸黑启动(Dark launch)蓝/绿部署(Blue/Green Deployment)金丝雀发布(Canari release)
 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end 摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一 查看全部
最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。
 
但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。
 
最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。
 本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158​  


目录


mulu.png


1. 简介​


DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。
woc.png

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。
 
1.1 管理信条
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。
IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。
 
1.2 一个典型的IT组织
在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:
devopsharch.png

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:
wofpeople.png

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)
 
1.3 运维人员测挫败感
接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:
sfd.png

来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services 
 
生产团队有将近一半(47%)的时间花在了与部署有关的工作中:
  • 执行实际的部署工作,或修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:
  1. 通过自动化部署将目前这种手工任务所需的时间减少31%。
  2. 通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

 
1.4 基础架构自动化
在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。
gl.png

这些统计告诉我们:
  • 只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
  • 如需手工运行55条命令,成功部署的概率将跌至22%。
  • 如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:
howmuch.png

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:
  • Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
  • Flickr每天部署10次。
  • Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?
 
 
1.5 DevOps:仅此一次,一颗神奇的银子弹
他们的秘密很简单:将敏捷扩展至生产端:
 
devops.png

喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。
那么核心原则到底是什么?
icc.png

下文将介绍最重要的三大基本原则。
 
2. 基础架构即代码
人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。
 
2.1 概述
以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:
 
asc.png

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。
 
2.2 DevOps工具链
DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:
  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。
 
基础架构组件的版本控制、持续集成和自动化测试
 
基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成
 
 
2.3 收益
DevOps的收益有很多,包括但不限于:
  • 可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。
  • 生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
  • 恢复时间:一键点击即可恢复生产环境,就是这么简单。
  • 确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
  • 维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
  • 让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。
 
 
3. 持续交付
 
持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:
  • 部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
  • 部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
  • 部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

ttr.png

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:
  • 从实践中学习
  • 自动化
  • 更频繁的部署

 
3.1 从实践中学习
 
持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:
idmcc.png

 
 
喜欢 | 作者 Jerome Kehrli ,译者 大愚若智 发布于 2017年4月24日. 估计阅读时间: 1 分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!1 讨论分享到:微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单

最近我阅读了很多有关DevOps的文章,其中一些非常有趣,然而一些内容也很欠考虑。貌似很多人越来越坚定地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不同看法。DevOps的范畴远远超过puppet或Docker等工具。

这样的看法甚至让我感觉有些气愤。DevOps在我看来极为重要,过去15年来,我一直在大型机构,主要是大型金融机构中从事工程业务。DevOps是一种非常重要的方法论,该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体,很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素:开发者和运维人员之间的混乱之墙。

请不要误会我的这种观点,除了某些XP实践,大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走,同时还有很多其他原因会导致软件开发项目的失败或延误。

相关厂商内容

聊聊容器编排与管理的挑战
智能化运维技术详解

机器学习模型训练的Kubernetes实践
京东物流系统自动化运维平台技术揭密
基于资产配置业务场景下的全链路监控平台

相关赞助商

CNUTCon全球运维技术大会,9月10日-9月11日,上海·光大会展中心大酒店,精彩内容抢先看

但在我看来,混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时间、同时也相当愚蠢的问题。

与其独自生闷气,我觉得不如说点更实在的东西,写一篇尽可能精准的文章,向大家介绍DevOps到底是什么,能为我们带来什么。长话短说,DevOps并不是某一套工具。DevOps是一种方法论,其中包含一系列基本原则和实践,仅此而已。而所用的工具(或者说“工具链”吧,毕竟用于为这些实践提供支持的工具集有着极高的扩展性)只是为了对这样的实践提供支持。

最终来说,这些工具本身并不重要。相比两年前,目前的DevOps工具链已经产生了翻天覆地的变化,可想而知,两年后还会产生更大的差异。不过这并不重要。重要的是能够合理地理解这些基本原则和实践。

本文并不准备介绍某些工具链,甚至完全不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践,它们的主要目的,毕竟这些才是对我而言最重要的。

DevOps是一种方法论,归纳总结了面临独一无二的机遇和强有力需求的网络巨头们,结合自身业务本质构思出全新工作方式的过程中所采用的实践,而他们的业务需求也很直接:以史无前例的节奏对自己的系统进行演进,有时候可能还需要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来说很明显是不可或缺的,但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的。本文将试图解释得出这个结论的原因和实现方法。

本文的部分内容已发布为Slideshare演示幻灯片,可在这里浏览:http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

目录1. 简介 1.1 管理信条 1.2 一个典型的IT组织 1.3 运维人员测挫败感 1.4 基础架构自动化 1.5 DevOps:仅此一次,一颗神奇的银子弹 2. 基础架构即代码 2.1 概述 2.2 DevOps工具链 2.3 收益 3. 持续交付 3.1 从实践中学习 3.2 自动化 3.3 更频繁的部署 3.4 持续交付的前提需求 3.5 零停机部署 4. 协作 4.1 混乱之墙 4.2 软件开发流程 4.3 共享工具 4.4 协同工作 5. 结论1. 简介

DevOps所关注的不是工具本身,也不是对chef或Docker的掌握程度。DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标(Goal)的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于:虽然都是企业中大型IT部门不可或缺的,但他们有着截然不同的目的(Objective)。

开发者和运维人员之间目的上的差异就叫做混乱之墙。下文会介绍这个概念的准确定义,以及为什么我认为这种状况很严峻并且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论(并从这些实践中派生出了各种工具),意在帮助这些人员向着一个统一的共同目的努力:尽可能为公司提供更多价值。

令人惊奇的是,这个问题竟然有一个非常简单的“银子弹”:让生产端变得敏捷起来!

而这恰恰正是DevOps所要达成的唯一目标!

但在进一步讨论这一点之前,首先需要谈谈其他几件事。

1.1 管理信条

IT管理这场战争的原动力到底是什么?换句话说,在软件开发项目中,管理工作首要的,以及最重要的目的是什么?

有什么想法吗?

我来提供一个线索吧:在建立一家初创公司时,最重要的事情是什么?

当然是要加快上市时间(TTM)!

上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。

在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。

TTM通常也会被叫做前置时间(Lead Time)。

第一个问题在于,(很多人认为)在开发过程中TTM和产品质量是两个对立的属性。在下文可以看到,改善质量(进而提高稳定性)是运维人员的目的,而开发者的目的在于降低前置时间(进而提高TTM)。

请容我来解释一下。

IT组织或部门通常会通过两个关键的KPI进行评估:软件本身的质量,因而需要尽可能减少缺陷的数量;此外还有TTM,因而需要将业务构想(通常由业务用户提供)变为最终成果,并以尽可能快的速度提供给用户或客户。

这里的问题在于,大部分情况下这两个截然不同的目的是由两个不同团队提供支持的:负责构建软件的开发者,以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织通常看起来是这样的:

主要由于历史的原因(大部分运维人员来自硬件和电信业务领域),运维人员和开发者分属不同的组织结构分支。开发者属于研发部门,而运维人员大部分时候属于基础架构部门(或专门的运维部门)。

别忘了,他们有着不同的目的:

此外作为旁注,这两个团队有时候会使用不同的预算来运营。开发团队使用构建(Build)预算,运维团队使用运营(Run)预算。不同的预算,对控制权越来越高的需求,以及企业IT成本的缩水,这些因素结合在一起会进一步放大两个团队各自目的的对立性。

(依本人愚见,时至今日,随着人与人之间无时无刻随时随地进行的交互,以及由不同目的推动着企业和社会进行数字化转型,IT预算方面古老的“规划/构建/运行”框架已经不那么合理了,不过这又是另一回事了。)

1.3 运维人员测挫败感

接下来看看运维人员,一起看看典型的运维团队把大部分时间都花在哪里了:

(来源:Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半(47%)的时间花在了与部署有关的工作中:

执行实际的部署工作,或
修复与部署工作有关的问题

这样的KPI其实相当疯狂,但实际上我们早就应该采纳。实际上早在40年前,计算机科学的“原始时代”就已涌现出运维团队,当时计算机主要运用在工业界,运维人员需要手工运行大量命令来执行自己的任务。为了履行职责,他们已经习惯于按照清单运行各种各样的命令或手工流程。

突然有一天他们终于意识到自己“总在做着相同的事情”,然而长达四十多年的工作过程中却几乎没人考虑过变革。

考虑到这一点你会发现,实在是太疯狂了。平均来说,运维人员将近一半的时间都在处理与部署有关的任务!

为了改变这种状况,必须考虑到两个最关键的需求:

通过自动化部署将目前这种手工任务所需的时间减少31%。
通过产业化措施(类似于通过XP和敏捷实现的软件开发产业化)将需要处理的与这些部署有关的问题减少16%。

1.4 基础架构自动化

在这方面也有一个相当富有启发性的统计结果:

以手工操作的数量所表示的成功部署概率。

这些统计告诉我们:

只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
如需手工运行55条命令,成功部署的概率将跌至22%。
如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

成功部署意味着软件能够按照预期在生产环境中运行。未能成功部署意味着有东西出错,可能需要进行必要的分析才能了解部署过程中哪里出错,是否需要应用某种补丁,或需要修改某些配置。

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意,对吧?

那么行业里这方面的现状是怎样的:

(来源:IT Ops & DevOps Productivity Report 2013 - Rebellabs )

(说实话,这个统计信息比较老了,是2013年的结果,相信现在的结果会有所不同)

然而这也可以让我们明确的知道,在基础架构自动化方面我们还有多远的路要走,并且DevOps的基本原则和实践依然是那么的重要。

网络巨头们当然会通过新的方法和实践及时满足自己的需求,他们早已开始构建自己的工程业务,而正是他们所确立的实践逐渐衍生出当今我们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧,举几个例子:

Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。
Flickr每天部署10次。
Netflix明确针对失败进行各种设计!他们的软件按照设计从最底层即可容忍系统失败,他们会在生产环境中进行全面的测试:每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。

他们这种做法秘密何在?

1.5 DevOps:仅此一次,一颗神奇的银子弹

他们的秘密很简单:将敏捷扩展至生产端:

DevOps的共存主要是为了扩展敏捷开发实践,进一步完善软件变更在构建、验证、部署、交付等阶段中的流动,同时通过软件应用程序的全面所有权予力跨职能团队完成从设计到生产支持等各环节的工作。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。

DevOps团队更侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。理想情况下,DevOps可以为开发者提供更可控的生产环境,帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行自己应用程序的构建、验证、交付和支持。

那么核心原则到底是什么?

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错,因为人脑实在是不擅长处理重复性的任务,相比Shell脚本,人类的速度实在是太慢了。毕竟我们都是人类,因此有必要像处理代码那样考虑和处理有关基础架构的概念!

基础架构即代码(IaC)是大部分通用DevOps实践的前提要求,例如版本控制、代码审阅、持续集成、自动化测试。这一概念涉及计算基础架构(容器、虚拟机、物理机、软件安装等)的管理和供应,以及通过机器可处理的定义文件或脚本对其进行的配置,交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过,它可以真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署可以继续效仿传统物理拓扑。我们可以相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面,上至基础架构下至操作系统设置,均可编码并存储至版本控制仓库。

2.1 概述

以非常概括的方式来看,基础架构和运维所需实现的自动化程度可通过下图这种架构来表示:

上述架构图中作为示例的工具主要面向不同层的构建工作,实际上DevOps工具链的作用远不止如此。

我觉得在这里可以略微深入地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁,代表了开发、运维、测试等环节之间的协作,因此DevOps工具是非常多种多样的,甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别,并可体现出软件开发和交付过程的不同阶段:

编码:代码开发和审阅,版本控制工具、代码合并工具
构建:持续集成工具、构建状态统计工具
测试:通过测试和结果确定绩效的工具
打包:成品仓库、应用程序部署前暂存
发布:变更管理、发布审批、发布自动化
配置:基础架构配置和部署,基础架构即代码工具
监视:应用程序性能监视、最终用户体验

虽然可用工具有很多,但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker(容器化)、Jenkins(持续集成)、Puppet(基础架构构建)、Vagrant(虚拟化平台)等常用、广泛使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力(而非基础架构的构建脚本或配置文件)及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物一样进行持续集成。

2.3 收益

DevOps的收益有很多,包括但不限于:

可重复性与可靠性:时至今日,构建生产用计算机只需要运行脚本或必要的puppet命令即可。通过恰当地使用Docker容器或Vagrant虚拟机,只需运行一条命令即可配置好包含操作系统层以及所需软件和配置的生产用计算机。当然,随着各种变更或软件开发、持续集成,并自动测试,这套构建脚本或机制也会进行持续集成。

最终幸亏有了XP或敏捷,我们在软件开发端所使用的同一套实践也能让运维端获益。

生产力:一键部署,一键供应,一键创建新环境……整个生产环境可以通过一条命令或一键点击的方式创建。这样的一条命令也许会运行长达数小时,但在这过程中运维人员可以从事其他更有趣的工作,而无需等待一条命令执行完毕后继续输入下一条命令,毕竟这样的过程有时候可能需要花费几天时间才能完成……
恢复时间!:一键点击即可恢复生产环境,就是这么简单。
确保基础架构的同质:彻底避免运维人员每次构建环境或安装软件时最终获得的结果与预期有所差异,这是确保基础架构绝对同质(Homogeneous)并且可再现的唯一可行方法。以此为基础,通过对脚本或Puppet配置文件使用版本控制机制,我们甚至可以重建出与上周、上个月,或软件特定版本发布时完全一致的生产环境。
维持整齐划一的标准:基础架构标准甚至可以不复存在,代码本身就是标准。
让开发者自行完成大部分工作:如果开发者自己突然可以在自己的基础架构上一键点击重建生产环境,他们也就可以自行完成很多与生产环境有关的任务,例如更好地理解生产失败,提供更恰当的配置,实现部署脚本等。

这只是我个人感觉IaC可提供的部分收益,相信还有很多其他收益。

3. 持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

从实践中学习
自动化
更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化
自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。
 
 
3.3 更频繁的部署
DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:
  • 首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)
  • 第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。
  • 第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。

change.png

那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。
 
3.4 持续交付的前提需求
在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:
  • 对软件组件的开发和平台的供应和设置进行持续集成。
  • TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。
  • 代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。
  • 软件的持续审计 - 例如使用Sonar。
  • 在生产级环境实现功能测试的自动化。
  • 更强大的非功能测试自动化(性能、可用性等)。
  • 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。
 
 
3.5 零停机部署
 
“零停机部署(ZDD)可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时,可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看,这应该是最佳部署方式,因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术:
  • 功能开关(Feature Flipping)
  • 摸黑启动(Dark launch)
  • 蓝/绿部署(Blue/Green Deployment)
  • 金丝雀发布(Canari release)

 
功能开关
功能开关可供我们在软件运行过程中启用/禁用相应的功能。这种技术其实非常容易理解和使用:为生产版本提供一个能彻底禁用某项功能的配置,并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说,若要将某个应用程序内的一个功能全局禁用或激活:
if Feature.isEnabled('new_awesome_feature')
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
或者如果要真对具体用户实现类似目的:

if Feature.isEnabled('new_awesome_feature', current_user)
# Do something new, cool and awesome
else
# Do old, same as always stuff
end
摸黑启动
摸黑启动的目的在于通过生产环境进行负载模拟!

在测试环境中,通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试,就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载,而是可以实际部署这样的功能,然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段,借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务,并且希望模拟所有用户同时输入文字,向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程,通过该进程将输入的搜索关键字发送给新增的自动补全服务,并自动发送多次。

就算新增的Web服务彻底崩溃了,也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了,我们至少还可以对该服务进行优化和完善,直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。
 
蓝/绿部署
蓝/绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后,可以修改负载均衡器的配置,以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收,用于构建下下一

详解微服务实践从架构到部署

运维技术OS小编 发表了文章 • 0 个评论 • 317 次浏览 • 2017-07-17 22:08 • 来自相关话题

前言

前段时间公司事情多,这篇长文写了放、放了写…耽搁了一些进度。各个自媒体的更新也慢了很多,这里给大家说句抱歉了。
 
现如今“微服务”遍地开花,已经成软件架构领域最受欢迎的热门话题之一。网上和书籍中都有很多关于微服务基础和优势的学习材料,但是我们可能会发现这东西在现实世界企业场景中似乎好像没那么普及,真正能跑的微服务资源其实也不是很多,大多是停留在概念和摸索阶段。

在这篇文章里,我打算讲讲微服务架构(MSA)的关键架构概念,以及如何在实践中将这些架构原理应用起来。





前因:单片结构

企业应用,因为服务于众多业务需求,因此会有些特定的软件应用提供许多功能,而一般惯例是把这些功能都堆在单个单片应用中。例如,ERP,CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署,在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。

面向服务架构(SOA)旨在通过引入“服务”的概念来克服以上的限制,“服务”是从应用程序提供的类似功能中提取出来的聚合和分组。因此,使用SOA,软件应用程序就会被设计为“粗粒度”服务的组合。然而,SOA中服务的范围非常广泛,这又引出了复杂而庞大的服务与一大堆操作(功能)以及复杂无比的消息格式和标准(如WS *标准)。




多数情况下,SOA中的服务彼此独立,只不过它们与所有其他服务一起部署在相同的运行时间里(只需考虑将部署到同一个Tomcat实例中的多个Web应用)。和单片软件应用类似,这些服务通过积累各种功而具有随时间推移的习惯。图1是一个非常好的一个单片架构的例子,显示了包括多个服务的零售软件应用,所有这些服务都能部署到同一应用程序。

说了那么多,大家是不是有点不明所以?我总结了一些重点,以下就是基于单片架构的应用程序的一些特性归纳:
单片应用程序被设计、开发和部署为单个单元。单片应用相对复杂,导致维护,升级和新特性困难重重。难以用单片架构来实践敏捷开发和交付方法。想更新某部分,很可能要重新部署整个应用。规模需求冲突的情况下,若想做单点扩展,要做好多倍资源甚至推倒重来的准备(例如,想给A服务更多CPU,B服务可能要重做,也可能要补两三倍memory)可靠性:一个不稳定的服务可以拖慢整个应用性能。难创新:采用新技术和框架非常困难,因为所有的功能必须建立在均匀的技术/框架上。
单片架构的天然特性,直接给微服务架构的异军突起带来了绝佳的机会。
 

后果:微服务架构

微服务架构(MSA)的基础是将单片应用作为一套小型和独立服务来开发,这些服务都在自己的空间独立开发、部署和运行。在微服务体系结构的大多数定义中,它普遍被解释为将巨大的可用服务隔离成一套独立服务的过程。

不过我对这些有自己的理解,微服务的逻辑不仅是将整个大容量服务分为独立服务,关键在于通过查看从整体提供的功能,我们就可以确定所需的业务能力。而这些业务能力可以具体实现为各自独立的细粒度和自包含(微)服务。它们可能在一个技术堆栈上实现,每个服务都处理一个非常具体和有限的业务范围。

因此,上面解释的在线零售系统场景可以通过如图2的微服务架构实现。通过微服务架构,零售软件应用程序被规整为一套微服务。而且从图2最底下一层可以看出,根据业务需求,还多了一个从原始服务组合中额外创建的一个微服务。换句话说,想跟进微服务,要有超大容量服务可能会分裂的准备,不过我相信相比于进步,这点麻烦值得付出。 




所以,铺垫了那么多,现在我们深入了解微服务的关键架构原理,这里重要的是最好带着实践的思路来思考问题。
 

设计微服务:大小,范围和功能

通过Microservices Architecture可以从头开始构建软件应用或改造现有应用程序/服务…无论是哪种方法,正确判定Microservices的大小,范围和功能,都至关重要。我感觉,这可能是在Microservices Architecture实践最初(对的,“最初”这个词用的没错)最难的事了。

现在聊聊关于微服务的规模、范围和功能的关键实践问题和对一些坊间误解的辟谣。
代码行数/团队规模都是坑B指标:这里先引入一个概念,双披萨团队,有兴趣的可以去深入了解。根据实施代码或团队规模,有几个讨论决定了Microservices的大小。然而,这些被认为是非常不切实际和糟糕的指标,即便我们仍然可以使用较少的代码/双比萨团队做规模开发,但这种思路完全违反了微服务架构主体。'Micro'有点误导性的词语:大多数开发人员倾向于认为他们应尽可能的减少服务,这是一个天然的误解。在SOA上下文中,服务通常被实现为具有数十个操作/功能的单片全局。所以,像SOA这样的服务就算命名为微服务,不会给你带来微服务架构的好处。
 
那么那么我们应该如何在微服务架构中正确设计服务?
 

微服务设计指南

单一责任原则(SRP):为微服务提供有限和重点突出的业务范围,有助于我们满足开发和提供服务的敏捷性。在微服务的设计阶段,我们应该找到各服务的边界,并将其与业务能力(也称为域驱动设计中的有界环境 )保持一致。微服务设计要确保敏捷/独立开发和部署服务的丝滑稳定。我们的重点应该放在微服务的范围上,而不是使服务更"小"。服务的大小应该是指所需的范围大小,以促进给定的业务能力。与SOA中的服务不同,给定的微服务应该具有很少的操作/功能和简单的消息格式。随着时间的推移,首先开始具有相对广泛的服务边界,重构到较小的服务界限(基于业务需求),这是一个很好的做法。
在我们的零售用例中,整体功能分为四个不同的微服务,即“库存”,“会计”,“运输”和“存储”。他们正在解决一个有限但重点突出的业务范围,使每个服务彼此完全脱钩,并确保开发和部署中的敏捷性。
 

微服务中的消息传递

在单片应用中,使用函数调用或语言级方法调用不同处理器/组件的业务功能。在SOA中,这种转移趋向于更为松散耦合的Web服务级别消息传递,主要基于不同协议(如HTTP,JMS)之上的SOAP。而具有数十种操作和复杂消息模式的Web服务是Web服务普及的关键阻力。对于Microservices架构,它需要简单而轻量的消息传递机制就行。
 

同步消息 - REST,Thrift

对于同步消息传递(客户端期望从服务及时得到响应并等待到达),在微服务体系结构中,REST是主流标配,因为它提供了基于资源API风格的HTTP请求响应实现的简单消息传递方式。因此,大多数微服务实现都使用HTTP以及基于资源API的风格(每个功能都以资源和在这些资源之上执行的操作来表示)。




另外,Thrift (可以在其中为微服务定义接口定义)可以作为REST / HTTP同步消息传递的替代方法。
 

异步消息 - AMQP,STOMP,MQTT

对于某些需要使用异步消息传递技术(客户端不期望立即响应或根本不接受响应)的微服务场景。多看看诸如AMQP, STOMP或MQTT之类的异步消息协议就好了。
 

消息格式 - JSON,XML,Thrift,ProtoBuf,Avro

决定微服务最适合的消息格式是另一个关键因素。传统单片应用使用二进制格式(习惯了,表示还好不算复杂);基于SOA / Web服务的应用使用基于复杂消息格式(SOAP)和模式(xsd)的文本消息。而在大多数基于微服务器的应用中,简单基于文本的消息格式即可,如JSON和XML,反正就是基于HTTP资源API风格跑起来。在我们需要二进制消息格式的情况下(文本消息在某些用例中可能会变冗长),微服务可以利用二进制消息格式,如Thrift,ProtoBuf或Avro…
 

服务合同 - 定义服务接口 - Swagger, RAML, Thrift IDL

若你把业务能力实现为服务,就需要定义和发布服务合同。传统单片应用几乎找不到这样的功能来定义应用的业务功能。在SOA/Web服务的世界里,WSDL用于定义服务合同。不过众所周知,WSDL不是用于定义微服务合同的理想解决方案,因为WSDL非常复杂且与SOAP紧密耦合。

由于我们在REST架构风格之上构建微服务器,所以我们可以使用相同的REST API定义技术来定义微服务器的合同。因此,微服务更多情况下用标准的REST API定义语言(如Swagger和RAML) 来定义服务契约。
对于不基于HTTP/REST(如Thrift)的其他微服务实现,可以用协议级别的“接口定义语言(IDL)”(如Thrift IDL)。
 

集成微服务(Inter-service / process communication)

在微服务架构中,软件应用程序被构建为一套独立的服务。因此,为了实现业务用例,需要在不同的微服务/流程之间建立通信结构。这就是为什么微服务之间的服务间/过程通信至关重要的原因。
 
在SOA实现中,服务之间的服务间通信通过企业服务总线(ESB)来实现,大部分业务逻辑都位于中间层(消息路由,转换和业务流程)中。然而,微服务架构促进消除中央消息总线/ESB,并将“智能”或业务逻辑移至服务和客户端(称为“智能端点”)。

由于微服务使用诸如HTTP,JSON等标准协议,因此在微服务之间的通信中,与不同协议集成的要求是最小的。Microservice通信中的另一种替代方法是使用轻量级的消息总线或网关,它们有最小的路由功能,并且仅用作在网关上实现业务逻辑的“dumb pipe”。基于这些风格,在微服务架构中不可避免的出现了几种通信模式。
 

点到点风格 - 直接调用服务

以点对点的形式,消息路由逻辑的整体跑在每个端点之上,服务可以直接通信。这里每个微服务器都暴露一个REST API,一个给定的微服务器或外部客户端可以通过对应的REST API调用另一个微服务器。




显然,这个模型适用于相对简单的基于微服务的应用。随着服务数量增加,复杂就会压倒一切的源头。传统SOA实现中使用ESB也是相同的原因,不过是为了摆脱混乱的点对点集成链接。总结微服务通信中点对点风格的缺点:
须在每个微服务级别实现终端用户认证,限制,监控等非功能性要求。由于不可避免的复制一些常用功能,每个微服务实现可能会变得复杂。服务和客户端之间的所有通信都无法控制(哪怕只是监控,跟踪或过滤)。通常直接沟通风格被认为是用于大规模微服务实现的微服务反向模式。
特征说完,总结:对于复杂的微服务用例,可以考虑轻量级的中央消息总线,而不是点对点连接或中心ESB,思路是为微服务提供一个抽象层,并可用于实现各种非功能的能力,这种风格被称为API网关风格,往下看。
 

API网关样式

API网关风格背后的关键思想是使用轻量级消息网关作为所有客户端/消费者的主要入口点,并在Gateway级别实现常见的非功能需求。通常,API网关允许通过REST/HTTP使用受管API。因此,在这里,我们可以将通过API-GW实现作为微服务的业务功能公开为管理API。Microservices架构和API管理的组合,这个算是最佳选择了。




在我们的零售业务场景中,如图5,所有的微服务都通过API-GW公开,这是所有客户端的单个入口点。总结下API-GW风格优势:
能够在现有微服务的网关级别提供所需的抽象。例如,API网关可以为每个客户端提供不同的API,而不是提一个所有类型的API。网关级、轻量级消息路由/转换。非功能性功能(如安全性,监控和调节)的应用能如臂指使。API-GW模式让非功能性要求在Gateway级别实现,微服务得以瘦身。
比较推荐API-GW,我没具体了解过,但这个应该也是应用最广泛的模式。
 

Message Broker风格

微服务还可以和异步消息的场景集成,比如队列或主题的单向请求以及订阅。给定的微服务可以做消息生成,并且它可以异步地将消息发送到队列或主题。那么消费的微服务器可以消耗来自队列或主题的消息。这种风格将消息生成与消息消费分离,中间消息代理缓冲直到消费处理。




消费/生产之间的通信基于异步消息标准(例如AMQP,MQTT等)的消息代理来实现。
 

分散式数据管理

单片架构中,应用将数据存储在单个和集中的数据库中,以实现应用的各种功能/功能。




在微服务体系结构中,功能分散在多个微服务器中,如果我们使用相同的集中式数据库,那么微服务器将不再彼此独立(例如,如果数据库模式已经从给定的微服务器发生变化)。因此,每个微服务器都必须拥有自己的数据库。




以下是在微服务架构中实施分散数据管理的关键方面:
每个微服务器都可以有一个私有数据库来保存实现从其提供的业务功能所需的数据。给定的微服务器只能访问专用私有数据库,而不能访问其他微服务器的数据库。某些业务场景中,可能单个事务需要更新多个数据库。在这种情况,其他微服务器的数据库应仅通过其服务API进行更新,而非直接访问。
非集中式数据管理提供完全解耦的微服务器,以及选择不同数据管理技术(SQL或NoSQL等,按需分配,可能不同数据库管理系统)的自由。再者对于涉及多个微服务的复杂事务用例,事务行为必须使用从每个服务提供的API来实现,并且逻辑位于客户端或中间(GW)级别。
 

权力下放的治理思维

微服务架构倾向于分散治理。一般来说,SOA治理指导了可重用服务的开发,建立如何设计和开发服务以及这些服务随时间的变化。它确定了服务提供商和这些服务的消费者之间的协议,告诉消费者他们期望什么以及提供者有义务提供什么。在SOA治理中,共有两种类型的治理:
设计时治理 - 定义和控制服务策略的服务创建,设计和实施;运行时管理 - 执行期间执行服务策略的能力;
那么,微服务环境中的治理究竟怎么理解?在微服务架构中,微服务通过各种技术和平台构建为完全独立和解耦服务。因此,不需要为服务设计和开发定义一个共同的标准。总结下微服务的权力下放治理能力:
在微服务架构中,管理不需要集中设计。微服务器可以因地制宜,决定其设计和实现。微服务架构促进了共享/可重用服务的共享。一些运行时管理方面,如SLA,节流,监控,常见安全要求和服务发现可以在API-GW级别实现。
 

服务注册和服务发现

在微服务架构中,需要处理的微服务器数量相当高。而且,由于微服务的快速和敏捷的开发/部署性质,他们的位置一般来说也会动态变化。因此,你需要在运行时间内找到微服务器的位置。解决此问题的方法是使用Service Registry。
 
服务注册表:
服务注册表保存微服务实例及其位置。Microservice实例在启动时注册到服务注册表,并在关机时注销。消费者可以通过服务注册表找到可用的微服务及其位置。
 
服务发现:
要找到可用的微服务及其位置,我们要一个服务发现机制。有两种类型的服务发现机制,客户端发现和服务器端发现,来看看这些服务发现机制各原理如何。
 
客户端发现:
在这种方法中,客户端或API-GW通过查询服务注册表来获取服务实例的位置。




这里客户端/API-GW必须通过调用Service-Registry组件来实现服务发现逻辑。
 
服务器端发现:
通过这种方法,客户机/API-GW将请求发送到在众所周知的位置运行的组件(如负载平衡器)。该组件调用服务注册表并确定微服务器的绝对位置。




Kubernetes等微服务部署解决方案提供了服务端发现机制,自媒体里链接不能发就算了。
 

部署

在微服务架构方面,微服务的部署同样起着至关重要的作用,关键要求如下:
能够独立于其他微服务部署/部署。必须能在每个微服务级别做扩展(给定的服务可能比其他服务获得更多的流量)。快速构建和部署。一个微服务的故障不得影响任何其他服务。
Docker提供了一种很好的方式来部署满足上述要求的微服务器,所涉及的关键步骤如下:
将微服务作为(Docker)容器镜像打包。将每个服务实例部署为容器。基于更改容器实例的数量来进行缩放。构建,部署和启动微服务将会快得多,因为我们使用Docker容器(这比常规VM快得多)
Kubernetes通过允许将一组Linux容器作为单个系统进行管理,在多个主机上管理和运行Docker容器,提供容器的共同位置,服务发现和复制控制,从而扩展Docker功能。其实大多数这些功能在微服务环境中也很重要,因此使用Kubernetes(在Docker上面)用于微服务部署已经成为一种非常强大的方法,特别是对于大规模微服务部署。




图11,显示了零售应用的微服务部署概述。每个微服务实例被部署为容器,每个主机有两个容器。同时可随意更改在给定主机上运行的容器数。
 

安全

现实很骨感,无论是不是微服务都应当得到安全方面的保护。在进入微服务安全性篇章之前,我们先快速过一下如何在单片应用层面实现安全。
在典型的单片应用程序中,安全性是关于发现“谁是呼叫者”,“呼叫者可以做什么”,以及“我们如何传播该信息”。这通常在位于请求处理链的开始处的公共安全组件中实现,该组件使用底层用户存储库(或用户存储)填充所需的信息。
那么,我们可以直接将这种模式转化为微服务架构吗?是的,但是这需要在每个微服务级别实现安全组件,该级别正在与集中式/共享用户存储库进行通信,并检索所需的信息。这是解决Microservices安全问题的一种非常乏味的方法。

还有,划重点,我们可以利用广泛使用的API-Security标准(如OAuth2和OpenID Connect)来找到我们的Microservices安全问题的更好的解决方案。在深入了解之前,我来总结下这些标准。
 
OAuth2 - 是访问委派协议。客户端使用授权服务器进行身份验证,并获取称为“访问令牌”的不透明令牌。Access令牌具有关于用户/客户端的零信息。它仅引用只能由授权服务器检索的用户信息。因此,这被称为“副参考令牌”,即使在公共网络/互联网中也可以安全地使用该令牌。OpenID Connect的行为与OAuth类似,但是除了访问令牌之外,授权服务器还会发出一个包含用户信息的ID令牌。这通常由JWT(JSON Web令牌)实现,并由授权服务器签名。因此,可以确保授权服务器与客户端之间的信任。因此,JWT令牌被称为“副值令牌”,因为它包含用户的信息,显然不能在内部网络之外使用它。
 
现在,让我们看看我们如何使用这些标准来保护我们零售业的微观服务。




如图12,这些是实现微服务安全性的关键步骤:
将身份验证保留到OAuth和OpenID Connect服务器(授权服务器),以便microservices成功提供访问权限,因为有人有权使用数据。使用API-GW样式,其中所有客户端请求都有一个入口。客户端连接到授权服务器并获取访问令牌(按引用令牌)。然后将访问令牌与请求一起发送到API-GW。网关上的令牌翻译:API-GW提取访问令牌,并将其发送到授权服务器以通过值令牌来检索JWT。GW将该JWT与请求一起传递到微服务层。JWT包含有助于存储用户会话等的必要信息。如果每个服务都可以了解JSON - Web令牌,那么已经分发了你的身份机制,那你就被允许在整个系统中传输身份。在每个微服务层,我们可以有一个处理JWT的组件,这是一个非常简单的实现。
 

交易

微服务中的交易支持如何?其实,支持跨多个微服务的分布式事务是一个非常复杂的任务。

微服务架构本身鼓励服务之间的无事务协调。这个想法是给定的服务是完全独立,基于单一的责任原则。跨多个微服务器分布式事务的需要通常是微服务体系结构设计缺陷的症状,通常可以通过重构微服务器的范围进行整理。

然而,如果强制性要求跨多个服务进行分布式交易,则可以通过在每个微服务级别引入“补偿操作”来实现这种情况。关键思想是,给定的微服务是基于单一责任原则,如果给定的微服务器未能执行给定的操作,那么我们可以认为这是整个微服务的失败。
 

设计失败

Microservice架构引入了一系列分散的服务,与单片设计相比,增加了在每个服务级别发生故障的可能性。由于网络问题,基础资源不可用,给定的微服务可能会失败。不可用或无响应的微服务器不应玩砸了整个基于微服务器的应用。因此,微服务应该有容错余地,能够在可能的情况下恢复,客户端也必须妥善处理。

此外,由于服务可能随时失败,因此能够快速检测(实时监控)故障,并尽可能自动恢复服务(故障自愈)很重要。在微服务玩家的眼里,处理错误有几种常用模式。
 
断路器
当你对微服务器进行外部呼叫,就可以在每次调用时配置故障监视器组件,并且当故障达到某个阈值时该组件将停止对服务的任何进一步调用(跳闸电路)。在打开状态(可以配置)的一定数量的请求后,将电路更换回关闭状态。

这种模式对于避免不必要的资源消耗,由于超时引起的请求延迟是非常有用,也让我们有机会更积极的监控系统(基于活动的开路状态)。
 
隔板
基于微服务器的应用的一部分的故障不应影响其他应用,隔板模式是关于隔离应用的不同部分,以便应用的某个部分的服务失败不会影响任何其他服务。
 
超时
超时是一种主观加入的合理机制,当你认为结果无法返回,则允许停止响应。

模式这里叨叨完。那么,我们在哪里和如何使用这些模式与微服务?大多数情况下这些模式都适用于Gateway级别,这意味着当微服务不可用或没有响应时,在网关级别,我们可以决定是否使用断路器或超时模式将请求发送到微服务。此外,在Gateway级别实现诸如隔板之类模式也很重要,因为它是所有客户端请求的单个入口点,也因此发送服务中的故障不应影响其他微服务器的调用。

另外,Gateway可以作为中心点,我们可以通过Gateway调用每个微服务来获取每个微服务器的状态和监视。
 
微服务,企业集成,API管理和遐(瞎)想
我们专门研究过微服务架构的各种特点,以及如何在现代企业IT环境中实现它们。但是,我们应该记住,微服务不是灵丹妙药。流行语概念的盲目适应不会解决“真实”企业IT问题。

它微服务是有很多优势,我们也应该充分利用。但是我们还必须记住,解决所有企业IT问题与微服务之间联系不一定就是强相关。例如,Microservices架构促进消除ESB作为中央总线,但是当涉及到现实世界的IT时,现在有很多不是基于Microservices的应用程序/服务。所以,整合是避不开的解决思路,要做集成。

所以,理想情况下,Microservices和其他企业架构概念(如Integration)的混合方法将更为现实。以后再聊了,这个能写的太多。 希望这能让你更清楚地了解如何在企业中使用Microservices。
分享阅读原文: http://dwz.cn/6iVsiQ  查看全部


前言


前段时间公司事情多,这篇长文写了放、放了写…耽搁了一些进度。各个自媒体的更新也慢了很多,这里给大家说句抱歉了。
 
现如今“微服务”遍地开花,已经成软件架构领域最受欢迎的热门话题之一。网上和书籍中都有很多关于微服务基础和优势的学习材料,但是我们可能会发现这东西在现实世界企业场景中似乎好像没那么普及,真正能跑的微服务资源其实也不是很多,大多是停留在概念和摸索阶段。

在这篇文章里,我打算讲讲微服务架构(MSA)的关键架构概念,以及如何在实践中将这些架构原理应用起来。
warch.png


前因:单片结构


企业应用,因为服务于众多业务需求,因此会有些特定的软件应用提供许多功能,而一般惯例是把这些功能都堆在单个单片应用中。例如,ERP,CRM和其他各种软件系统被规划构建为具有数百个功能的整体。这种带坑应用一经部署,在往后的故障排除、扩展和升级场景中就是一场接一场的恶梦了。

面向服务架构(SOA)旨在通过引入“服务”的概念来克服以上的限制,“服务”是从应用程序提供的类似功能中提取出来的聚合和分组。因此,使用SOA,软件应用程序就会被设计为“粗粒度”服务的组合。然而,SOA中服务的范围非常广泛,这又引出了复杂而庞大的服务与一大堆操作(功能)以及复杂无比的消息格式和标准(如WS *标准)。
wss.png

多数情况下,SOA中的服务彼此独立,只不过它们与所有其他服务一起部署在相同的运行时间里(只需考虑将部署到同一个Tomcat实例中的多个Web应用)。和单片软件应用类似,这些服务通过积累各种功而具有随时间推移的习惯。图1是一个非常好的一个单片架构的例子,显示了包括多个服务的零售软件应用,所有这些服务都能部署到同一应用程序。

说了那么多,大家是不是有点不明所以?我总结了一些重点,以下就是基于单片架构的应用程序的一些特性归纳:
  • 单片应用程序被设计、开发和部署为单个单元。
  • 单片应用相对复杂,导致维护,升级和新特性困难重重。
  • 难以用单片架构来实践敏捷开发和交付方法。
  • 想更新某部分,很可能要重新部署整个应用。
  • 规模需求冲突的情况下,若想做单点扩展,要做好多倍资源甚至推倒重来的准备(例如,想给A服务更多CPU,B服务可能要重做,也可能要补两三倍memory)
  • 可靠性:一个不稳定的服务可以拖慢整个应用性能。
  • 难创新:采用新技术和框架非常困难,因为所有的功能必须建立在均匀的技术/框架上。

单片架构的天然特性,直接给微服务架构的异军突起带来了绝佳的机会。
 


后果:微服务架构


微服务架构(MSA)的基础是将单片应用作为一套小型和独立服务来开发,这些服务都在自己的空间独立开发、部署和运行。在微服务体系结构的大多数定义中,它普遍被解释为将巨大的可用服务隔离成一套独立服务的过程。

不过我对这些有自己的理解,微服务的逻辑不仅是将整个大容量服务分为独立服务,关键在于通过查看从整体提供的功能,我们就可以确定所需的业务能力。而这些业务能力可以具体实现为各自独立的细粒度和自包含(微)服务。它们可能在一个技术堆栈上实现,每个服务都处理一个非常具体和有限的业务范围。

因此,上面解释的在线零售系统场景可以通过如图2的微服务架构实现。通过微服务架构,零售软件应用程序被规整为一套微服务。而且从图2最底下一层可以看出,根据业务需求,还多了一个从原始服务组合中额外创建的一个微服务。换句话说,想跟进微服务,要有超大容量服务可能会分裂的准备,不过我相信相比于进步,这点麻烦值得付出。 
asarch.png

所以,铺垫了那么多,现在我们深入了解微服务的关键架构原理,这里重要的是最好带着实践的思路来思考问题。
 


设计微服务:大小,范围和功能


通过Microservices Architecture可以从头开始构建软件应用或改造现有应用程序/服务…无论是哪种方法,正确判定Microservices的大小,范围和功能,都至关重要。我感觉,这可能是在Microservices Architecture实践最初(对的,“最初”这个词用的没错)最难的事了。

现在聊聊关于微服务的规模、范围和功能的关键实践问题和对一些坊间误解的辟谣。
  1. 代码行数/团队规模都是坑B指标:这里先引入一个概念,双披萨团队,有兴趣的可以去深入了解。根据实施代码或团队规模,有几个讨论决定了Microservices的大小。然而,这些被认为是非常不切实际和糟糕的指标,即便我们仍然可以使用较少的代码/双比萨团队做规模开发,但这种思路完全违反了微服务架构主体。
  2. 'Micro'有点误导性的词语:大多数开发人员倾向于认为他们应尽可能的减少服务,这是一个天然的误解。
  3. 在SOA上下文中,服务通常被实现为具有数十个操作/功能的单片全局。所以,像SOA这样的服务就算命名为微服务,不会给你带来微服务架构的好处。

 
那么那么我们应该如何在微服务架构中正确设计服务?
 


微服务设计指南


  1. 单一责任原则(SRP):为微服务提供有限和重点突出的业务范围,有助于我们满足开发和提供服务的敏捷性。
  2. 在微服务的设计阶段,我们应该找到各服务的边界,并将其与业务能力(也称为域驱动设计中的有界环境 )保持一致。
  3. 微服务设计要确保敏捷/独立开发和部署服务的丝滑稳定。
  4. 我们的重点应该放在微服务的范围上,而不是使服务更"小"。服务的大小应该是指所需的范围大小,以促进给定的业务能力。
  5. 与SOA中的服务不同,给定的微服务应该具有很少的操作/功能和简单的消息格式。
  6. 随着时间的推移,首先开始具有相对广泛的服务边界,重构到较小的服务界限(基于业务需求),这是一个很好的做法。

在我们的零售用例中,整体功能分为四个不同的微服务,即“库存”,“会计”,“运输”和“存储”。他们正在解决一个有限但重点突出的业务范围,使每个服务彼此完全脱钩,并确保开发和部署中的敏捷性。
 


微服务中的消息传递


在单片应用中,使用函数调用或语言级方法调用不同处理器/组件的业务功能。在SOA中,这种转移趋向于更为松散耦合的Web服务级别消息传递,主要基于不同协议(如HTTP,JMS)之上的SOAP。而具有数十种操作和复杂消息模式的Web服务是Web服务普及的关键阻力。对于Microservices架构,它需要简单而轻量的消息传递机制就行。
 


同步消息 - REST,Thrift


对于同步消息传递(客户端期望从服务及时得到响应并等待到达),在微服务体系结构中,REST是主流标配,因为它提供了基于资源API风格的HTTP请求响应实现的简单消息传递方式。因此,大多数微服务实现都使用HTTP以及基于资源API的风格(每个功能都以资源和在这些资源之上执行的操作来表示)。
api.png

另外,Thrift (可以在其中为微服务定义接口定义)可以作为REST / HTTP同步消息传递的替代方法。
 


异步消息 - AMQP,STOMP,MQTT


对于某些需要使用异步消息传递技术(客户端不期望立即响应或根本不接受响应)的微服务场景。多看看诸如AMQP, STOMP或MQTT之类的异步消息协议就好了。
 


消息格式 - JSON,XML,Thrift,ProtoBuf,Avro


决定微服务最适合的消息格式是另一个关键因素。传统单片应用使用二进制格式(习惯了,表示还好不算复杂);基于SOA / Web服务的应用使用基于复杂消息格式(SOAP)和模式(xsd)的文本消息。而在大多数基于微服务器的应用中,简单基于文本的消息格式即可,如JSON和XML,反正就是基于HTTP资源API风格跑起来。在我们需要二进制消息格式的情况下(文本消息在某些用例中可能会变冗长),微服务可以利用二进制消息格式,如Thrift,ProtoBuf或Avro…
 


服务合同 - 定义服务接口 - Swagger, RAML, Thrift IDL


若你把业务能力实现为服务,就需要定义和发布服务合同。传统单片应用几乎找不到这样的功能来定义应用的业务功能。在SOA/Web服务的世界里,WSDL用于定义服务合同。不过众所周知,WSDL不是用于定义微服务合同的理想解决方案,因为WSDL非常复杂且与SOAP紧密耦合。

由于我们在REST架构风格之上构建微服务器,所以我们可以使用相同的REST API定义技术来定义微服务器的合同。因此,微服务更多情况下用标准的REST API定义语言(如Swagger和RAML) 来定义服务契约。
对于不基于HTTP/REST(如Thrift)的其他微服务实现,可以用协议级别的“接口定义语言(IDL)”(如Thrift IDL)。
 


集成微服务(Inter-service / process communication)


在微服务架构中,软件应用程序被构建为一套独立的服务。因此,为了实现业务用例,需要在不同的微服务/流程之间建立通信结构。这就是为什么微服务之间的服务间/过程通信至关重要的原因。
 
在SOA实现中,服务之间的服务间通信通过企业服务总线(ESB)来实现,大部分业务逻辑都位于中间层(消息路由,转换和业务流程)中。然而,微服务架构促进消除中央消息总线/ESB,并将“智能”或业务逻辑移至服务和客户端(称为“智能端点”)。

由于微服务使用诸如HTTP,JSON等标准协议,因此在微服务之间的通信中,与不同协议集成的要求是最小的。Microservice通信中的另一种替代方法是使用轻量级的消息总线或网关,它们有最小的路由功能,并且仅用作在网关上实现业务逻辑的“dumb pipe”。基于这些风格,在微服务架构中不可避免的出现了几种通信模式。
 


点到点风格 - 直接调用服务


以点对点的形式,消息路由逻辑的整体跑在每个端点之上,服务可以直接通信。这里每个微服务器都暴露一个REST API,一个给定的微服务器或外部客户端可以通过对应的REST API调用另一个微服务器。
dtd.png

显然,这个模型适用于相对简单的基于微服务的应用。随着服务数量增加,复杂就会压倒一切的源头。传统SOA实现中使用ESB也是相同的原因,不过是为了摆脱混乱的点对点集成链接。总结微服务通信中点对点风格的缺点:
  • 须在每个微服务级别实现终端用户认证,限制,监控等非功能性要求。
  • 由于不可避免的复制一些常用功能,每个微服务实现可能会变得复杂。
  • 服务和客户端之间的所有通信都无法控制(哪怕只是监控,跟踪或过滤)。
  • 通常直接沟通风格被认为是用于大规模微服务实现的微服务反向模式。

特征说完,总结:对于复杂的微服务用例,可以考虑轻量级的中央消息总线,而不是点对点连接或中心ESB,思路是为微服务提供一个抽象层,并可用于实现各种非功能的能力,这种风格被称为API网关风格,往下看。
 


API网关样式


API网关风格背后的关键思想是使用轻量级消息网关作为所有客户端/消费者的主要入口点,并在Gateway级别实现常见的非功能需求。通常,API网关允许通过REST/HTTP使用受管API。因此,在这里,我们可以将通过API-GW实现作为微服务的业务功能公开为管理API。Microservices架构和API管理的组合,这个算是最佳选择了。
apigew.png

在我们的零售业务场景中,如图5,所有的微服务都通过API-GW公开,这是所有客户端的单个入口点。总结下API-GW风格优势:
  • 能够在现有微服务的网关级别提供所需的抽象。例如,API网关可以为每个客户端提供不同的API,而不是提一个所有类型的API。
  • 网关级、轻量级消息路由/转换。
  • 非功能性功能(如安全性,监控和调节)的应用能如臂指使。
  • API-GW模式让非功能性要求在Gateway级别实现,微服务得以瘦身。

比较推荐API-GW,我没具体了解过,但这个应该也是应用最广泛的模式。
 


Message Broker风格


微服务还可以和异步消息的场景集成,比如队列或主题的单向请求以及订阅。给定的微服务可以做消息生成,并且它可以异步地将消息发送到队列或主题。那么消费的微服务器可以消耗来自队列或主题的消息。这种风格将消息生成与消息消费分离,中间消息代理缓冲直到消费处理。
messbroker.png

消费/生产之间的通信基于异步消息标准(例如AMQP,MQTT等)的消息代理来实现。
 


分散式数据管理


单片架构中,应用将数据存储在单个和集中的数据库中,以实现应用的各种功能/功能。
darch.png

在微服务体系结构中,功能分散在多个微服务器中,如果我们使用相同的集中式数据库,那么微服务器将不再彼此独立(例如,如果数据库模式已经从给定的微服务器发生变化)。因此,每个微服务器都必须拥有自己的数据库。
apidb.png

以下是在微服务架构中实施分散数据管理的关键方面:
  • 每个微服务器都可以有一个私有数据库来保存实现从其提供的业务功能所需的数据。
  • 给定的微服务器只能访问专用私有数据库,而不能访问其他微服务器的数据库。
  • 某些业务场景中,可能单个事务需要更新多个数据库。在这种情况,其他微服务器的数据库应仅通过其服务API进行更新,而非直接访问。

非集中式数据管理提供完全解耦的微服务器,以及选择不同数据管理技术(SQL或NoSQL等,按需分配,可能不同数据库管理系统)的自由。再者对于涉及多个微服务的复杂事务用例,事务行为必须使用从每个服务提供的API来实现,并且逻辑位于客户端或中间(GW)级别。
 


权力下放的治理思维


微服务架构倾向于分散治理。一般来说,SOA治理指导了可重用服务的开发,建立如何设计和开发服务以及这些服务随时间的变化。它确定了服务提供商和这些服务的消费者之间的协议,告诉消费者他们期望什么以及提供者有义务提供什么。在SOA治理中,共有两种类型的治理:
  • 设计时治理 - 定义和控制服务策略的服务创建,设计和实施;
  • 运行时管理 - 执行期间执行服务策略的能力;

那么,微服务环境中的治理究竟怎么理解?在微服务架构中,微服务通过各种技术和平台构建为完全独立和解耦服务。因此,不需要为服务设计和开发定义一个共同的标准。总结下微服务的权力下放治理能力:
  • 在微服务架构中,管理不需要集中设计。
  • 微服务器可以因地制宜,决定其设计和实现。
  • 微服务架构促进了共享/可重用服务的共享。
  • 一些运行时管理方面,如SLA,节流,监控,常见安全要求和服务发现可以在API-GW级别实现。

 


服务注册和服务发现


在微服务架构中,需要处理的微服务器数量相当高。而且,由于微服务的快速和敏捷的开发/部署性质,他们的位置一般来说也会动态变化。因此,你需要在运行时间内找到微服务器的位置。解决此问题的方法是使用Service Registry。
 
服务注册表:
服务注册表保存微服务实例及其位置。Microservice实例在启动时注册到服务注册表,并在关机时注销。消费者可以通过服务注册表找到可用的微服务及其位置。
 
服务发现:
要找到可用的微服务及其位置,我们要一个服务发现机制。有两种类型的服务发现机制,客户端发现和服务器端发现,来看看这些服务发现机制各原理如何。
 
客户端发现:
在这种方法中,客户端或API-GW通过查询服务注册表来获取服务实例的位置。
apigwc.png

这里客户端/API-GW必须通过调用Service-Registry组件来实现服务发现逻辑。
 
服务器端发现:
通过这种方法,客户机/API-GW将请求发送到在众所周知的位置运行的组件(如负载平衡器)。该组件调用服务注册表并确定微服务器的绝对位置。
sr.png

Kubernetes等微服务部署解决方案提供了服务端发现机制,自媒体里链接不能发就算了。
 


部署


在微服务架构方面,微服务的部署同样起着至关重要的作用,关键要求如下:
  • 能够独立于其他微服务部署/部署。
  • 必须能在每个微服务级别做扩展(给定的服务可能比其他服务获得更多的流量)。
  • 快速构建和部署。
  • 一个微服务的故障不得影响任何其他服务。

Docker提供了一种很好的方式来部署满足上述要求的微服务器,所涉及的关键步骤如下:
  • 将微服务作为(Docker)容器镜像打包。
  • 将每个服务实例部署为容器。
  • 基于更改容器实例的数量来进行缩放。
  • 构建,部署和启动微服务将会快得多,因为我们使用Docker容器(这比常规VM快得多)

Kubernetes通过允许将一组Linux容器作为单个系统进行管理,在多个主机上管理和运行Docker容器,提供容器的共同位置,服务发现和复制控制,从而扩展Docker功能。其实大多数这些功能在微服务环境中也很重要,因此使用Kubernetes(在Docker上面)用于微服务部署已经成为一种非常强大的方法,特别是对于大规模微服务部署。
dockercon.png

图11,显示了零售应用的微服务部署概述。每个微服务实例被部署为容器,每个主机有两个容器。同时可随意更改在给定主机上运行的容器数。
 


安全


现实很骨感,无论是不是微服务都应当得到安全方面的保护。在进入微服务安全性篇章之前,我们先快速过一下如何在单片应用层面实现安全。
  • 在典型的单片应用程序中,安全性是关于发现“谁是呼叫者”,“呼叫者可以做什么”,以及“我们如何传播该信息”。
  • 这通常在位于请求处理链的开始处的公共安全组件中实现,该组件使用底层用户存储库(或用户存储)填充所需的信息。

那么,我们可以直接将这种模式转化为微服务架构吗?是的,但是这需要在每个微服务级别实现安全组件,该级别正在与集中式/共享用户存储库进行通信,并检索所需的信息。这是解决Microservices安全问题的一种非常乏味的方法。

还有,划重点,我们可以利用广泛使用的API-Security标准(如OAuth2和OpenID Connect)来找到我们的Microservices安全问题的更好的解决方案。在深入了解之前,我来总结下这些标准。
 
  • OAuth2 - 是访问委派协议。客户端使用授权服务器进行身份验证,并获取称为“访问令牌”的不透明令牌。Access令牌具有关于用户/客户端的零信息。它仅引用只能由授权服务器检索的用户信息。因此,这被称为“副参考令牌”,即使在公共网络/互联网中也可以安全地使用该令牌。
  • OpenID Connect的行为与OAuth类似,但是除了访问令牌之外,授权服务器还会发出一个包含用户信息的ID令牌。这通常由JWT(JSON Web令牌)实现,并由授权服务器签名。因此,可以确保授权服务器与客户端之间的信任。因此,JWT令牌被称为“副值令牌”,因为它包含用户的信息,显然不能在内部网络之外使用它。

 
现在,让我们看看我们如何使用这些标准来保护我们零售业的微观服务。
wservice.png

如图12,这些是实现微服务安全性的关键步骤:
  • 将身份验证保留到OAuth和OpenID Connect服务器(授权服务器),以便microservices成功提供访问权限,因为有人有权使用数据。
  • 使用API-GW样式,其中所有客户端请求都有一个入口。
  • 客户端连接到授权服务器并获取访问令牌(按引用令牌)。然后将访问令牌与请求一起发送到API-GW。
  • 网关上的令牌翻译:API-GW提取访问令牌,并将其发送到授权服务器以通过值令牌来检索JWT。
  • GW将该JWT与请求一起传递到微服务层。
  • JWT包含有助于存储用户会话等的必要信息。如果每个服务都可以了解JSON - Web令牌,那么已经分发了你的身份机制,那你就被允许在整个系统中传输身份。
  • 在每个微服务层,我们可以有一个处理JWT的组件,这是一个非常简单的实现。

 


交易


微服务中的交易支持如何?其实,支持跨多个微服务的分布式事务是一个非常复杂的任务。

微服务架构本身鼓励服务之间的无事务协调。这个想法是给定的服务是完全独立,基于单一的责任原则。跨多个微服务器分布式事务的需要通常是微服务体系结构设计缺陷的症状,通常可以通过重构微服务器的范围进行整理。

然而,如果强制性要求跨多个服务进行分布式交易,则可以通过在每个微服务级别引入“补偿操作”来实现这种情况。关键思想是,给定的微服务是基于单一责任原则,如果给定的微服务器未能执行给定的操作,那么我们可以认为这是整个微服务的失败。
 


设计失败


Microservice架构引入了一系列分散的服务,与单片设计相比,增加了在每个服务级别发生故障的可能性。由于网络问题,基础资源不可用,给定的微服务可能会失败。不可用或无响应的微服务器不应玩砸了整个基于微服务器的应用。因此,微服务应该有容错余地,能够在可能的情况下恢复,客户端也必须妥善处理。

此外,由于服务可能随时失败,因此能够快速检测(实时监控)故障,并尽可能自动恢复服务(故障自愈)很重要。在微服务玩家的眼里,处理错误有几种常用模式。
 
断路器
当你对微服务器进行外部呼叫,就可以在每次调用时配置故障监视器组件,并且当故障达到某个阈值时该组件将停止对服务的任何进一步调用(跳闸电路)。在打开状态(可以配置)的一定数量的请求后,将电路更换回关闭状态。

这种模式对于避免不必要的资源消耗,由于超时引起的请求延迟是非常有用,也让我们有机会更积极的监控系统(基于活动的开路状态)。
 
隔板
基于微服务器的应用的一部分的故障不应影响其他应用,隔板模式是关于隔离应用的不同部分,以便应用的某个部分的服务失败不会影响任何其他服务。
 
超时
超时是一种主观加入的合理机制,当你认为结果无法返回,则允许停止响应。

模式这里叨叨完。那么,我们在哪里和如何使用这些模式与微服务?大多数情况下这些模式都适用于Gateway级别,这意味着当微服务不可用或没有响应时,在网关级别,我们可以决定是否使用断路器或超时模式将请求发送到微服务。此外,在Gateway级别实现诸如隔板之类模式也很重要,因为它是所有客户端请求的单个入口点,也因此发送服务中的故障不应影响其他微服务器的调用。

另外,Gateway可以作为中心点,我们可以通过Gateway调用每个微服务来获取每个微服务器的状态和监视。
 
微服务,企业集成,API管理和遐(瞎)想
我们专门研究过微服务架构的各种特点,以及如何在现代企业IT环境中实现它们。但是,我们应该记住,微服务不是灵丹妙药。流行语概念的盲目适应不会解决“真实”企业IT问题。

它微服务是有很多优势,我们也应该充分利用。但是我们还必须记住,解决所有企业IT问题与微服务之间联系不一定就是强相关。例如,Microservices架构促进消除ESB作为中央总线,但是当涉及到现实世界的IT时,现在有很多不是基于Microservices的应用程序/服务。所以,整合是避不开的解决思路,要做集成。

所以,理想情况下,Microservices和其他企业架构概念(如Integration)的混合方法将更为现实。以后再聊了,这个能写的太多。 希望这能让你更清楚地了解如何在企业中使用Microservices。
分享阅读原文: http://dwz.cn/6iVsiQ 

不仅是 Linux 运维最佳实践

运维技术OS小编 发表了文章 • 0 个评论 • 297 次浏览 • 2017-06-30 00:07 • 来自相关话题

我们面对的是一个不断变化的世界,业务需求在变,技术架构在变,开源工具与商业系统异构部署,新工具和技术概念层出不穷,唯有一套科学的技术方法论才能应对这些变化。很多时候,我们在面对新的问题时,会束手无措。因此,在 OSC 第 132 期高手问答中,我们策划了“Linux 运维最佳实践”的主题,并邀请了@xufengnju(胥峰)作为高手嘉宾。

@xufengnju(胥峰),资深运维专家,有 10 年运维经验,在业界颇具威望和影响力。也是盛大游戏高级研究员,2006 年毕业于南京大学,2011 年加入盛大游戏,工作至今,曾参与盛大游戏多款大型端游和手游的上线运维,主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。

自动化运维在近几年一直都是很火热的话题,技术也一直在进步,因此对于技术人员来说,最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求,思想才是运维人员应该毕生修炼的目标!本次高手问答的高手嘉宾对运维服务体系有着深度的思考,因此问答中产生的内容也是十分有质量。

本文从多个角度整理了与运维相关的内容,包括工具的选择、运维中遇到的问题、自动化运维相关等等。
 
Q&A​
 一、工欲善其事必先利其器,如何选择工具? 
1. 对服务器安全和监控,可以推荐一些开源工具吗?监控好像也就 nagios, cacti, zabbix,还有其他可以推荐的吗?安全方面如何监控?

监控工具各有侧重点,zabbix 同时支持 snmp 和自己的 agent,也支持自定义模板,在大部分场景下都是不错的选择。

另外,不要把 zabbix 视为只能监控服务器信息,通过自定义模板,也可以监控业务层面的指标。安全监控分为主动检测,如 Tenable Nessus,以及 IDS、IPS。

2. Linux 运维中,服务器版本都用什么版本?CentOS 5 还是 CentOS 6、Ubuntu?为什么选择这个版本?有做哪些测试?

目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,主要是考虑到它的稳定性以及熟悉程度最高。

3. 对于使用缓存有什么推荐吗?一般就 Redis, Codis。还有那些比较好用的开源软件?

对于类似 session-id 这样的可以非持久存储的数据,可以考虑 memcached,使用一致性哈希算法分布式存储。

4. 做自动化发布,除了 Jenkins 持续集成工具,还有那些好用的工具呢?

目前我所知道的,一般都是 Hudson 或者 Jenkins,后者是前者分支出来的。这些工具都有丰富的插件,灵活使用这些插件是关键所在。

5. 问个 MySQL 问题,三个版本(MySQL(官方版本)、Percona Server 、MariaDB)您建议使用哪个版本,原因是?

我们团队一般使用的是官方版本。主要是考虑到支持和生态。

6. 服务器日志收集和分析有什么好工具推荐吗?ELK 貌似有点复杂,不太会用,有其他的推荐么?

ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本,但还是值得去研究和尝试的。

7. 书里有开源出一些工具和脚本吗,哪里可以下载到?

书上的脚本我正在整理,其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git  

8. 请问你们现在运维都是基于 Ansible 吗?我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火,还没实践用过,请问这个用起来差别大吗?

各种不同的批量管理工具各具特点,根据自己的熟悉程度和实际业务需要选择一个完全掌握即可
目前 IaaS 平台是自研的,基于 KVM

二、绝知此事要躬行,运维中遇到问题?1. LVS 和 HAPROXY 后端服务器规模可以到什么程度,比如有多少个应用,多少台后端服务器?

这个取决于应用的类型,在实际的业务场景下,需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大,可以考虑 LVS 的 DR 模式。一般情况下,负载均衡器不太会成为瓶颈。

负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计?
通过开源的 Zabbix 模板或者自定义模板,这些都不难实现。有没有相关的命令集进行统计,或者详细的统计实例?

针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术,建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm,netstat 等。

2. 对于涉及多个平台(Unix, Linux, Windows)的统一管理(认证,配置,服务)有什么好的解决方案或者思路么?

先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证,可以考虑,这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品,比如 Ansible 或者 Salt。目前我们用的自研系统,思路和 Ansible 类似。

3. 如何监控服务,业务运行状态监控你是怎么做的?

我们的监控系统是自研的,对游戏来说,很重要的一个业务指标是在线人数,它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。

4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本,业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台?

我们批量管理服务器的方式是 ssh,思路和 Ansible 类似。CMDB 提供基础数据的管理,是自研的。

5. 请问有使用过流量镜像吗?就是把线上的流量镜像一份,引到测试环境,用真实的用户数据测试,想了解下从 0 开始实施的过程。

关于流量镜像的原理,可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后,你应该可以自己写一套。我没有亲自实践过,你可以自己关注下 tcpcopy 这个项目。

6. CentOS 6 要如何做系统和网络优化?/etc/sysctl.conf 中的这个参数
net.ipv4.tcp_max_tw_buckets = 6000要如何设置,是越多越好吗?设置成 16000?
net.ipv4.tcp_max_tw_buckets = 16000

对于系统优化来说,要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket,如系统中 timewait 状态较多,可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外,如果使用长连接对于减少该状态的连接数有效。

7. 如果有 100 多台服务器,大部分都是在提供业务的服务器,如何升级呢?除了停机维护,现在有什么比较好的解决方案吗?

如果本身业务切分比较好,例如采用无状态的微服务等架构,可以通过前端负载均衡器进行灰度升级。如果应用做的不好,只有单台的这种,或者集中数据库,就比较麻烦了。

8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念?

你说的 FARM 应该是某硬件负载均衡设备的专有名词,应该是负载均衡组的概念。在 LVS 和 HAProxy 里面,负载均衡组的数量上没有硬限制,但实践中一般不会配置太多,因为这涉及到维护成本以及 HA 环境下主备切换时的开销。

9. 系统是 CentOS release 6.5 (Final), 系统没有自动回收内存,16G,我自己写了个 Shell 脚本,每次执行判断小于 1G 的时候回收内存

可以关注下 sysctl 中 swap 以及 swappiness 的一些配置

10. 请问如果是有很多 ECS/VPS,系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能,但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗? 

在我的这个演讲里面讲到了异构系统的批量管理方法,你可以参考下。

http://www.build.net/greatops/453250.html  。另外,你可以参考下 Ansible 或者 salt。

三、自动化运维相关,工程师思维?
1. 可以说下什么是自动化运维,如何才算服务器做了自动化运维?包括哪些?自动化发布,有问题可以回滚?

运维自动化是一个仁者见仁智者见智的概念。我的理解是,运维自动化要打通从代码开发完到正式上线的所有环节,包括版本构建、打通自动测试、自动化上线以及自动化监控。

在这个大命题下,可以根据自己工作环境和自动化水平的不同,选择一两个痛点开始进行自动化实践。最后形成完整体系。

2. 想请问一下自动化运维怎么做的?需要从那些方面考虑?我所考虑到的有实施运维,日常巡检维护,以及故障自动化处理,和提醒。除了这些请问还要注意那些方面?另外,随着 IT 技术的日新月异,涌现了很多新的应用,请问该如果有一个基本的路子来做运维,或者规律,流程来达到运维需求?例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步,更多的是上线后的运维。更多是想要一种思路,能列举大家遇到过的问题,以及问题如何处理? 

你的问题很好,但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值,但需要结合一些 DevOps 思想来进行适当的改造,融合两者的长处。从拥抱变化开始,以一种开放的态度来进行运维。但不变的一点是,以为业务创造价值为最终目标,这就是运维的目标。

3. 实现运维自动化,最主要就是配置管理、状态管理和变更管理,其中配置管理要如何来做,有什么好的方法分享下吗?

对配置管理,我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。

前者是一般意义上的 CMDB 的范畴,这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配;

对于后者,一方面是系统(例如版本控制系统的结合),一方面是流程(例如和变更管理挂钩)。在我们的实践中,这 2 个方面都有涉及。

4. 请问你主导运维自动化平台的功能设计和实施,是通过 Python 开发管理工具吗?另外,你们是重新开发,还是根据 Saltstack 之类的进行二次开发。

底层使用 SSH 协议建立服务器管理通道,上层使用 PHP 开发管理界面以及封装一些常用操作,比如密码修改、脚本下发和执行等。完全自主开发。

 
四、做好安全措施很重要,安全相关的问题1. 运维离不开安全,服务器的安全也很重要,书中有讲运维安全这块吗,如何把控安全这块?

书中有安全主题。安全是一个庞大的体系,书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题,比如社会工程和入侵检测,可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。

2. Web 安全监控有开源解决方案吗,能否做到在接入层就把一些可能的漏洞拦掉?Suricata?

Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具,你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试,不要出现误判。另外,建议对生产环境进行定期的安全扫描,例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。

 
五、Docker 很火热,在运维中结合使用?1. 在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪,存在什么问题,如何解决?

目前我们在调研 Docker 技术,只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式,要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外,我不是网易公司的,我目前在盛大游戏工作。 

2. Docker 化对运维影响深远吗?

Docker 化对运维有影响,它带来的影响包括:持续交付、微服务以及 DevOps 理念的冲击。作为运维,我们要拥抱这个变化,通过不断学习和实践来迎接这些挑战。

3. 为何国内没有一家成熟的 Docker 方案公布细节呢?

Docker 还是一个新生事物,各家使用的场景和模式有所不同,而且会有一些二次开发的管理系统和调度系统。

 
六、不是所有对比都会产生伤害,工程师想的只是最优方案1. 游戏服务器运维和网站服务器运维以及 APP 服务器运维,有哪些不同点和相同点?

这个问题很有代表性。不同点是,网站和 APP 运维接触的通用开源软件比较多,游戏运维接触的大部分都是自研的程序。

共同点是,都需要掌握操作系统知识、软件硬件以及网络知识,还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。

2. 作为运维人员,Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢?

作为高级编程语言,Python 有非常丰富的库,包括核心库和第三方库,很多时候不需要自己造轮子;

相比 Shell,它有更好的控制力、重试机制,比如对 Socket 设置超时等等。

3. CentOS 比起 Ubuntu 来说有啥优势?为什么服务器大多用 CentOS?

不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,稳定性以及熟悉程度最高。

选择某个发行版时,要考虑它的生态,比如上下游的支持,还有一点,就是运维人员招聘的方便程度,国内熟悉 CentOS 的稍多一些。

4. 想问下只有一台服务器,有多个应用,是用 LVS 做负载好还是 Nginx?差别大吗?

你说的后端应用是基于 HTTP 或者 HTTPS 的吗?如果是的话,并且吞吐量不大的情况下,使用 Nginx 即可;如果非 HTTP 或者 HTTPS 的 TCP 应用,建议使用 LVS;如果 HTTP 或者 HTTPS 吞吐量特别大的情况下,使用 LVS DR 模式。

七、You Need Backup,与备份相关的一些问题1. 1000 台机器规模,备份系统应该要做到什么程度?

1000 台服务器,要区分业务类型,如果类型单一,备份就比较好做。如果类型多,那么要考虑的地方包括:数据库更新的频率(全备+增量备份?还是只使用全备)、数据备份的大小、数据集中归档的要求。

2. 备份是怎么做的?上百 T 的图片、附件有什么高雅的备份方案?

在线备份这一块,可以考虑使用 erasure coding 算法,在增加一定可靠性的能力下,不至于导致备份存储的成本过高。同时要考虑离线备份,比如磁带。

八、路漫漫其修远兮,运维工程师的职业生涯1. 你觉得在未来,运维的核心会是什么,自动化,预判或是其他?

我觉得,未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程,把自己的能力灌输到机器上。当然,理想很丰满,现实很骨感。这需要我们的不懈努力。

2. 作为工作 4 年多的测试工作者,在运维方面也是有一定的涉猎,在公司维护自己的测试环境,有时候也需要一定运维功底,从 Windows Server 到 Linux,学习很多,也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾,后续工作也没时间去实践,目前使用的是 ng 负载,采用 Tomcat 部署方案,工作实在比较忙,很想在运维方面也有一定的提升!不知道从何入手好,求大神指教。

从你的描述来看,目前是兼职运维。我建议是否可以考虑,在搭建环境之外,多多研究下其中的原理,同时用自动化脚本维护这些环境呢。相信你也有一些编程经验,这些对于你后续实践运维也是有帮助的。另外,就是可以多看看别人总结的运维案例,少走一些弯路。

3. 运维技术挺杂的,如何看待这种杂?给人感觉好像什么都会点,对于工作 5-6 年的运维来说,有什么好的学习建议?

如你所说,运维技术要求范围确实蛮广的。我觉得,对于工作了一定时间的运维同学来说,可以考虑的方向有以下几个:
DevOps 实践(加强自己的编程能力,系统学习一门高级编程语言,运维自动化)对自己的技术薄弱点重点学习,比如系统学习网络知识看一些比较好的运维技术书籍,学习别人的干货

4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制,我们这里将运维和 BI 结合在一起。扩展运维工具和架构,将已成熟的 BI 接入运维体系,解放业务专员的工作,常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里,运维从一层平台逐渐变成一种框架,有需要的场景都可以套用。技术一直在变,但最重要的不是技术,而是用技术提供服务的思想。
 
除了和 BI 结合,运维思维还可以和哪些相关业务场景结合,可以在新的方向上产生价值呢?

我很赞同你的想法和实践,“用技术提供服务的思想”。我个人认为,运维的终极目标可能是“没有运维工程师的”自运维,或者叫智能运维,是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然,实现这个目标还有很长的路要走。

5. Devops 对运维有那些改变,能简单说下嘛?

Devops 从概念提出到现在已经有一段比较长的时间了,总体来说,我认为它带来的变化是:持续交付能力需要打通研发、测试和部署运维的整个链路,它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外,对运维来说,就是要拥抱变化,以开放的态度进行协作。

6. 现在哪个版本的 Linux 使用最广泛,还有 Linux 运维,我们需要学习一些语言吗,比如 Python 之类,这样才能算是一个真正的好运维?

不要犹豫了,立即开始学习编程吧,不管 Perl 还是 Python,熟悉哪一种都行。在这里,我不对比 Perl 和 Python 的优缺点。坚持用自己的代码(加上别人的框架和库)来解决重复的运维问题,你会成长的更快。CentOS 用的比较多。

《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容,你可以先看看。如果感兴趣的话,立即开始吧。

7. 请问您写书,是怎么坚持写下来的?是把平时工作重点的问题,记录下来,每天写一点,再总结吗?写书有什么工具软件吗,还是只是用 Word 来写?能分享下写运维书籍的方法吗?

这个问题非常好,也是我想分享的。写书的素材依赖于平时的积累,建议大家平时多写写标准的文档,word 格式可以参考咱们这本书的编排。比较重要的 3 点是:
visio 图要保留下来,不能只存图片,因为可能还要调整排版有些故障现场,尽量记录详细,现象和分析过程、辅助的日志和抓包文件等,建议都保留下来脚本按照分类保存下来,以便查找

有关 Linux 运维最佳实践的问答内容至此结束,各位读者可以转到原帖浏览更多内容。
原文:运维技术干货 — 不仅是 Linux 运维最佳实践 。 查看全部
我们面对的是一个不断变化的世界,业务需求在变,技术架构在变,开源工具与商业系统异构部署,新工具和技术概念层出不穷,唯有一套科学的技术方法论才能应对这些变化。很多时候,我们在面对新的问题时,会束手无措。因此,在 OSC 第 132 期高手问答中,我们策划了“Linux 运维最佳实践”的主题,并邀请了@xufengnju(胥峰)作为高手嘉宾。

@xufengnju(胥峰),资深运维专家,有 10 年运维经验,在业界颇具威望和影响力。也是盛大游戏高级研究员,2006 年毕业于南京大学,2011 年加入盛大游戏,工作至今,曾参与盛大游戏多款大型端游和手游的上线运维,主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。

自动化运维在近几年一直都是很火热的话题,技术也一直在进步,因此对于技术人员来说,最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求,思想才是运维人员应该毕生修炼的目标!本次高手问答的高手嘉宾对运维服务体系有着深度的思考,因此问答中产生的内容也是十分有质量。

本文从多个角度整理了与运维相关的内容,包括工具的选择、运维中遇到的问题、自动化运维相关等等。
 
Q&A​
 
一、工欲善其事必先利其器,如何选择工具?
 
1. 对服务器安全和监控,可以推荐一些开源工具吗?监控好像也就 nagios, cacti, zabbix,还有其他可以推荐的吗?安全方面如何监控?


监控工具各有侧重点,zabbix 同时支持 snmp 和自己的 agent,也支持自定义模板,在大部分场景下都是不错的选择。

另外,不要把 zabbix 视为只能监控服务器信息,通过自定义模板,也可以监控业务层面的指标。安全监控分为主动检测,如 Tenable Nessus,以及 IDS、IPS。


2. Linux 运维中,服务器版本都用什么版本?CentOS 5 还是 CentOS 6、Ubuntu?为什么选择这个版本?有做哪些测试?


目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,主要是考虑到它的稳定性以及熟悉程度最高。


3. 对于使用缓存有什么推荐吗?一般就 Redis, Codis。还有那些比较好用的开源软件?


对于类似 session-id 这样的可以非持久存储的数据,可以考虑 memcached,使用一致性哈希算法分布式存储。


4. 做自动化发布,除了 Jenkins 持续集成工具,还有那些好用的工具呢?


目前我所知道的,一般都是 Hudson 或者 Jenkins,后者是前者分支出来的。这些工具都有丰富的插件,灵活使用这些插件是关键所在。


5. 问个 MySQL 问题,三个版本(MySQL(官方版本)、Percona Server 、MariaDB)您建议使用哪个版本,原因是?


我们团队一般使用的是官方版本。主要是考虑到支持和生态。


6. 服务器日志收集和分析有什么好工具推荐吗?ELK 貌似有点复杂,不太会用,有其他的推荐么?


ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本,但还是值得去研究和尝试的。


7. 书里有开源出一些工具和脚本吗,哪里可以下载到?


书上的脚本我正在整理,其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git  


8. 请问你们现在运维都是基于 Ansible 吗?我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火,还没实践用过,请问这个用起来差别大吗?


各种不同的批量管理工具各具特点,根据自己的熟悉程度和实际业务需要选择一个完全掌握即可
目前 IaaS 平台是自研的,基于 KVM


二、绝知此事要躬行,运维中遇到问题?
1. LVS 和 HAPROXY 后端服务器规模可以到什么程度,比如有多少个应用,多少台后端服务器?


这个取决于应用的类型,在实际的业务场景下,需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大,可以考虑 LVS 的 DR 模式。一般情况下,负载均衡器不太会成为瓶颈。


负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计?
通过开源的 Zabbix 模板或者自定义模板,这些都不难实现。
有没有相关的命令集进行统计,或者详细的统计实例?


针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术,建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm,netstat 等。


2. 对于涉及多个平台(Unix, Linux, Windows)的统一管理(认证,配置,服务)有什么好的解决方案或者思路么?


先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证,可以考虑,这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品,比如 Ansible 或者 Salt。目前我们用的自研系统,思路和 Ansible 类似。


3. 如何监控服务,业务运行状态监控你是怎么做的?


我们的监控系统是自研的,对游戏来说,很重要的一个业务指标是在线人数,它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。


4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本,业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台?


我们批量管理服务器的方式是 ssh,思路和 Ansible 类似。CMDB 提供基础数据的管理,是自研的。


5. 请问有使用过流量镜像吗?就是把线上的流量镜像一份,引到测试环境,用真实的用户数据测试,想了解下从 0 开始实施的过程。


关于流量镜像的原理,可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后,你应该可以自己写一套。我没有亲自实践过,你可以自己关注下 tcpcopy 这个项目。


6. CentOS 6 要如何做系统和网络优化?/etc/sysctl.conf 中的这个参数
net.ipv4.tcp_max_tw_buckets = 6000
要如何设置,是越多越好吗?设置成 16000?
net.ipv4.tcp_max_tw_buckets = 16000


对于系统优化来说,要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket,如系统中 timewait 状态较多,可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外,如果使用长连接对于减少该状态的连接数有效。


7. 如果有 100 多台服务器,大部分都是在提供业务的服务器,如何升级呢?除了停机维护,现在有什么比较好的解决方案吗?


如果本身业务切分比较好,例如采用无状态的微服务等架构,可以通过前端负载均衡器进行灰度升级。如果应用做的不好,只有单台的这种,或者集中数据库,就比较麻烦了。


8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念?


你说的 FARM 应该是某硬件负载均衡设备的专有名词,应该是负载均衡组的概念。在 LVS 和 HAProxy 里面,负载均衡组的数量上没有硬限制,但实践中一般不会配置太多,因为这涉及到维护成本以及 HA 环境下主备切换时的开销。


9. 系统是 CentOS release 6.5 (Final), 系统没有自动回收内存,16G,我自己写了个 Shell 脚本,每次执行判断小于 1G 的时候回收内存


可以关注下 sysctl 中 swap 以及 swappiness 的一些配置


10. 请问如果是有很多 ECS/VPS,系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能,但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗? 


在我的这个演讲里面讲到了异构系统的批量管理方法,你可以参考下。

http://www.build.net/greatops/453250.html  。另外,你可以参考下 Ansible 或者 salt。


三、自动化运维相关,工程师思维?

1. 可以说下什么是自动化运维,如何才算服务器做了自动化运维?包括哪些?自动化发布,有问题可以回滚?


运维自动化是一个仁者见仁智者见智的概念。我的理解是,运维自动化要打通从代码开发完到正式上线的所有环节,包括版本构建、打通自动测试、自动化上线以及自动化监控。

在这个大命题下,可以根据自己工作环境和自动化水平的不同,选择一两个痛点开始进行自动化实践。最后形成完整体系。


2. 想请问一下自动化运维怎么做的?需要从那些方面考虑?我所考虑到的有实施运维,日常巡检维护,以及故障自动化处理,和提醒。除了这些请问还要注意那些方面?另外,随着 IT 技术的日新月异,涌现了很多新的应用,请问该如果有一个基本的路子来做运维,或者规律,流程来达到运维需求?例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步,更多的是上线后的运维。更多是想要一种思路,能列举大家遇到过的问题,以及问题如何处理? 


你的问题很好,但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值,但需要结合一些 DevOps 思想来进行适当的改造,融合两者的长处。从拥抱变化开始,以一种开放的态度来进行运维。但不变的一点是,以为业务创造价值为最终目标,这就是运维的目标。


3. 实现运维自动化,最主要就是配置管理、状态管理和变更管理,其中配置管理要如何来做,有什么好的方法分享下吗?


对配置管理,我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。

前者是一般意义上的 CMDB 的范畴,这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配;

对于后者,一方面是系统(例如版本控制系统的结合),一方面是流程(例如和变更管理挂钩)。在我们的实践中,这 2 个方面都有涉及。


4. 请问你主导运维自动化平台的功能设计和实施,是通过 Python 开发管理工具吗?另外,你们是重新开发,还是根据 Saltstack 之类的进行二次开发。


底层使用 SSH 协议建立服务器管理通道,上层使用 PHP 开发管理界面以及封装一些常用操作,比如密码修改、脚本下发和执行等。完全自主开发。


 
四、做好安全措施很重要,安全相关的问题
1. 运维离不开安全,服务器的安全也很重要,书中有讲运维安全这块吗,如何把控安全这块?


书中有安全主题。安全是一个庞大的体系,书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题,比如社会工程和入侵检测,可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。


2. Web 安全监控有开源解决方案吗,能否做到在接入层就把一些可能的漏洞拦掉?Suricata?


Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具,你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试,不要出现误判。另外,建议对生产环境进行定期的安全扫描,例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。


 
五、Docker 很火热,在运维中结合使用?
1. 在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪,存在什么问题,如何解决?


目前我们在调研 Docker 技术,只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式,要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外,我不是网易公司的,我目前在盛大游戏工作。 


2. Docker 化对运维影响深远吗?


Docker 化对运维有影响,它带来的影响包括:持续交付、微服务以及 DevOps 理念的冲击。作为运维,我们要拥抱这个变化,通过不断学习和实践来迎接这些挑战。


3. 为何国内没有一家成熟的 Docker 方案公布细节呢?


Docker 还是一个新生事物,各家使用的场景和模式有所不同,而且会有一些二次开发的管理系统和调度系统。


 
六、不是所有对比都会产生伤害,工程师想的只是最优方案
1. 游戏服务器运维和网站服务器运维以及 APP 服务器运维,有哪些不同点和相同点?


这个问题很有代表性。不同点是,网站和 APP 运维接触的通用开源软件比较多,游戏运维接触的大部分都是自研的程序。

共同点是,都需要掌握操作系统知识、软件硬件以及网络知识,还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。


2. 作为运维人员,Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢?


作为高级编程语言,Python 有非常丰富的库,包括核心库和第三方库,很多时候不需要自己造轮子;

相比 Shell,它有更好的控制力、重试机制,比如对 Socket 设置超时等等。


3. CentOS 比起 Ubuntu 来说有啥优势?为什么服务器大多用 CentOS?


不同 Linux 分支各有特点,比如 Ubuntu 新版本发布较快,如果追求内核版本升级速度的话,可以考虑。CentOS 一直是我们的主要 Linux 发行版,稳定性以及熟悉程度最高。

选择某个发行版时,要考虑它的生态,比如上下游的支持,还有一点,就是运维人员招聘的方便程度,国内熟悉 CentOS 的稍多一些。


4. 想问下只有一台服务器,有多个应用,是用 LVS 做负载好还是 Nginx?差别大吗?


你说的后端应用是基于 HTTP 或者 HTTPS 的吗?如果是的话,并且吞吐量不大的情况下,使用 Nginx 即可;如果非 HTTP 或者 HTTPS 的 TCP 应用,建议使用 LVS;如果 HTTP 或者 HTTPS 吞吐量特别大的情况下,使用 LVS DR 模式。


七、You Need Backup,与备份相关的一些问题
1. 1000 台机器规模,备份系统应该要做到什么程度?


1000 台服务器,要区分业务类型,如果类型单一,备份就比较好做。如果类型多,那么要考虑的地方包括:数据库更新的频率(全备+增量备份?还是只使用全备)、数据备份的大小、数据集中归档的要求。


2. 备份是怎么做的?上百 T 的图片、附件有什么高雅的备份方案?


在线备份这一块,可以考虑使用 erasure coding 算法,在增加一定可靠性的能力下,不至于导致备份存储的成本过高。同时要考虑离线备份,比如磁带。


八、路漫漫其修远兮,运维工程师的职业生涯
1. 你觉得在未来,运维的核心会是什么,自动化,预判或是其他?


我觉得,未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程,把自己的能力灌输到机器上。当然,理想很丰满,现实很骨感。这需要我们的不懈努力。


2. 作为工作 4 年多的测试工作者,在运维方面也是有一定的涉猎,在公司维护自己的测试环境,有时候也需要一定运维功底,从 Windows Server 到 Linux,学习很多,也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾,后续工作也没时间去实践,目前使用的是 ng 负载,采用 Tomcat 部署方案,工作实在比较忙,很想在运维方面也有一定的提升!不知道从何入手好,求大神指教。


从你的描述来看,目前是兼职运维。我建议是否可以考虑,在搭建环境之外,多多研究下其中的原理,同时用自动化脚本维护这些环境呢。相信你也有一些编程经验,这些对于你后续实践运维也是有帮助的。另外,就是可以多看看别人总结的运维案例,少走一些弯路。


3. 运维技术挺杂的,如何看待这种杂?给人感觉好像什么都会点,对于工作 5-6 年的运维来说,有什么好的学习建议?


如你所说,运维技术要求范围确实蛮广的。我觉得,对于工作了一定时间的运维同学来说,可以考虑的方向有以下几个:

  • DevOps 实践(加强自己的编程能力,系统学习一门高级编程语言,运维自动化)
  • 对自己的技术薄弱点重点学习,比如系统学习网络知识
  • 看一些比较好的运维技术书籍,学习别人的干货


4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制,我们这里将运维和 BI 结合在一起。扩展运维工具和架构,将已成熟的 BI 接入运维体系,解放业务专员的工作,常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里,运维从一层平台逐渐变成一种框架,有需要的场景都可以套用。技术一直在变,但最重要的不是技术,而是用技术提供服务的思想。
 
除了和 BI 结合,运维思维还可以和哪些相关业务场景结合,可以在新的方向上产生价值呢?


我很赞同你的想法和实践,“用技术提供服务的思想”。我个人认为,运维的终极目标可能是“没有运维工程师的”自运维,或者叫智能运维,是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然,实现这个目标还有很长的路要走。


5. Devops 对运维有那些改变,能简单说下嘛?


Devops 从概念提出到现在已经有一段比较长的时间了,总体来说,我认为它带来的变化是:持续交付能力需要打通研发、测试和部署运维的整个链路,它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外,对运维来说,就是要拥抱变化,以开放的态度进行协作。


6. 现在哪个版本的 Linux 使用最广泛,还有 Linux 运维,我们需要学习一些语言吗,比如 Python 之类,这样才能算是一个真正的好运维?


不要犹豫了,立即开始学习编程吧,不管 Perl 还是 Python,熟悉哪一种都行。在这里,我不对比 Perl 和 Python 的优缺点。坚持用自己的代码(加上别人的框架和库)来解决重复的运维问题,你会成长的更快。CentOS 用的比较多。

《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容,你可以先看看。如果感兴趣的话,立即开始吧。


7. 请问您写书,是怎么坚持写下来的?是把平时工作重点的问题,记录下来,每天写一点,再总结吗?写书有什么工具软件吗,还是只是用 Word 来写?能分享下写运维书籍的方法吗?


这个问题非常好,也是我想分享的。写书的素材依赖于平时的积累,建议大家平时多写写标准的文档,word 格式可以参考咱们这本书的编排。比较重要的 3 点是:

  • visio 图要保留下来,不能只存图片,因为可能还要调整排版
  • 有些故障现场,尽量记录详细,现象和分析过程、辅助的日志和抓包文件等,建议都保留下来
  • 脚本按照分类保存下来,以便查找


有关 Linux 运维最佳实践的问答内容至此结束,各位读者可以转到原帖浏览更多内容。
原文:运维技术干货 — 不仅是 Linux 运维最佳实践 。

基于CMDB与SALTSTACK的运维自动化之路

运维技术OS小编 发表了文章 • 0 个评论 • 454 次浏览 • 2017-06-29 01:10 • 来自相关话题

作者介绍​

张延礼,现苏州蜗牛高级运维经理,就职于腾讯多年,熟悉基础架构运维及业务运维,在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现,运维支撑体系规划和执行团队管理等方面具有丰富经验。

正文

本文基于蜗牛从零开始建设运维自动化的一些实践,总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。

一、自动化体系规划

1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块




服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等,处在运维工作的最高层;技术决策主要是为实现管理目标去制定总体方案,实施路径;技术执行则是落地的最后一环,这一环工作往往呈现零散、杂乱、重复、频繁变更的特点,承接的需求量最多,但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题:将大量重复低价值含量的人力实施变成自动化执行,最大化地降低人力依赖,提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维,个人认为首要的是要有建设思路与方法论,以下供参考:









3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化起步的阶段,建议是组建运维开发团队,从整体规划,基于ESB思想,分层建设,让支撑平台从业务逻辑中解耦。比如就业务运维而言,整个操作工作面无非就是对业务运营环境的各种操作、配置,以及对业务应用程序的管理,简单来说就是OS层和应用层。




要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西还需要与应用的研发人员规范相关接口,这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维各类业务流程的纯线上自动化。
 

二、自动化实施路线

业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化;如无统一的标准及规范,运维支撑工作将异常混乱,自动化也难以实施。因此自动化有一个基础:标准化,标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控,流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求,基于以上自动化体系建设思路,前期规划的建设线路如下




1、信息的标准化管理:CMDB

在运维工作中,信息的管理往往是难点,运维侧涉及的信息太多,且也与其他职能部门多点关联,信息流转于整个流程的多个职能部门、多个环节




中小型企业中,手工线下记录的方式居多,线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题,经常出现:
线下表格有,实际位置找不到,或信息不对称不清楚设备状态,不清楚哪个业务在使用一个部门做了变更,其他部门不知情变更一条上联链路,无法及时判断影响范围及程度

根本问题及给运维工作带来的痛点如下




因此我们引入一套基于ITIL体系的配置管理数据库CMDB,旨在为运维团队建立线下与线上一致性的基础信息库,作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化,系统主要功能模块如下图:




系统本身主要功能可归结为2个方面:基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user,除此之外,对于API-user,此系统提供了一整套接口界面与其它任何需要信息的系统进行对接,这也是设计初衷,将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统,而运维需要做的就是维护CMDB本身基础数据的完整性、准确性,CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更,处处同步。




如上为CMDB业务管理模型,作为运维统一信息库,与其他系统平台数据互通,深度整合后实现信息的管理、维护、展现全部线上化。

产品设计过程中涉及的几个关键点:
CI及属性需要贴合实际环境,同时考虑长期的运维规划管理的不仅是CI及其属性,还有CI之间的关系,状态流转机制等等充分考虑扩展性及灵活性,如引入自定义属性来满足未来或暂时不可预见的需求
 
2、通用型作业平台
对于运维执行工作而言,绝大部分的实现均是对运营环境的各类操作,在业务体量上去后,需求导致的运维操作密集度不断增加,如公司内某款游戏业务部署在近上百台主机上,一次维护要对此上百台逐一进行相应的操作,如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是:




我们决定做一个通用型运维操作平台来解决这些问题,为运维人员提供一个可以批量控制和操作大规模主机的通道,运维人员在web界面中可以定制所有的运维操作,指定执行的对象,通过平台下发执行并返回结果,例如 批量shell脚本执行,大量文件传输,发布变更,数据备份等等各类场景。对于产品设计上遵循以下几点:




技术实现上,基于公司运维环境,我们对后端系统有如下需求:
良好的scale-up/scale-out,灵活扩展,支持复杂网络结构轻量级、高效的后端通信机制,成千上万的管理规模跨平台,支持windows、unix-like多平台,无需重复开发

运维门槛低,使用运维熟悉的命令操作及脚本语言即可完成一切作业,无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统;前端系统涉及到的交互逻辑及业务逻辑自主研发,自研部分需实现的逻辑如下:
全网统一的一套基于web的用户界面,将所有操作逻辑通过web层来调用salt-api,web前端提供与直接登录机器操作一样的灵活性和自由度,运维人员在web上完成所有操作。对运维操作进行建模,将其分解为几大原子操作类型,一切复杂的序列化操作逻辑可通过原子的自由组合来实现,给用户提供自由灵活的操作方式基于以上逻辑,再给salt加一层应用接口,便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。




后端salt的逻辑这里不赘述,由于实际网络环境的特殊性,我们采用了二层架构,即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通,可以非常灵活的适应各类业务,各种场景。

如运维人员可以在界面定义好一个版本发布作业:xx业务发布,分解整个发布流程中到每一步骤,并写脚本或调用外部接口来实现具体的操作,最终线上操作只需在页面点击开始执行就可:




当然用户自定义作业可以复用,通过传参的方式实现实例化,避免必要每次发布都建作业。
 
3、建设过程中的问题总结
 
做好产品设计及架构设计
充分解析运维内部需求,各具体平台或产品业务区分明确,产品定位一定要清晰,不要想着让微波炉具备电冰箱的功能,自动化整个体系不是一个产品能解决所有问题,需要自顶向下分层设计,产品之间相互解耦且又对外提供接口,能方便的整合与被整合。

组建运维内部开发团队
运维自动化的建设,最好是组建运维内部团队来进行开发,直接丢给业务研发部门往往做出来的东西不是运维侧想要的,因其不易理解运维侧的需求场景、痛点,操作方式等等;如实在没有运维开发团队,那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽,绝大多数研发人员往往只考虑产品功能实现,而很少关注可维护性设计,导致业务给运维人员带来很大的无价值工作量,更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的,运维侧需形成可维护性标准规范,推动业务开发遵循将非常利于运维自动化的建设。

文章来源:微信订阅号"运维帮"
地址:http://dwz.cn/6c2Yqz  查看全部


作者介绍​


张延礼,现苏州蜗牛高级运维经理,就职于腾讯多年,熟悉基础架构运维及业务运维,在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现,运维支撑体系规划和执行团队管理等方面具有丰富经验。


正文


本文基于蜗牛从零开始建设运维自动化的一些实践,总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。


一、自动化体系规划


1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块
sank.png

服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等,处在运维工作的最高层;技术决策主要是为实现管理目标去制定总体方案,实施路径;技术执行则是落地的最后一环,这一环工作往往呈现零散、杂乱、重复、频繁变更的特点,承接的需求量最多,但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题:将大量重复低价值含量的人力实施变成自动化执行,最大化地降低人力依赖,提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维,个人认为首要的是要有建设思路与方法论,以下供参考:
gui1.png

gui2.png


3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化起步的阶段,建议是组建运维开发团队,从整体规划,基于ESB思想,分层建设,让支撑平台从业务逻辑中解耦。比如就业务运维而言,整个操作工作面无非就是对业务运营环境的各种操作、配置,以及对业务应用程序的管理,简单来说就是OS层和应用层。
osapp.png

要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西还需要与应用的研发人员规范相关接口,这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维各类业务流程的纯线上自动化。
 


二、自动化实施路线


业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化;如无统一的标准及规范,运维支撑工作将异常混乱,自动化也难以实施。因此自动化有一个基础:标准化,标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控,流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求,基于以上自动化体系建设思路,前期规划的建设线路如下
auto.png

1、信息的标准化管理:CMDB

在运维工作中,信息的管理往往是难点,运维侧涉及的信息太多,且也与其他职能部门多点关联,信息流转于整个流程的多个职能部门、多个环节
cmdb.png

中小型企业中,手工线下记录的方式居多,线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题,经常出现:
  • 线下表格有,实际位置找不到,或信息不对称
  • 不清楚设备状态,不清楚哪个业务在使用
  • 一个部门做了变更,其他部门不知情
  • 变更一条上联链路,无法及时判断影响范围及程度


根本问题及给运维工作带来的痛点如下
td.png

因此我们引入一套基于ITIL体系的配置管理数据库CMDB,旨在为运维团队建立线下与线上一致性的基础信息库,作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化,系统主要功能模块如下图:
cmdbmodle.png

系统本身主要功能可归结为2个方面:基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user,除此之外,对于API-user,此系统提供了一整套接口界面与其它任何需要信息的系统进行对接,这也是设计初衷,将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统,而运维需要做的就是维护CMDB本身基础数据的完整性、准确性,CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更,处处同步。
list.png

如上为CMDB业务管理模型,作为运维统一信息库,与其他系统平台数据互通,深度整合后实现信息的管理、维护、展现全部线上化。

产品设计过程中涉及的几个关键点:
  • CI及属性需要贴合实际环境,同时考虑长期的运维规划
  • 管理的不仅是CI及其属性,还有CI之间的关系,状态流转机制等等
  • 充分考虑扩展性及灵活性,如引入自定义属性来满足未来或暂时不可预见的需求

 
2、通用型作业平台
对于运维执行工作而言,绝大部分的实现均是对运营环境的各类操作,在业务体量上去后,需求导致的运维操作密集度不断增加,如公司内某款游戏业务部署在近上百台主机上,一次维护要对此上百台逐一进行相应的操作,如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是:
problem.png

我们决定做一个通用型运维操作平台来解决这些问题,为运维人员提供一个可以批量控制和操作大规模主机的通道,运维人员在web界面中可以定制所有的运维操作,指定执行的对象,通过平台下发执行并返回结果,例如 批量shell脚本执行,大量文件传输,发布变更,数据备份等等各类场景。对于产品设计上遵循以下几点:
ci.png

技术实现上,基于公司运维环境,我们对后端系统有如下需求:
  • 良好的scale-up/scale-out,灵活扩展,支持复杂网络结构
  • 轻量级、高效的后端通信机制,成千上万的管理规模
  • 跨平台,支持windows、unix-like多平台,无需重复开发


运维门槛低,使用运维熟悉的命令操作及脚本语言即可完成一切作业,无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统;前端系统涉及到的交互逻辑及业务逻辑自主研发,自研部分需实现的逻辑如下:
  • 全网统一的一套基于web的用户界面,将所有操作逻辑通过web层来调用salt-api,web前端提供与直接登录机器操作一样的灵活性和自由度,运维人员在web上完成所有操作。
  • 对运维操作进行建模,将其分解为几大原子操作类型,一切复杂的序列化操作逻辑可通过原子的自由组合来实现,给用户提供自由灵活的操作方式
  • 基于以上逻辑,再给salt加一层应用接口,便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。

archflow.png

后端salt的逻辑这里不赘述,由于实际网络环境的特殊性,我们采用了二层架构,即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通,可以非常灵活的适应各类业务,各种场景。

如运维人员可以在界面定义好一个版本发布作业:xx业务发布,分解整个发布流程中到每一步骤,并写脚本或调用外部接口来实现具体的操作,最终线上操作只需在页面点击开始执行就可:
scripts.png

当然用户自定义作业可以复用,通过传参的方式实现实例化,避免必要每次发布都建作业。
 
3、建设过程中的问题总结
 
做好产品设计及架构设计
充分解析运维内部需求,各具体平台或产品业务区分明确,产品定位一定要清晰,不要想着让微波炉具备电冰箱的功能,自动化整个体系不是一个产品能解决所有问题,需要自顶向下分层设计,产品之间相互解耦且又对外提供接口,能方便的整合与被整合。

组建运维内部开发团队
运维自动化的建设,最好是组建运维内部团队来进行开发,直接丢给业务研发部门往往做出来的东西不是运维侧想要的,因其不易理解运维侧的需求场景、痛点,操作方式等等;如实在没有运维开发团队,那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽,绝大多数研发人员往往只考虑产品功能实现,而很少关注可维护性设计,导致业务给运维人员带来很大的无价值工作量,更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的,运维侧需形成可维护性标准规范,推动业务开发遵循将非常利于运维自动化的建设。


文章来源:微信订阅号"运维帮"
地址:http://dwz.cn/6c2Yqz 


一个成熟的自动化运维系统应具备哪些功能?

运维技术Nock 发表了文章 • 0 个评论 • 548 次浏览 • 2017-04-15 16:47 • 来自相关话题

结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎 查看全部
结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎

部署管理工具:Chef vs Puppet vs Ansible vs SaltStack vs Fabric

运维技术OS小编 发表了文章 • 0 个评论 • 1901 次浏览 • 2016-12-28 16:09 • 来自相关话题

Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?

今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。

1、Ansible





Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 




这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
基于SSH,因此不需要在远程节点上安装任何代理。使用YAML语法易于学习。Playbook结构简单,结构清晰。具有可变注册功能,可使任务为以后的任务注册变量比一些其他工具更加精简的代码库
 缺点:
不如基于其他编程语言的工具强大。它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它即使是基本功能,也需要变量注册,这使得更简单的任务更复杂内省很差。 很难看到playbooks里的变量的价值输入,输出和配置文件的格式之间不一致性能和速度有待加强
Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 

2、chef





Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 




Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点:
丰富的模块和配置配方集合。代码驱动的方法为您的配置提供更多的控制和灵活性。围绕Git提供强大的版本控制功能。“Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。
 
缺点:
如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。这不是一个简单的工具,这可能导致大的代码库和复杂的环境。不支持推送功能。
Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 

3、Fabric





Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。比这个领域的其他工具更简单,更容易部署与SSH进行广泛集成,实现基于脚本的精简
 
缺点:
Fabric是单点故障设置(通常是您运行部署的机器)使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。
Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 

4、Puppet





Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。





Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
通过Puppet Labs建立良好的支持社区。它有最成熟的接口,几乎在每个操作系统上运行。简单的安装和初始设置。在这个空间中最完整的Web UI。强大的报告功能。
 
缺点:
对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。与代码驱动方法相比,模型驱动方法意味着更少的控制。
Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 

5、SaltStack





SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点:
一旦您完成设置阶段,即可轻松组织和使用。他们的DSL是功能丰富,并不是逻辑和状态所必需的。输入,输出和配置非常一致 - 所有YAML。内省是非常好的。 很容易看到Salt内发生了什么。强大的社区。在主模型中具有minions和层级层次的高可扩展性和弹性。
 
缺点:
很难设置和挑选新用户。文档在介绍层面很难理解。Web UI比空间中的其他工具的Web UI更新,更不完整。对非Linux操作系统不是很大的支持。
SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 

Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/  查看全部
chef.puppet_.ansibe_.saltstack_.fabric_.png


Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?


今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。


1、Ansible


ansible.png

Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 
AnsibleDashboard.jpg

这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
  • 基于SSH,因此不需要在远程节点上安装任何代理。
  • 使用YAML语法易于学习。
  • Playbook结构简单,结构清晰。
  • 具有可变注册功能,可使任务为以后的任务注册变量
  • 比一些其他工具更加精简的代码库

 缺点
  • 不如基于其他编程语言的工具强大。
  • 它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它
  • 即使是基本功能,也需要变量注册,这使得更简单的任务更复杂
  • 内省很差。 很难看到playbooks里的变量的价值
  • 输入,输出和配置文件的格式之间不一致
  • 性能和速度有待加强

Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 


2、chef


chef.png

Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 
ChefBoard.jpg

Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点
  • 丰富的模块和配置配方集合。
  • 代码驱动的方法为您的配置提供更多的控制和灵活性。
  • 围绕Git提供强大的版本控制功能。
  • “Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。

 
缺点:
  • 如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。
  • 这不是一个简单的工具,这可能导致大的代码库和复杂的环境。
  • 不支持推送功能。

Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 


3、Fabric


fabric.png

Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
  • 擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。
  • 比这个领域的其他工具更简单,更容易部署
  • 与SSH进行广泛集成,实现基于脚本的精简

 
缺点:
  • Fabric是单点故障设置(通常是您运行部署的机器)
  • 使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具
  • 虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。

Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 


4、Puppet


Puppet.png

Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。

PuppetBoard.jpg

Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
  • 通过Puppet Labs建立良好的支持社区。
  • 它有最成熟的接口,几乎在每个操作系统上运行。
  • 简单的安装和初始设置。
  • 在这个空间中最完整的Web UI。
  • 强大的报告功能。

 
缺点:
  • 对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。
  • 支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。
  • 由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。
  • 与代码驱动方法相比,模型驱动方法意味着更少的控制。

Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 


5、SaltStack


saltstack.png

SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点
  • 一旦您完成设置阶段,即可轻松组织和使用。
  • 他们的DSL是功能丰富,并不是逻辑和状态所必需的。
  • 输入,输出和配置非常一致 - 所有YAML。
  • 内省是非常好的。 很容易看到Salt内发生了什么。
  • 强大的社区。
  • 在主模型中具有minions和层级层次的高可扩展性和弹性。

 
缺点:
  • 很难设置和挑选新用户。
  • 文档在介绍层面很难理解。
  • Web UI比空间中的其他工具的Web UI更新,更不完整。
  • 对非Linux操作系统不是很大的支持。

SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 


Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack


使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/ 

高效DevOps的10项实践「翻译」

互联网资讯小白菜 发表了文章 • 0 个评论 • 640 次浏览 • 2016-09-09 15:49 • 来自相关话题

采用这些DevOps实践可以实现高效协作,平滑运营,更整洁的代码等目标。

DevOps已经成为了我们行业最热门的流行语之一。然而出人意料的是,在更紧密的愿景和开发团队和运营团队更有效的协作之上,很少有共识DevOps到底意味着什么。不同组织对DevOps有着不同的定义,其实DevOps有个新兴的最佳实践核心,其更进一步的目标是高度协作以生产更好的软件。在这里我考验了这些实践。但是坦白说,我并不只从开发人员角度来观察这些实践。

我按优先级从高到低列出了这些实践条目,后面的实践往往依赖于前面的实践。

实践1:利益相关者的积极参与

DevOps的根本原则是开发人员,运营人员以及支持人员必须定期紧密的工作在一起。言外之意是他们必须互相视对方为重要的利益相关人,并积极争取一起工作。敏捷社区中一个普遍的实践是“现场客户”。这个实践出自于极限编程,它鼓励开发人员应该与业务人员紧密合作。规范的敏捷团队将该实践更进一步,即利益相关的积极参与,这意味着开发人员应该与所有利益相关者一起紧密工作,包括运营人员及支持人员,而不仅仅是业务人员。这是双向的:运营人员和支持人员也必须愿意和开发人员紧密工作。
 

实践2:自动化测试

敏捷软件开发人员被称为质量感染者,这是因为他们关注于编写高质量的代码,渴望测试越早开始越好。结果,自动化的回归测试是敏捷团队普遍采用的实践。该实践有时又被扩展为测试先行的方式,比如测试驱动开发(TDD),以及行为驱动开发(BDD)。由于敏捷团队经常一天多次运行他们的自动化测试集,并且能够马上修复发现的问题,所以他们比普通团队能达到更高的质量。对于运营人员而言,在同意一个解决方案发布到产品环境前,坚持足够的质量审查,这是件好事情。
 

实践3:集成配置管理

要实现以集成的方式来进行配置管理(CM),开发团队不仅要习惯于在解决方案层级应用CM,还需要考虑自身的解决方案与组织的其余基础设施之间的 产品环境配置问题。对于一些开发人员而言这是个不小的转变,因为他们往往习惯于只考虑当前他们工作的解决方案的CM。在DevOps环境中,开发人员需要拥有企业级视角,在更高的层次看待问题。他们的解决方案如何能在产品环境结合其它资源带来优势?其它资源是否能支持被开发的解决方案?言外之意是开发团队需要了解及管理他们产品的所有范围的依赖。集成配置管理也使得运营人员了解新的发布潜在的影响,从而更容易决定进行发布的时间。
 

实践4:综合变更管理

从IT的角度来看,变更管理是一门确保IT基础设施的演化能对整体组织的支持成功及有意义的艺术。但是对于项目-团队层级则颇具挑战。这是因为非常多的技术,甚至相似技术的多个版本会被使用在单个解决方案的开发过程中。由于DevOps引入了与运营有关的企业级问题,综合变更管理策略会变得越来越复杂,因为需要考虑大量的解决方案能够在产品环境中同时运行和交互。为了实现综合变更管理,开发团队必须与运营团队紧密合作,来从组织层面了解任何技术的改变带来的影响。该方式依赖于前面的实践-利益相关者的积极参与,集成配置管理及自动化测试。
 

实践5:持续集成

持续集成(CI)是构建及验证项目的规范,当有代码更新被迁入到版本控制系统时,会进行自动化的回归测试及代码分析。CI是与DevOps相关的性感的敏捷开发实践之一(至少从开发人员角度来说是如此)。CI确保开发人员以较小的,可以对代码缺陷立即反馈的常规步骤来开发一个高质量的可以工作的解决方案。
 

实践6:集成部署计划

从开发团队角度而言,部署计划总是需要与该组织的运营人员交互。有些情况下,与运营人员接口的专家被特称为发布工程师。经验丰富的团队将使开发,运营及支持团队这些利益相关者一起持续的制定部署计划。当你采用了DevOps策略,你会很快意识到需要一种跨团队的方式来完成发布计划,因为需要运营人员与整个开发团队一起工作。对于运营人员来说这不是什么新鲜事,但是对于只习惯工作于孤立环境的开发团队来说却很惊奇。如果你的团队还没有这样做,你需要开始从组织层面来考虑部署时间表。更远一步,为了支持持续部署,发布工程师需要增加发布次数,因为敏捷团队已经可以持续及一致地达到发布的质量要求。
 

实践7:持续部署

持续部署是持续集成实践的扩展。对于持续部署,当集成在一个沙盒中成功完成时,变更会被自动升迁到另一个沙盒中,集成会自动的在这里进行。自动升迁一直持续,直到有人验证了所有的变更,特别是开发向运营的过渡期。

持续部署使得开发团队减少了新功能从被验证到部署到产品环境的时间,使得业务更具响应性。然而,持续部署增加了运营风险,因为如果开发团队没严格遵守规范,会增加缺陷被引入到产品环境的潜在风险。在企业级环境中成功的执行持续部署要求实现前面介绍的所有实践。
 

实践8:产品支持

企业级环境中,大多数的应用程序开发团队工作在已经存在于产品环境的解决方案的新的功能上。他们不仅工作于该新功能,还有解决严重的产品问题的职责。开发团队往往被称为产品的“第3级支持”,因为他们是解决棘手的产品问题的第三个(也是最后一个)团队。尽管做第三级产品支持的需要是普遍的,但是看板和规范敏捷交付(Disciplined Agile Delivery, DAD)则是例外,很多敏捷方法只解决传递这些影响。该实践的一个重要的副作用是给予了开发者发生在产品中的此类问题的鉴别能力,提供给他们一种学习机会,从而在设计解决方案时就考虑到相应的问题。
 

实践9:应用监控

正如其名称所示,这是一个运营实践,监控已经发布到产品的环境的正在运行的解决方案和应用程序。技术基础设施平台(比如操作系统),应用程序服务器,以及通讯服务通常提供监控功能,可以工作于一些监控工具(比如微软管理终端,IBM Tivoli 监控, 以及jManage)。然而,为了监控特定应用程序的功能,比如只给特定用户使用的用户界面,仪表化该信息需要与你组织的监控基础设施兼容,这需要构建到应用程序中。开发团队需要知道该运营要求,或者,更好的方式是可以访问一个框架,该框架可以直接提供相应的仪表化。
 

实践10:自动化的仪表盘

使用自动化仪表盘的实践是IT领域的商业智能(business intelligence, BI)。该实践分为两个方面,开发智能以及运营智能。开发智能需要使用开发工具来仪表化产生的指标。例如,你的配置管理(CM)工具已经记录了谁以及什么时候迁入代码。持续集成工具可能同样记录了构建发生的时间,运行了多少个测试,测试运行的时间,构建是成功还是失败,运行成功的测试数量等。这些原始数据会被分析并显示在一个自动化的仪表盘中。运营智能是之前讨论过的应用程序监控的一个方面。使用了自动化仪表盘,组织的整体指标开销将被显著降低(但是不能完全淘汰,因为不是所有的事情都能被自动化)。自动化仪表盘提供了实时的对组织的管理团队的洞察。
 

DevOps与文化息息相关

在讨论了这些苛刻的支持DevOps的实践之后,我需要强调主要的限制成功的因素是能否建立一个贯穿整个IT组织的相互协作的相互尊敬的文化。我的经验是,当决定采用高效的DevOps策略时,人及他们相互工作的方式是成功的主要决定因素。不幸的是,在组织中带来文化变迁比采用一些新的实践要难得多。

原文地址:http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363?pgno=1
作者:Scott W. Ambler
翻译:黄博文@无敌北瓜  查看全部
采用这些DevOps实践可以实现高效协作,平滑运营,更整洁的代码等目标。

DevOps已经成为了我们行业最热门的流行语之一。然而出人意料的是,在更紧密的愿景和开发团队和运营团队更有效的协作之上,很少有共识DevOps到底意味着什么。不同组织对DevOps有着不同的定义,其实DevOps有个新兴的最佳实践核心,其更进一步的目标是高度协作以生产更好的软件。在这里我考验了这些实践。但是坦白说,我并不只从开发人员角度来观察这些实践。

我按优先级从高到低列出了这些实践条目,后面的实践往往依赖于前面的实践。


实践1:利益相关者的积极参与


DevOps的根本原则是开发人员,运营人员以及支持人员必须定期紧密的工作在一起。言外之意是他们必须互相视对方为重要的利益相关人,并积极争取一起工作。敏捷社区中一个普遍的实践是“现场客户”。这个实践出自于极限编程,它鼓励开发人员应该与业务人员紧密合作。规范的敏捷团队将该实践更进一步,即利益相关的积极参与,这意味着开发人员应该与所有利益相关者一起紧密工作,包括运营人员及支持人员,而不仅仅是业务人员。这是双向的:运营人员和支持人员也必须愿意和开发人员紧密工作。
 


实践2:自动化测试


敏捷软件开发人员被称为质量感染者,这是因为他们关注于编写高质量的代码,渴望测试越早开始越好。结果,自动化的回归测试是敏捷团队普遍采用的实践。该实践有时又被扩展为测试先行的方式,比如测试驱动开发(TDD),以及行为驱动开发(BDD)。由于敏捷团队经常一天多次运行他们的自动化测试集,并且能够马上修复发现的问题,所以他们比普通团队能达到更高的质量。对于运营人员而言,在同意一个解决方案发布到产品环境前,坚持足够的质量审查,这是件好事情。
 


实践3:集成配置管理


要实现以集成的方式来进行配置管理(CM),开发团队不仅要习惯于在解决方案层级应用CM,还需要考虑自身的解决方案与组织的其余基础设施之间的 产品环境配置问题。对于一些开发人员而言这是个不小的转变,因为他们往往习惯于只考虑当前他们工作的解决方案的CM。在DevOps环境中,开发人员需要拥有企业级视角,在更高的层次看待问题。他们的解决方案如何能在产品环境结合其它资源带来优势?其它资源是否能支持被开发的解决方案?言外之意是开发团队需要了解及管理他们产品的所有范围的依赖。集成配置管理也使得运营人员了解新的发布潜在的影响,从而更容易决定进行发布的时间。
 


实践4:综合变更管理


从IT的角度来看,变更管理是一门确保IT基础设施的演化能对整体组织的支持成功及有意义的艺术。但是对于项目-团队层级则颇具挑战。这是因为非常多的技术,甚至相似技术的多个版本会被使用在单个解决方案的开发过程中。由于DevOps引入了与运营有关的企业级问题,综合变更管理策略会变得越来越复杂,因为需要考虑大量的解决方案能够在产品环境中同时运行和交互。为了实现综合变更管理,开发团队必须与运营团队紧密合作,来从组织层面了解任何技术的改变带来的影响。该方式依赖于前面的实践-利益相关者的积极参与,集成配置管理及自动化测试。
 


实践5:持续集成


持续集成(CI)是构建及验证项目的规范,当有代码更新被迁入到版本控制系统时,会进行自动化的回归测试及代码分析。CI是与DevOps相关的性感的敏捷开发实践之一(至少从开发人员角度来说是如此)。CI确保开发人员以较小的,可以对代码缺陷立即反馈的常规步骤来开发一个高质量的可以工作的解决方案。
 


实践6:集成部署计划


从开发团队角度而言,部署计划总是需要与该组织的运营人员交互。有些情况下,与运营人员接口的专家被特称为发布工程师。经验丰富的团队将使开发,运营及支持团队这些利益相关者一起持续的制定部署计划。当你采用了DevOps策略,你会很快意识到需要一种跨团队的方式来完成发布计划,因为需要运营人员与整个开发团队一起工作。对于运营人员来说这不是什么新鲜事,但是对于只习惯工作于孤立环境的开发团队来说却很惊奇。如果你的团队还没有这样做,你需要开始从组织层面来考虑部署时间表。更远一步,为了支持持续部署,发布工程师需要增加发布次数,因为敏捷团队已经可以持续及一致地达到发布的质量要求。
 


实践7:持续部署


持续部署是持续集成实践的扩展。对于持续部署,当集成在一个沙盒中成功完成时,变更会被自动升迁到另一个沙盒中,集成会自动的在这里进行。自动升迁一直持续,直到有人验证了所有的变更,特别是开发向运营的过渡期。

持续部署使得开发团队减少了新功能从被验证到部署到产品环境的时间,使得业务更具响应性。然而,持续部署增加了运营风险,因为如果开发团队没严格遵守规范,会增加缺陷被引入到产品环境的潜在风险。在企业级环境中成功的执行持续部署要求实现前面介绍的所有实践。
 


实践8:产品支持


企业级环境中,大多数的应用程序开发团队工作在已经存在于产品环境的解决方案的新的功能上。他们不仅工作于该新功能,还有解决严重的产品问题的职责。开发团队往往被称为产品的“第3级支持”,因为他们是解决棘手的产品问题的第三个(也是最后一个)团队。尽管做第三级产品支持的需要是普遍的,但是看板和规范敏捷交付(Disciplined Agile Delivery, DAD)则是例外,很多敏捷方法只解决传递这些影响。该实践的一个重要的副作用是给予了开发者发生在产品中的此类问题的鉴别能力,提供给他们一种学习机会,从而在设计解决方案时就考虑到相应的问题。
 


实践9:应用监控


正如其名称所示,这是一个运营实践,监控已经发布到产品的环境的正在运行的解决方案和应用程序。技术基础设施平台(比如操作系统),应用程序服务器,以及通讯服务通常提供监控功能,可以工作于一些监控工具(比如微软管理终端,IBM Tivoli 监控, 以及jManage)。然而,为了监控特定应用程序的功能,比如只给特定用户使用的用户界面,仪表化该信息需要与你组织的监控基础设施兼容,这需要构建到应用程序中。开发团队需要知道该运营要求,或者,更好的方式是可以访问一个框架,该框架可以直接提供相应的仪表化。
 


实践10:自动化的仪表盘


使用自动化仪表盘的实践是IT领域的商业智能(business intelligence, BI)。该实践分为两个方面,开发智能以及运营智能。开发智能需要使用开发工具来仪表化产生的指标。例如,你的配置管理(CM)工具已经记录了谁以及什么时候迁入代码。持续集成工具可能同样记录了构建发生的时间,运行了多少个测试,测试运行的时间,构建是成功还是失败,运行成功的测试数量等。这些原始数据会被分析并显示在一个自动化的仪表盘中。运营智能是之前讨论过的应用程序监控的一个方面。使用了自动化仪表盘,组织的整体指标开销将被显著降低(但是不能完全淘汰,因为不是所有的事情都能被自动化)。自动化仪表盘提供了实时的对组织的管理团队的洞察。
 


DevOps与文化息息相关


在讨论了这些苛刻的支持DevOps的实践之后,我需要强调主要的限制成功的因素是能否建立一个贯穿整个IT组织的相互协作的相互尊敬的文化。我的经验是,当决定采用高效的DevOps策略时,人及他们相互工作的方式是成功的主要决定因素。不幸的是,在组织中带来文化变迁比采用一些新的实践要难得多。


原文地址:http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363?pgno=1
作者:Scott W. Ambler
翻译:黄博文@无敌北瓜 


IT运维自动化是一组将静态的设备结构转化为根据IT服务需求动态弹性响应的策略,目的就是实现IT运维的质量,降低成本。