访问及书评:DevOps 中 Linux 服务器疑难追踪最佳实践

Kyle Rankin 为在 DevOps 文化中面向 Linux 服务器的团队提供具有实践意义的故障排除建议和技术。本书目标对象为那些对Linux 服务器故障排除还有一定知识欠缺的系统工程师、开发者和QA 工程师。富有经验的Linux 系统工程师会发现该书说明了在在交叉功能团队环境中应该分享一些内容新颖，并具有说明性的内容。当进行故障排除时, 老练的Linux 工程师会把这本书作为一个在实验室帮助开发人员和QA 同事的指导性手册.

Focusing on DevOps 关注于 DevOps

第一章为在 DevOps 文化中的每个人提供了一个故障排除的解决方法。DevOps 处于最突出的位置，为有着不同专业背景的个人有效地交互提供了舞台。第一章指导人们执行以下几件事：

• 故障排除上采用分而治之的心态。
• 在故障排除期间选择 IRC 或类似的基于文本的聊天技术
• 故障排除时先由快速简单的测试开始，尽量避免慢并复杂的测试。
• 首先使用已知的解决方案。
• 文档记录故障排除经验，以及解决方案。
• 首先从近期的修改开始考虑。
• 逐步建立对系统如何工作和交互的知识和理解。
• 只有特殊调查时才使用互联网。
• 重启前，尽量多地收集与系统出问题相关的信息。

整本书中 Kyle 对作为 DevOps 文化中一个重要部分——常见基本故障排除技能做了陈述。他做了如下说明：

“在一个 DevOps 组织中，所有团队间的协作依然困难，但是当遇到故障排除时，人们依然按照他们传统的角色来执行，尽管此刻并没有指责游戏。为什么？嗯，就算每个人都想很好地一起协作，但是可能并非每个人都有相同的故障排除技能和技巧，所有人可能依然期待别人去故障排除自己的那一部分。”

第二章至第十章则将 Linux 服务器上会存在的问题分为几个域。以下就是 Kyle 从 Linux 服务器故障排除角度所提出的一个主题列表：服务器运行缓慢、引导、磁盘、网络、DNS、邮件、网站、数据库和硬件。

Server Slowness 服务器运行缓慢

Linux 服务器会在某些棘手的线程产生以下类型的高负荷时呈现出“慢”的状态：CPU、RAM 或 I/O。在故障排除过程中，团队需要定位并停止这些线程以阻止该进程降低服务器性能。大多数 Linux 服务器都有判断问题及违规线程类型的工具。命令行接口工具“uptime”（或者 CLI）通过汇报最后 1 分钟，5 分钟和 15 分钟的平均负载来帮助诊断 CPU 负载问题。CLI 工具“top”通过向控制台不断发布系统信息来帮助诊断 CPU 和 RAM 负载问题.CLI 工具“iotop”用来诊断 I/O 负载问题. 之前提到的命令行分析工具是用来分析运行这些工具时是否存在问题，同事我们也需要不同的分析工具来分析问题发生之后。“sysstat”工具包提供一整套工具通过可配置的时间间隔来收集数据并报告问题发生之后的信息.Problems Booting**** 引导问题

通过分别对经典的“System V Init”和“Upstart Init”进行描述，Kyle 从bios 到init 覆盖了Linux 启动流程。随后，该书深入潜入到启动流程中可能会造成问题的各单独组成部分中，并讨论如何解决这些问题。该书涵盖了以下内容：基本输入输出系统（BIOS），GRUB，禁用闪屏，安装根文件系统，以及安装二级文件系统。书中材料的安排顺序允许读者对一个或多个潜在问题进行有序地分析和解决每个问题。

Disk Issues

读者将通过一系列的疑难排除实例来获取关于硬盘问题的知识。首先从如何管理一个满的硬盘开始，此时 Linux 已经为根用户的登录和文档移动保留了足够的空间。该保留空间可以通过使用“tune2fs”功能来检测。然后通过“du”指令协助跟踪那些最大目录。如果硬盘没被写满，却无法创建文件，那意味着没有多余的信息节点（inode）。利用“df -i”指令来查看有多少节点正在被使用。另外一个硬盘问题是文件系统在遭遇一个错误后通过增加只读文件数量来自我保护。通过使用“mount”功能指令来重置。当“/proc/mdstat”路径连接控制台时会见失败的硬盘在 RAID 中显示出来。而“mdadm”指令则可将失败的影彷从 RAID 配置中移除，与此同时，在 RAID 配置中加入一个好的硬盘。

Networking Problems 网络问题

当某一客户端电脑无法连接服务器时，从客户端开始的每个网络层都需一一分析。在客户端电脑从使用”ethtool“命令开始来判断网络物理链接是否存在。一旦有链接被检测到，接下来就是判断其接口是否打开，及是否有 IP 地址。“ifconfig”命令将回报接口状态和 IP 地址。然后，对默认网关进行带有“route”命令的检测，另外，“ping”命令用来测试客户端与其他电脑的通信。当确保了基本的通信后，需要使用“nslookup”来测试 DNS 确保服务器名字已经获取。使用“traceroute”来判断客户端沟通路径是否在连接服务器的路劲上分解下去了。一旦确认了连接机器的路径，使用“telnet”功能检查远程端口是否打开。接着，使用 SSH 连接服务器，然后在服务器端本地使用“netstat”命令，另外通过“iptables”命令来检测防火墙。使用“iftop”功能检测低性能网络。最后，如果需要分析协议，可以使用“tcpdump”功能或“winshark”工具对服务器进行深层的由内而外的协议检测。

DNS Issues DNS 问题

DNS 问题存在于客户端和服务器端。在客户端，可以使用“nslookup”功能来判断问题是否是“/etc/resolv.conf”文件错误设置引起的。另外一种情况是服务器可能通过回复客户端提示所查找主机还没被设置。“dig”功能非常强大，能帮助检测服务器问题，其中包括：递归域名服务器，DNS 缓存，TTL，区域语法错误和区域传输问题。

Email Issues 邮箱问题

邮件是通常是通过那些常见的协议来发送的。其邮件头包含有它传输过程中的路线等重要信息。如果没有成功接收到邮件，可以使用“telnet”来发送邮件，它通过连接接口 25 和输入 SMTP 协议相关字符数据来完成这一步骤。这样从邮件服务器返回的代码号就可以用来分析存在问题。另外，“nmap”也会暴露出邮件服务器是否在侦听端口。扫描日志文件及检查邮件服务器配置也可以进一步诊断邮件问题。

Website Down 网站宕机

Nginx 和 Apache 服务器提供的是类似的网站服务。网站的很大一部分责任在于接受请求和发送响应。当一个网站变得不可用时，我们很快就能知晓。首先需要确认的是网站所需服务是否还在运行，可以通过“service”命令来检测，另外，还需要使用“chkconfig”命令（或取决于 Init 系统的类似工具）来确保该服务的设置是在服务器启动时就开始。命令行工具“wget”和“curl”使用 http 协议与网站沟通，用以快速检测其可用性。比如，为了跟踪 web 服务器服务重启，可以使用各实用程序来确保特定的 URL 返回一条成功消息（状态码 200）。网站服务请求使用 HTTP 协议，该协议有一组众所周知的状态码。本书描述了该状态码范围及其相关涵义。同时 Web 服务器生产的日志也可以用于检测错误。从日志中能找出最常见的错误包括配置错误和权限问题。此外，web 服务器可以直接通过网页来报告它的状态。Web 服务器所报告的统计信息可以直接用来判断是否存在由于过大负荷所造成的延迟或错误。

Database Slow 数据库缓慢

MySQL 和 PostgresSQL 是两个工业级数据库技术。这两个数据库技术所提供的服务都可以通过之前提到过的“service”和“chkconfig”命令来检测。检查数据库服务器的总体模式跟 web 服务器类似。对日志的检测可以显示之前的问题，同样，数据库本身也会报告它们的当前状态。可以对日志进行特殊设置以用于特殊的记录，比如：跟踪较慢的查询。此外，用于分析服务器缓慢和硬盘问题的工具同样适用于数据库故障排除。

Hardware Failure 硬件故障

故障排除可能会检测出有故障的硬件。最常见的要数硬盘驱动器，但是以下其它硬件组件也可能存在有故障（或者造成故障）：RAM，网卡，温度和电源。每个设备都会表现出其独有的症状，而有些症状则有不同的根源。

InfoQ与本书作者 Kyle Rankin 针对以下不同话题进行交流：

InfoQ**：都有哪些其它的书帮助你（Kyle Rankin）成为Linux服务器专家的？为什么？**

Kyle：关于技术的书可以分为两种，一种放在家中的书架上，另外一种保证放在你的书桌上。我曾换过几个工作，我意识到有几本书总能保留到下个书桌：

《DNS and BIND》和《Postfix the Definitive Guide》：出于同样的原因，我一直将这两本书置于我的身边。在我的工作中，我总是有 DNS 和邮件服务器打交道，而每当我遇到 BIND 或 Postfix 配置问题时，这两本书一直是我的第一手资料。

《TCP/IP Illustrated, Vol 1》：该书用于从基本层面理解 TCP/IP 是如何工作的。在我的书中，经常强调理解事物是如何工作的会在故障排除时起到很大的帮助，该本书绝不仅仅简单地解释了 3 方 TCP 握手或什么是 MAC 地址，它深入地解释了所有主要低层协议。

《Forensics Discovery》：我能想象到很多系统管理员在该书刚出来时就直接把它过掉了，因为他们假定该书主要目标是安全方面人员。而我对安全和辩论术有着浓厚的兴趣，在该书的开头几个章节为描述 Linux 文件系统如何在低层工作树立了良好的例子。与此同时，我也非常感激这是一本很薄的书。太多的作者通过填充长篇大论或大量引用材料来使书本加厚，而我则偏向于那些薄的、切入中心的书本。

InfoQ**：你的书与其他Linux服务器及疑难排除书籍有什么区别？**

Kyle：首先你会意识到我的书并没有厚得跟电话簿一样。我认为总体上，已经有太多的技术书籍过多地关注如何加厚书本，他们往往大量引用可以从软件文档或个人主页获取的相关免费资料。或者，很多技术书籍过分努力想让读者觉得其更聪明或更技术化，当往往忽略了其可读性。我倾向于选择一个更简单，更实际的方式来进行疑难排除，讲述一般问题类型，以及如何使用常见工具来追寻根本原因。书中我有很多机会大可将书籍增厚，比如，花上个几页来记录每个 MySQL 或 Postgres 分析度量。但是，我选择尽量将内容精华到读者真正需要知道的范围。

InfoQ：对于个人来说，需要采取什么方式来帮助跨功能团队学习书中的资料呢？

Kyle：向跨功能团队介绍本书最好的方法之一就是疑难排除一个非产品问题。这样，每个人都可以根据自己的时间一步一步来，也不用担心犯错。从团队中挑选出一人作为领队，他可以是传统团队中的开发或 QA。另外一种方式则是在事后调查分析时，采用书中所说的疑难排除步骤。因此团队可以讨论他们在解决问题时所采用的步骤，并将它们与书中的步骤进行对比。

关于作者

Kyle Rankin 目前是 Artemis Internet, Inc. 公司系统工程领导。除了《DevOps Troubleshooting》，他还著写过《Knoppix Hacks》、《Knoppix Pocket Reference》、《Linux Multimedia Hacks》和《Ubuntu Hacks》，并为多本其它书做出贡献。Rankin 是 Linux Journal 一名优秀的专栏作家，曾发表于 PC Magazine，TechTarget 网站和其他各类刊物。他经常演讲于开源软件，其中包括 SCALE、OSCON、Linux World Expo、Penguicon 及一系列 Linux 用户组。

参考英文原文： Interview and Book Review: DevOps Troubleshooting: Linux® Server Best Practices

感谢陈菲对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。