云计算正在加速淘汰那些低端运维

我从事云计算行业也有些年头了，之前做 CDN 后来做公有云和私有云以及容器云的技术支持工作，在工作中我遇到形形色色的客户，这些客户大都来自传统行业，例如快递、工业以及一些中小型创业公司，当然还有一些互联网行业的从业者，和这些用户接触后，我发现他们的运维水平都相当的低。一些简单的系统故障都没有能力解决或者是即使有能力也懒得去自己解决，完全依赖云厂商。

打个比方,一个客户(这个用户是一家互联网企业，具体身份暂且不表，如果暴露出来我怕影响这家单位的名声)，在使用yum 安装 gcc 时出现了如下报错：

One of the configured repositories failed (CentOS-7 - Base - 163.com), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 
3. Disable the repository, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable base

老实讲，我觉得他问这种问题真的让我怀疑他的老板是如何把他招聘进来的。这种问题的报错信息和修复方案操作系统已经明明白白清清楚楚的表达了，就算你英文差劲到完全看不懂，你也可以做如下操作来迅速的查找解决方案：

• 第一复制报错信息去找翻译软件翻译看看到底说的啥，虽然现在的翻译软件不能完全翻译准确，但是大概意思应该还是可以看清楚的。
• 第二，直接把内容复制粘贴到搜索引擎去搜索，这一条的解决方案是最快速的。

不过既然他已经找到我们了，我也给他提供了修复方案，让他更换yum 源，但是这家伙又给我贴了一段报错

http://mirrors.163.com/centos/7/os/x86_64/repodata/repomd.xml: [Errno -1] Error importing repomd.xml for base: Damaged repomd.xml file Trying other mirror.

然后因为这个问题，他折腾了三个多小时，最后我不得不一步一步的写下解决方案

# echo "nameserver 114.114.114.114" >> /etc/resolv.conf

# cd /etc/yum.repos.d

# curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

# yum clean all

# yum makecache

我姑且把这类用户算成小白用户吧，因为很明显他对于 Linux 完全不懂，这种问题并不是需要多少技术含量才可以解决的，应该属于 Linux 最基础最基础的知识了。如果他是科班出身，我绝对会鄙视他不学无术，如果他不是科班，这老板是怎么把他招聘进来做服务器管理工作的，让这种人来运维操作服务器，这业务稳定性让人着实担心，后面指不定还会遇到例如服务器黑入侵、误删文件等等一系列因为他的水平不足导致的各种运维故障，然而我想他到时候肯定会把锅甩给云厂商。

还有一类人是他有一定的技术能力解决问题，但是他对于云厂商依赖特别大，大大小小的问题完全不经过大脑思考，不会想着自己先排查一遍，实在解决不了了才反馈云厂商。遇到问题总是想着自上而下的思路去解决而不是自下而上的，一旦发现问题立马会把问题归结于是不是云厂商出现了问题，而不是自己本地系统或网络出现了问题，比如，一台Windows server 无法连接，这种问题最优的解决方案应该是：

• 第一，确认本地是否能够ping 通 这台服务器的 IP 地址，如果可以ping 通并且ping 值正常说明服务器之间网络是没有问题的；

  如果无法ping 通，确认是否服务端禁止了icmp 协议。

• 第二， Telnet 这台服务器的远程端口，例如 3389 ，如果打不开，可能原因：

  • 服务器端口没打开，可能是防火墙之类的阻挡了请求
  • 如果之前可以连接，可以回想下是不是之前做了什么操作导致的，可以通过 VNC(云厂商都提供这种方式) 进入系统确认防火墙和远程配置是否打开。

• 第三，如果上面都确认无误，可以就行尝试例如通过其他机器Telnet 确认下是否可以，以判断是否是本地操作系统设置原因导致的。例如厂商 ping 其他网站看看是否有问题以及本地是否对远程访问做了一些禁止策略，或尝试连接其他服务器是否仍然存在相同问题。

• 第四，确认下本地到服务器的路由是否有问题，可以通过 traceroute、mtr 等工具辅助判断

• 第五，拿着报错信息百度(都不要求你谷歌了)。

• 第六，去看下云厂商的监控信息，看下是不是CPU、内存或磁盘IO、磁盘利用率等出现异常导致的服务器死机。

这五步快速操作下，最多不超过2分钟就可以排除是本地问题还是服务器自身问题亦或是云厂商问题。

其实这都是最基本的运维能力吧！ 这些都不会真的不能算是运维，只能算是打杂的。

以上如果还未解决，可以把你的排查思路和结果(截图) 反馈给云厂商协助处理，一般这样的用户我还是不会抗拒的，至少他有自己先解决。但是大多数情况下，我遇到的客户都是遇到问题就想着把责任归结于云厂商。

云计算行业虽然发展迅速，但是从业人员的技术水平越来越差，很多用户的运维水平甚至连RHCSA(红帽最低级的水平) 都没有达到。这些低端人才迟早有一条会被时代丢到垃圾堆去的，只不过是时间问题。

其实，我身边的很多开发人员，他们虽然不算专业的运维，但是运维水平都非常强，除了代码写的好以外，甚至自己的业务都自己运维，包括服务的自动化发布、系统调优、故障拍错等等。所以这种低端运维还有什么出路？只不过是个打杂的而已。

十年前，那会还云计算还不火，低端运维可能在IDC会用个光盘安装个操作系统就有口饭吃，十年后，操作系统根本就不需要你去机房安装，直接线上鼠标点点就可以，技术不断发展，人也要不断进步才能不被时代淘汰。