开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请联系 liuaustin3 ，（共1730人左右 1 + 2 + 3 + 4 +5） 4群（230+）,另欢迎 OpenGauss 的技术人员加入。
事情很凑巧，就在临时工昨天对于上次阿里云的故障对于数据库层面的影响进行了分析后，当天阿里云的数据库爆发了大面积的界面故障和 API信息获取的问题。
在昨天早晨，笔者针对阿里云的MongoDB的部分进行config server 地址进行申请，但是操作失效尝试多次后故障依旧无法获得地址信息，在此情况下，开启工单，从早上9：00截止到文章撰写完毕的 6个小时，截止文章完成故障仍未被解决，基于此次故障影响，笔者当天对于基于界面的数据库操作全部禁止，并也告知与公司有关联的部分客户，禁止操作数据库界面的部分，以免带来不可预测的故障问题。
此间在群里也和一些群友，展开嘴炮，针对上云是一个必然，进行了捍卫的一些言辞，但打脸的是，当天就有数据库方面的故障，阿里云的故障最近比较多，希望阿里云能挺过目前的多事之秋，否则只能开始在技术层进行一些列的”准备工作”。
是的，上云容易，下云难，这是一个上完云的人不愿意在去讨论的话题，基于上云后，不少单位在上云后在技术力量，人员配置等都在大幅度的停止和削减，从老板的层面依靠云的技术，来削减成本，而在遇到问题的时候，各个公司只能消极的等待故障的解决并对于阿里云的客服人员发泄情绪。
基于下云的部分，或尽量摆脱一些云独有的技术，在此被提上议题，这里我们可以列举一些云数据库独有的技术
1 云数据库监控技术与监控指标
2 数据库方面的独有的技术与产品
3 数据库数据迁移与数据集传输技术
4 大数据分析软件技术与周边
基于这些笔者正在反思，对于云技术的依赖上的一些问题，比如云原生的数据库产品，云原生的产品的确有很多技术是开源数据库产品不具有的，正是因为这些原因，在云数据库出现大面积故障的情况下，如何开展下云的技术选型的工作，才是一个难题，从人员的配置上，基于云的企业，基本上没有什么能力下云，从技术的储备上，从基础设置的搭建上，以及维护等等
同时基于云上的数据产品的完整性和相关周边设施的充分性，下云必然会遇到诸多难题，但基于这几次的问题，依赖云上的一些独有的技术，是否应该，这就必须在进行考虑了。
是否应该将数据库部分，改变策略，逐步转移到 ECS + 自建的数据库的模式也要考虑，但是基于云上ECS 主机的一些限制和资源共用的问题，自建ECS + 自建数据库的部分，小批量的还可以，大批量的情况下，转型需要经验和人力资源的储备等等，并且备份方面和数据库周边维护的方面也都需要在自建的情况下考虑。
基于此问题，如果敢兴趣也可以在群里展开讨论，是否有必要下云或摆脱那些云独有的技术，怎么最大化避免云故障给生产和业务带来的问题。
相关云管数据库的故障周边，可以参考如下文章。
https://mp.weixin.qq.com/s/3F1ud-tWB3eymu1-dxSHMA
