企业业务发展到一定阶段，为什么容易遇到基础设施瓶颈？

很多企业的IT，都是这样一路长出来的。最开始只有一个官网和一套基础的办公系统，一台服务器就够应付。后来业务做起来了：订单要有管理系统，客户资料要有专门的软件，财务上了系统，业务数据需要数据库，还要和合作方对接，于是又多出各种接口。每一项需求出现的时候，想的都是先把眼前的事解决掉，机器多一台，系统多一套。

这样长出来的基础设施，往往没有经过整体规划。几年之后回头看，资源分散在不同的机器上，维护起来很繁琐，数据存在哪里、有没有备份、由谁负责，各个系统的说法并不统一。

所以瓶颈通常不是哪一台设备坏了，而是这些积累下来的零散问题。下面把企业日常运营中最常见的六类问题逐个拆开，看看云主机在每一类里能起什么作用，也会说明它解决不了什么。读的时候可以对照一下，自己的企业属于哪一种。

问题一：传统IT设备投入周期长，项目启动容易受到硬件准备限制

一个新项目要上线，如果依赖自购服务器，流程大致是这样的：先确定配置，询价下单，等设备到货；设备到了要安装上架、配置网络；接着装操作系统，部署运行环境；最后才轮到业务程序。中间任何一环卡住，项目就得往后拖。

临时加设备的时候，这个问题尤其明显。比如业务部门下个月要做一次活动，需要多一台机器，采购、机房、网络几个部门各有各的排期，协调下来，活动可能都已经结束了。

云主机的解决思路，是通过云端实例的开通和规格选择，让项目启动时不必先等一批实体设备。选好规格，开通实例，装好系统，就可以进入应用部署，前期等待的环节少了不少。需要提醒的是，这只解决了硬件准备的问题，应用本身的部署和测试，该做的还是要做。

问题二：业务系统分散，IT资源难以统一管理

企业里常见的情况是，网站在一台服务器上，数据库在另一台，内部办公系统放在别处，业务应用还有单独的服务器。这些机器的操作系统可能不一样，购买时间不一样，有的甚至属于不同的业务平台。

管理起来就变成：每台机器有各自的登录方式、各自的监控办法、各自的维护记录。想知道所有服务器现在的状况，只能一台一台去查。人员一有变动，交接尤其头疼，很多信息只存在某个人的脑子里。

云主机的思路，是把这些实例放进同一个管理入口，用标准化的方式管理资源，比如统一查看实例，统一执行开关机、升级之类的操作，分散管理带来的操作负担会小一些。不过统一入口管的只是云主机这一层，系统内部的应用配置和账号权限，依然需要企业自己建立规范。

问题三：业务变化较快，原有计算资源无法及时匹配

项目上线、用户增长、搞活动、发布新功能，这些时刻对资源的要求各不相同。平时跑得好好的系统，一到活动当天访问量上来，就变慢，甚至打不开；反过来，活动一结束，资源又闲了下来。

固定的设备很难应对这种起伏：买得多，平时浪费；买得少，关键时刻掉链子。

云主机让企业可以根据实际需要调整实例规格和资源配置，资源的使用方式更灵活。比较稳妥的做法，是对即将到来的变化提前有个预判，提前调整并留出测试时间，而不是等系统已经变慢了才临时处理。具体怎么调整，是否需要重启实例，以所选产品的说明为准。

问题四：数据管理方式不统一，数据保护存在薄弱环节

先看一个很常见的现象：企业的数据散落在各处。数据库在一台机器上，业务文件放在另一台的某个目录里，系统日志留在各自的服务器上，备份文件有的在本机，有的拷到了某个人的硬盘里。一旦出问题，最先暴露的就是“这份数据到底在哪”“最新的备份是哪一份”。

数据保护其实包含好几件不同的事，平时常被笼统地说成“做了备份”。分开来看，大概有五件：

正常业务数据存储：数据日常放在哪里，读写是否稳定。

日常数据备份：定期复制一份，用来应对误删和损坏。

历史版本恢复：能不能回到某个时间点的状态，而不只是最新的一份。

异地数据保护：备份和原数据不在同一个地点，应对机房层面的问题。

数据迁出和长期归档：业务终止或更换服务商时，数据能否完整导出，旧数据怎么长期保存。

不少企业五件事里只做了前两件。云主机在这里的位置是：底层存储机制承担业务数据的存储和一部分平台层面的保护，数据库服务可以负责数据库层面的管理。但企业仍然需要根据数据的重要程度，制定自己的备份方案，包括备份频率、保留周期，以及定期做恢复演练。平台层面的存储保护，代替不了这些安排。

问题五：企业不同地区的业务访问缺乏统一规划

业务系统的使用者，从来不会都坐在同一间办公室里。总部在一个城市，分公司在别的地方，销售和技术人员常常出差，有的客户甚至在海外。这些人访问同一套系统，网络条件却各不相同：有的在公司网络里，有的用家里的宽带，有的在国外使用当地运营商的网络。

如果当初部署系统时，只考虑了放在哪台机器上方便，没有考虑访问的人在哪里，就容易出现一部分人用着顺畅、另一部分人总在抱怨慢的情况。而问题究竟出在系统、线路，还是用户自己的网络，往往还很难说清。

比较实际的做法，是先弄清楚访问对象的分布，再决定部署区域和网络方案。云主机服务商通常有多个地区的节点，企业可以据此选择更贴近主要使用者的位置。本节只谈部署区域的规划，线路层面的技术细节不在这里展开。

问题六：缺少持续的资源管理和技术支持机制

许多企业，尤其是中小企业，并没有专职的运维人员。IT工作常常由一两个人兼着做，网络、办公设备、服务器、各类软件，样样都要管。服务器出问题的时候，他很可能正在处理别的事。

对这样的团队来说，有几样东西格外重要。控制台和API，能让开关机、升级、查看状态这类日常事务不必逐台登录去做；运行状态可以查看，有异常时能比较早地发现；服务商的技术支持，则让自己搞不定的时候，有一个明确的地方可以求助。这几项合起来，才算得上一套持续的管理机制，而不是出了事才手忙脚乱。

恒讯科技云主机如何对应企业基础设施建设中的实际需求？

前面讲了六类问题，恒讯科技云主机的产品能力与它们的对应关系，整理成下面这张表。

表里只是对应关系，并不是说有了这些能力，问题就会自动消失。比如多地区节点，企业仍要先弄清自己的访问对象在哪里；三层存储也不能取代企业自己的备份方案。具体的产品规格、可选节点、开通方式和服务范围，以官网产品页、购买方案和服务协议为准。

企业上云不能只完成服务器迁移，还需要做好基础设施整合

把服务器搬到云上，只是上云工作的一部分。如果原来的混乱原样搬过去，不过是换了个地方乱。迁移前后的管理工作，大致分成三段。

迁移之前，先清点现有的应用和服务器，哪些在用，哪些已经闲置。再梳理系统之间的依赖关系，比如订单系统连着哪个数据库，某个接口被哪些程序调用，这些依赖一旦漏掉，迁移之后常常是某个功能莫名其妙失效。然后制定资源分配计划，每个系统放在哪台实例上，配置多大。

迁移过程中，要检查数据的完整性，迁完之后核对数据量、关键记录和文件是否一致。还要做迁移测试，最好先拿非关键业务或测试环境试一遍，确认能正常运行，再切换正式业务。

迁移之后，要建立运维规范：谁负责哪些实例，备份怎么做，变更怎么记录，出现故障找谁。缺了这一步，云主机很容易变成又一批没人管的服务器。

云主机能解决的，是基础设施层面的具体问题：硬件准备慢、系统分散、资源不匹配、数据保护不全、地区访问不均、日常管理缺人。它解决不了业务系统自身的设计问题，也不意味着所有系统都适合上云。比较合理的起点，是从自己现有的架构出发，判断哪些系统适合迁移，哪些资源需要调整，再制定实施方案。

如果企业正在评估业务上云，可以把现有的系统情况和遇到的问题梳理出来，向恒讯科技说明业务需求，一起看看哪些环节适合用云主机来解决。