Day 2：什麽是 SRE

那麽，我们今天就来谈谈到底 SRE 是什麽，以及他如何在软件的生命周期发挥作用吧。

SRE 的由来

SRE，全称为 Site Reliability Engineering，台湾通常译为「网站可靠性工程」，而相对应的职位，自然就是 Site Reliability Engineer，缩写亦为 SRE。这个概念最早被 google 的 Ben Treynor 在 2003 年所提出的，基本上是期望可以透过软件工程的手法解决日益复杂的维运问题，透过开发各种自动化工具辅助，解决那些重复且繁琐的流程，将人力解放出来投入在开发上，以提供更可靠的软件以及更快的迭代速度。

可靠性

可靠性的高低，取决於服务不可用的时间长短，当不可存取的时间越短，则服务的可靠性就越高，通常来说，我们会以「可用时间」的比率来量化它，例如 99% 就代表在一年之中，至多有 3.65 天无法存取服务是被允许的。

影响可靠性的因素有很多，其中几个重要的指标包括 MTBF（平均故障间隔时间，Mean Time Between Failure）和 MTTR（平均修复时间，Mean Time To Repair），这两项指标非常直接的影响服务的可靠性，越高的 MTBF 表示故障的频率越低，而越低的 MTTR 表示每次发生错误时造成的影响会更小。

以 Normal OJ 为例

所以朝着这两个方向努力便是提高可靠性的思考方向，然而造成故障的原因有很多，具体有哪些是可以尝试改善的呢？我想这对於每个专案来说可能会有些许的差异，以 NOJ 在这些时间运作的情况来看，主要的故障成因包括：

• 学校停电：因为我们的 server 放在学校，所以每当学校停电时，整个网站便无法存取了。
• 程序逻辑错误：就是 bug 啦，因为种种原因而被布署到 server 上，可能进而导致使用者无法存取服务。

关於以上两点，学校停电这部分就我们现有的资源来说无法完美的避免，也就是说就 MTBF 来看，他不是们可以掌控的因素，学校停电就得关机（当然如果可以转移到 Azure 等云端服务可以避免这类型的问题，可是我们没钱 ）。然而若是在 MTTR 这方面，却是有可以着手改善的空间，因为目前还是需要我们自己在电力回来的时候手动把 server 打开并开启服务，若是可以在复电後自动开机或是重启服务，都会比起手动操作来得有效率，有效提高可靠性。

然而天有不测风云，有时候可能会发生像是乖乖过期之类的一些意料之外的状况，就算原本有准备一些自动复原的手法也没办法正确的执行，这时候还需要架设监控的系统，替我们定期检查服务的发育有没有正常，啊不对，是有没有在正常运作，并且在发生无法自动化处理的状况时发出警报通知相关人员。

而关於程序本身的 bug 导致服务没有办法正常运作的情形，只要不更新程序码，就不会有 bug 了。

(source: meme generator)

没啦，开玩笑的。比较合理的策略可以分成两个方面来看，第一个是要预防 bug 在部属到生产环境之後才被发现，所以在对专案做出任何变更的时候，我们应当要确保这些变更都有做过足够的测试，才将他合进 main branch。

而有关於测试的设计，我想网路上应该已经有不少相关的讨论了，这边就只提一点，那就是测试要尽量可以自动化执行，因为人在长期执行重复的动作时难免会出错，可能会导致测试的结果不正确，意外将 bug 引进 main branch，所以有自动化的测试很重要。完整的测试可以有效地降低错误发生的机率，也就是说可以提升 MTBF。

另外一个部份是事後的补救机制，当 bug 已经发生，我们需要花多少时间让服务恢复到可用的状态？把 bug 修掉当然是个方式，然而我们很难评估一个 bug 需要花多少时间去修复，更好的选择是先将版本倒退回上个可以正常运作的版本，这个操作通常来说相对比较容易。

以 NOJ 来说，我们部署的流程应该足够简单（一个 shell script），然而在发现错误的部分却做得不够好，这边我想可以改善的流程有两点：

1. 检测服务是否正常：以往出现问题，往往是修课的同学在使用上遇到一些问题跟我们回报过後，才会开始处理。若是有个自动化的流程可以检查生产环境是否正常的话，就可以更早的发现问题。
2. 纪录可以正常运作的版本：在发生问题之後，我们需要退回到上一个版本，然而目前我们对於「上一个可以正常运作的版本」并没有纪录，所以说这部分还需要手动找到可以运作的版本，若是有纪录下来的话，那们自动退版也就会变得比较容易实现了。

小结

今天简单的介绍了 SRE 是什麽，并且提及了两个重要的概念。

自动化

自动化可以有效地节省人力，并且降低因人为的失误而造成的错误，让我们有精力将时间花在改善流程上面。

监控

监控可以在服务上线之後，帮助我们确认服务是否正常，并且在需要的时候主动通知相关人员，避免我们是在错误发生一段时间之後才发现，争取更多修复的时间。

参考资料

• Service Availability: Calculations and Metrics, Five 9s, and Best Practices
• The Factors That Impact Availability, Visualized