跳转至

序言

主要作者

@taoky

本文编写中

如果你正在阅读这段话，那么你可能手头要负责一台或者多台服务器的维护，也有可能仅仅只是希望能够更加了解自己正在使用的系统。本前言部分会介绍与系统管理员职责相关的内容，帮助你在阅读本教程的内容之前，对相关概念与自己需要做的事情有一个简单的认识。

运维、SRE 与 DevOps

当我们讨论「系统管理」相关的职责时，我们可能经常听到标题中阐述的几个词：

运维

运维需要管理系统，处理突发事件，部署业务所需要的应用，并且确保系统的性能、稳定性与安全性。运维需要管理包括服务器、网络、存储等系统，做好系统监控、备份等维护操作，并且需要有故障排除的能力。

SRE (Site Reliability Engineering)

SRE 是 Google 于 2003 年提出的概念，希望将软件工程相关的方法应用到系统管理的工作中去。SRE 在运维工作的基础上，需要尽可能地通过软件开发的方式来实现系统管理的自动化，减少人为干预，从而构建可靠的系统。SRE 还在运维的基础上引入了其他的概念，诸如可靠性的定义以及衡量方式等。

DevOps

DevOps 和 SRE 的工作很多时候是相近的，但是 DevOps 更加侧重于开发与运维之间的融合，减少两者之间的沟通成本，加快产品的开发与迭代。例如，开发可能会希望能够尽可能快速地部署自己的更新，而运维可能会由于稳定性上的顾虑而尽可能避免变化，但通过 CI（Continuous Integration，持续集成）和 CD（Continuous Delivery，持续交付）上的工作，更新（交付）可以在保证稳定性的同时更加快速。

Linux 201

需要注意，Linux 201 不是专门的 SRE/DevOps 入门教程。

可靠性指标

当我们讨论「可靠性」时，经常可以听到像「3 个 9」「4 个 9」这样的描述，这代表了服务正常运行的时间比例。如果服务的可靠性有 3 个 9（99.9%），那么每年则最多允许不可用 8 小时 41 分钟 38 秒。如果再加一个 9（99.99%），那么每年的不可用时间段就最多只允许 52 分钟 9.8 秒。在签订法律合同时，这项指标也被称为 SLA（Service Level Agreement），代表了服务提供商和客户之间的可用性约定，如果服务没能达到 SLA 的要求，服务提供商需要提供补偿。

s/SLA/availability/g

不少时候，SLA 这个词会被误用来描述某个服务的「可用性」，这通常是不正确的（除非你与服务提供商签订了正式协议）。特别是对公益性质的网络服务而言，因为这类服务无法承担违约赔偿责任，因此只能够尽力而为保障可用性，而不能使用 SLA 这种有合同约束效力的词汇。

更好的说法是「某个服务的可用性（uptime 或 availability）在某年达到了 / 预期能达到 99.9%」。

那么如何定义「可用」呢？这就与 SLI（Service Level Indicator）有关了。SLI 是用来衡量服务情况的具体值，例如，HTTP 的响应时间就是一种典型的 SLI。

高于「3 个 9」的可靠性目标要达到不是一件容易的事情。即使堆很多人来三班倒工作，要达到「4 个 9」的水准也仍然是一件困难的事情。因此在企业中，运维/SRE 工作会需要使用更加复杂（Linux 201 也不太会涉及）的方式来提高可靠性，例如尽可能实现自动化运维，减少因为需要人力介入导致不可用时间增长的问题；使用分布式的架构，尽可能排除单点故障（Single Point of Failure，SPOF）问题；设置热备服务等等。

所以我需要做什么？

如果你希望可以快速搭建出和中型、大型企业类似的高可靠性系统的话，或者尽可能使用云厂商的能力构建整体系统的话，那么 Linux 201 可能不是一个合适的教程。但是 Linux 201 并非对前述提到的工作没有帮助——我们相信，完整地理解（相对）简单、小型的系统（或者说「单机」情况下）内部的工作原理，是理解更大的系统不可或缺的前提。

除却技术以外，不管是系统管理员/运维/SRE/DevOps 中的何者，恰当的工作态度也同样是必要的。你需要对你管理的系统/服务负必要的责任，包括：

  • 保证相应的系统/服务尽可能处在安全可靠的状态
  • 不能因为个人原因蓄意破坏用户数据
  • 尊重用户的隐私，不能够利用用户的数据获取不当利益
  • 与用户以及其他管理成员保持沟通与合作

因此，这是一份能力、道德素养与责任心缺一不可的任务。同时，在将系统的重要权限授予其他用户时，也请确保对应的用户了解相关的注意事项，并能够为自己的行为负责。特别需要注意的是，目前大语言模型无法代替没有任何经验的用户进行系统管理（这一点也可以从下面的例子看到），并且由于忽略警告、盲目听从建议等原因，可能会导致更严重的后果。

sudo 的首次提示语

当作为普通用户第一次使用 sudo 命令时，你会看到下面这段话：

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

这三点（隐私、谨慎、责任）概括了上面提到的必要原则。

USENIX 的 System Administrators' Code of Ethics（系统管理员伦理守则）对这些必要的原则有着更深入的描述。

此外，在维护的过程中，出现问题是不可避免的。但是在出现问题之后，应当避免责备某个具体的人。正如绝大部分的飞机事故都是各个方面的问题共同导致，几乎不会出现某一个人需要承担全部责任的结果一样，一个合格的系统管理员，需要能够系统地分析故障原因（这也被称为 Post-Mortem，即「事故复盘」或「事后分析」），并且针对分析得到的问题，或编写工具，或改进流程，这样才能够有效地防止同样的问题再次发生。

事故复盘

一份简单的事故复盘包括以下内容：

  • 事件描述与发展时间线：在什么时候发生了什么？影响到了谁？导致了什么结果？当时是怎么处理的？
  • 原因分析：发生对应问题有什么技术上与非技术上的原因？
  • 改进措施：具体如何改进防止问题再次发生？改进步骤每一步的负责人是谁？改进的时间表是什么？
  • 总结：有哪些地方做得好（正面经验）？有哪些地方做得不足（教训）？

著名事故的复盘

真实案例

这是一件真实发生的、在某群聊中流传出来的例子：实验室的 A 将服务器的用户私钥提供给了 B（用户有 root 权限），B 为了运行游戏尝试将 Linux 远程重装为 Windows，在咨询 GPT 后进行操作（聊天记录的 GitHub Gist 存档），结果导致数据丢失，所幸服务器上没有重要数据。

尝试回答以下问题：

  1. 该事件的事故复盘大概会是什么样子？
  2. 如果你是 A，你会如何处理这件事情？如何确保类似的事情不会再次发生？
  3. 如果你是 B，从这件事情上你得到了哪些教训？