农夫山泉？农夫山泉都开始招 SCM 了。

跨界

这个不是屌丝公司的区分标准，你们公司显然已经高大上了，待遇高大上，加班也高大上，呵呵。

说到底还是对人不够尊重。说白了就是不愿意要初婚未孕的女性。但是每个女人不都会经历这么个阶段么？设身处地的为别人想一想，从良知的角度去考虑一下，不难作出判断。

可惜良知泯灭，良知泯灭啊。

@ 付超群 看了@Easy 和 @ 程显峰-Mars 的访谈，项目出问题最终还是会落到位尊智薄这四个字上，方法/工具/流程仅是辅助，简单点说就是跟对人做对事，卓越的工程师/PM 是把复杂问题简单化，而不是提高管理复杂问题的"能力"

@ 平凡的香草: 大多数难题在合适的人面前都不是难题，但仅靠 “人”，缺乏足够好的工具、流程、方法的辅助，要么事情会做起来非常费劲，要么会…这种情况大家见到的也不少。

@scmroad配置管理之路 跟对人就很难，做对事更是不可控

[i=s] 本帖最后由 laofo 于 2014-11-5 10:25 编辑

读者评论：互联网公司和软件工程那些事

上周程显峰的访谈发布后，引发大家热议，微信转发过千。本想整理出一些观点，却发现都是一边倒的叫好声。JobDeer 的创始人 Easy 有感而发，结合自己在技术和产品上的经验，写了一篇较长的评论。他认为未来应该在产品经理中普及敏捷的概念，并提出了用 “「产品工程」替代「软件工程」” 的假设。

技术人攻略曾经发过一篇 Easy 的采访，讲他从新浪云离职之后，从做 “快简历” 到程序员拍卖网站 “JobDeer” 的转型过程。最近他把自己对技术人职业发展的观点，整理成了一本叫《程序员跳槽全攻略》的电子书。Easy 一直致力于寻找可复制的方法，创业成功这件事儿可能大部分得靠运气，但踏踏实实依靠技术，找一份过得去的工作，应该是有模式可循的。感兴趣的读者，可以去 SelfStore 免费下载。

正文：

关于软件工程，我一直有一些零散的想法，正好 @ 技术人攻略 这期聊这个话题，于是顺手写了这篇「散」文。

[b] 关于延期 [/b]

2004 年，我大学毕业到新浪时，正好参与了一个大型的互联网项目——新浪教育频道见习就业项目。进度是由项目经理控制的，光是需求分析报告叠起来有一个 iPhone 侧面高。过程还算正规，有 ER 图，有数据结构表，还有界面示意图。从项目开始我们就天天加班到晚上四五点，回去睡个觉，早上 9 点回来接着干。还记得我和伟平半夜 3 点出去买烟，回来看见前端的妹子一边哭一边切页面。最后项目还是延期了蛮久。

出于对加班的恐惧，那时候我就对软件工程产生了兴趣，然后读了大量关于软件工程的书，统一过程、敏捷开发、极限编程以及最后期限、人月神话这些周边。我试图弄懂，为什么需求和开发之间，会有如此之大的鸿沟，以至于它能成为一门独立学科。

这个思索持续了多年，我一直没有找到合适的答案，直到 2009 年我回到新浪，担任新浪云计算产品经理。

SinaAppEngine 项目 8 月立项，11 月上线第一个版本，整体进度延迟 3 天（这就是为什么它是 11 月 3 日上线的），当时我们就五六个人。我在新浪云负责的最后一个大项目——新浪云商店第一期上线，没有进度延迟。

这让我发现，延期最核心的问题其实并不在于过程，而在于需求。作为一个曾经开发过亿访问量系统的产品经理，我可以异常精准的控制需求和进度。我们在需求分解时，可以在技术实现级别讨论时间表。最终我们的时间表可以精准在小时级别，误差在天。这招屡试不爽，从快简历到 JobDeer.com，我们的进度延期都最多几天。

[b] 关于质量 [/b]

再来说质量的控制。

[b] 如何提升软质量 [/b]

程序员有一个习惯，就是把自己的高标准拿去要求别的人。所以我们会发明各种高效但是一点都不易用的框架，觉得——如果连这个都不明白，还当什么程序员。

我一直都是这么想的，但当我 08 年自己开工作室的时候，我发现我没法招到技术特别好的人，我们新招的同学甚至搞不明白面向对象。

于是后来我写了 LazyPHP 框架，这是一个用面向过程封装面向对象的框架。整个框架 20 个函数，搞定一切。它只有一个目标，让不懂面向对象的人，也可以写出强壮的 Web 程序。大体来说，它做到了。

再说一件事情。在设计 SAE 的时候，我们有一个最常讨论的话题，就是如何让那些写出不良代码的程序员进行自我修正。后来我们采用了云豆和配额两个方式来进行软性限制。现在 SAE 上访问量特别大的应用都优化得特别好。

[b] 如何提升硬质量 [/b]

我从来不相信软件是什么艺术，艺术从来不会 Done is better than perfect。所以 [b] 有些核心的质量指标是必须的，比如单元测试，比如编码规则，比如常规安全检查。而这些东西，不应该作为圣经天天念，而应该简单粗暴的做到代码发布系统里边，不遵守就提交不了的代码。[/b]

[b] 关于软件工程 [/b]

坦白的说，我觉得「软件工程」这个名字过时了，那是软件时代的遗物，在互联网时代是很诡异的。软件不再是被定义好的大规模工程，分发到外包公司去做实现。它是产品不可分割的一部分，是受需求影响最大最惨的部分。

需求分析，原来是软件工程的起点，现在已经由专门的产品团队来做了，这个决定创业公司生死存亡的东西，居然以前是程序员在做。user story，在没有用户画像、应用场景时也很容易失之千里。

我们需要一个新的，产品整体的工程化，以天为周期进行全产品流程迭代的过程。[b] 而我在这个方向找到的最接近的理论，是《精益创业》。它是精益开发在产品全流程的实现方法论。[/b]

我觉得，未来「产品工程」会替代「软件工程」。

大型互联网公司的技术团队会分成两类人，一类做私有云平台——提供通用技术能力（这部分前期可以用公有云），一类直接合并到业务团队做实现。

超大型项目，会被 API 分割成平台和应用，通过强隔离的方式有序生长；而以往那些依赖关系，也会在这个层面得到很好的解决。

大部分人不用关心系统，只需要关心自己的应用。

软件工程本身，则浴火重生，从一个面向过程式的管理，变成一个面向对象式的支撑环境（有点像对象容器）。

具体的东西，我没想太好，我就随便写写，您就顺便看看。

作者介绍：

技术人攻略访谈是关于技术人生活和成长的系列访问,由独立媒体人 Gracia 创立和维护。报道内容以 “人” 为核心，通过技术人的故事传递技术梦想；同时以小见大，见证技术的发展和行业的变迁。在这个前所未有的变革时代下，我们的眼光将投向有关：创造力、好奇心、冒险精神，这样一些长期被忽略的美好品质上。相信通过这样一群心怀梦想，并且正脚踏实地在改变世界的技术人，这些美好的东西将重新获得珍视。

http://segmentfault.com/blog/devlevelup/1190000000757771

//@Easy: 说明 ① 本文不是反驳之前访谈的，它的核心是 ② 需求按天变化时，工程化的方式过时了 ③研发无法独立定义需求，产品应该介入进度控制 ④[b] 软件质量和需求相关，没有需求就没有质量 [/b] ⑤软件工程应该成为支撑而非限制，云时代应该从生态角度去看待系列项目。

[i=s] 本帖最后由 laofo 于 2014-11-3 17:43 编辑

如何通过 DevOps 解决团队配合问题

一、技术团队细分及配合问题

在 IT 企业里产品从创意到交付给用户，从整体上看是由技术部门负责，但如果深入到技术部门，会发现由不同的技术团队负责不同的部分或者阶段。一般会分产品团队、开发团队、测试团队以及运维团队，在互联网公司里，运维团队一般还分基础运维和产品运维两个团队，基础运维负责基础设施 (包括机架、网络、硬件) 和操作系统的安装，为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。

不同的技术团队一般隶属不同的部门，分散在公司不同的办公区域，团队内部的沟通相对多一些，但团队之间的沟通较少。不同团队都会形成自己的办事习惯、节奏，都有自己的关注点，一般只是知道与之接口的团队的总体职责，但是不知道对方可能面临的困难与工作中的挑战点。另外，如果公司够大，每个团队内部又会分为许更细的小团队，如基础运维一般有系统团队、网络团队和 IDC 团队等，这样更加重了团队之间沟通难度。

从产品策划到上线，一般是以下边的顺序经过各个团队：

开发团队收集产品的需求，定下时间表并进行开发 开发完后，交由测试或质量团队进行测试 然后交给运维团队布署新产品或新版本 运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复 在上面的每个阶段，对应的团队都是各做各的，一般是在最后才会把球踢给下一个团队，如果下一个团队发现问题又会把球踢回原来的团队。如果你深入到不同的团队中去，或听到不同的抱怨声音。

基础运维团队经常抱怨： [list] [] 产品开发一点计划都没有，突然要上线机器，让我们措手不及。 [] 每个产品都急着上线，谁催得急就上谁的，谁能说一下，到底那个重要？ [] 动不动就要重装系统，坏了一块盘就着急去修，刚从机房回来，又要过去。 [] 上线太突然了，没有交换机，没有机架，还需要搬别的机器腾地方。 [] 那个地方有机架和交换机端口，但没有四层设备，他们又要放在四层后边，真的没有办法了。 [] 刚跟他们上线到一个机房，他们又说要换到另一个机房，尽折腾。 [*] 他们怎么能那么用设备，把上连端口带宽都跑满了。 [/list]

产品运维团队会说： [list] [] 真没办法，上个线不是说没机架，就是没有交换机，还有就是说没有四层设备。 [] 从来不告诉我们什么时候能设备能上线交付给我们，不派专人催着这事，一点谱都没有。 [] 本来没有想好怎么用这些设备，先提前一个月申请上线，得我们想清楚了，他们却说又得换机房。 [] 网络怎么老是出问题，他们怎么规划的。 [] 开发的代码太不靠谱，一上线就引发用户投诉，只能回滚到老版本。 [] 开发人员的技术能力不行，写不出能用的版本。 [*] 开发要求有一个跟生产环境一样的测试环境，这不可能有的。 [/list]

而开发团队却说：

[list] [] 他们又不让我们碰线上的系统，生产环境是什么样，我们都不知道，没法开发代码。 [] 我们辛苦开发几个月，上线出问题又直接回滚了，心情很不好受。 [] 代码在测试环境或我的机器跑的好好的呀，怎么一上线就出问题呢。 [] 测试怎么测的，那么多问题发现不了。 [*] 我们希望产品运维同事帮忙搭一个跟线上一模一样的测试环境。 [/list]

另外，测试团队的人也许会说： [list] [] 开发人员不写规定写单元测试代码。 [] 想着能用一个自动的集成测试环境，因为开发的原因，老是实现不了。 [] 测试环境跟生产环境不一样，好多问题才发现 [] 还有那么多的 bug 没有解决，产品就催着上线。 [/list]

二、技术团队之间配合不好的影响

上面看到的团队之间的冲突和抱怨问题虽然都不一样，产生的影响确是类似的：

产品上线的进度延误，整个团队很难正常交付新版本。 产品上线后问题很多，影响用户的访问。 团队的士气很差。

最近又发生了运维团队与开发团队之间的配合不好的问题，影响及原因如下：

新产品上线延误了两个星期，正常情况下一天就可以上线。原因是开发考虑不周，测试环境中没有发现，到上线前才发现部署到多台机器上后，按开发原先计划的方式多台机器无法协作完成任务。还有就是在设计阶段没有考虑生产环境的状况，在上线的过程中需要做出对应的代码调整。

上线后质量不稳定，出现多次紧急修复。原因同上。

临时增加硬件投入。新产品中有个组件采用全新的技术方案，跟原来的 LAMP 体系不兼容，所以需要新增机器，单独部署。 除低了服务可用性标准，并产生了遗留问题。因为临时需要增加硬件，而恰好又只有一台，这样就形成了单点，如果该机器出现故障，服务将全部中断。另外，由于开发前设计上考虑不周，跟别的组件集成时产生别的单点。所以这些降低了服务的可用性，以后还得想办法解决。除此之外，组件采有新的软件，安装、服务起停以及软件配置的管理都是纯手工打造，以后还得找时间纳入到自动配置管理中。 影响了团队士气。在上线过程中开发、测试和运维都觉得不舒服，相互之间产生了抱怨。如果不处理好，会影响以后的配合。 虽然，有些问题确实需要靠某些团队提高自身的人员技能才能解决好，但这些团队能够形成一股合力的话，同样的人员组合肯定会产生更好的效果。

三、过去解决团队配合问题的方法

第一次碰到团队之间的配合问题时，我们还没来得及解决的时候，公司战略调整，整个开发和系统运营团队转给了另一个大部门。但我们在别的地方重新梳理技术团队时，后来又没有出现这种问题，回想起来，我们的做法是：

部分开发人员有生产环境中服务器的帐号，可以观察代码的运转情况，少数核心开发人员还有 sudo 权限，当然他们也不会随便修改服务器的设置 开发时一开始就会跟系统运维团队沟通，在代码中增加数据收集的接口和监控接口，这样上线后，很容易收集产品的性能数据，并能方便地对运行状态进行监控与报警 生产环境中也有沙箱与 beta 环境，这样大的版本从测试中过渡到生产环境前，先在沙箱环境中适应一段时间，这样能相对平稳过渡到生产环境 部分开发人员临时转到系统运维团队工作一到二个季度，跟系统运维同事一起上线产品，解决产品在运行中发生的问题，这样更好地了解代码如何在生产环境中运行，回去之后能更好地运维同事沟通，开发出来的代码更容易在生产环境中运行 这样，不同团队之间虽然有职责上的明确分工，但在中间的配合的部分做了不少柔性处理。另外，开发、运维与测试等团队中的核心人员之间本身就有认同感，大家一开始的目标就是奔着公司能成功来的，这是没有出配合问题的根本原因。这一点其实跟 DevOps 的核心点类似，既然如此，何不重新审视一下 DevOps，并参考着解决团队之间的配合问题呢。

四、DevOps

DevOps 是 2010 年从欧洲传过来的概念，最先是由一群有着跨学科技能的工程师提出来的，为了解决下面的问题：

推出新功能和解决老问题的周期过长 新产品或新版本上线充满风险，代码能否在生产环境中稳定运行，没有人有信心，只能艰难地推上去，再看是不是有问题 不同团队相互隔离，配合差。如开发人员收到问题后，第一反应是 “在我的机器上工作得好好的呀” 我认为 DevOps 的核心是不管你是开发者、测试人员、管理者、DBA、网络工程师还是系统管理员，大家都是一起的，只有一起努力给客户提供稳定而高质量的软件服务，实现公司的商业利益才会有别的，包括自己的工作机会。

所以，DevOps 实际是给各个团队之间搭桥，让他们不仅仅是依靠上线申请单这样的鸿雁传书工具进行沟通，而且经常离开自己的孤岛，走到别人的岛上去，了解别人，并提供自己的想法，帮助对方。

DevOps 更象是一种运动，每家公司都需要根椐自身的特点进行借鉴，推动团队之间的协作与合作。需要在三个方面努力：

人员 一方面对现有人员进行培训，鼓励他们了解别的团队的工作、面临的挑战等，让他们用自己的特长去审视和帮助别的团队，另一方面也想办法招一些全面的技术人才，在不同团队之间搭出一些适用的桥来。

流程 在研发的前期，让系统运维同事参与起来，一起搭建测试环境，验证想法，或者也可以在一些项目团队中直接配有系统、开发和测试以及产品人员，一起为产品的上线努力。出现问题的时候，一起想方法找到问题的真正根源，避免相互推托，将解决方案落实在以后的研发过程中。从绩效考核流程上也需要考虑协作因素。

工具 说实在的，大家针对 DevOps 在工具方面其实讨论得更多，这里面跟敏捷有些类似之处。快速的系统部署和自动化产品代码发布方面的工具显得尤为重要了。

为了避免校弯过正，走向另一个极端，也需要避免下面的对 DevOps 的常见误解：

DevOps 意味着要给开发者 root 权限 可以给开发者加 sudo 权限，运行指定的命令，比如重启 web 服务。让开发者更多地了解生产环境和产品的运行状况，但并不意味着让开发者象管理员一样的去管理机器。

所有系统管理员需要写代码，所有开发者需要上架机器 在系统管理和开发者各个领域仍然需要各自的专家，如存储、网络、安装、javascript 等专门的人才，DevOps 并不意味着让大家不做自己专长的事情。

你一定要用某个工具，不然就不是 DevOps 一些技术和自动化的工具对推动各个团队之间协作很有帮助，但是还是需要聚焦于要解决的问题，根椐问题和组织的特点选择合适的工具。

我们需要招聘 DevOps，DevOps 不是一个新的岗位

五、结合 DevOps，解决团队配合问题

管理人员关注团队之间的沟通机制及氛围：

以新版能在生产环境中可靠稳定运行为目标，形成协作的氛围。 在项目的早期，立项之间，运维、开发与测试就进行沟通，可能的话坐在一起，面对面沟通。 在项目上线前，除了测试功能，还要关注部署、备份、监控、安全以及配置管理，在早期发现的问题越多，越能尽少后期的问题并避免影响用户体验。 建立各个团队的核心成员定期沟通机制。 团队之间的协作纳入绩效考核过程中去。 让开发人员了解运维工作、关注点及挑战，并从开发视角帮助运维：

开发人员参与运维团队的内部培训，了解线上的系统。 了解运维如何定位并解决故障、如何监控系统的运转情况等。 少数开发人员可以跟运维一样发版本到生产环境中，让开发人员关注并了解自己代码的运行情况。 从运维的视角修改代码，方便运维人员进行日常的变更与调整，监控与报警。 帮助运维人员修改 puppet 配置模板。 帮助运维人员编写与修改产品的发布脚本，提高自动化水平。 让运维人员了解开发过程的关注点及挑战，并从运维角度改善开发过程：

运维为开发在公司搭建基于虚拟机的测试环境，虚拟机的安装、配置管理以及代码的发布采用跟生产环境一样的方式。 开发人员与测试人员象运维一样发布版本到测试环境中。 鼓励开发与测试人员修改 puppet 配置与模板，管理自己的虚拟机。 在生产环境中建立了 beta 环境，开发人员可以直接发版本上去，让代码在最终上线前多一层缓冲。 运维去了解代码的模块结构，从运维的角度修改代码，让产品上线后更方便运维与适应生产环境的特点。 运维参与到持续的集成测试中，用自己的自动化知识帮助实现自动的集成测试等。 来源：http://www.infoq.com/cn/articles/lxh-teamwork-devops

Rackspace 希望 DevOps 助力实现自动化云管理

Rackspace 正在拓展他们的支持解决方案，并将 Chef 等 DevOps 工具纳入其中以帮助企业自动化他们的云管理。

通过全新的 DevOps 自动化服务，Rackspace 将为帮助企业部署和扩展运行在 Linux 上的应用的 DevOps 工具提供支持。Rackspace 在上周四表示，该服务很快将能够与 Windows 协同工作。DevOps 为一种软件开发概念，旨在让开发与运营部门之间的互动更为顺畅。

尽管任何人都可以使用这一服务，但是该服务最适合那些需要快速扩展基础设施或是希望在今后扩展基础设施的企业。Rackspace 在网站上称，如果企业是通过 Chef 实现自动化或是使用 StatsD、Graphite 和 New Relic 进行监控，那么他们可以向 Rackspace 寻求帮助。Rackspace 还将对一些用于工作流自动化、日志聚合和源控制的工具提供支持。

Rackspace 能够编写、测试和维护 Chef 的 “烹饪书”。其中 “烹饪书” 的功能是描述系统如何被配置。Hadoop 和 MySQL 等软件可以通过 “烹饪书” 被安装、配置和优化。厂商也可以在代码发生变化或出现其它事件时帮助公司分析性能是如何提高或是如何恶化的。

Rackspace 称，这一解决方案背后的原因是企业发现他们难以招聘到和培训出 DevOps 人才，而 Rackspace 与此同时则通过管理自己的基础设施中总结出了许多经验。

Rackspace 表示，DevOps 自动化服务将率先提供给一些精通 Chef 的美国地区客户，预计明年年初将向全球提供。尽管 Rackspace 目前还没有透露该服务的价格，但是用户可以通过 Rackspace 的网站申加入限量供应项目。

DevOps 如何提升 IT 运营人员的形象？

当 IT 运维人员开始失宠时，来自 DevOps 运动中的 “形象提升” 方法应该是最佳的应对方案。

不像 DevOps（开发运营组合），IT 运营的地位倍受争议， 他们被普遍认为存在公关问题。DevOps 的解决方案能否像把运营专家安插在产品开发团队中，让其自吹自擂这么简单呢？一位来自 Etsy.com 的高级副总裁认为：“这是前进之路的一部分。”

DevOps 运动的倡导者 John Allspaw，也是 Web 运营和容量规划相关书籍的作者，曾效力于多个国际著名网站。他目前是 Etsy.com（一个类似 ebay 但专注于手工艺品的网站）的技术运营高级副总裁。我们咨询了 Allspaw 关于 IT 运营人员引入 DevOps 运动之前与之后的对比，然后为他们的 IT 运营人员如何提升形象提出一些建议。

开发和运维在 Etsy 是怎么工作的？

John Allspaw：在 Etsy，开发团队是沿着功能的边界分开的，比如：移动、支付、防欺诈和搜索功能，每个团队都有一位特定的运维工程师，他参加团队的周会，获悉项目的进展情况，得知是否有新的需求要制作出来。他同样负责培训其他的产品运维人员关于项目的进展情况。因为这位特定的运维工程师提前参与了开发过程，我们在代码还没有写之前就具备了警示和配套基础设施，并且运维人员在设计时也有更大的发言权。

你认为 DevOps 模式可以用在非 Web，非产品开发导向的公司吗？

Allspaw：要问我 DevOps 模式能否用在别的公司？当然。但有没有效果呢？我现在只能说，也许没有，因为大家意识上还是把 IT 视为 “开支” 而非 “盈利”，和请个清洁工倒垃圾一样。

IT 能做些什么来改变此窘境呢？

Allspaw：IT 普遍被认为是一个 “黑盒子”，人们很难看到里面是什么。我们解决此观念的一个方法是把用于网站的监控应用到公司 IT。比如无线。原来无线网络相当复杂。对它的期望是大部分时间工作，但是看不出你做什么也许导致它不工作。因此我们在一个仪表板上制作一幅带有无线接入点信号和链接到此接入点人数的图表，让每个人随时查看，包括接线员。这样，如果无线出现异常，她就不会只是无奈的抱怨：“什么垃圾网络啊！” 这使她现在能够看看是不是无线接入点超负荷了，这也打开了这个 “黑盒子”。

还有就是找到便宜简单易实现的方法让组织的非技术部分更加高效和更受公众称赞。Etsy 的打印机神奇般地从来没有缺过打印纸。为什么？应为我们有一张图标显示每个打印机的打印纸的数量，同时还有预警，就像我们在服务器上做的一样。每当我告诉别人这事，甚至在像 Google 一样的公司，他们都会惊道：“哇，这真是一个好主意！”

在你开始在 DevOps 办公环境工作之前，IT 运维人员的工作是怎么样的？ Allspaw：在传统企业中，IT 运维人员职责是可用性和在某种程度上性能。只有高级管理才清楚了解开发的进度情况。 通常开发人员自己会独自写下一堆东西，然后当他们完成了，却发现不能发布，因为运维没有购买相应的服务器或没有预警或其它。这很悲剧，因为运维全蒙在鼓里，这让我们联想：如果运维人员把 XXX 搞定，开发应该可以更加快。

你用公用云吗？

Allspaw：当然， 我们试着利用那些我们感觉不需要自己去搭建的服务。我们使用 Google Apps、 PagerDuty 和一些托管的 B2B 软件即服务（SaaS）用于例如欺诈检测和支付处理。我们利用 Amazon Web Services 合理的放置：我们通常用 S3 存储长尾图片（long-tail photo）， 但用于需要低延时热门图片，我们在我们的数据中心有一层缓存。

但是，认为所有事情都能外包出去的组织终究会 “梦想破灭”。我们业内有句话：“自己的可用性属于自己。” Etsy 可以用 Gmail 用于公司邮件，但我们不抱幻想它让我们从我们关注整个事情上解脱。它仅仅是另一个选择。

如何才能实现 DevOps 战略？

DevOps 是 IT 交付过程令人兴奋和具有深远意义的转变。承诺很诱人： 从根本上提高生产力，更低的成本和更可靠的系统。

那么，你应该跟随潮流，让你的 IT 部门去参与开发运营融合（DevOps），对吧？大家都开始干了，所以你也别落后。最大的问题不是干不干，而是怎样干，从哪里入手？

首先，走出去，招聘一些 DevOps 人才。等等，DevOps 可不是一个岗位哦。

好吧，你应该创建一个 DevOps 工作组或者部门，对吗? 在一个 DevOps 主管的带领下，你可以训练出一个伟大的 DevOps 团队——再等等！！——DevOps 既不是一个部门，也不是一种职能。

好吧，如果它不是一个岗位、 一个职能或一个部门，那 DevOps 到底是什么？

DevOps 是文化、 流程、 技术和人。DevOps 战略是将许多学科融合为一套有凝聚力的组织原则。DevOps 是一种新的 IT 系统交付方法，承诺更快交付、更高质量、终结全球饥荒、获得永生！好吧，也许不包括最后两个……DevOps 也意味着 IT 组织在时间、经历和资源各方面的庞大的投入。

DevOps 也就是应用程序开发和系统运维的融合 可以改造和提升 IT 交付能力。DevOps 概念同样也极易被滥用，所以我认为应该立一个警示牌。警告：DevOps 滥用可能导致丢饭碗、 业务中断、和 CEO 郁闷地汇报。

DevOps 为什么不容易

首先，让我们弄清楚 DevOps“不是什么”。DevOps 不是 Chef、Puppet 或者 Salt Stack，或者任何其它工具、脚本环境或者技术。虽然自动化是 DevOps 的核心理念，但它不等于自动化。

DevOps 也不会是你组织里深层次技术和专业技能的替代品。去专业化，并不意味着你要解雇你所有的 Linux 或者 Oracle 专家。

对于高度集中的科技公司例如 Yahoo 、Facebook 或 Yammer，那里的所有 DevOps 主管想要取得 DevOps 成功非常艰难。对于传统企业，特别是大型分布式组织，在整体意义上的 DevOps 成功往往是不可能实现的。

为什么这么难？一个原因：文化。

DevOps 要求深层次的文化和组织变革。需要改变行为习惯 ——要改变的太多太多。这意味着大家要扔掉奉行了几十年的显规则和潜规则。你不得不告诉老部下们，大部分他们知道的和每天做的事物都已经过时了。

IT 组织结构调整很容易。我可以把开发人员和运维人员安排在同一个房间，安排他们完成工作，这也是一种显式的调整。但是，这两个不同的群体的人，带着多年不一样的培训经历和不同的技能，真能够融入 DevOps 组织吗？要知道，他们可能来自不同的星球！

怎样搞定 DevOps

想要为 DevOps 和应用灵活性而重塑你的团队，需要领导层的勇气和无私奉献。当然，它也需要花费时间和金钱，并且需要在团队成员筛选上做出艰难的决定。

为了促进 DevOps 战略，调整考核和激励机制是必要的。如果你依然只根据敲出代码的生产力来奖励开发人员，或者根据基础设施的可靠性来奖励运维人员，那么，什么都不会改变。相反，应该奖励系统创建和运维的整体团队，并且根据团队工作的全部要素来确定奖励。

围绕业务系统而不是职责来组织工作，这就是 DevOps 打破 IT 分组壁垒的寓意。一个团队应该有开发人员创建代码，从用户界面到业务逻辑和数据结构，也应该有运维人员负责操作自动化和部署。

人们需要知道他们需要对什么样的系统负责，而并不仅仅是毫无责任地从一个系统换到另一个系统。唯一的例外是专家。

团队待在一起，共同为他们的应用和系统负责。

不要制造一个团队支持太多应用的局面。在这个预算缩减的年代很难考虑周全，但是经历这种融合转变之后，你的团队将更加富有成效，并且不需要额外人员就能应对需求的增长。

你需要充足的专家参与项目和为团队提供支持 ——这些人都是不同学科的大师和专家。他们为系统提供支持，但是不会长期指派给某一个系统。他们不需要对这些系统负责。

全面自动化 —— 部署、 升级、 扩展、 维护、 数据卫生、 测试、 监测、 安全和策略管理。在自动化方面投入巨资，目标是 100% 的自动化，不考虑低于 90% 的可能性。但是，全面自动化也可能会引起自动化泛滥。集中审查和调整可以控制 Chef 或 Puppet 脚本库的无序增长。

针对整个团队进行奖励和表彰。成功离不开大家共同的努力，同样，问题需要整个团队自我反省。系统团队应该承认专家们的贡献 ，对表现杰出的专家给予奖励。

围绕建设运营融合的原则制定新的企业体系结构标准。这将确保系统符合运维的需求。

DevOps 战略必须获取本组织自顶向下的全面支持。整个行政领导团队 ——不只是首席信息官 ——应知道它为什么重要和怎样使它取得成功。

请记住，这是重大的文化和组织变革，多分配些时间开展培训和组织开发活动。如果你变革得太快而忘了和您的所有团队步调一致，你将整天陷入失误和冲突——最后满盘皆输。

DevOps：从理念到实施

为什么会有 DevOps 的出现？

DevOps 这个新理念的出现，是为了应对 IT 环境中普遍面临的一些挑战。 [attach] 2498[/attach]

敏捷的出现缩小了上图所示的第一个隔阂，也就是商业需求和开发之间的隔阂，有效的加快了产品开发的周期和效率。那么这无疑为运营团队增加了很多压力。

于是上图中第二个隔阂，也就是开发和运维之间的隔阂需要解决，于是 DevOps 的理念应运而生。

如何解决开发和运维的隔阂呢？

首先要明白隔阂产生的原因。开发人员和运维人员认识的方法，以及各自所处的角色，都存在根本性的差别。

开发团队要求的不断满足新的客户需求，并快速实现新的功能。而运营最关心的是 “稳定压倒一切”，任何差错都有可能对生产环境中的用户造成直接影响。有些服务提供商都和客户签署 Service Level Agreement。服务中断意味着直接的财政损失。衡量指标不同，自然工作的重点不同。

那么我们首先要从文化上着手。

根本上要从文化上着手。文化的改变是第一位。了解自己的工作队全局的影响。

运维团队必须明确的认识到，如果不能快速把开发成果推倒生产环境，企业就很可能被其他竞争对手超越。长久以来就很有可能被市场淘汰。覆巢之下，焉有完卵？那么运维团队也就没有存在的意义了。但不是说稳定不重要，我们需要实施一系列手段来实现即快又稳。

开发团队必须明确认识到开发代码或者更改设置时，可能会对整个系统稳定性和性能的影响。

其次要从组织结构上着手，考虑开发团队和运维团队的直接领导是同一个人，尽量避免部门直接互相指责和扯皮。

第三要实施一些工具及方法。

如何具体实施？

正如很多企业采用敏捷开发一样，这需要一个准备，尝试和逐步实施的过程。其实 DevOps 仅仅是一个理念，而且这个理念在不断变化和发展中。无论公司大小，IT 环境面临的有很多挑战是共通的。大公司组织结构相对发杂，人员理念和文化的形成非一夕一朝之功。在实施 DevOps 反面，反而小公司有很多的优势。

除了 IT 企业外，DevOps 对于传统的行业（金融，电信等等）也同样有借鉴意义。因为在不久的将来，每一个公司都是数字化的公司。没必要强调你的企业是不是采用 DevOps，应该开始深入了解你的环境中需要解决的问题是什么，再看 DevOps 中的一些方法是不是会帮到你，然后再具体实施一些措施和借用一些工具来帮助你。比如我所关注的虚拟化平台的运维，就可以借鉴 DevOps 的很多思想。

标准化和自动化：

尽量采用模板和指定好的流程来更新 Master Image，采用 Puppet，Chef 等工具来实现系统管理自动化，尽量减少人为干预。同时也避免了不必要的人为失误。

像管理代码一样管理系统配置：

很多应用的配置，因为需求变化而更改。但文档往往没有同步更新。需要有工具来记录系统的配置参数。也就是说借鉴软件开发中管理 Code 的方式，来对系统环境的设置进行版本控制和同一的管理。从而保证环境的一致性和稳定性。

这样可以捕捉到和规定配置不一致的情况，也可以快速的找到问题所在，提高排错的效率并缩短时间。

要有独立 Dev/Test 环境

新的配置必须在独立的 Dev 环境中充分测试后，才能在生产环境中实施。

测试自动化

采用一些工具和方法，自动测试系统改动后的各项功能和指标。大大减少测试需要的人力和时间。

开发人员能自己创建开发环境

vCloud Director 可以很好的满足这个需求。系统管理员可以把运算、网络和存储的资源专门分配给开发团队，并授予适当权限。开发人员自己可以瞬间创建模板以及新的环境。

我们离 DevOps 有多远：持续集成思想的延伸

Wikipedia 对 DevOps 的定义是：

持续集成思想

怎样才能达到这样一种状态呢，我们先放一下，看看持续集成（Continuous Integration）体现出来的一些思想。

纵览全局（打破职责界限）

rd，qa，op，如果仅仅按照这样的角色标签去处理事情，那就和圣经里的巴别塔一样，大家不说同一种语言怎么能劲往一处使呢。

我们把目标放得更远一些，不再为了赶代码而将质量保障交给 qa 和 op，不是为了增加测出 bug 的数量而和 rd 争论，不是为了减少变更而是积极的适应变更，我们共同的目标是实现商业目的，确保软件质量（也包括变更质量和运行质量）也是其中的一部分。频繁的变更不是质量的杀手，而应该在软件开发整个流程多个环节进行质量的保障，并频繁的运行这些保障。

这种方法就打破了目前的 rd->qa->op 流水线的流程，而是将三者紧密的结合在一起。从实践的结果来看，rd 每次提交代码都会触发一系列的自动化步骤，包括编译，单元测试，代码覆盖率，功能测试，部署测试，性能/容量测试（注：后两者受限与时间要求，实际实施不会每次提交代码都触发）。Rd，qa，op 都在过程中做质量保障。 [attach] 2492[/attach] 是努力减少变化还是在变化发生时做好准备。一定是后者，因为当一件事情频繁发生时，问题才会大量的暴露。解决暴露出来的问题才能促进业务更好的发展，也是对团队能力的提升。

拿一个的实际例子，部署测试（Deploy check）和性能/容量测试（capacity test），我们比 QA 有更多的资源和条件，那么我们就应该主动承担起这份工作，然后将其加入到整条质量保障线的必要环节上。

[attach] 2493[/attach]

浑然一体（而非七零八落）

代码树被管理起来——主干开发

[attach] 2494[/attach]

主干开发的好处是每个 rd 都知晓整体的变更，所有的 feature 作为一个整体发布，对 OP 的现实意义就是上线变得更有规律，非计划的、临时的上线最后消失。

代码和周边（配置，数据，构建脚本，单元测试，测试用例）统一作为产品被管理起来——一键式产构建，测试，部署，完成产品的最终发布。

SVN 结构样例

module |--product |----code |----bin |----scm_product.conf（描述程序地址） |----module_control |----conf |----data |----data_description（描述数据存放地址） |----ci-script
|----test_case
|----build_script
|----test_script
|----deploy_script
|--development
|--test 好处易见，生成一个完整的产品的所有原料都被管理起来，上线仅需要一个版本号，不会出现上线时冗长的步骤，做版本 diff，部署环境 diff，测试 case diff 都非常简单。而且，环境的备份也变得简单和纯粹了。

研发（开发，测试，发布，部署）全过程被管理起来。所有角色在一个界面下工作，使用共同的平台，统一的源码管理，共享。

[attach] 2495[/attach] 大家都在一个平台上工作，所有的任务都在这个平台下，各角色间对互相的工作有更深入的了解，并且，工作状态也可以共享。

少就是多，简洁就是美（用简单的方法解决问题） 持续集成的解决方案是简洁的。产品由 SVN 去管理，构建过程由 CI server 负责，而构建过程包含了编译，测试，发布，部署过程

[attach] 2496[/attach]

没有封闭的系统，没有蹩脚的流程，配合开放的系统（Code Review/wiki）所有的信息被自然的整合在一起。而一切都是以提高变更速度，提高产品质量为目标。

当解决方案让你觉得不自然（或有很多内容无法囊括，或需要人为干预）的时候，那这个方案就不是一个完美的方案，必定在某一些方面受到了限制，这些限制有可能是历史造成的。要勇于质疑，扩展角度，提升高度。去掉角色的限制，站在产品的角度去思考，对于整体的优化的解决方案就产生了。

以终为始（一直以发布级的质量要求产品）

写代码都是为了要发布的，也就是需要上线使用的，那在开始编码就以产品的质量要求代码，要求 check in 的代码就是能够完成编译的，具备一定功能并且可以部署的产品。

将质量内建于产品中。每次代码的提交都会经历单元，功能，部署，性能/容量测试。在上线前我们就能够知道是否能成功部署，线上的服务器是否能撑住。这样的产品在上线时我们就不会有那么大的压力了，OP 也不需要担心回滚的风险了，即使回滚，那么回滚也是 one step。小菜一碟。

我们与 DevOps 的距离

那么我们离 DevOps 有多远呢。从各个公司放出来的技术资料（flickr 最全面），最经典的是 flickr 的 10+ deploys per day，他们的最佳实践有以下几点，而起穿针引线作用的是持续集成（技术上）和思考方式（文化上）。

Culture：

1.respect 2.trust 3.healthy attitude about failure 4.avoiding blame 从文化上，我们需要一种氛围，不仅仅把自己看作 rd，qa，op 这样的角色，哪里有质量缺口，我们就要把它补起来；哪里有不通畅的地方，我们就要把它疏通。RD 了解 op 的部署方式，能够获取 OP 提供的监控指标；OP 也了解 RD 的开发方法，开发流程，所面对的问题。放开自己的眼界，从更高的视角看待和解决问题。

Tools：

1.Automated infrastructure（自动化，系统之间可集成） 2.shared version control（SVN 共享源码） 3.one step build and deploy（持续构建和部署） 4.feature flags（公司内部称为 single branch，主干开发） 5.Shared metrics 6.IRC and IM robots（信息整合） 技术上的这些要点被 3（持续集成/部署）一线贯穿。

4 点（主干开发）是持续集成的前提

1 点（自动化），2 点（代码及周边集中管理）是实施持续集成的必要条件

5 点是 1 的一部分（图表是由自动化系统产生的）

可见，技术上的核心是持续集成/部署

5 所提到的有较高的技术要求。要求我们将业务/运维上的指标变得可测量，直至可预测。这里面的两个核心技术内容就是：

容量测量（Capacity management）

容量的变化体现在用户行为（流量）系统变更（软件性能）和资源（服务器数量，冗余度计划）等几个因素的变化上，将容量和这些变化挂钩，在每一个因素变化下重新得到系统的容量，从而在变更中控制容量不足造成的风险。有一个要点，我们需要的是系统的容量而不是单个模块的性能。

质量反馈（Quality feedback）

变更会导致质量变化，而质量变化体现在各种指标上，而测量这些指标（包括应用指标：平响，处理效率等和系统指标：负载，网络流量），发现指标之间的规律，将指标 share 给整个团队，从而有效的达成质量的反馈，控制变更（包括内部变更和外部条件的变化）造成的质量下降的风险。本质上说，容量测量也是质量反馈的一部分。

在实施持续集成的过程中，并行实施的三个项目：

持续部署/一键式部署（continuous deployment/one step deploy）， 容量测试/管理（Capacity Test/Management） 质量反馈（Quality feedback） 分别对应于上面三个要点，共同支撑系统的高速迭代，减少系统频繁变更引发的风险。

借助于持续集成，我们在实践中向 DevOps 迈进了一大步，离业界的最佳实践已不远。dev 和 ops 说着同一种语言，共同为业务发展和质量保障做出贡献。

敏捷/精益开发方法可以提高应变业务变化的能力，并内建质量。DevOps 把开发和运维的沟壑抹平。那么我们的 development 和 ITIL 就能够结合到一起了。

[attach] 2497[/attach] 我们曾经愿景将服务器放到机架上，一键就能完成服务上线，我们已经有了一个好的开始，这个目标就会实现。

[i=s] 本帖最后由 laofo 于 2014-11-3 16:15 编辑

Kubernetes 系统架构简介 作者 杨章显

Kubernetes 作为 Docker 生态圈中重要一员，是 Google 多年大规模容器管理技术的开源版本，是产线实践经验的最佳表现 [G1] 。如 Urs Hölzle 所说，无论是公有云还是私有云甚至混合云，Kubernetes 将作为一个为任何应用，任何环境的容器管理框架无处不在。正因为如此， 目前受到各大巨头及初创公司的青睐，如 Microsoft、VMWare、Red Hat、CoreOS、Mesos 等，纷纷加入给 Kubernetes 贡献代码。随着 Kubernetes 社区及各大厂商的不断改进、发展，Kuberentes 将成为容器管理领域的领导者。

接下来我们会用一系列文章逐一探索 Kubernetes 是什么、能做什么以及怎么做。

[b] 2. 什么是 Kubernetes[/b]

Kubernetes 是 Google 开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用 Kubernetes 能方便地管理跨机器运行容器化的应用，其主要功能如下：

1) 使用 Docker 对应用程序包装 (package)、实例化 (instantiate)、运行 (run)。

2) 以集群的方式运行、管理跨机器的容器。

3) 解决 Docker 跨机器容器之间的通讯问题。

4) Kubernetes 的自我修复机制使得容器集群总是运行在用户期望的状态。

当前 Kubernetes 支持 GCE、vShpere、CoreOS、OpenShift、Azure 等平台，除此之外，也可以直接运行在物理机上。

接下来本文主要从以下几方面阐述 Kubernetes：

1) Kubernetes 的主要概念。

2) Kubernetes 的构件，包括 Master 组件、Kubelet、Proxy 的详细介绍。

[b] 3. Kubernetes 主要概念 [/b]

3.1. Pods

Pod 是 Kubernetes 的基本操作单元，把相关的一个或多个容器构成一个 Pod，通常 Pod 里的容器运行相同的应用。Pod 包含的容器运行在同一个 Minion(Host) 上，看作一个统一管理单元，共享相同的 volumes 和 network namespace/IP 和 Port 空间。

3.2. Services

Services 也是 Kubernetes 的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过 Proxy 的 port 和服务 selector 决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。

3.3. Replication Controllers

Replication Controller 确保任何时候 Kubernetes 集群中有指定数量的 pod 副本 (replicas) 在运行， 如果少于指定数量的 pod 副本 (replicas)，Replication Controller 会启动新的 Container，反之会杀死多余的以保证数量不变。Replication Controller 使用预先定义的 pod 模板创建 pods，一旦创建成功，pod 模板和创建的 pods 没有任何关联，可以修改 pod 模板而不会对已创建 pods 有任何影响，也可以直接更新通过 Replication Controller 创建的 pods。对于利用 pod 模板创建的 pods，Replication Controller 根据 label selector 来关联，通过修改 pods 的 label 可以删除对应的 pods。Replication Controller 主要有如下用法：

1) Rescheduling

如上所述，Replication Controller 会确保 Kubernetes 集群中指定的 pod 副本 (replicas) 在运行， 即使在节点出错时。

2) Scaling

通过修改 Replication Controller 的副本 (replicas) 数量来水平扩展或者缩小运行的 pods。

3) Rolling updates

Replication Controller 的设计原则使得可以一个一个地替换 pods 来 rolling updates 服务。

4) Multiple release tracks

如果需要在系统中运行 multiple release 的服务，Replication Controller 使用 labels 来区分 multiple release tracks。

3.4. Labels

Labels 是用于区分 Pod、Service、Replication Controller 的 key/value 键值对，Pod、Service、 Replication Controller 可以有多个 label，但是每个 label 的 key 只能对应一个 value。Labels 是 Service 和 Replication Controller 运行的基础，为了将访问 Service 的请求转发给后端提供服务的多个容器，正是通过标识容器的 labels 来选择正确的容器。同样，Replication Controller 也使用 labels 来管理通过 pod 模板创建的一组容器，这样 Replication Controller 可以更加容易，方便地管理多个容器，无论有多少容器。

[b] 4. Kubernetes 构件 [/b]

Kubenetes 整体框架如下图 3-1，主要包括 kubecfg、Master API Server、Kubelet、Minion(Host) 以及 Proxy。

[attach] 2489[/attach] 图 3-1 Kubernetes High Level 构件

4.1. Master

Master 定义了 Kubernetes 集群 Master/API Server 的主要声明，包括 Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage 以及 Client, 是 client(Kubecfg) 调用 Kubernetes API，管理 Kubernetes 主要构件 Pods、Services、Minions、容器的入口。Master 由 API Server、Scheduler 以及 Registry 等组成。从下图 3-2 可知 Master 的工作流主要分以下步骤：

1) Kubecfg 将特定的请求，比如创建 Pod，发送给 Kubernetes Client。

2) Kubernetes Client 将请求发送给 API server。

3) API Server 根据请求的类型，比如创建 Pod 时 storage 类型是 pods，然后依此选择何种 REST Storage API 对请求作出处理。

4) REST Storage API 对的请求作相应的处理。

5) 将处理的结果存入高可用键值存储系统 Etcd 中。

6) 在 API Server 响应 Kubecfg 的请求后，Scheduler 会根据 Kubernetes Client 获取集群中运行 Pod 及 Minion 信息。

7) 依据从 Kubernetes Client 获取的信息，Scheduler 将未分发的 Pod 分发到可用的 Minion 节点上。

下面是 Master 的主要构件的详细介绍：

[attach] 2490[/attach] 图 3-2 Master 主要构件及工作流

3.1.1. Minion Registry Minion Registry 负责跟踪 Kubernetes 集群中有多少 Minion(Host)。Kubernetes 封装 Minion Registry 成实现 Kubernetes API Server 的 RESTful API 接口 REST，通过这些 API，我们可以对 Minion Registry 做 Create、Get、List、Delete 操作，由于 Minon 只能被创建或删除，所以不支持 Update 操作，并把 Minion 的相关配置信息存储到 etcd。除此之外，Scheduler 算法根据 Minion 的资源容量来确定是否将新建 Pod 分发到该 Minion 节点。

3.1.2. Pod Registry Pod Registry 负责跟踪 Kubernetes 集群中有多少 Pod 在运行，以及这些 Pod 跟 Minion 是如何的映射关系。将 Pod Registry 和 Cloud Provider 信息及其他相关信息封装成实现 Kubernetes API Server 的 RESTful API 接口 REST。通过这些 API，我们可以对 Pod 进行 Create、Get、List、Update、Delete 操作，并将 Pod 的信息存储到 etcd 中，而且可以通过 Watch 接口监视 Pod 的变化情况，比如一个 Pod 被新建、删除或者更新。

3.1.3. Service Registry Service Registry 负责跟踪 Kubernetes 集群中运行的所有服务。根据提供的 Cloud Provider 及 Minion Registry 信息把 Service Registry 封装成实现 Kubernetes API Server 需要的 RESTful API 接口 REST。利用这些接口，我们可以对 Service 进行 Create、Get、List、Update、Delete 操作，以及监视 Service 变化情况的 watch 操作，并把 Service 信息存储到 etcd。

3.1.4. Controller Registry Controller Registry 负责跟踪 Kubernetes 集群中所有的 Replication Controller，Replication Controller 维护着指定数量的 pod 副本 (replicas) 拷贝，如果其中的一个容器死掉，Replication Controller 会自动启动一个新的容器，如果死掉的容器恢复，其会杀死多出的容器以保证指定的拷贝不变。通过封装 Controller Registry 为实现 Kubernetes API Server 的 RESTful API 接口 REST， 利用这些接口，我们可以对 Replication Controller 进行 Create、Get、List、Update、Delete 操作，以及监视 Replication Controller 变化情况的 watch 操作，并把 Replication Controller 信息存储到 etcd。

3.1.5. Endpoints Registry Endpoints Registry 负责收集 Service 的 endpoint，比如 Name："mysql"，Endpoints: ["10.10.1.1:1909"，"10.10.2.2:8834"]，同 Pod Registry，Controller Registry 也实现了 Kubernetes API Server 的 RESTful API 接口，可以做 Create、Get、List、Update、Delete 以及 watch 操作。

3.1.6. Binding Registry Binding 包括一个需要绑定 Pod 的 ID 和 Pod 被绑定的 Host，Scheduler 写 Binding Registry 后，需绑定的 Pod 被绑定到一个 host。Binding Registry 也实现了 Kubernetes API Server 的 RESTful API 接口，但 Binding Registry 是一个 write-only 对象，所有只有 Create 操作可以使用， 否则会引起错误。

3.1.7. Scheduler Scheduler 收集和分析当前 Kubernetes 集群中所有 Minion 节点的资源 (内存、CPU) 负载情况，然后依此分发新建的 Pod 到 Kubernetes 集群中可用的节点。由于一旦 Minion 节点的资源被分配给 Pod，那这些资源就不能再分配给其他 Pod， 除非这些 Pod 被删除或者退出， 因此，Kubernetes 需要分析集群中所有 Minion 的资源使用情况，保证分发的工作负载不会超出当前该 Minion 节点的可用资源范围。具体来说，Scheduler 做以下工作：

1) 实时监测 Kubernetes 集群中未分发的 Pod。

2) 实时监测 Kubernetes 集群中所有运行的 Pod，Scheduler 需要根据这些 Pod 的资源状况安全地将未分发的 Pod 分发到指定的 Minion 节点上。

3) Scheduler 也监测 Minion 节点信息，由于会频繁查找 Minion 节点，Scheduler 会缓存一份最新的信息在本地。

4) 最后，Scheduler 在分发 Pod 到指定的 Minion 节点后，会把 Pod 相关的信息 Binding 写回 API Server。

4.2. Kubelet

[attach] 2491[/attach] 图 3-3 Kubernetes 详细构件

根据上图 3-3 可知 Kubelet 是 Kubernetes 集群中每个 Minion 和 Master API Server 的连接点，Kubelet 运行在每个 Minion 上，是 Master API Server 和 Minion 之间的桥梁，接收 Master API Server 分配给它的 commands 和 work，与持久性键值存储 etcd、file、server 和 http 进行交互，读取配置信息。Kubelet 的主要工作是管理 Pod 和容器的生命周期，其包括 Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client 以及 Health Checker 组件，具体工作如下：

1) 通过 Worker 给 Pod 异步运行特定的 Action。

2) 设置容器的环境变量。

3) 给容器绑定 Volume。

4) 给容器绑定 Port。

5) 根据指定的 Pod 运行一个单一容器。

6) 杀死容器。

7) 给指定的 Pod 创建 network 容器。

8) 删除 Pod 的所有容器。

9) 同步 Pod 的状态。

10) 从 Cadvisor 获取 container info、 pod info、root info、machine info。

11) 检测 Pod 的容器健康状态信息。

12) 在容器中运行命令。

4.3. Proxy

Proxy 是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，从上图 3-3 可知 Proxy 服务也运行在每个 Minion 上。Proxy 提供 TCP/UDP sockets 的 proxy，每创建一种 Service，Proxy 主要从 etcd 获取 Services 和 Endpoints 的配置信息，或者也可以从 file 获取，然后根据配置信息在 Minion 上启动一个 Proxy 的进程并监听相应的服务端口，当外部请求发生时，Proxy 会根据 Load Balancer 将请求分发到后端正确的容器处理。

1. 下篇主题

下篇讲述在 CentOS7 上用 Kubernetes 来管理容器。

1. 个人简介

杨章显，现就职于 Cisco，主要从事 WebEx SaaS 服务运维，系统性能分析等工作。特别关注云计算，自动化运维，部署等技术，尤其是 Go、OpenvSwitch、Docker 及其生态圈技术，如 Kubernetes、Flocker 等 Docker 相关开源项目。Email: [email] yangzhangxian@gmail.com[/email]

1. 参考资料

https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs http://www.slideshare.net/rajdeep http://www.docker.com

转自 http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction

吸收外面的理念、一些实践为我所用还是不错的。但是一定要选择适合自己的。 东西是好东西，未必适合每一个公司。

我们生活在一个非常功利、信仰缺失的时代，人们只想快速获取财富，很难有正确的价值坚持。用博弈论解释，这种浮躁走向了囚徒困境，类似日本、德国这种成熟社会，大家做事都不浮躁，整个社会能达到比较高的均衡。而在一个浮躁社会，没按规矩的人走得更快，于是那些按规矩做事的人就吃亏了。这种浮躁其实把大家都害了，把行业也害了。

IT 现在和钱离得比较近，所以病得挺重，整个行业里充满了骗子与强盗。大家努力的方向不是提升自己，而是只要能获得钱的事情都会去做。任何时代都有骗子，但一个国度里大部分人都是骗子，是不正常的，还是应该实实在在创造一点价值。

热衷于炒作概念，是行业浮躁的表现之一。前几天参加一个研讨会，讨论了半天，才发现这群人不是在玩大数据，而是玩 “数据”。因为以前根本没有数据，决策主要靠拍脑袋，现在有数据了，就觉得自己与时代划上了等号，想裹着这个外衣去挣钱，真是无知者无畏啊。好多人觉得有 Hadoop 集群了，上了硬件了，从政府那里拿到钱就牛逼了。可对数据没有理解，不知道怎么用 Hadoop 发挥价值，有钱也没有用。云计算也类似，被地方政府当成了房地产来搞，涌进许多根本不懂这个行业的人。

这种浮躁会导致软件研发竞争优势下降，我们在圈子里有讨论，如果做高端基础软件，硅谷研发成本会比国内更低，能雇佣更高素质的人才，有更好的配合，以及更确定的产出。国内拿到钱的互联网公司，将来可能都会去北美建立研发中心。贵不贵是一说，还有值不值的问题，为什么中国建研发中心不值，这是一个很耐人寻味的问题。

互联网行业看上去门槛低一些，创业相对容易，但总要设置一些门槛给竞争对手，所以还是要有自己的积累。我以前曾喷过阿里这样的公司，觉得他们做的东西不够专业，但后来我改变了观点，他们能坚持这么长时间，能把云计算推到这样的高度，就算走了一些弯路，也是值得敬佩的。这些实实在在的创业者，才是业界的良心。 技术人攻略：根据你做敏捷咨询的经验，实施技术团队过程改进的最大困难在什么地方？

最大的困难在于建立起团队成员对你的信任。许多敏捷实施失败的原因，就是因为程序员不信你，特别是团队资深的人不信你，基本一定会失败。从事敏捷咨询行业的人，许多并不是技术背景，他可以讲一大堆方法论，但程序却写得乱七八糟。所以想做好技术团队的过程改进，至少你得是个懂技术的人，首先要向团队展示出自己的技术能力，才有机会去解决困扰他们的问题。

管理大师德鲁克曾说过：“你度量什么，就能改善什么”。在具体过程改进实施中，我喜欢从细节着眼，寻找一些善于实施，又能见到效益的改善。比如我经常会用到一个方法：度量程序员的时间花在了什么地方。如果大家都是靠猜测，管理不好也不奇怪。

我曾经装过一个软件，记录自己使用电脑的行为，例如统计每天用了多少时间上微博、聊、写邮件，还是写代码。真正把时间记录下来之后，才发现实际结果和自己的感觉大相径庭。社交要消耗大量时间，非常影响工作效率，所以后来我把 IM 都关掉，集中处理工作。

一个管理良好的团队也是一样，想要改善需，就必须要有动力。作为管理者，你必须刺激团队成员身上的动力，给他们一面镜子，照出来他们背后的魔鬼，这样才会有改善的基石，这也是建立信任的其中一步。大部分程序员都很尊重事实，当他发现每天 5 个小时都花在聊天上，自己就会想办法去改善。逐渐实行这样能见到效益的改善，就会获得团队信任。

好多找我做咨询的人，容易关注一些表面现象，比如敏捷实施的各种方法。在我看来，表面的东西只占 20%，真正想做好过程改进，必须花很多时间做基础工作。比如上面提到的对团队工作时间的测量，对你的改善目标，提供了强有力的数据支撑，是非常基础的改进工作。敏捷是一个方法论，在团队内功真正得到提升之前，那些方法没有任何用处，而且高深莫测的方法，会让大家感觉到不确定，容易对此起反抗。

实际工作中，许多咨询顾问不会花精力，去做看上去没有科技含量、很琐碎、不为人知的事情。就像刚刚谈到的大数据行业现状，大家在会上讨论着大数据的建模、分析、如何出漂亮报表，但 80% 的脏活累活，是要把数据有效地进行搜集和整理，它是简单的体力活，但做不好的话，根本没有后面这些故事。过程改进也类似，绝大部分工作就是普通工作，没有太多技术含量，也没什么值得可说的，但必须把这些基础打好，才会有后面的故事。

国外谈论敏捷的，都是有 20 多年工作经验的人，敏捷宣言发起者，都是业界大牛。而平时工作中，我常接触到一些许多没什么工程经验的人在实施敏捷，并且在各种业界大会上，沾沾自喜地分享他们的经验，所以我后来也很少参加敏捷的这些会了。我怀着一颗敬畏的心，去读大师的作品，思考我工作中的不足。我感觉自己做的工作都很普通，都是大师们说过的，很普通的那些事情，值得分享的不太多，失败倒是有很多。

[b] 技术人攻略：你从什么时候成为技术圈的交际花？你工作跨的圈子很多，是否会影响知识的积累？ [/b]

我也不知道从什么时候开始成为交际花，大概是 2011 年初，我翻译了《MongoDB 权威指南》那本书之后，参加了很多技术交流活动。在这些活动上，遇到了不少志同道合、真正热爱技术的人，让我感觉很踏实，于是就更愿意参加社区活动。

客观地说，许多活动的内容和组织都还有很大的提升空间。大家感觉日本的技术做得应该不怎么好，但我最近看了一本日本的技术刊物，发现他们的技术讨论很深入，国内罕有。我之所以会去各个技术会议当出品人和主持人，是因为不想作为批评者旁观，而是主动推动这些事情的发展，促成技术交流的气氛。

离开上一家公司之后，许多做互联网金融的公司都给我打电话。我会问他们一个问题：技术能给你们公司带来什么？在我看来，大部分互联网金融公司处在初期阶段，还远远没到拼技术的时候。他们拼的都还是业务，业务做得好，技术外包一个，都能撑过去。

现在加入的这家公司做 APM 应用性能监控，提供的是纯技术产品。我个人更希望在一家不浮躁，纯粹以技术为价值导向的公司工作。云计算快速发展，已经到了踏踏实实给大家创造价值的阶段，我希望通过公司提供的 SaaS，让大家用得更舒服、更省钱。

我一直很喜欢跨领域学习，对很多东西都有好奇心。大学本来是航天工程力学系的，却因为研究工业自动化系统，获得了电气工程学院的 Rockwell 奖学金。尝试新东西在我看来不是障碍，而是乐趣。

工作以后，在不同圈子认识了不同的人，在互联网金融圈认识的人，如果一直待在广告圈，是无论如何也遇不上的。在各个圈子有朋友之后，可以做一些融合的事，比如想知道金融里面安全怎么做，就会有很多安全圈的朋友给我出主意。当然，在不同圈子太多，单一的业务上说不上特别精通，但我个人积累的重心一直放在技术上，一直在认真研究和探讨自己感兴趣的东西，从来没有放弃过对积累的追求。

作者介绍：

技术人攻略访谈是关于技术人生活和成长的系列访问,由独立媒体人 Gracia 创立和维护。报道内容以 “人” 为核心，通过技术人的故事传递技术梦想；同时以小见大，见证技术的发展和行业的变迁。在这个前所未有的变革时代下，我们的眼光将投向有关：创造力、好奇心、冒险精神，这样一些长期被忽略的美好品质上。相信通过这样一群心怀梦想，并且正脚踏实地在改变世界的技术人，这些美好的东西将重新获得珍视。

http://segmentfault.com/blog/devlevelup/1190000000749805

[b] 技术人攻略：你从什么时候起开始对对研发管理感兴趣？[/b]

我是学工程出身，本科就读于哈工大航天工程与力学系，研究生是悉尼大学的航天专业，期间受到了严格的工程训练。传统航空业的研发和制造体系非常完整，拿造飞机举例，悉尼大学的本科生就完全可以组装出可供销售的飞机，因为整个生产过程非常严格，任何一个扳手都有编号，有详细的记录和流程，不可能搞错任何东西。

虽然专业选择了航天，我对编程却非常热爱。从小学就开始写程序，那时候家里没有电脑，每次上机需要走 40 分钟山路。研究生期间，独立完成了完整的有限元分析软件，算是我在科学计算领域的一次实践。

回国之后，我加入的第一家公司 Antiy，很重视底层技术，产品做得非常成功，但研发管理做得并不好。我在那期间学了很多软件研发历史，但在研发体系建设上，还是留下了许多遗憾。随后加入做互联网广告监测的创业公司 ADMaster，当时公司正在筹建，人员来源多种多样，研发管理问题比较突出。我的职位是专职敏捷教练，配合技术负责人做团队建设，开始更深入地思考研发管理。

刚进入 IT 这一行时我很难理解，为何在传统工程和制造领域很平常的事情，在 IT 领域却是需要商量和悬而未决的。可靠性在航天等领域早已解决得很好，为何软件行业却一直解决不了产品质量问题。后来看了不少管理的书，发现 IT 研发管理的许多思想都是从建筑业、制造业借鉴而来，例如快速迭代、精益管理等概念。

结合工作实践，我逐渐发现了研发管理问题的症结所在。研发能力是工作的综合体现，内功水平是关键，任督二脉打通了，练什么都很快，至于到底用哪个套路，是很轻松的一件事。举个例子，大家通常说要做 “敏捷转型”，认为自己是从传统软件研发转型成敏捷，关于二者的争论也显得像是泾渭分明的两派，但实际上不是。难道传统软件就不做配置管理吗？难道敏捷就不做测试吗？这两派理论有八成是一样的，即便在软件工程教科书里，也同样有关于质量控制、配置管理、迭代等理论，如果很好地去执行，同样可以达到不错的效果。

为什么敏捷转型失败的案例很多，因为企业并不具备相应的内功，只想寻求解 yao，以为敏捷能有所帮助。实际上如果不打好基础，结果还是一样。具备这种内功的人，玩传统软件也会很好。航天、制造、金融行业并不过分强调敏捷，当然敏捷里的好东西，他们也能非常快地去借鉴。《精益软件开发艺术》这本书的作者来自波音公司，他们将其在制造上的经验应用于研发，对软件的驾驭能力相当高。

强调时髦的概念，对研发帮助并不大。比如知道了 TDD 测试驱动开发，对团队帮助有多大呢？TDD 想执行好，要求对测试理论有深入理解，但大部分国内开发团队不仅不具备很高的测试水平，连测试是什么，如何测都不知道。这种情况下去推广 TDD 是没有意义的。

[i=s] 本帖最后由 laofo 于 2014-10-31 15:23 编辑

[b] Eight Docker Development Patterns[/b]

In the past I've written about my "home cloud" that used to be OpenVz containers, and how I've come to advocate rebuilding the "build server" for every build

Docker has quickly become one of my favorite enabling tools for this overall philosophy of creating repeatable builds that results in as-static-as-possible server environments.

Here I will outline some patterns that have started to show up repeatedly in my use of Docker. I don't expect any of them to be particularly novel or any big surprises, but I hope some can be useful, and I would very much like to hear from others about patterns you come across while working with Docker.

A foundation for all of my Docker experiments, is keeping state that should persist in volumes, so that the Docker containers themselves can be re-created at will without data loss (unless I've been naughty and modified container state without updating the Dockerfile's - and regularly rebuilding the containers helps stop that bad habit).

The examples Dockerfiles below are all focused on that: Creating containers where the containers themselves can be replaced at any time without having to think about it.

The more regularly the containers are recreated; the more habitual this becomes, the more it reinforces a habit of avoiding state outside of clearly defined locations that are explicitly persisted.

[b] 1. The Shared Base Container(s)[/b]

Docker encourages "inheritance" so this should not come as a surprise - it is a fundamental aspect of effectively using Docker, not least because it contributes to reducing the time it takes to build new containers by not having to re-execute steps as often. Docker does a good job - sometimes too good - of trying to cache intermediate steps, but it is easy to lose out on opportunities for sharing when not being explicit about it.

One of the first things that became apparent on migrating my various containers to Docker was the amount of redundant setup.

I run separate containers for most projects that I expect to ever deploy anywhere, at least the moment it needs any long running processes, or needs any specific packages beyond my "standard" set, so I have many containers, and the set is rapidly growing.

To the point where I'm considering moving towards trying to run "everything" (including the few desktop apps I depend on) in Docker in order to make mybase environment entirely disposable.

So I quickly started extracting my basic setups into base containers for various purposes. Here's my current "devbase" Dockerfile:

The fun part here is the haproxy.cfg, which is generated by a script that generates backend sections like this from the output of "docker ps"

backend test acl authok http_auth(adminusers) http-request auth realm Hokstad if ! authok server s1 192.168.0.44:8084 and a bunch of acls and use_backend statements in the frontend definition that dispatches [hostname].mydomain to the right backend.backend test.

If I wanted to be fancy, I'd deploy something like AirBnB's Synapse, but it has far more options than I need for my dev use.

For my home environment, this makes up most of my infrastructure needs. While at work I'm rolling out an increasing array of infrastructure containers whose purpose is to make deployment of the actual applications a breeze as I'm transitioning a full private cloud system towards Docker.

http://www.hokstad.com/docker/patterns

有关 DevOps 的五大误解

DevOps 是如何降低别的已建立的最佳实践来显自己，并吸引了的很人， 这令我感觉到很不可思议。突然之间 ITIL, COBIT 和平衡计分卡全部失宠了，与此同时，DevOps 的拥护者又主张 ITIL, COBIT 已经没有用了，应该丢弃了。

虽然 DevOps 基于敏捷思维、改变和持续交付，但 IT 服务管理过程还是需要确保弹性和稳定性，这仍然比以往任何时候都更重要。所以不要随波逐流。

[b] 误解三：DevOps 是技术运动 [/b] 关于 DevOps 有很多非常好的技术资料，以及许多新的思考方向，所有这些都由新产品和技术所支持。虽然它是有价值的素材，但有一句经常被遗忘老话说：自动化坏流程只会导致更快的坏流程。所以只是通过良好的新工具而建立的快速应用开发商店，但完成的工作却不能满足业务或客户的期望，这也不具任何意义。

[b] 误解四：我们业务对 DevOps 免疫 [/b]

许多组织认为 DevOps 的原则不适用，因为他们已经外包了，或者是工没有应用程序开发功能。另外一些人推测说，因为他们工作产品制造企业或政府服务交付中，任何基于推动连续变更的运动，在 “没坏，就不要修复它” 的世界中都不占有一席之地。

[b] 误解五：DevOps 将改变世界 [/b]

因为宣传过度，许多人会把 DevOps 当作急救 yao。但是考虑一下这个场景：无论是最佳实践、方法或运动，应用程序开发项目的成功率 20 年来改善不大。虽然 2012 年开始成功的项目有很多，但 61% 的项目仍然面临着挑战，缺乏竞争力。

有人调侃说，DevOps 涉及到五个方面：人、人、人、人，还是人。所以在迈入 DevOps 大门前，先想想你的团队的文化、流程和指标。如果不能满足客户需求，DevOps 就不会有效果。DevOps 是否真的能给开发人员和运维人员之间带来平衡，其实还需要进步的实践。

[i=s] 本帖最后由 laofo 于 2014-10-30 16:58 编辑

采用 DevOps 的文化挑战

尽管 Rebel 实验室没有保证在 2014 年再做一次 DevOps 调查，但 Oliver 认为 “如何更好地了解组织为什么不采用 DevOps，有哪些实际的困难？这包含现实问题和文化问题，是一个值得探索的有趣领域。”

你真的了解 DevOps 吗？

windows 还是 Linux ？

能否抓个图看看？

苏州这一年多发展十分迅速，很多软件研发公司陆续在苏州开新的研发中心。。。。南京在这方面动作的确不多。 考虑下苏州？

C:\Users\laofo>tfsbuild Microsoft (R) TfsBuild Version 10.0.0.0 for Microsoft Visual Studio v10.0 Copyright (c) Microsoft Corporation. All rights reserved.

TfsBuild help [command]

command The name of the command you want help on

List of commands:

start Starts a new build on the build computer delete Deletes completed build(s) destroy Destroys completed build(s) stop Stops the build that is in progress help Prints this help message

C:\Users\laofo>

话说，都用 TFS 了，为啥不试试 TFSbuild?

一帮人老说上海 SCM 少，这不是挺好的职位嘛

不过口令有点特别，呵呵

需要很多个。其实现在如果公司真给你办理户口不是很难，关键公司是多一事不如少一事。

不错，以后还真应该注意这个问题。

很多时候 windows 自己是不区分大小写的，但是 Jenkins 区分。