SuperMap Online是国内首家提供GIS云主机业务的在线GIS平台，可实现GIS数据的在线托管与应用。作为需要实时、在线运维的互联网产品，既需要不断开发、上线新功能，又需要保证在线网站的稳定、可靠。开发上线新功能与稳定的运维之间似乎天生就存在冲突，而产品总要不断推出新功能，如何才能做到持续的交付上线？秘诀就在于SuperMap Online引入了DevOps理念！
DevOps是什么？有什么价值？谁最需要？SuperMap Online又是如何成功应用的？
本文将为您揭晓SuperMap Online在DevOps方面的实践，分享DevOps带来的持续、高效交付。
##什么是DevOps
DevOps（Development和Operations的组合词），望文生义：开发+运维？是又做开发又做运维的岗位吗？
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、活动或惯例，可以直观描述为“开发团队与运营团队之间更具协作性、更高效的关系”。再具体一些，我们可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
DevOps的主要目标是，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。DevOps涵盖了代码开发、构建、测试、发布以及部署和反馈等环节，闭合成一个”无限大”符号（∞）形状的DevOps能力闭环。可以说，DevOps是一种使持续交付成为可能的理念，关注于所有人共同协作以改进开发效率、提高生产力，同时增加稳定性并降低平均故障修复时间。
高效和低效之间这么大的差别是怎么产生的？
体会一下，你和你的团队是否害怕部署？是否害怕新部署带来的“变更”会打破现有的一切？
对于传统的软件开发方法而言，部署通常都是罕见、痛苦且具有破坏性的事件。而对于应用DevOps实践的组织而言，部署则是经常的、没有痛苦且可靠的。这就是DevOps给产品团队带来的最大不同。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，按照以前的工作方式，开发和部署不需要深入的跨部门的支持；而现在，基于DevOps理念却需要极其紧密的协作。当然，DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。需要频繁交付、持续交付（Continuous Delivery）的企业可能更需要DevOps，高效交付正是DevOps的初衷。
看到这里，你是不是觉得DevOps已经牛到飞起现在就想引进团队？亦或觉得DevOps只是在敏捷开发的基础上加了个运维？嗯，是（在敏捷的基础上再进一步到生产环境下），也不是（环境复杂度更高且跨部门协作更多，不只是量变）。
##持续交付：SuperMap Online的DevOps实践
DevOps，是文化，是理念，是技术，是方法论，也是流程和工具的实践。文化理念是略玄的，几句话道不尽，而流程和工具则是可以学习和实践的，下面我们结合SuperMap Online的实践来具体体会DevOps下的工作流程。先来个总体流程图，避免看晕。
- 不间断“上线”，需要不定期地把新功能部署到生产环境下的在线网站上，并不中断服务
- 监控，后台各类进程的服务状况、日志收集、异常报警，日常运维以此为基础
- 灾备，需保证7*24小时不间断服务，做灾备节点、提供故障切换机制，主节点有故障自动切换到备用节点
- 随时可回滚，必须可以很容易的回滚到前面的版本以处理意外问题
所以，要实现SuperMap Online生产环境下的持续交付（Continuous Delivery），在流程上，除了持续集成（CI），还需要关注持续部署（CD）、监控、灾备、故障恢复等。
###实践2：基于公有云环境的持续部署
首先，什么是持续部署（CD）？
我们知道，CI的目标是对开发团队的代码进行集成，包括代码的构建、单元测试与集成测试的执行，以及生成执行结果的报表等等。而CD是与CI紧密联系在一起的下一环节。CD（Continuous Deployment）过程通过在管道（DeploymentPipeline）中定义的步骤，将CI生成的结果部署至集成、预发布环境甚至生产环境中。CD的过程是“持续的”，理论上，一旦有代码签入源代码控制系统，后续过程就会自动进行测试、对代码进行构建、并将构建结果部署至目标环境中。
结果很美好，但是如何做到“持续”则是一个难题。DevOps理论出现了这么多年，到这两年用的人才真正多起来，原因就在于IT技术已经发展到了可以支撑“持续性”，而这项技术就是云计算。基于云环境的自动化部署，在保证基本安全性的同时，可以利用云的高可伸缩性、高可用性，并降低成本（按需使用）。同时，基于云环境的部署本身是自服务的，可以缩短部署周期，从而使得持续部署的“持续”、“频繁”成为可能。
SuperMap Online作为互联网产品，其部署环节需要直接将产品或新功能部署到生产环境下。如果采用传统的手动搭建环境、自行部署，则更新部署的周期必然很长，这显然不能满足互联网产品的需求。而云计算技术的发展和成熟，使得DevOps有了更多的配合工具，且SuperMap Online本身是部署在公有云平台（阿里云）上的，因此其持续部署也首选公有云环境。
具体来说：SuperMap Online产品经过CI验证并打包后，会通过自动化手段，持续部署到公有云平台的生产环境。基本流程是：
- CI打包，发布包含新功能的完整产品包
- 自动上传至服务器
- 目标服务器（公有云）定期检测，发现新包
- 自动下载至目标环境（生产环境）
- 自动配置目标环境
- 完成部署并生成部署报告
部署周期一般跟随团队进展，可固定为1-2个迭代周期（理论上可以每天，但根据实际需求只需短周期频繁小部署），同时也会根据功能需求，随时更新上线。
###实践3：自动化部署测试与上线前内测
- 自动化测试
作为在线产品，SuperMap Online的自动化测试，包含两个部分。
一方面，与源代码一起提交、构建、运行的自动化部署测试，即持续集成（CI）的一部分，让我们代码的每一次提交都可以触发一次构建/测试。自动化测试不只是单元测试（UT），还包含模仿用户行为的集成测试IT和验证测试VT。
另一方面，为了验证在线SuperMap Online网站的实时有效，也会对网站进行基本的可用性测试。这部分测试代码（VT）会定期向网站发请求，确保SuperMap Online可访问、可登录、基本功能可用（PS：主要覆盖实时运维监控做不到的粒度）。
- 利用“镜像”网站（itest）上线前内测
前面我们介绍了SuperMap Online的持续部署是直接部署到在线的生产环境下，是直面最终用户的。是不是听上去有点紧张？是的，从产品包直接到生产环境，是有风险的。考虑到这个风险，SuperMap Online的部署并不是直接从CI打包就部署到生产环境，中间还有一步终极保障——上线前的内测。
上线前内测，是在新功能正式部署上线前，通过自动化流程将新功能、新变更都部署到专门用于内测的“镜像”网站，这个“镜像“就是专门用来模拟SuperMap Online生产环境的。通过在镜像网站的内测（自动化VT+手工），可以保证这些新功能、变更可以满足预期，且不会带来其他额外的问题。此时，才可以通过自动部署流程将这些新功能和变更同步到真正的生成环境下，即SuperMap Online网站。
那么，到这里，持续交付的流程就结束了吗？当然不是，一个在线运行的网站还需要持续的监控及日志体系。
###实践4：持续的监控和日志体系
搭建一个持续可靠的监控/日志体系，就是一个持续检查和反馈的机制，这样才能形成上文提到的DevOps”无限大”闭环。
- 基于公有云平台的持续监控
SuperMap Online部署于公有云平台，直接使用云平台的监控功能来实时监控SuperMap Online站点，如CPU，内存、IO等服务器资源，以及网络流量。如果网站或服务器出现异常，监控平台会通过邮件，短信自动报警。
- 持续的可视化日志体系
通过日志体系可以实时检查并展示服务器和应用程序的运行状态，如应用请求和错误等。同时，对服务器和应用程序的问题日志进行格式化处理，有利于排查，方便定位问题。此外，一个完善的日志体系还包括日志的集中管理（分布式系统尤其需要）与可视化分析。虽然文本形式的日志更详细，但是不易阅读和统计分析。
SuperMap Online采用ELK（ElasticSearch+Logstash+Kibana）实现日志统计与可视化，通过这种持续的记录、处理、管理、分析，汇集所有干系进程的日志，为网站的持续、稳定、安全运行提供保障。
2870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
