Linux系统运维.docx

资源描述

Linux系统运维.docx

《Linux系统运维.docx》由会员分享，可在线阅读，更多相关《Linux系统运维.docx（78页珍藏版）》请在冰豆网上搜索。

Linux系统运维.docx

Linux系统运维

系统运维桑昂整理（来源 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 条警报。

如果对你的系统来说，超时的警报没有什么实际意义，那就别让它发。

要

针对各种具体的情况进行成功性测试：

是的，这个服务可以进行一个新的 TCP 连接，它甚至可以响应，但

是它还记得它要做什么工作吗？

◆如果你有 500 个 Web 服务器，其中一个挂掉了，你可能不必马上知道这个情况。

但是，如果负载均

衡器没有把这台机子踢出去，导致错误报告出现在了用户的屏幕上，那么你必须知道这个情况！

有关数据图形化，历史数据

◆图形的作用是让趋势可视化。

历史数据的作用是让你对数据进行精确的分析。

不要把这两者混为一

谈！

对图形进行目测，很容易获得错误的数值。

许多站点都使用 rrd 类型的系统或其他的数据聚合系统，此

类系统按照时间对数据进行平均化处理，然后保存在存储空间中。

这不仅仅是难以阅读的问题：

这根本是

错误的！

◆如果你要浏览数百张图才能精确地对一个问题进行定位，那真是糟透了。

想要找出极值？

请使用脚

本提取数据。

◆如果你必须使用图形来解决问题，尽量把各种高级的概念整合到一个单一的页面中，然后让这个页

面链接到拥有具体信息的子页面中。

如果你在数据库负载中可以看到一个峰值，你可以点击这个页面对那

些数据库进行概览，然后找到那一两台可疑的机器。

基本的理念是尽快地缩小范围，尽可能的减少猜测。

日志记录，使用多个数据流

◆无论是独立工作还是与开发部门合作，都要把尽可能多的有用的信息记录到日志中。

无论是分析之

后再保存，还是直接扔进数据库中生成报告，这些都无所谓。

信息终归是有用的。

◆有用的例子：

页面呈现时间（哪个页面？

哪个设备？

），面向用户的错误，数据库和内部服务错误，

带宽使用率等。

◆建立图表，报告，并对产生的历史数据进行比较。

◆报告是十分重要的。

每周或每天对你的基础设施变更进行汇总。

数据存储方式，数据库

◆诚然，数据库运维是一套完整而独立的知识体系。

但是有时，你不能把一切都丢给你的 DBA。

◆拥有多个冗余的数据库会给你带来很多好处。

对于一个庞大的 Oracle 实例来说，从前，很多运维工

作需要好几个小时的关机维护时间；而现在，完全可以在服务运行的同时进行。

MySQL 和数据库复制功能

是一件奇妙的事情。

◆和 DBA 们一起努力，尽量为可能会发生问题的数据库争取到最好的硬件。

RAID 10，大量的 RAM，高

速硬盘，乃至于强悍的 RAM 磁盘和 SSD。

运维人员对提供商要货比三家，这样可以减轻 DBA 对硬件的恐惧。

3 / 41

系统运维桑昂整理（来源 51CTO）

从长远来看，找出哪个品牌的硬件更加优秀会节省大量的资金。

◆数据库配置一直在改变。

现在出现了 HiveDB，MySQL Proxy，DPM 这些软件。

我们绝对应该对巨大的

数据集进行分割。

我们也可以考虑一下像 starling 和 Gearman 这样具有一定创新性的软件。

了解一下这些软

件的用途，同时，了解一下并不是一切东西都要保存在一个数据库中的。

◆善用你的过滤器！

如果这些数据很重要，应该对它们进行备份！

单片的 NFS 服务器的快照很奇妙，

它并不是一个备份！

◆可以虑一下替代的解决方案。

MogileFS 现在变得越来越好了（参考阅读：

分布式文件系统试用比较）。

实际上，还有其他类似的项目可以免费（或廉价）地维护大量的存储文件。

类似的系统基本上都是是为

、archive.org 等站点而开发的。

我们最终会让廉价的 NFS 过滤器成为标准！

多一些横向扩展，少一些纵向扩展

◆横向扩展是我们应该走的路。

应该使用常规的（即：

可用的，价格适中的，标准的。

而不是特便宜

的！

）硬件，然后和大家一起努力，确保各方面都可以进行横向扩展。

◆横向扩展从两台机子开始。

另外，进行冗余的时候也会涉及到横向扩展。

◆尽可能的横向扩展，但是不要傻乎乎的扩展。

在 MySQL 复制中有一个经典的白痴扩展的例子：

使用

一个 master 对很多个 slave。

所有的 slave 必须完成全部的写入，而写入次数是与读取次数成比例增加的（大

多数应用都是这样）。

也就是说，你添加的 slave 越多，通过添加 slave 扩展的资源就越少。

◆留意一下替代的解决方案。

按照用户或区域对多个数据库进行划分，同时避免增加过多的 slave。

实

际上，有许多种方法可以达到这个目的。

◆一切都可能扩展！

路由器，交换机，负载均衡器，Web 服务器，数据库，等等。

◆记得纵向扩展吗？

以前那些邪恶的大型机们有很多核，很多 IO 板，配备了非常昂贵的存储设备。

而

现在，多核这个概念开始蔓延了。

◆RAM 是廉价的。

◆将以上两点合并起来，这意味着你只需要再次合并服务就可以了。

这儿有一个负载均衡器，那儿有

一个 Web 服务器……如果一个应用程序可以使用许多个 CPU（比如 apache），那么这是完美的。

如果它不

能（比如 memcached），那么你最终可能会由于离散的服务太多而浪费掉大量的可用资源。

◆作业系统（job systems）也许可以填补这个鸿沟。

哪里的核心的越多，哪里的工作线程就越多。

缓存

◆对于开发者和系统运维人员来说，缓存可是个好东西，值得大力发展！

的确，它是不可思议的。

它

是与众不同的。

有时你可能必须要为它做一个权衡。

有效地使用缓存可以让系统的整体性能提升 10 倍之多。

对于你当前的系统来说，这是一个巨大的“放大镜”，并且，它的成本在总成本中只占很小的一部分。

◆Memcached。

它可以为服务提供缓存，让数据库结构非标准化（这可以提升性能！

），对 squid 缓存进

行优化，甚至可以提高操作系统缓存的利用率。

◆测试它，玩弄它，并打破它。

使用缓存会带来新的问题。

要做好准备。

让工作异步化

◆可以使用 Starling, Gearman, The Schwartz 等工具。

作业系统可以给应用程序提供更多的灵活性。

工作

线程可以一次性地产生出来，也可以是持久的（载入缓存数据，准备数据等）。

它们可以在不同的硬件上，

它们的地理位置也可以不同。

它们既可以是同步的，也可以是异步的。

◆维护这些东西是一个运维人员的问题。

使用它们既是开发者的问题也是运维人员的问题。

◆当用户点击“给我所有的朋友发送邮件”的时候，把这个工作列入计划，然后马上说：

“OK，已经完

成了！

你的朋友马上会收到你的邮件！

”——通过异步化的方式来处理这个工作。

◆作业系统是衔接各个服务的一个场所。

博客投递-〉IM 通知，定期计费-〉收费服务，网关认证等。

◆容易扩展。

在请求进入的地方会有一些瓶颈，所有的工作线程必须要做的事情就是“拉”。

这个是相

对于 HTTP 中大量推/拉的状态而言的。

4 / 41

系统运维桑昂整理（来源 51CTO）

安全和巡查

◆一定要安装安全更新！

这十分重要！

有很多疯狂的网络专家致力于在尽可能短的时间内给你提供这

些更新。

不要因为你害怕改变而让他们白白地付出劳动。

◆安全性也是分层的。

明白你能确保什么，以及不能做什么。

MySQL 有密码访问机制，并不意味着可

以允许直接通过互联网来访问它。

◆在 SSH 上禁用密码。

使用经过加密的 passphrase 密钥来进行身份验证。

远程的用户无法猜出你的私

有密钥。

他们必须从你这里才能得到它。

把它保管好。

做好这点，就没必要在防火墙中关闭你的 SSH 端口

了。

◆搞清楚你的应用程序是如何工作的，它具体需要做些什么，并相应的进行调整。

比如说，如果你的

应用当中，只有付费页面和 Twitter 投递服务是需要连接外部互联网的，那么就把它们做成工作线程。

将这

部分工作线程放在特定的设备中，让它们只能访问特定的主机。

这可以神不知鬼不觉地把你的网络的其余

部分保护起来。

◆对于 PHP 站点来说，以上这些建议尤其重要，但是在其他地方，它们也可以发挥作用。

如果有人要

入侵，那么多半是通过你的应用。

即使有人从前门入侵了系统，也要让他们花费很大精力才能进入保险箱。

你需要确保的是他们无法将数据带走或上传至别的什么服务器上。

◆除了这些具体的建议之外，你还应该多读一些资料。

自己判断，自己动手测试。

如果你不知道一个

安全模型是如何工作的，一时半会儿可能问题不大，但是这就会导致你不知道它的限制在哪里，甚至于无

法判断它是否在工作。

◆基于测试，理论，攻击树的安全机制是不会在背后给你一刀的。

当人们构想出模糊的安全模型的时

候我也很喜欢它，但是像我这样的普通人都可以把它弄的支离破碎。

◆尽可能地进行巡查！

对面向外部服务的所有访问，包

括所有在请求中指定的参数，都要进行审查。

对于你的应用程序来说，找出极值，然后彻底禁止输入超出

范围的值。

做你能做的所有事情，让数据以可追溯的方式工作。

◆如果你怀疑某些东西可能会被破坏，应该采取适当的预防措施，最好懂得一点计算机取证方面的知

识（或者聘请一个专门从事这项业务的公司）。

通过移除可疑的网络访问来做出响应，通过一系列的控制台

或直接通过终端来检查整个系统。

在已经被破坏的机器上，避免使用任何的服务，配置文件，或数据。

很

多人都是“清除了一个木马”，但是不知道它是怎么进来的——这样并不算真正地清除了这个木马。

◆如果你有安全团队，取证专家，或其他人手，那么你尽量不要接触那台机器，把它隔离起来。

这意

味着不要重新启动它来“清除一些奇怪的进程”。

他们需要这些证据。

如果你必须这么做，就去做吧，但是

要记得把系统彻底地清理干净，打上所有的安全更新，尽量搞清楚他们是否已经破坏了重要的数据。

做你

能做的所有事情。

◆安全实际上是一种权衡。

如果你做错了，开发者和用户们都会“揭竿而起”：

他们会找到一些方法来

绕过安全机制。

如果他们可以绕过它，那说明你的工作并没有做好。

如果他们不能绕过它，那么他们也许

会放弃，然后离开。

◆紧抓访问控制。

这意味着运维人员必须要为已经锁上门的“房间”提供一些窗户。

不让开发人员进

入生产环境，意味着他们必须抹黑解决难题。

你的确不能让开发者们直接对服务进行修改，但是你可以提

供日志工具和调试工具等等。

对于各种产品来说，这些都是成功的秘诀。

【51CTO.com 译稿，转载请注明原文作译者和出处。

】

原文（最后附原文）：

Dormando's [crappy] Operations Mantras

5 / 41

系统运维桑昂整理（来源 51CTO）

系统管理员必须了解的六大铁律

【51CTO 11 月 25 日外电头条】编辑导读：

系统管理员们踏上岗位，都已经具备了一些有关系统和服务

的知识，如如何搭建生产环境，如何备份，如何监控系统等等，这些知识可能来自学校，可能来自自学。

然而在工作了数年之后，系统管理员们对生产环境中的操作又会有了很多新的了解。

下面，资深运维专家

Paul Venezia 为我们总结了他认为系统管理员在生产环境中必须遵守的六大铁律。

这是一些学校里不会教的

知识。

遵守这些规则，你几乎可以解决任何一个问题。

在复杂的数据中心基础设施中，这种能力可以让你通过丰富的经验和自身的知识快速而准确地发现问

题之所在。

这种能力只可意会，不可言传。

没有人会提供和“超自然故障排除”有关的认证的。

但是，那些重量级的问题解决专家都会遵守一些通用的，不成文的规则。

这是我自己使用的六个规则。

注意，它们适用于大多数情况，但是并不是所有情况。

1、永远不要修改服务器或网络设备的连接接口

虽然这听上去很简单，但是，令人吃惊的是，人们经常会修改他们用于连接到某个设备的网络接口的

属性，这种行为的失败率很高。

有时，这条规则可能是可选的，但是，如果有一种方法可以排除潜在的隐

患，何乐而不为呢？

如果你不得不修改这个接口，可以在这个接口上配置一个辅助 IP（secondary IP）——

通过另外一个设备或子网，串行控制台，KVM 等来连接。

如果设备放在远程的办公室里（那里没有 IT 职员），

那么这绝对是一条真理。

2、保证总是有办法回到原点

无论何时，只要有可能的话，都要提供一种可以把问题恢复到原始状态的方法。

这意味着，在对故障

磁盘做任何修改以前，应该为这个故障磁盘做一个映像，备份整个目录结构（你不可能知道你以后需要哪

些文件，这样可以以防万一），或者，在你胡乱摆弄一个已经出现故障的操作系统以前，应该在物理服务器

上抽取出这块磁盘的 RAID1 阵列。

当然，在虚拟机环境下，这会更加容易一些，因为你可以简单地做一个

快照。

3、文档，文档，还是文档

在所有这些规则中，这条规则也许是大家最少遵守的规则了。

毫无疑问，应该把一个问题和解决方法

文档化。

当你处在混乱状态之中的时候，你的解决方法也许并不明智。

这就是说，当一个问题尘埃落定以

后，要保留一份“尸检报告”，通过这份报告，你可以重新检查当时那个解决方案采取的步骤和途径。

把它

写下来，然后把它保存在安全的地方，最好是放到公司内部的 wiki 上；并且，应该备份到几个不同的地方。