故障描述

DCloud服务器在做跨云切换，这是DCloud第一次做这类事情，经验不足，轻视了风险，以为可以无缝切换，所以未提前发公告。

但从12月17日周日晚10点半起，还是造成了部分业务中断或缓慢，尤其是登陆鉴权服务的中断，给当时仍在使用的开发者带来了很大麻烦。

• 开发者无法登陆HBuilder，鉴权失效，进而造成了无法打包等一系列故障。
• uniCloud控制台无法登陆，无法更新云函数。

本次切换是提前在新云部署好后再切换的，但还是有2个故障点：

往上追一层的原因分析：

• 故障1属于跨云切换经验不足。
• 故障2暴露了相关代码不健壮，后续会升级HX和服务器交互代码来彻底解决主备切换的不完善。

再次说明：DCloud服务器故障不影响开发者的线上业务运行。
包括uniCloud虽然无法登陆管理，但云函数和数据库是在阿里云、腾讯云、支付宝小程序云上的，线上云函数连接不经过DCloud服务器，所以这块不会被影响。

后续改进

开发者肯定会追问，如何避免DCloud服务器以后再次异常导致自己的开发工作受影响？

1. DCloud会努力保证服务器的正常，跨云切换是非常低频的事件，日常维护方面DCloud从域名到服务器均有主备策略，我们会加大对主备切换相关代码逻辑的完善。
2. DCloud计划后续更新HX，确保DCloud服务器异常时不影响开发者打包Web和Wgt。
   HX发行时会校验开发者账户和AppId的匹配关系，这是防止黑产盗用正常用户的AppID。而AppId对应着DCloud的很多服务，付费插件、uniCloud、安全网络、加固...
   （当然仅凭这个校验无法防护所有黑产，DCloud还有其他措施配套。）
3. DCloud一直以来都提供离线打包，App有离线打包，导出Wgt也将确保不因DCloud服务器异常而受影响。uni-app的cli也一直都可以离线发行Web和小程序。

我们无法保证DCloud的服务器一直不出问题，但我们可以保证：

1. 相关人员吸取了教训，变得更有经验
2. 相关代码会被仔细review，变得更健壮
3. 相关制度会更加完善和细化，进一步降低问题出现的概率和破坏性

DCloud是一个负责任的公司，有自己的行为准则，无论您后续是否继续使用DCloud的工具和服务，无论您是否为DCloud支付费用，
这些不影响DCloud将严格要求自身，按照更高质量要求的标准提供服务。

更新：
18日上午及中午，随着开发者流量增加，一批与存储相关的业务并发性能受到影响。
该问题是因为存储文件体积较大，部分文件还未迁移到新云，老云的文件通过外网流量访问，而外网流量带宽不足导致。
随着各处的带宽配置增加，该问题已解决。
由于积压了较多打包排队请求，DCloud已经扩容了打包机，目前打包拥堵已恢复正常。