6.7　本章总结

    至今为止全手动部署的环境想要实现全部自动化，应该从哪里着手？回答是“先去寻找协助者和出资方”。

    部署的自动化是从开发人员、QA 团队到运维团队各部门通力协作的产物。请耐心地向他们讲解推进部署自动化会带来哪些好处，以推进团队齐心协力。

    除了团队的齐心协力之外，新的环境以及构建新环境所需的时间也是必不可少的。要向出资方、公司的管理层讲解部署自动化的相关内容。如果你所在的公司拥有充沛的资源，并且提供了类似于 Google 的 “20% 规则”这样的研究时间，可以在讲解前先着手进行自动化所需的工作，通过演示可运行的系统来进行讲解。如果能够频繁地向客户提供价值，对于大多数公司来说都会产生好的影响。

    如果团队内部有不合作的成员，最初他们可能会觉得麻烦而不遵守既定的规则，即便这样也请耐心地推进自动化。当部署自动化开始逐渐渗透到整个团队、整个公司时，它就成为必不可少的存在了。

    原来的部署需要专门的知识和经验，如果部署的自动化开始正常运转，那么这样的知识及经验就不再需要了。工作人员也可以通过维护自动化的环境，夜间得以安睡，节假日可以享受私人时间。而从公司的角度来说，对于能够让工程师幸福的部署自动化，也没有理由不实施。

    专栏　PaaS 的使用方式
    什么是 PaaS
    这里并不是要否定本章的内容，但构建自动部署的环境总要花费相当的成本。当然通过实现自动化应该能够获得与其投资相符合的收益，但那些因为项目生命周期短而希望投资最小化的情况下，或者是创新公司希望尽早获得用户反馈的情况下，可以考虑使用 PaaS（Platform as a Service）。
    PaaS 是一种由运营商负责提供从网络、OS 到应用服务器等中间件的服务。因为 PaaS 能够立即提供可使用的应用程序运行环境，所以开发人员能够专心于开发工作。
    PaaS 在国内外有 Heroku、Force.com、Google App Engine、Cloud Foundry、OpenShift、AWS Elastic Beanstalk、DotCloud、Windows Azure、IIJ GIOMOGOK、NIFTY Cloud C4SA 等众多提供商。
    选择 PaaS 时要注意可使用的语言及语言的版本、应用服务器（Apache Tomcat/jetty 等）、可使用的数据库服务、API 的提供、可扩展性、使用成本、插件的种类等。
    以 Heroku 为例，登录账户后从管理画面上传应用程序，只要向指定的远程目录实施 git push，就能启动 Web 服务了。无需安装或调整 Apache，只需在管理画面增加名为 Dyno 的 Heroku 特有的 Web 服务的进程数量，就能够处理大量的请求。开发人员只需要 10 分钟就能够搭建起可扩展的 Web 服务并公开。
    PaaS 的适用场景
    PaaS 能够方便地应用于初期的小规模开发，还能够调整规模。针对这样的特点，这里介绍几种有效的使用方法。
    • 创新公司希望尽早公开服务
    没有足够的资源构建开发环境、测试环境、正式环境的情况下，不要直接仅构建正式环境并公开服务，而是利用 PaaS 获取用户的反馈并反映到产品中，还可以筹措资金等。
    • 无法预测峰值负荷的服务
    提供手机游戏等峰值无法预测的服务时，可以利用易于扩展规模的 PaaS。当服务步入正轨，形成可预测负荷的运营体制后，再来考虑转移到公司内部运维等选项。
    • 生命周期短的服务
    例如限定期限为 1 个月的展会网站等，也可以使用 PaaS。展会开始时收到大量请求的情况下，可以预先扩展规模进行应对。展会结束后再缩减规模，这样就能够以最少的成本维持服务运营，客户解约的话也可以立即停止服务。像这样，无需负担多余的资产，非常适合于短时间的使用。
    • 融入到企业内部的部署流水线中
    很多 PaaS 都可以使用全球公开的 URL，因此可用于营业用的环境，或者为了获取特定顾客反馈的 demo 环境，这是个很大的优点。
    有了 PaaS 就不需要部署自动化了？
    在适合利用 PaaS 的场景范围内，也许可以说不需要环境的配置。但是，PaaS 也并不是万能的。使用 PaaS 之前，请仔细考虑 PaaS 的下列缺点。
    • 服务的使用量超过一定限度后，费用会激增
    vendor lock-in27 的风险
    • PaaS 的限制和应用程序的特性不相符的情况
    发生问题时，有时难以获得调查或分析原因用的日志
    • 向云运营方提出的监查要求可能不被接受
    想要的服务等级（service level）和合同内容或 SLA28 （Service Level Agreement）不相符的情况
    • 存在因无法确定问题原因而难以追究责任的情况
    当服务的规模增长到一定程度，PaaS 的费用和提供的服务等级开始变得不相符，或者由于公司的规则原本就和 PaaS 的限制不相符合等情况下，就很难继续使用 PaaS 了。在规划新的服务时，建议综合考虑应用程序的特性，探讨将程序部署到哪里。并且结合定期发布后服务的增长，需要重新考虑怎样的环境才是合适的。
    离开 PaaS 的时机
    可以考虑将在 PaaS 上公开的应用程序移植到 AWS（Amazon Web Services）等的 IaaS 环境，或者自行运营的公司内部环境中。例如，由于超过了预计的访问量导致 PaaS 的使用成本变得无法接受等之前叙述的缺点超过使用 PaaS 的优点时，就有必要移植应用程序。
    那么，移植时必须注意哪些事项呢？主要有以下 3 点。
    • 应用程序运行环境的构建
    数据的移植
    • 服务的切换
    第 1 点就是要构建新的应用程序运行环境。没有托管的服务器组或者自己的数据中心的情况下，可以使用 AWS 等的 IaaS 环境。构建环境时可以一边参考本章内容一边进行。
    第 2 点是处理持久性数据时，需要对数据进行移植。如果持久性数据保存在 RDBMS 中，可以取得 Dump 数据（导出数据），并预先确认好导入数据的操作步骤。导入、导出所耗费的时间和切换环境时服务中断的时间直接相关，因此需要事先验证需要消耗多少时间。支持增量备份的话，可以预先备份好实施移植之前的部分，这样能够使服务中断的时间达到最小。
    第 3 点是服务的切换。如果使用域名的话，可以预先缩短 DNS 记录的 TTL（Time To Live，报文的有效时间），为能够在瞬间完成切换做好准备。切换时禁止访问旧的环境（PaaS），可以通过显示维护画面来防止再向旧的环境存储数据。无法沿用之前的 URL 的情况下，需要考虑访问旧环境时重定向到新环境的调整方式。移植期间需要保留旧的环境，因此可以在确认访问量的基础上来决定关闭旧环境的时间。

    27 过度依赖特定供应商的独特技术进而无法替换为其他供应商提供的同类产品。——译者注

    28 服务等级相关的事前协议。主要是系统正常运行率相关的赔偿等内容。