前言¶

本文初稿编写中

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

运维、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），代表了服务提供商和客户之间的可用性约定。

那么如何定义「可用」呢？这就与 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 中的何者，恰当的工作态度也同样是必要的。你需要对你管理的系统/服务负必要的责任，包括：

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

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

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