Linux运维应该定期完成的九件事

很不幸，容易入门反而掩盖了需要做的维护工作，这些工作是保持系统稳定和使系统长期处于一个良好的工作次序中所必需的。一个单一的服务器通常可以在没有人工干预的情况下运行很长时间。但是前提是所有其他的位和块必需被提前配置。

关于这个列表，最糟糕的事情是你可能已经几个月或几年没有做这些事情了。你忽略这些事情中的任何一件，它们都会在最糟糕的时候回来作祟：比如流量高峰期，硬盘驱动器崩溃，或黑客攻击的时候。Linux运维应该定期完成的九件事?我们这就为您来总结一下。

配置管理

我用配置管理来开始，是因为它和这个列表中的其余项有很大的不同。这一项对单一的服务器并不重要，但是如果你有许多系统，这一项就至关重要了。Puppet或Chef这样的配置管理工具允许你编写‘recipes’来定义服务器应该如何的被放置在一起。那些‘recipes’可以在每个服务器上运行产生一个一致的、容易复制的安装程序。这可以让你立即启动一个系统的新拷贝，可以给你的安装提供极大的自由度。

配置管理是做了，但是，却给服务器安装程序添加了一定的初始化复杂性，所以如果你胆子小，不用也罢。不过，即使只有两个或三个服务器，好处也是相当巨大的。

备份

这一项是显而易见的，大多数的系统管理员都会在这方面做点工作的。如果你没有一个可靠的备份策略，你现在需要马上调整它。哪怕只等一天，后果很可能就是是灾难性的。同时请确保你正确的做了备份，因为备份很容易做错。Mozy，Carbonite，Backblaze等工具的At-home备份已经取得了很大的进展，但是类似的Linux解决方案还远没有成熟。Rsync ，tar，和类似的脚本工具一直很受欢迎，并且也是可行的替代方案，但是必须要小心，以适应像MySQL数据库那样的特殊情况。每个人的备份需求是不同的，所以无论你选择什么解决方案也要仔细研究它潜在的不足。你选择的解决方案应该：

◆定期运行

◆保持多轮的备份

◆自动的删除旧的备份

◆在你的现在的操作系统以外存储备份

◆保持和你的原始数据一样的安全性

◆合并所有的关键数据，关键的配置文件(更换服务器以后启动和运行系统可能会需要的任何东西)，和最近的日志

测试你的备份

紧跟着备份计划的是测试它。这意味着定期检查备份是否一直在做，产生的文件是否是有效的并且是否没有被损坏，以及他们是否包括你需要的所有数据。一个好的经验法则是如果你的备份每30天一轮换，那么你应该经常的重新检查他们。这里自动化工具可以帮一些忙(自动地检查备份文件是否是最新的，是否是合理的大小并且是否有效)。尽管如此，没有任何东西可以替代人的眼睛……否则，当你发现你并没有备份那些你认为你已经备份的数据时，就只有哭的份了。

日志轮换

在最近几年，Ubuntu，RedHat和其他主要的发行版针对他们提供的软件包的logrotate的运行和配置有了很大的改善。所以你的apache和mysql日志也可以被合适的轮换(默认设置是相当合理的，虽然可能并不是你希望的方式)。但是你添加的“额外”的东西，例如Rails应用程序，需要建立它自己的logrotate条目。缺少这个步骤会在最不合适的时刻引发无数的“硬盘驱动器已满”的服务器错误。当然，通常你甚至不知道你的日志引发了这个问题。针对这种情况，资源监视才是关键。

资源监视

跟踪CPU，内存的使用情况，硬盘空间，带宽，等可以让你更好的洞察你的系统状态。当流量增加的时候，你可以比较你的增加的内存或IO使用情况，来提前规划你的“scaling”。RRDTool/Munin，ServerDensity和Cloudkick是观察这些随着时间的推移而变化的数据的很好的选择。如果你选择的工具包括对意外的变化(失控的进程，驱动器已满等)的警报功能，你将会领先任何潜在的问题一步。

进程监视

对你的网站来说，让你的Apache，MySQL和类似的进程一直处于运行状态至关重要。有几个很好的工具，例如Monit和God，可以帮助你确保你的进程一直处于运行状态。通过检查进程的响应性，打开的端口，或进程id那些工具可以重新启动一个已死的服务或在一个失控的进程使你的整个系统崩溃前终止它。配置这件事的规则是个老大难问题，但是当一切都做好的时候，可以节省大量的凌晨3点钟的宕机时间。

安全加固(Hardening)

Hardening包含了许多不同的操作，这些操作可以使你的stock系统更安全。许多简单的操作经常会被遗漏。你真的知道那些正在运行的进程中的每一个都做了什么吗?在你的系统上，哪些额外的端口和服务被打开了?有合适的PAM模块载入来进行安全认证吗?又一次，RedHat和Ubuntu走在了时代的前列，他们提供了安全stock系统，并确保最常见的软件包遵守正确的安全协议。但是，这并不意味着你可以跳过这个步骤。

安全更新

在一个基于apt或RPM的系统上，安全更新是很容易执行的。这个过程的陷阱是很难知道升级包是否会在你的栈里引发某些类型的错误。为了确切知道升级包将对你的系统产生怎样的影响，拥有一台同样配置的模拟服务器是唯一的好办法。幸运的是，由安全更新引发的麻烦是十分罕见的。修复一个更新的兼容性问题，需要花费一些停机时间，这个风险要比你的系统上的一个已知安全漏洞被利用的风险小很多。所以，不要让“not knowing”阻止你进行正确的升级。最后，不是每一个安全漏洞都能马上获得一个安装补丁。查看CVE字典上的可用警报，可以让你在补丁可用前，在保持你的系统安全性方面争取主动。为了确保一切都平滑的运行并保持最新，在这方面真的没有什么可以代替人的肉眼。

日志监视/安全扫描/入侵检测

这个列表中的所有项都是最低限度需要完成的。它们很容易被忘记，直到你的系统已经被入侵为止，你可能都不会想起它们。对异常活动，黑客攻击和其他恶意行为的持续扫描，对于帮助阻止或减轻攻击来说，是十分重要的。

总结

这当然不是一个完整的列表，但是它也是十分广泛的，许多开发者和系统管理员只是没有时间、兴趣或知识来处理它们。更糟糕的是，许多开发项目被移交给了客户，而一旦技术团队迁移到另一个项目上，这些客户就没有能处理这些事情的职员了。