转载 这些年受到互联网企业的影响，很多大型企业都在上云，搞中台。我一直担心这些没有互联网基因的企业学习互联网企业后，会不会学了个四不像。前些年拜访一位企业的IT部门领导的时候，他自豪地说，自从他们的系统上了云之后，运维起来简单多了，再也没有像当年用Oracle那样，整天要找专家来分析宕机原因了。真的如此吗？
后来在一个会议上我遇到了他们负责云平台运维的哥们。那哥们说，以前没上云的时候，小问题不多，出事都是大问题 ，不过有Oracle RAC，只要存储没出问题，也出不了啥大问题。为了上云，开发商都对应用做了适应性改造，首先数据库都拆成了多个小库，SQL也拆了不少，一些在Oracle上能跑的SQL不拆了在RDS上根本跑不动，所以数据库的压力确实不大。一旦数据库出问题，基本上限流、杀会话、切主备、找慢查询，几板斧下来大多数就解决了。如果这几招不管用，那就麻烦了，定位和解决问题都是几个小时起步的。不像以前，30分钟搞不定就要记录事件了。不过现在上云的系统大多数不是特别重要的系统，只要开发商和客户那边能协商好，也不会算是运维事件。还好，这类大型故障并不多，大多数时候切个主备就基本上搞定了。
原来这才是系统上云就变得易于运维的真相，并不是易于运维了，而是不怎么运维了。每次出问题也不需要找原因（也压根儿不知道怎么去找根因），先通过三板斧恢复运行，如果三板斧失效，那就完全靠运气了，一通折腾说不准什么时候就解决问题了。
这其实也是我担心的问题，学互联网的模式，学了一半，可能是一件更危险的事情。这些企业上了互联网的私有云平台，其功能是公有云的阉割版，本身就能力偏弱，企业一般也舍不得买高级运维工具和服务，所以系统上云后分析诊断能力比在云下下降了不少。
近年来随着上云速度的加快，一些重要性比较高的系统也逐渐迁移到云上了，最近系统发生的能够让领导感知到的故障也多了起来。虽然故障的频率比起当年用Oracle来说少了 一些，不过每次数据库性能问题等故障造成的业务系统停运时间比以前长了很多。按照他们的计算，总体上来说，上云后的可用率和以前差不太多，不过每次出故障后的处置都是心惊肉跳的。
其实系统上云并不是坏事，用云上RDS替代Oracle，只要应用改造做到位，钱花到位，也是可以干好的。但是运维工具链的不足将会给今后的系统运营带来巨大的不确定性。以前一套Oracle RAC，靠一两个有经验的DBA，加上三线专家的支撑，是完全搞得定的。现在拆分成了几十个RDS实例，再加上主从，读写分离等，如果手头没有趁手的运维工具，那还真的挺麻烦的。
云平台本身自带的运维工具偏编排和管理，监控预警诊断分析等方面的能力是偏弱的。一般来说也就是慢SQL、业务限流等功能做得比较完善，其他方面的功能真的不知道开发出来是给谁用的。有一次拜访一个客户的时候，正好他们有几个RDS实例出问题了,CPU被打爆，系统变得极慢。正好我 在场就被抓差去帮忙紧急处置。我看了一会儿工具觉得无所适从，除了让他们马上做一些慢SQL限流，防止整个系统崩溃外真的不知道干什么。当时第一反应是问他们能不能直接连到数据库上去看看innodb的情况。RDS管控台真的不是为诊断分析设计的。后来凭着经验通过加索引和清理了某张没啥用的表的数据算是临时控制住了系统，不过面对这堆号称白屏运维工具，我感觉真的是面对了一个黑盒子。
我想数据库上云是一个趋势，在企业内网中，私有云上的数据库实例也会越来越多，在核心系统上云之前，企业是不是应该先把运维工具链做好，否则我还真为这些核心系统捏了把汗。
文章转载自： 白鳝|
