还是继续这个网站运维的话题吧。前面谈了知识管理与积累，这次谈一下运维过程中的自动化管理。
在进行这篇的扯淡之前，让我想起了《太平广记》里的一个《 板桥三娘子》的故事，姓赵的客商窥探到客栈老板娘三娘子在小箱子中取出小孩玩具大小的木头牛，木头人，喷口水，木头人、牛开始犁地耕作，撒一粒荞麦种子，木头小人种下，不一会儿，荞麦长成开花结实，木头人收割，乃至磨成面粉。然后三娘子把木头牛、人收入箱中，用得来的面粉做了数张面饼。多么好的一个自动化场景呀。
自动化的目的
自动化管理是网站规模化之后必须要面对的问题。为什么要自动化?肯定不是为了炫技，针对一个发展中的网站来说，自动化的主要目的还是为了节省维护成本，提升运维成熟度能力。另外一个经常被忽略的收益是能让运维工作更有趣味性一些，不那么无聊，不无聊的有益副作用是减少人为出错的可能。
自动化针对的范围大致可以分为安装自动化、部署自动化、软件发布自动化、升级自动化、监控自动化等几个方面。优化自动化? 别，这个稍微”高级”并且不靠谱了一点。
自动化要解决的问题是 N 次循环的过程，如果 N 不具备延续性，那么自动化未必有必要。比如某个过程可能只是短时间内需要临时进行几次，是否有必要将其自动化就有待于商榷。如果计划和开发自动化过程的成本高于非自动化成本就没必要了。
开发自动化过程
如果看过古龙的小说，他曾经描述过几个有趣的懒人，懒人造了一些木头人和机关来帮自己干一些不愿意做的事情。自动化多少就是”懒人”要做的事情，因为懒嘛，所以才会想办法节省时间和其他成本。一般来说，这个过程的开发者也是使用者，所以没必要一定要按照所谓的项目过程去走，但是开发者必须能够产出一份文档给同团队的伙伴(如果有的话)。
考虑到多数的网站运维可能都是在 Unix like 环境中的，而 Unix 的哲学思想之一就是”Write programs that do one thing and do it well”，每个过程只做一件事情就很关键，”功能单一的自动化模块”是有必要的，把不同的模块拼装起来再去完成更复杂的需求。
Unix 相比 Windows 来说，天生具备可自动化能力。如 Shell/BASH(自动化日常操作)、CronTab(自动化任务调度) 、Expect (自动化交互场景) 、rsync(数据远程同步)等 啊都是一些需要注意的技术内容。
优化自动化过程
自动化过程一般要有个生命周期，定期升级、优化也是有必要的。面对不同的应用场景应该逐渐改进自动化的可用性。
示例：自动部署 Linux
对于批量的 Linux 安装，RedHat 提供有 Kickstart Installations 自动安装解决方案，不过该方案相对比较繁琐，前不久推出的 Cobbler 是让人眼前一亮的好工具(参见 hutuworm 的介绍文章)。我一直怀疑 Cobbler 是中国人命名的项目，因为 PXE 发音为”pixie”(皮鞋)，而 Cobbler 的中文意思是”补鞋匠”。
OS 安装完毕之后的软件安装、更新是个麻烦事。在一个 Linux 的环境中，SA 一定不要为软件相互依赖性浪费太多的时间。什么 YUM、APT、YAST 啊，能用就用上。别太迷信自己编译软件所能带来的优化收益，实际上犯错的几率更大。达到某个规模后，本地建立、维护一个软件资料库(repositories)也是有必要的。
Linux 软件安装进化之路：
手工预编译-->RPM-->APT 等工具
已经进化到更好的阶段了，没必要还走着老路在原地折腾。
其他参考：Flickr 运维曾经采用 System Image 来自动化 Linux 相关的的运维工作。或许也可以尝试一下。
在系统配置管理(别混淆到另一个配置管理上去)方面，其实 cfengine 就挺好用的。更多类似工具参考这个比较列表。
标准化，减少后续维护成本是节省人力资源的一大法门。
自动化的一些风险
必须要承认的是，自动化有的时候是容易带来一些风险的，比如”冲掉”原有配置文件信息，不恰当的自动化脚本给系统带来额外负载等，在运维过程中需要不断总结经验。(又落入俗套)
这方面值得推荐的一本书是《UNIX和Linux自动化管理》，借鉴一下其中的思路和方法。
对了，补充一下前面的《板桥三娘子》的故事发展，三娘子的面饼如果被客人吃下，则会变成驴…… 同样，自动化有的时候会把人陷进去的，运维人不要变成自动化的奴隶。
这个话题还需要继续下去么? 我再想想 …
