自动化运维经验谈，以及为什么 Docker 是革命性的

随着开发效率的提高，运维的自动化已经成为很多技术团队越来越重视的问题，否则部署的速度容易成为业务创新的瓶颈。在这个背景下，定位于给互联网公司做运维服务的云络科技公司接触了越来越多的客户，对国内互联网公司的运维水平有相当多的了解。他们看到的现状是怎样的？技术团队要实现运维自动化应该从哪里开始？像 Docker 这样的技术如何影响开发者与运维工程师？在本次采访中，云络科技 CEO Steve Mushero 谈论了这些话题。

嘉宾简介

Steve Mushero 从硅谷来到中国，在全球范围内的广泛行业及从业企业中拥有超过 25 年的技术管理经验，其中包括 IT 运营、软件开发、物流、制造以及机械等领域。他曾在土豆网（中国）、Intermind、New Vine Logistics 以及 Advanced Management Systems 等企业担任过 CTO，拥有首席架构师工作经验，并以顾问身份为世界卫生组织、格莱珉银行基金会以及多家全球财富五百强企业的全球化项目提供指导。

自动化从构建和测试开始

运维自动化的关键在于标准化。当你有一个成熟的团队，有标准化的流程，那么运维自动化就水到渠成了。而如果你什么都没有，那就需要先设定优先级。

我们的目标当然是将所有的流程标准化，而哪些要放在前面做？做起来比较简单的，和比较重要的。我认为构建和测试的流程是最基本的第一步。这对于交付产品的公司来说容易一些，对互联网公司来说更复杂一些，而测试比构建也要复杂一些，但这是基础。构建和测试的流程标准化做好了，就可以准备做自动化的工作了。

不过我见过的很多公司连 Git 都还没有，仍然在用最原始的 FTP push 来更新代码。我的观点是，如果你还没有用上 Git 这样的工具，那根本就不用考虑什么自动化的问题，因为条件完全不成熟。

所以，我们假设你的团队能够很好的使用 Git，然后你建立了构建和测试的标准化流程，然后你就可以用工具来实现自动化。这可能是 Jenkins 这样的工具，不过 Jenkins 比较复杂，如果你只是一个很简单的网站，那么自己写一些脚本来实现自动化是更合适的。

到此为止，我们说的还不是自动化运维，而是自动化工具链。工具链就是开发工具链，从 IDE，到代码提交，代码审查，构建，到测试，仍然属于开发的范畴。在这之后才是运维的范畴，就是往生产环节部署。

部署

运维自动化最关键的部分是运行环境的定义。我们的目标是让各个阶段的代码完全一样，即开发者在自己笔记本上写的代码，到集成阶段的代码，到线上环境的代码，都是一致的。为什么 Docker 这么火，就是因为它帮助开发者很简单的就让自己的开发环境跟生产环境一致。环境的标准化，意味着目录、路径、配置文件、储存用户名密码的方式、访问权限、域名等种种细节的一致和差异处理的标准化。这涉及到很多方面，也是自动化运维最困难的一部分。

这里要注意的是，像 Puppet 这样的工具并不是魔法。你需要自己为你的环境定义一套描述的方式，工具是无法为你完成这项工作的。无论是 Puppet 还是 Jenkins，都是根据你的定义来管理你的环境。你决定用户名和密码如何储存，你决定配置文件的路径。开发者很喜欢把各种配置和 url 之类的参数硬编码到代码里，这很快；他们还喜欢东搞西搞的用一些乱七八糟的手段让软件通过测试，但是如果要构建一个真正的系统，这些小把戏根本没用。你必须强迫他们采用标准的方式写代码，比如强制他们把用户名和密码写在固定的地方，然后你才能跟 Puppet 说，配置文件在这里，测试环境用这个配置，生产环节用那个配置。到这里就很简单了。

线上环境问题排查

对于线上环境的问题发现与解决，大部分基础的问题都能用工具来自动发现并提醒，比如磁盘空间不够，比如 MySQL 崩溃，比如访问网站的时候出现错误页面等等，有很多现成的工具可以抓到它们错误的信息。

比较困难的是排查网站为什么变慢这样的性能问题。我们经常看到客户的开发团队提交新代码后引入问题。在测试做得不好的时候这很常见，事实上很多东西是很难测试的，尤其是性能；而互联网公司又尤其没有测试的文化，互联网开发人员大多关注特性的实现，而不像传统企业级开发那样有很多测试的工具和流程。

理想的情况下，每个人提交代码前都应该测试。但既然反正也没人这样做，那么用工具来帮忙还是很有用的。比如 New Relic 这样的工具就很强大，它可以发现代码层面的问题。我们有时候也用我们的工具帮客户做测试，包括负载测试。性能测试是挺困难的一件事，既不容易用起来，也不容易让别人用起来，一般来说你需要一个专门的团队才能做性能测试，但互联网公司基本没有（除了 Google、Facebook 这样的），就算想有也找不到人。所以要善用工具。

Docker 的意义

Docker 很有意思，很火，很新，当然也很多问题。它目前没多少大型部署案例，所以人们不断的发现问题也是很正常的事情。

总体来说，Docker 是一个对开发者非常友好的东西：简单的实现不同机器上的环境标准化，可以轻松拿来拿去，而且在不同的云平台上都支持。而把 Docker 用起来对运维而言则是很大的挑战，我们帮一个客户做一个规模较大的 Docker 部署，一个有经验的 DevOps 团队也花费了几个月的时间。为什么？

Docker 容器就跟 VM 差不多，从运维的角度，会希望像管理 VM 那样管理 Docker 容器，但是 Docker 容器很难 troubleshooting，因为默认来说它没有 SSH，你要怎么登陆到一个容器里去查看里面发生了什么问题？Troubleshooting，这是一个最大的问题。

默认来说，Docker 容器也无法运行 cron 任务或者 batch 任务，意味着你没法儿让它自动做备份之类的工作，而这是最基本的运维任务，这是另一个必须解决的问题，否则你根本无法构建一个自动化管理的云环境，而要解决这个问题，你需要搞一些手段，比如改造它的架构，但是你一折腾，又引入了很多新的问题要解决。

Docker 有很好的网络机制，但是也很复杂，所以我们 bypass 了所有的 Docker 网络，而这也引入了一些问题。Docker 容器也没有好的重启方法，因为你很难看到哪个是哪个，需要做一些好的命名映射的管理系统。总之，要在大型部署中把 Docker 玩好，你需要各个方面的专家，还需要时间。

我并不怀疑 Docker 是趋势，它的概念非常好，会极大的改善开发者的世界。如果你的系统比较简单，不是很大，那么用 Docker 是完全没问题的。而且它的文档很好，这也是很赞的地方。我相信它会引领未来。它只是还需要时间来完善。而这也不奇怪：想想 KVM，其实 KVM 做的事情很简单，就关注系统层和 CPU、内存、存储、网络的交互，并不难理解，但即使是目标如此简单的项目也多年处于问题层出不穷的状态，人们不断的围绕它开发工具，改进它，才到了今天的可用状态。Docker 则复杂的多，有很多层：它是一个环境管理系统，它是个打包系统，它是个文件系统，它包含一套网络机制，它是一个 repo 系统，它是个代码系统，等等。基本上，Docker 想要把所有的东西都扔到一个小盒子里，五脏俱全。当你用 Docker 提交代码时，你做的事情跟以前是完全不同的。在以前我们只是把代码提交上去，而在 Docker 中我们把整台计算机（虚拟机）提交上去。想象一下，这就好像是交换电脑一样，开发者把整台电脑交给运维，电脑里面的环境和代码都有了，是不变的；而运维需要把所有的电源网线什么的都插回去，需要处理很多变化的东西，比如变更的 IP、用户名、文件系统等等。这是全新的方式。