云卷云舒:云数据库使用攻略

很多上了云的业务运维团队依然在抱怨,已经花了大价钱使用了云数据库,为什么还要那么操心,每周的故障也不少,甚至比以前更多了?

企业上云最佳姿势,上云合理不踩坑

一、很多业务的运维团队都有这样的困扰?

我相信很多运维的团队都有这样的感受,明明使用上了最先进的云数据库,但是还是在受着持续的困扰和煎熬,貌似对于云服务商的投诉也看不到效果。 

我这里想谈几点我自己的感想,本人做过企业开发工程师,也做过云服务商的产品架构师,其实大家对于上云一直都有或多或少的误解,简单的产品部署到云上绝对不是真正的云化。

二、用户选择上云的触发因素

以数据库为例,用户选择上云无外乎如下几类原因:

(1)成本考量:云数据库弹性扩展、按需使用带来的成本下降;

(2)使用低门槛:云数据库的扩展 ,甚至动态提升配置,无需手动操作;

(3)控制台:有现成的数据库控制台、管理工具帮助自己构建了一个简易的监控系统;

(4)运维少操心:依赖云服务商的运维团队来保障业务。

但是在用户业务上云之后,依然存在的困扰也不少,其实上云之后,还是要掌握基本的应用架构技巧,方能把好事做成好事。

三、上云后问题并不一定改善

(1)访问数据库,依然会出现性能问题:部分用户因为上云了,错误的认为性能是无线扩展的,在SQL的写法上就忽略了设计,当然会出现频繁的死锁、大比率的慢查询、无索引的情况。这个时候即使是云也未必能够实现极致的扩容来满足你的超强大容错性。其实能解决办法的就是客户自行的监控,同事时云服务商也能有健全的客户侧问题处置机制,避免频繁的投诉影响产品声誉,这些都是客户服务和运维部门,和产品部门应该共同努力的方向。

(2)数据库的抖动无法预知:因为云数据库往往通过构建大批量的实例来实现扩容的,但是对于云来讲,云数据库的版本升级,很多情况是全局性的,那么对于客户来讲就必然受到波及,这个由云服务商来搞定波动最小的问题,但是如果得不到应用侧的配合、或者应用侧没有针对云数据库日常升级所潜藏的风险做好适配,那么万一云数据库升级出现意外,对业务来讲这个就不能简单的称之为“波及”了。所以说云数据库所存在的一些问题,在业务侧都要做好应对,大的问题、大的难题已经由云帮助业务解决了,但是也需要做好小问题、广泛风险的适配,这才是最佳玩法。

(3)告警不太准确:云数据库在版本变更时,是很容易触发业务侧的告警的,但是由于是版本变更引起,所有风险基本都是可控的,但是业务侧却又不知道是因为云服务商在进行“变更”,还是真的“出了意外”,所以此时告警对客户来说依然敏感,很可能收到告警短信半夜爬起来排查,但是排查后发现是好的,业务没什么问题。所以说,上了云数据库的业务,最好能清晰地了解产品的高可用机制和告警机制,避免持续发生误报。

(4)上了云数据库发现成本反而变高了:云内资源有一定的冗余性,但是增加了备份、带宽、服务的成本,看上去比以前花出去的钱多了,但是这个成本效率要想达成理想值的话,同样需要最佳的使用姿态,比如备份策略的设置,备份副本的留存时长,备份带宽的选择等等。另外比如开发运维团队没有真正的适应到云上,人力成本并没有快速的压降下来。

简单总结一下,其实用上了云数据库之后,接受了云产品带来了便利性,但是业务架构并没有完全和云对接上,甚至业务团队架构也没有适配云的特性做出改革。面向云架构的运维体系设计至关重要,也是必须尽快开展的,否则企业的数字化转型就还是初级阶段,价值和成本优势都没法发挥。

四、最佳的用云建议

1、业务产品的架构层面:如果仅仅是部分的业务模块(如队列、数据库)使用了云产品,那么对于云产品的稳定性要有所准备,最好也有一些额外的设计,比如订购两套,构建起容灾架构,容灾节点可以购置低配规格。或者里用云能力快速构建一套系统、拨测系统都很现实,哪怕是短暂的,在业务上线或者版本发布初期,上一套监控系统,待业务迭代稳定后可以废除或简化;

2、运维层面:最好清楚了解云产品的高可用机制,对于云服务商所不提供的监控手段,一定要自行补充完毕,这个的补充并不一定要完全重建,基于云产品的一些基础能力快速构建监控能力也十分方便的。甚至与云服务商的运维团队成立联合保障团队,逐渐完善下来,相信会大大加速永云稳定性提升的速度;

3、组织架构上也做出适当的改革:往往我们说的企业上云大多数也都是部分使用到了云服务,比如云主机、云数据库、云VPC,并不是完全的基于云构建云原生架构,这时候可以考虑将业务从边缘到核心逐渐完全基于云构建,比如使用云的对等链接、DEVOPS、云监控,这一套下来需要充分和团队磨合,不过只要适应下来,那么成本肯定是可以大大降下来的;

4、加强与云服务团队的互动:俗话说话哭的孩子有奶吃,在一些新型的云服务商快速发展的时候,往往会非常重忠实用户的意见和需求,往往不计成本的投入支持,这个时候我们不放成本云服务上的忠实粉丝,哪怕短时间内产品上云会出现不稳定,这里和云服务商加强互动,共同优化云产品,共同提升业务产品架构对于云能力的适配度,比如提出一个双活的需求,同时愿意陪同云服务商走下去,那么这个功能一旦出来,那么绝对是为你100%定制的,大家双赢。

同时我也要给云服务商提个建议:

1、对于运维能力,一定要基于“对用户影响最小化”的思路去开展版本交付;交付时不可避免的一定要做好告警屏蔽,否则你会折腾死你的宝贵的客户;

2、对于产品运行的监控,一定要努力做到预警,先于用户发现问题,及时干预处置修复,这里的预警关键在于抖动风险预测、性能水平检测等;

3、强化最实践间分享,加强与忠实客户的互动,联合打造云原生用云标杆,同时结合场景形成最佳实践并在官网发布,以此鼓励用户用云,以及懂得用云,减少低级的问题出现。

对于高阶用户可以读一下下面两篇文章:

1、云卷云舒:算力网络+云原生(上):打造云网边端协同架构-CSDN博客icon-default.png?t=N7T8https://blog.csdn.net/bishenghua/article/details/134946582?spm=1001.2014.3001.5502

2、云卷云舒:算力网络+云原生(下):云数据库发展的新篇章-CSDN博客icon-default.png?t=N7T8https://blog.csdn.net/bishenghua/article/details/135050556?spm=1001.2014.3001.5502

  • 21
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Cloud云卷云舒

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值