纵观十年的软件行业发展，云计算，云服务已经逐渐深入到了互联网企业的日常运作当中。云服务的便捷性，可靠性，安全性，成为了企业降低综合成本、提高人员利用率的不二法宝。

---

2010年，项目组特意购买了十多台DELL的小型服务器以及一些硬件设备，用于电信软件产品的开发测试。为了确保这些宝贝疙瘩的稳定运行，我们特意重新装修了一个办公区域。除了强弱电这些基础改造外，我们还铺设防静电地板，安装独立空调，更换灭火喷淋设备，甚至还特意规划出了一个更衣区域。

2020年，借助于云服务，软件研发的办公地点变得格外灵活，不管是在公司，还是在家，甚至在动车上。

服务器上云

2014年底，我入职一家商业软件企业，该公司主要通过销售软件盈利。

公司的办公区域也有一个10平米左右的机房，里面除了陈列着好几个机柜外，空置区域还放置着好几台服务器，地面和天花板上可见各种临时接的网线。只要一打开门，各种服务器的轰鸣声就会覆盖整个办公区域。就算配备了UPS应急电源，也不排除一些极端情况导致服务器断电，出现官网无法访问的情况。并且，还得安排专人负责机房的温度、湿度、以及可能出现的墙壁渗水，服务器宕机等状况。

2016年开始，我们摒弃了把官方网站放在自有服务器上的方式，而是采用租赁阿里云ECS，把整个官网放到了云上。这样，就不需要考虑本地机房或者IDC机房是否会由于停电导致官网无法访问，也无需考虑关于机房的实际情况。

在这期间，还发生过一件有趣的事情。运维团队直到服务器续费时才发现由于扩容疏忽没有手动重启实例，导致了一年前的购买的扩容包实质上并没生效。也就是说，该ECS实例已经零停持续运行了一年以上的时间。

至于服务器的安全性，通过设置访问白名单，把阿里云的ECS服务器的远程管理端口仅仅开放给研发运维团队所在网络，运维团队通过VPN登录跳板机对服务器网站进行更新。除了有次因为Docker自身漏洞导致的异常登录报警外，服务器没有出现过其他的安全相关问题。

在前期，我们的数据库服务器依然是使用手动安装在ECS上的Mysql-Server，由公司运维人员进行日常维护的，偶尔会出现诸如磁盘空间耗尽所导致数据库错误的情况，运维团队会花费人力去分析解决由于环境所导致的各种问题。因此，我们开始思考一个问题，既然阿里云新出了云数据库，为什么不尝试尝试呢？借鉴灰度发布的经验，我们把测试环境的数据库切换到了云数据库，在运行一段时间后，云数据库的优势已经很明显了，维护方便，性能也够用。据此，生产环境的数据库也顺理成章的切换到了云上，通过数据库迁移的方式把原本存储在ECS上的内容切到了云数据库里。

逐渐，企业的测试环境和生产环境也全都上云了，不同环境之间通过VPC技术进行网络隔断。这下，企业机房里的设备仅仅剩下企业路由器和交换机。同时，我们还是保留了几台用于存储备份云上数据的服务器了。后来发生的“前沿数控技术事件”，证明了在本地做一定程度的备份还是很有必要的。为了进一步压缩机房空间，我们把有线网络做了进一步的精简，企业日常办公所使用的网络也从有线网络逐步切换至无线网络。并且在研发团队的无线网络出口增加了个跳板机，研发同事能够无障碍的链接到云上研发测试环境中。

应用上云

以往的研发经历中，我们有购买第三方商业插件授权，用于数据报表统计相关工作。但是因为缺乏持续维护更新，该插件属于。偶尔，开发和测试的同时会相视一笑：又是那个插件的问题，对吧。

新的架构设计中，我们放弃了购买第三方的商业插件的计划，而是把目光投向了云服务。

系统中工商证照的读写功能，分别涉及到了证照的存储和识别两个技术点。按以往的开发模式，证照图像的存储会首先由运维工程师规划相应的目录，后端研发工程师根据项目的实际需要，通过编码的方式对文件进行管理。在这其中不可避免会涉及到文件存储介质，用户访问权限，运维容灾等问题。而证照识别方面，相对简单的方法就是参考部分开源项目，通过GPU运算对模型进行进一步的调优，然后通过后续业务对模型进行持续深入的优化。

用云服务替代独立授权插件在可维护性上有着无可比拟的优势，相关模块在开发效率和质量上都会有很大的提升。文件存储模块仅仅需要研发工程师调用云服务的API就可以完成文件存储的相关功能。而证照识别不仅正确度更高，而是费用也会大幅度降低。详见《OCR-链接》。而由于云服务的本质，使得这个购买的行为不再是一锤子买卖，而是按量计费，如果服务存在任何问题，随时可以通过简单的接口调整切换至备选的方案。以存储为例，这块在国内的大型云服务提供商备选方案有亚马逊AWS的S3，阿里云的OSS，以及腾讯的COS。由于前沿数控技术数据丢失的事情《加腾讯云声明》，腾讯云的COS被首先给排除了。亚马逊S3，稳定性和可靠性是没问题的，价格相对较高。而阿里云的OSS，在价格上相比AWS来讲会便宜些。加上我们现有的云服务器均使用ECS，所以，阿里云的OSS成为了我们的第一选择，而AWS则成为后备。

服务上云

在服务器和云服务上云后，我们开始思考另一个问题，能否借助于云服务，进一步降低服务器的运维成本，提升整体效率。

阿里云的ECS上除了运行着开发环境和测试环境外，还有不少的研发环境也在ECS上。例如，用于代码版本控制的Gitlab，任务管理系统Redmine，持续集成工具Jenkins，测试用例管理TestLink等。这些应用通过私有化部署方式安装，运维工程师通过升级的方式修复当前版本的缺陷，或者导入新的功能。除了在升级前做模拟外，每次升级还需要选择非工作时间进行。升级过程一旦出现异常，就得投入更多的时间和人力用于版本回滚、数据恢复的问题，甚至会对正常的研发工作造成影响。

以版本控制工具为例，云上主要有两种形态的产品提供方式，独立SaaS服务商和云服务商两种。独立的SaaS提供商专注于代码版本管理，依托代码管理工具做相应的扩展，例如：Gitee、Gitlab、Github、Bitbucket等。云服务商则是更倾向于提供一体化的研发过程解决方案，例如阿里云效，华为DevCloud，腾讯云Coding  DevOps。结合项目的实际情况和方式，我们选择相对保守的策略，使用Gitee作为云上的版本控制工具。除了部分核心代码外，所有的业务代码均存放在Gitee上，并通过中间服务器将每一次提交及时同步到备份服务器上。

当疫情爆发时，线上环境恰到好处的承载了虚拟团队的研发需求。业务开发模式快速从集中办公切换至WFH。针对虚拟团队运作过程中所发现的家用PC机性能和存储问题，后续考虑看看在线的IDE和文件存储NAS吧。