大规模集群管理和运维自动化

说到大规模集群管理，就离不开运维自动化。一个人手工也许可以运维几百台机器，但是随着集群规模的增长，我们需要的是一个人运维数万台机器。 这在大规模集群管理中是一个常见的问题。因此，运维自动化是一个很重要的事情，这也是为什么很多公司原因上云，因为上云之后运维的问题就托管给 云平台了。这也是云平台这么贵还能卖的这么好的原因。

运维自动化的问题到底是一个什么问题？我认为，可以拆解为以下子问题：

1. 自动发现错误
2. 自动修复错误
3. 安全（Safety 而非 Security）

这里的每一个问题都是复杂的，困难的问题，远非表面上看起来那么简单。以下仅作简单的展开，提供一些思路。

自动发现错误

我们先简单的将错误划分为两类：硬件错误和软件错误。

硬件错误

通常，商业硬件都会提供一些接口用于获取硬件错误信息，这些错误信息是由硬件自检产生的，例如硬盘 S.M.A.R.T。通过这些接口报告的错误信息是 比较准确的。但是还有一些情况，虽然硬件出问题了，但是硬件自检没有检测到。这种情况也会影响运行的软件，需要通过其他方式进行检测。这种问题 通常是由业务方发现异常，排除软件错误因素后，或由统计结论导出，确认为硬件问题。具体是什么硬件问题，还需要离线进行进一步检测。

还有一类特殊的硬件错误，发生点不在本机，但是也会影响服务，即网络错误。网络错误根据现象一般有以下分类：

1. 传输内容错误，例如数据位反转
2. 大量丢包，例如 CRC 校验莫名出现大量错误，但是实际上没错（有可能是硬件错误，也有可能是系统内核错误）
3. 带宽下降，例如交换机错误
4. 连接丢失，例如交换机错误

由于网络错误不一定发生在本机，因此很难通过单机定位问题，通常通过 PingMesh 结合其他手段发现问题，例如流量监控，内核关键 metric，交换机关键 metric。 近的新方向是结合 SDN 和机器学习发现并解决网络问题。

软件错误

软件错误的类型五花八门。通用的检测和容忍错误的机制是复杂而困难的（例如拜占庭问题），所以要允许用户灵活方便的扩展错误发现规则。 一般来说，软件错误有以下几种：

1. 操作系统错误
2. 依赖环境错误
3. 数据错误
4. 配置错误
5. 自身 bug

自动修复错误

通用的解决所有问题的方案（大概率）是不存在的，但是我们又不能完全为每一个特殊的错误定制修复的方法。对于硬件故障，我们只有换机器一条路可走。 对于操作系统的问题，通常重启即可解决问题，如果不能解决问题，可能需要重做系统。重做系统也涵盖了系统升级的需求（考虑到有些时候需要升级内核 才能解决问题）。数据错误需要使用强 checksum 校验，具体需要多强，需要覆盖多大范围，则是一个仁者见仁智者见智的问题。配置错误和自身 bug 其实 是部署需要解决的问题，如果能够及时发现问题，只需要在部署的过程中中止并回滚即可解决问题。而如何部署，又是一个可以写一篇文章的大问题了:D

安全

自动化担心的问题就是安全。不能保证安全会导致可怕的后果，例如瞬间几万台机器被重做系统。在大规模集群管理中，所谓安全，实际上指的是安全规则， 安全规则保证的则是 SLA。可预期的 SLA 通常由 MTBF（Mean Time Between Failures）计算得出理论上限。自动修复会导致理论 MTBF 降低，这是因为 我们通过错误发现机制在建模的时候考虑了更多的错误因素。重启服务，重启机器，重做系统，换机器，都会导致服务中断。我们可以认为，在错误修复 期间，这台机器上的服务不可用。此时，如何有序的保证剩下的可用机器总是大于一定数量（并且满足一定规则），则是安全的核心。