从一个小问题探讨解题思路

序言

前奏一响，心一动，就是跑路的信号，从入门到删库。。。你看这篇文章，她像不像一封辞职信。

运维的终点在哪儿？如果运维的终点是没有运维，那么这一切又将有什么存在的含义？

风言风语

问题背景：

在容器升级的过程中，一般做的第一步就是把镜像从镜像仓库下载到本地机器，从而能大大加快升级时间，提升问题的解决效率，从而就会执行指令docker pull imagename:imagetag，出现报错如下：

Error response from daemon: Get https://registry-1.docker.io/v2/: 
dial tcp: lookup registry-1.docker.io on 
10.0.2.2:53: server misbehaving

解决思路：

• 首先看到报错信息，第一感觉就是无法解析网络，从而使用ping镜像仓库的地址，发现是可以解析并联通的。
• 再看报错中的url很奇怪，我们使用的url是私有的镜像仓库，这个地址是不对的，另外显示server misbehaving，第一眼看过去，还以为是说服务器不作为，翻译一下，看到是服务端异常。
• 查看一下相关的资料，大部分都是说无法解析地址，需要修改resolve配置文件
• 优先解决url不对的问题，从而使用docker login进行登录私有镜像仓库，再次尝试pull，问题解决。

如果你碰到了这个问题你该怎么解决？

在看到问题的时候，做的第一件事是判断优先级，这是一个紧急问题还是一个普通问题还是一个故障，如果是故障，那么就影响迅速收集业务的影响范围，五分钟之内发出故障通知。

优先级定了之后，就需要整理下思路该如何去解决了，首先观察告警信息，有没有碰到过，碰到过就按照既定方案走即可，如果没碰到，就要看下报错的细节，例如上面的报错中，关键字有镜像的url地址，报错的是在哪个dns服务器上进行解析报错的，其中的error response说明也已经链接上了docker进程。

大致的报错信息已经整理完成，这个时候应该想想相关的架构了，当使用docker pull的时候，命令会发送到dockerd进程，然后使用dockerd的配置去连接镜像中心，包括用户名，密码，url。。。这个地方主要思考的是理论结合目前具体的报错，来猜测目前的问题可能出现在哪儿，也进一步加深对理论的掌握，从而知行合一，其实蛮难的。

后面就是尝试一些具体的解决方案，看看是否能解决，从而逐步缩小问题可能出现的路径，可能是配置，可能是去查看一些其他的日志，是单独发生的还是整体发生的，从而判断是客户端问题还是服务端的问题。

如果没有思路怎么办，那就只能查一查，或者问问人。。。所以思路一般来自于对系统架构的了解，如果对架构不了解，那么这些问题都不知道从何下手。。。有的时候你会发现架构很简单，但是解决问题也无从下手，其实这是正常的，因为理论只是宏观上解决思路，而具体的报错需要了解很多的细节，就像一个小小的配置文件中的配置项。

看了这篇文章，你可能会掌握：

1 理论如何联系实际，不是空谈理论，也不是只着眼于现实，现实只是一个个问题的拼凑，不能成体系，而理论恰恰弥补这种缺陷。 2 理论的存在是让我们能解决未知的问题，让我们有一个排查的大方向，所以看理论的时候，可以演练这种情况，给自己提出一些问题，让自己来解，从而也有一个实际的经验可以参考。

明年春暖花开日，就是我们见面之时。。。

风来风往，动的都是人心，实际上，如果是为了逃避无法解决的问题，那么离开又有什么意义？因为下一次依旧会碰到这种类似的问题，那么下一次呢？下一次，你还是继续逃避？继续换一人？？？换一个环境并不会换一个脑子，换一个人只不过是换一城，这都是围城。。。有问题无法解决么，除非生死。。。

碰到解决不了的问题，只是暂时你认为解决不了，解决不了其实才是真正的开始，如果你碰到的问题都能轻松解决，那么留不下任何回忆，也找不到任何成就感，如果一件事很轻松，那说明此时可能正是跑路之时。。。因为要开启下一个挑战周期。

有的时候会迷恋轻松解决问题的过程，但是不要留恋，诱惑处处有，你要搞清楚你的使命，因为时间都在流逝，你不知道是你在玩玩，还是时间在玩玩。。。那么终点在哪儿？到底要走向何方才是这一旅途的终点？