Google_sre_001

[other] 再读 Google‘s SRE: Introduction

Google’s SRE Book 对整个互联网的影响是毋庸置疑的.

What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team. 这是 SRE 的核心, 是 SRE 的基础. 没有强读写代码能力的纯运维价值过弱. 没有能力阅读 istio & envoy 源码的人是无法运维 mesh 的. 能写代码是将日常操作自动化&系统化的基础, 手动操作既不安全也不高效.

In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s). 时至今日, 这个团队目标的定义依然毫不过时. 服务体验是我们的核心目标, change managemnet, monitoring, emergency response 是我们的手段, 效率, 或者说成本的约束, 避免了单一目标使行为走向极化.

As already discussed, Google caps operational work for SREs at 50% of their time. 把时间和精力放在高收益的事情上, 这对打工人来说是通用的. 收益即包括对公司业务的, 也包括对个人成长的, 二者至少在大部分时候方向应该是一致的. 一方面, 要通过自动化, 流程化将自己从重复性的劳动中解放出来, 另一方面, 学会拒绝, 学会讲道理.

Pursuing Maximum Change Velocity Without Violating a Service’s SLO. 在保证系统稳定的基础上实现业务的快速迭代.

Monitoring 监控是决策的基础, 清楚线上服务的状态是必须而不是可选. 用 metrics 来看趋势和整体情况, 用日志来定位具体问题.

控制信息的有效率, 我一直推崇用一个显示器的面积来展示系统最核心的指标. 但是随着系统规模的进一步扩大, 这个目标越来越难实现. 同时, 我也无法保证自己永远在显示器前, 所以我们要将主动发现问题转变为问题主动提醒我们, 也就是监控.

需要立刻处理的问题, 需要立刻报警. 可以随后处理的问题, 也应该主动通知, 避免重复性的巡检. 比如说数据库的磁盘使用率超过 70%, 并不需要立刻处理, 但是值得关注并处理.

记住控制报警的有效率, 避免关键信息被淹没, 提高报警的公信力.