文档介绍：系统运维桑昂整理(来源 51CTO)
系统运维
(声明:以下内容由桑昂整理摘自 51CTO,不负任何法律责任,详情请访问关内容)
系统运维秘诀:变化,监控,扩展(分三篇)(英文版)
系统管理员必须了解的六大铁律
系统管理员应该怎样高效的书写文档
系统管理员最需要自动化的十大任务
系统管理员都应该知道的系统常识
系统管理员之企业生存守则
资深系统管理员给 Linux/Unix 新人们的建议
漫谈运维:半神半仙亦民工
几个常用的 Linux 监控脚本
Linux 生产服务器 Shell 脚本分享
1 / 41
系统运维桑昂整理(来源 51CTO)
系统运维秘诀:变化,监控,扩展(分三篇)
完全理解本文内容需要一定的运维经验。您可能对这些文章也会感兴趣:
1. 系统管理员必须了解的六大铁律
2. 系统管理员都应该知道的系统常识
3. 漫谈运维:半神半仙亦民工
以下为正文。(最后附英文原文)
在运维管理的过程中,我发现了很多有价值的秘诀,本文是这些秘诀的一个总结。虽然这些秘诀可能
比较“唯心”,但是我还是把它们总结出来了,相信它们会对你有帮助的。
Dormando 的运维秘诀分成以下三大篇:
1. 技术篇
2. 交流篇
3. 实践篇
技术篇
为变化而设计
◆Google 的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件,升级现有的软件,
进行扩展,设备损坏,以及人员流动等。
◆每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个 Linux 发行版牢牢地
绑定在一起是一个好主意,但事实上这跟把它们完全隔离一样糟。如果实在有必要,你可以进行分层,并
使用一点间接性。
◆这并不意味着你的系统必须是平台无关的。其实我们的目的很简单:一变二,二变二十,一个系统
必须可以应对各种突发事件。也就是说,如果一个系统管理员被公共汽车撞了,你有应对的方案!如果挂
载的硬盘出现故障了,你有应对的方案!如果某些人运行了 rm -rf /,你也有应对的方案!增量的进行变更。
记得安全更新,以及保持内容更新。
使用自动的,可重复的构建过程
◆不要手动构建任何东西。如果你一定需要手动构建,那么就做两遍,在做第二遍的时候把用到所有
的命令都提取出来。
◆下面这一点十分重要:将新硬件上线到生产环境的过程不应该超过 15 分钟,而且这个过程必须足够
简单。否则,当一个服务器出现故障,而没有人知道如何更换它的时候,你就该倒霉了。
◆下面这一条是普世真理:这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建
一次,但只要你构建过一次,就一定会有第二次。比如,当它损坏的时候,或者你必须进行一次重大的升
级才能让它在在接下来的两年时间里更加稳定的时候。
◆测试,检查新构建好的服务器。这应该是比较容易的,因为你的构建过程都是自动化的,对吧!
◆脚本化的构建,意味着从某个 Linux 发行版的 V3 升级到 V4 应该是很快的。安装
V4,对脚本进行测试。如果有问题,参考文档并修复它,直到它可以再次正常工作。这最多应该是一个星
期的工作,而不是一个长达一年的浩大工程(因为那时,刚刚完成的 V5 已经发布了!)
2 / 41
系统运维桑昂整理(来源 51CTO)
使用冗余
◆容易重新构建,并不意味着你可以忽视冗余。跳转盒,邮件服务器,计费网关,等等。如果其中的
一半挂掉了却并不造成客户的宕机,生活将会变得更加简单。
◆按照以上方针来做的话,当某个设备在凌晨 3 点出现故障的时候,你可以“以后再处理那个出现故
障的设备!”,把冗余的机器先替换上去。
◆下面这一条是个聊胜于无的解决方案:Rsync。DRBD 也许也不是一个完美的解决方案,但是它可以提
供令人称奇的服务。(参考阅读:DRBD 笔记,DRBD 实例 1,DRBD 实例 2)
使用备份
◆备份是个严肃的话题。使用硬盘,烧录磁带。压缩它们,移动它们,并行地运行。对每一样东西进
行备份!
◆如果你的构建过程是自动的,整个过程都可以被备份。如果到目前为止的几条你都做到了,那么一
个真正的“灾难恢复”计划也许并不是那么遥不可及的。
监控正确的东西
◆监控你能监控的所有东西,而且要用正确的方法来进行监控。如果你的 NFS 服务器挂掉了,不要让
你的监控工具发送 1000 条警报。如果对你的系统来说,超时的警报没有什么实际意义,那就别让它发。要
针对各种具体的情况进行成功性测试:是的,