互联网+的需要
在信息越来越繁杂的互联网时代，公司所运行的项目越来越多，项目相关服务繁多，服务之间存在复杂的依赖关系，运维与管理任务越来越繁重，手工交付需要花费很多的人力与时间，且安全性和时效性均无法保证。对于多资源型分布/分离式部署项目，Udeployer应运而生。
随着企业对版本上线质量和速度的要求越来越高，敏捷开发、Devops的接受度越来越高
传统的交付方式因为项目之间缺少依赖、环境不一致、版本不一致、人为操作失误等情况使得项目交付过程中问题不断，而互联网企业发展节奏快、版本发布频率高，上线出故障影响面广、影响度高，因而企业对于敏捷开发、持续集成、自动发布都有强烈的需求。
自动化从构建和测试开始
运维自动化的关键在于标准化。当你有一个成熟的团队，有标准化的流程，那么运维自动化就水到渠成了。而如果你什么都没有，那就需要先设定优先级。
我们的目标当然是将所有的流程标准化，而哪些要放在前面做？做起来比较简单的，和比较重要的。我认为构建和测试的流程是最基本的第一步。这对于交付产品的公司来说容易一些，对互联网公司来说更复杂一些，而测试比构建也要复杂一些，但这是基础。构建和测试的流程标准化做好了，就可以准备做自动化的工作了。
不过我见过的很多公司连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团队也花费了几个月的时间。为什么？
推荐阅读：