记云架构师与 OpenStack 的一天

我们抢在OpenStack东京峰会之前对二位进行了专访，题为《记一位OpenStack/云架构师的一天》。其中Vijay阐述了云及OpenStack架构的理论定义以及企业对这项成果的接纳情况，而Vinny则立足于自身探讨了OpenStack贡献复杂性及其持续集成与持续交付(简称CI/CD)实践。他们的状态相当活跃，以颇为幽默的话锋解答了我们提出的诸多疑问。

什么样的技术从业者算是云架构师?云架构师与其它架构师角色之间存在着哪些差异?

Vijay Chebolu (以下简称VC): 云架构师指的是那些同时担当着业务与技术领导者职务，负责设计并构建一整套云体系，并确保其能够解决企业中具体业务需求的职能角色。一位云架构师需要拥有宏观层面的业务审视角度，并具备推动云构建项目走向成功的必要技术能力。

Vinny Valdez (以下简称VV): 我打算根据自己的实际感受谈谈云架构师与其它类型架构师之间的区别，他们往往需要对数据中心之内的各信层面拥有深度了解及专业知识积累，具体包括系统管理、自动化、虚拟化、存储以及网络等等。云架构师需要有能力理解复杂的整合体系，从而设计出适合业务需求的解决方案。以我们自身为例，我们可能需要亲自动手完成工作并执行一些物理层面的实现任务。云架构师应当了解企业业务，同时又拥有高超的技术水平——单纯在白板上勾勾划划是不足以成为一名出色的云架构师的。

OpenStack架构师拥有哪些独特的素质?我们该如何将自己培养成一位OpenStack架构师?

VC: OpenStack项目是一种全局性的开发人员与云计算技术人员协作项目，旨在构建起能够同时面向公有云与私有云环境的标准化云计算平台。OpenStack架构师的主要任务在于为企业环境配置、设计并部署一套基于OpenStack的云体系。负责这套平台设计与开发工作的应该属于OpenStack产品架构师，他们的目标在于让OpenStack成为实际上的云计算执行标准。而负责利用私有云以及公有云为这套云平台提供所需资源的部署人员则属于OpenStack部署架构师，他们的主要任务是建立起一套具备可靠性、可扩展性以及安全性的OpenStack云体系。

您认为目前OpenStack的实际普及程度如何?OpenStack是否已经做好了全面进入企业环境的准备?您又是否能与我们分享几个企业客户主动采用OpenStack技术以及相关作法的实例?

VC: OpenStack在过去五年当中已经得到了长足发展，而且最近开始为众多企业所关注。OpenStack在最近的几个版本当中致力于进一步提升平台自身的可靠性与稳定性，从而帮助其获得更为强大的企业客户吸引力。受到多位大型供应商的有力推动，目前OpenStack已经做好了与企业业务环境对接的准备。目前使用OpenStack早已不是什么需要遮遮掩掩的秘密，以Comcast、沃尔玛以及CERN为例：这些都是企业采用OpenStack技术的绝佳实例。甚至一部分金融服务机构，例如美国银行，也已经开始将OpenStack纳入其主要云体系当中作为备选平台。

Vinny，您曾经是OpenStack项目的贡献者之一，特别是参与到了《OpenStack架构设计指南》的编撰工作当中。我们也希望能够为OpenStack做出自己的贡献，那么您对于我们参与OpenStack开发的热情有哪些指导意见?需要满足哪些先决条件?OpenStack的组织结构又是怎样的?

VV: 我认为首先需要指出的是，大家其实并不一定非要以专业开发者的身份参与贡献。OpenStack维基百科当中给出了大量很好的且适合作为起点的贡献方式。具体贡献方式当然取决于大家的实际角色定位，例如开发人员、作家、设计师、安全专家乃至测试人员等等。如果大家无法确定自己适合哪种出发点，那么先从说明文档着手也是不错的选择。参与OpenStack贡献并没有什么硬性的先决条件。整个流程就是创建一个合适的账户，而后签署贡献者许可协议就行——是的，就这么简单。

说起上面那份设计指南，其实我算是非常幸运。在这份材料的编写过程当中，我以志愿者的形式加入了一份电子邮件通信名单。我所在的公司对此深表理解及支持，愿意给我一个礼拜的时间从而这方面工作，甚至提供专门的经费保证我能够与其他十二位来自其它企业且才华横溢的社区成员共同协作。我的大部分贡献都在此阶段完成，当然后续还对具体内容进行了深入调整与添加。因此我给大家的建议时，一定要加入项目相关邮件通信名单来寻找未来的贡献机遇。我知道每个人都为了日常工作忙得不可开交，但哪怕再小的贡献都会对项目的未来产生积极作用。如果大家发现了一处输入错误、一个bug或者构思出了一项新功能，那么即使各位本身不知道如何编程/修复/撰写，也可以把思路或者规划蓝图提交给其他协作人员。

您对于那些刚刚准备采用OpenStack的企业会给出怎样的建议及提示?OpenStack部署工作中存在着哪些常见陷阱，企业又该如何加以规避?

VC: 在企业当中变化总是需要与固有惯性相冲突。企业当中的常见误区之一就是努力把OpenStack作为传统的Mode 1虚拟化平台来看待。事实上，从实际要求及用例出发总结需求，再将其与OpenStack所能提供的用例相印证往往是比较好的选择。我已经无数次亲眼看到企业之所以有意采纳OpenStack，单纯是因为它是业界当中火热出炉的新鲜事物。每一套平台都拥有自己的特性与定位，大家不可能在遵循传统思路的同时将其纳入体系。就如今这个双模式IT的时代之下，最重要的就是理解Mode 2 IT的实际要求。OpenStack是一套非常适合支撑创新型Mode 2环境的平台，因为其要求企业立足于DevOps原则快速交付产品及解决方案，而这一原则的核心在于将基础设施作为代码资产进行处理。

您能够谈谈OpenStack的开发流程——包括审查、测试、持续交付以及持续集成?

VV: 除了起初的账户注册与CLA设置，接下来最重要的步骤就是设置并使用Git。我们当然可以通过很多种不错的方式来作为起点，但最好的选择无疑还是使用Git并进行实践。在刚刚上手的时候，Git往往会带来比较陡峭的学习曲线——特别是大家从未使用过Git或者此前使用的是其它版本控制系统，不过一旦理解了其工作流程、大家就会发现这才是最高效且最具逻辑性的方案。目前我们几乎在利用Git处理一切任务，包括客户配置、内部项目、内部培训文件乃至各类开源项目。一旦大家熟悉了Git，接下来要做的就是使用一款名为git-review的插件模块，其能够与OpenStack Gerrit审查系统相对接。整个工作流程为选取需要处理的对象、将其复制至本地库、在git分支当中进行本地化变更、提交本地变更、运行单元测试、而后将其提交至Gerrit审查系统进行审查。到这里，持续集成/持续交付系统会检测到变更内容并向审查人员发出通知。至少要由两位核心审查人员批准通过之后，对应的变更内容才会得到认可并被整合到项目当中。这只是对整个流程的简要概括，大家可以点击此处了解与之相关的更多详情(英文原文)。

随着云平台数量的持续增长，我们现在是否有必要利用标准化规范来避免供应商或者平台锁定的问题?

VV: 绝对应该。企业最担心的就是自身业务体系被牢牢锁定在特定供应商身上。特别是在开发人员需要将成果部署至多种平台，或者从某套云体系迁移至其它云体系当中时，供应商锁定会给企业带来非常严重的问题。红帽公司一直专注于解决上游锁定难题，这不仅是为了帮助客户避免困扰，同时也是为了让整个技术社区更为自由。我们建议其它企业也应遵循同样的处理思路。

我们曾听不少客户提起过，开源技术对于企业并不太友善，特别是在说明文档支持以及采纳客户变更请求方面。总体来讲，您对这个问题有着怎样的看法?我们该如何加以处理?具体来讲，OpenStack社区是如何解决这类难题的?

VC: 认为开源对于企业用户不太友善的观点其实并不准确。没错，不能否认很多开源项目在初期发展阶段会带来说明文档质量低下等问题。不过有了红帽这类大型企业的支持，如今客户已经能够以更为便捷的方式实现自己的变更请求，而红帽则在推动上游技术调整方面拥有强大的能力。

Vinny，您的孩子们似乎对技术很感兴趣。那么作为父亲，您希望自己的女儿们能够在怎样的世界中成长，特别是与技术及开源相关的时代背景?

VV: 我的孩子们是挺喜欢技术方面的东西。我对于有这样的小孩儿感到无比骄傲。我也很高兴地看到她们的成长环境比我小时候有着更多技术元素，而她们在上学及玩耍时所接触到的技术元素之多也令人感到讶异。我七岁的女儿Faryn曾经缠着我，让我教她如何开发一套《我的世界》Mod，而我向她推荐了Scratch作为学习起点。我的两个女儿，特别是9岁的Ava，已经开始通过Khan Academy来提高自己的数学水平了。

她们小的时候，我给她们的是一台装有Fedora系统的笔记本电脑，她们会在上面玩玩儿童游戏。这一切都源自开源贡献，而我也建议其他家长能够充分发挥由此带来的积极作用。对我而言，接下来要做的就是购买一台3D打印机，并指导她们如何使用Blender——这样她们就能自己设计并打印出喜欢的玩具了。我希望这种趋势能够持续下去，而我的女儿们也能够借此充分发挥自己的想象力——这一切都要归功于开源理念。

关于OpenStack

OpenStack是一个由NASA(美国国家航空航天局)和Rackspace合作研发并发起的，是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。