［OT］求拍砖

[毅涛 杨]

我们团队最近在做一款产品。涉及到很多服务器运维和运营的。希望大家能够一起拍砖。能够提出一些建设性意见。

这个产品理念如下。当然，已经做的差不多了。

云计算时代，我们告诉你如何高效软件交付。

2014年2月，微软新CEO 萨蒂亚·纳德拉正式上任，提出“移动和云计算”的战略方向。3月，微软发布针对iPad的免费版Office，支持微软OneDrive服务，实现多屏与云平台的无缝打通。无独有偶，云存储服务商DropBox 5月宣布其用户超过三亿人。随着数据与流程的云化，更多的企业接受BYOD（Bring Your Own Device），办公成本以及效率都得到了极大的改善。

新型企业软件极大提升了办公效率，软件研发组织和项目团队又可以从云上获得哪些好处呢？传统软件交付过程里面存在哪些协作与效率问题？这些问题是否能通过云服务来改善？

软件研发组织分析

以某传统软件组织为例，一个典型的软件研发组织往往由以下的部门以及角色组成。它往往具有以下的特点：

图1

典型的软件组织结构

•矩阵式管理：员工同时隶属职能与项目两条线：职能部门主要着眼于员工能力的建设以及资源的调配，项目线则负责具体项目的交付。

•项目团队：项目通常由业务部门牵头，从各职能部门选调员工组成团队，一般包括项目经理、需求分析、开发和测试等几类角色。

•IT支撑部门：负责线上的软件系统监控与维护，并满足项目交付团队对于IT设备等基础设施的要求，一般作为一个整体为不同的项目团队或部门提供IT服务。

在部门壁垒比较深的软件公司，项目团队内部不同角色之间、项目团队与IT团队之间的协作效率存在很多问题。重点表现在：

•协作流程长、审批环节多：项目团队角色之间的协作往往需要经过部门间的沟通、甚至更高层领导的介入。由于涉及部门间的协作和审批，项目团队对一台测试机器的申请都需要2～3周。

•低效的文档与会议：不同的角色有各自的工作重点和诉求，很多时候只能通过文档或会议作为跨部门的主要协作方式，没有围绕着可发布的软件制订项目成功的衡量指标。

•IT支撑部门成为瓶颈：80%的精力在维护20%的线上维护工作上，无法及时支撑多个项目交付过程对于研发环境以及发布的要求。IT团队往往困于加班和无价值的繁琐工作。

•所有操作都依赖于手工：无论是项目的构建集成，抑或环境的创建配置，又抑或软件包的发布上线，这些活动都依赖于手工，不仅繁琐，而且易错。

由于以上的问题，我们在软件组织或者团队中经常可以看到项目团队很难得到有效的发布候选包、发布候选包从未做上线工作验证、项目团队缺乏足够的类生产环境进行上线验证等问题。这些问题就严重制约了软件组织的软件交付效率和质量，无法满足外部业务市场的要求。

外部市场对软件交付的要求

新兴业务的方兴未艾，云计算、互联网金融、大数据、互联网思维等对企业的传统业务造成了很大的冲击。余额宝自去年问世八个月以来就获得了1500余亿资金量，一跃成为全国最大的货币基金；小米手机在成立两年多销售额超过100亿，去年双十一3分钟销售过亿，超过了诸多老牌国产手机厂商。

“站在台风口，猪也能飞起来”，这些成功案例背后是其强大的快速、高效软件交付的能力。据统计，Amazon的平均部署时间是11秒、一小时最多部署1079次、一次最多部署30000台服务器。看起来不可思议的数字是如何做到的？《大规模敏捷开发实践：HP LaserJet产品线敏捷转型的成功经验》一书透露了成功的奥秘——高效的持续交付平台：

图2

HP LaserJet分层持续集成

•分层的质量验证流水线：按照产品团队结构，分为多个阶段的持续集成，频率从每次代码提交触发构建到每天构建不等，每个阶段包括不同的测试类型，以过滤不同级别的缺陷。一旦失败，将自动记录故障，并通知相关人员。

•充分的功能验证环境：不同阶段的测试都有独立的类生产部署环境来保障功能的充分验证，并不会因为资源问题而陷入等待、甚至出现测试不充分的情况。

•快速的自动化发布：不同团队的子系统版本包都实现了自动化部署，可以快速地部署到类生产环境上，不仅触发下一步的自动化测试，也验证了版本包发布到生产环境的风险。

市场的高度不确定性对软件团队的协作和效率提出了更高的要求，而传统软件组织结构对管理职能和专业性的强调很难满足软件的高效交付。因此，打破项目团队与IT团队的部门壁垒势在必行。项目团队引入持续交付基础设施和实践，IT支撑团队给项目团队提供充分快速的部署环境服务，项目团队与IT支撑团队一起维护软件系统的自动化部署。尤其在中大型的软件组织里面，为了避免成为瓶颈以及更好地推广持续交付，IT支撑部门（或者质量中心）应积极定义组织内项目团队需要的持续交付服务和环境服务，并将其固化下沉为基础服务平台，以支撑上层的项目团队。

云上的软件交付

面对市场需求的不确定性，软件组织里面需要一个持续交付平台（或者称之为持续交付云），打通部门间的协作。持续交付平台借助底层云技术的支撑，向不同的软件研发团队提供软件交付过程中对持续集成服务、环境服务以及部署活动的支撑。那么，持续交付平台应该提供那些服务呢？

图3

持续交付平台架构

•云基础设施：可以是各类IaaS公有云、私有云或者虚拟化管理软件（VMware、XenServer、Hyper-V等），通过可编程的API为上层的各类服务提供弹性、快速的虚拟资源服务。

•项目环境服务：项目团队交付所需要的基础设施以及支持性服务统称为项目环境服务，主要包括代码分支策略、持续集成、应用包版本库以及针对环境配置的服务。

•项目持续集成流水线：针对每个项目提供代码集成服务，包括编译、单元测试、代码检查、数据库、自动部署和测试等阶段，一般覆盖项目团队从代码到上线的完整质量验证。

•交付报表：为项目软件交付评估提供软件质量和交付风险的可视化，同时提供项目团队软件质量的横向与纵向对比报表，为团队的质量改进提供决策依据。

当软件组织建设了持续交付平台之后，项目团队的不同角色以及IT团队之间的协作就变得非常的简单和高效

•项目初期：IT团队在持续交付平台上创建针对项目的持续集成基础设施、代码库等环境服务，并按照一定的标准初始化持续集成流水线，项目团队可以快速进入开发。

•项目中期：持续集成服务持续地对代码修改进行集成和验证，项目团队可以根据环境配置服务快速得到所需的测试部署环境，再从持续集成流水线获得可供部署的版本包，并通过自动化部署到类生产的环境（单机或者存在依赖关系的集群），项目团队的其他成员（业务人员、测试人员甚至客户）可以及时手工验证。

•项目上线：项目团队从已验证的应用版本包中选择合适的版本包，提交到发布候选包资源库里面。IT人员在查验过发布候选文件之后，执行自动化部署到生产环境上，并自动执行部署后的验证脚本。

•监控日志：在整个过程中，项目团队所有的操作变更都会通过事件日志记录作为追溯。IT团队只需要监控IT基础设施的整体运行情况，而不用花费时间精力手工去为项目团队创建、配置机器，IT团队只需要及时响应监控预警即可。

综上所述，项目团队与IT团队在持续交付平台上自助式完成所有的操作，极大地减少了项目过程中的审批和等待时间。同时，通过自动化的集成验证帮助项目团队实时验证软件版本的质量、自动化环境服务帮助项目团队得到充分的类生产测试环境验证以及自动化部署及早验证软件版本包的上线风险，持续交付平台帮助项目团队实现了高效的软件交付。

云上的软件交付实践

为了支撑以上的持续交付平台顺利运行，我们需要在团队和组织中引入如下的实践：

图4

持续交付平台实践

•DevOps：开发人员与运维人员相互向对方学习其技术和理念：一方面，引入各种自动化工具，减少手工运维，如Fog操作底层虚拟平台、Puppet提供环境配置管理、Capistrano完成自动化部署、Nagios/Logstash进行机器监控；另一方面，开发人员参与运维，导入自动化运维工具，并及早将运维场景（心跳检测、日志等）纳入需求开发中去。

•EaaS（Environment as a Service）／环境即服务：项目获得环境的周期时间是衡量软件交付高效与否的重要指标，尤其是存在复杂依赖关系的集群环境。软件组织可以使用环境配置管理工具，如Puppet/Chef/Ansible/Chocolatey等，将单机环境或者集群环境的软件安装、环境配置等工作自动化起来，再通过storeconfig或类似AWS CloudFormation/OpenStack Heat等工具完成复杂集群环境的自动化配置。理想情况下，项目团队只需要在网页上选择需要的环境模板，持续交付平台可以自动创建所需的虚拟机，并完成虚拟机之间的网络、依赖关系等设置。

•Package Versioning／包版本管理：版本包是由专人手工生成、管理，还是通过自动化版本工具管理，这也是判断软件团队交付高效与否的重要指标。不同语言技术的版本包格式，如Java的jar/war、C#的NuGet等，但些版本包格式都不是自安装的格式，不足以支撑生产环境的自动化发布。建议采用RPM/DEB配合各自资源库（如yum repo），利用RPM／DEB的版本生命周期机制，实现自动化的环境检测配置、安装动作以及安装后的验证清理工作。

•Release Pipeline／发布流水线：软件的发布应该遵循合规性等要求，包括待发布版本包验收、目标环境验证、版本包部署、部署后验证等几个阶段。其中要注意部署后验证的自动化，以及时发现缺陷并采取回滚或修复等措施。通过采集发布过程的数据，生成发布报告，对发布的时间、日志、验证结果、性能对比等进行分析。

建议

市场上的云服务已经如火如荼，在笔者“冲击巨人，梳理云计算的2013-2014”一文中分享了对于对未来云服务发展趋势的预测。那么，面对互联网上各种可信的云服务，软件组织或团队应该如何抉择？笔者认为，软件团队应从效率与管控两个维度出发，结合自身对云服务的需求，针对性地选择云产品和服务：

无论是自建服务平台抑或使用公有的云服务，软件团队都应可以自助式地获得交付所需的各种环境和服务，从而关注于软件本身的开发与实现，并缩短业务人员对软件新功能的反馈周期。为了这一点，软件组织应该及早评估云服务的引入或建设，并借助专业顾问的力量，为软件团队打造高效的软件交付平台。

结语

人类从远古时代走来，面对自然世界的生存竞争，学会了协作；进入到工业社会，当用泰勒与“蓝血十杰”为代表的科学管理法武装之后，人类第一次登陆了月球；在进入互联网时代，市场的不确定性日益增长，软件的高效、高质量交付成为追求卓越的软件组织的诉求。

在历史的发展长河中，分工协作的演变又往往伴随着工具、流程的演化，从而促使工作效率的提升。蒸汽机解决了交通和工业生产的效率问题，福特流水线解决了汽车装配的效率问题，丰田精益的U型工位又解决了任务切换的效率问题。

云计算的时代已然来临，弹性、集中的云服务给软件研发带来了无限的便利和可能。当软件组织中传统通过组织结构、流程的协作方式被集中的持续交付平台服务替代，支撑团队的管理智能转化为服务，项目团队专注于开发，整个软件组织的效率得到极大的提升。到时，又何愁“台风口难觅，灯火阑珊”呢？

[Abioy Sun]

其实你只要用三句话说清楚你的产品就可以，这么长，一般没人看的。

--
--
高性能服务器研发与运营
http://groups.google.com/group/dev4server
---
您收到此邮件是因为您订阅了Google网上论坛上的“高性能服务器研发与运营邮件列表”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到dev4server+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[zhuo yikang]

的确，我准备之后看，结果忘了。。

[lit...@gmail.com]

这东西叫持续交付，难点在数据的平滑迁移，其他东西在云上都相对容易做

---

lit...@gmail.com

 

发件人： 'zhuo yikang' via 高性能服务器研发与运营邮件列表

发送时间： 2015-03-13 22:58

收件人： dev4server

主题： Re: ［OT］求拍砖

[Yunfan Jiang]

不错 主要就是数据迁移 尤其是涉及冲突性的数据结构修改 

Name: yunfan
Site: http://geek42.info/
Interest:
  - Lang: [forth, clojure, c, python, lua]
  - software: [nginx, redis]
  - abstract: [vm, tiny, cloud, html5]
  - history
  - science-fiction
  - music: [new-age, vangelis, yanni]