SRE站点可靠性工程师

Google定义

关于SRE的工作内容，Google定义了以上三个主要内容，其是一个金字塔结构，越往上在日常工作中的占比相对越少。而且细化下来的工作内容为：

对应的理念可以总结为以下几句话：

从事该工作所在的部门管理有5w台左右的服务器资源，组织处在上图中的第三级和第四级转型阶段。做为最初的SRE工程师，我这里的职责总结有以下几点。

各平台工具构建：这里列举几个最基础常见的工具，如：

监控大屏：如何将最关键的信息在监控大屏显示，需在有哪些指标。
CMDB：构建一个动态的CMDB（基于图数据库），现网有相关数据变动时，可以快速的更新相关数据到CMDB平台。比如虚拟漂移，确保其所在的宿主机在５分钟内能更新为新的数据。在出现故障时，能通过平台工具输入设备信息，立即了解故障面信息。
故障调度平台：多专业组协同时，如何确保信息能一屏同步，调度过程中确保各人查询的都是最有用的信息。各子平台的指标数据如何能接入该平台，如何输入对应的指令或描述直接返回对应的信息（chatops）。
告警聚合压缩平台：主机、设备、应用出现问题时，按常规运维手段告警信息是喷涌的，如何将区量告警压缩为真正有用的几条
根因智鉴平台：如何通过图数据库（关系）、日志、告警、时间等信息通过噪音、关联检测消除确认故障根因。
……

当然还有弹性自愈平台（比如通过k8s等自调度技术实现）、趋势拟合预测（态势感知）等相关平台。

流程管理： 这里也只列举几个常见的流程，如：

On-call调度流程：故障等级如何定义、在多长时间该如何上升、都要有什么人参与，谁是调度第一责任人（确定将军）。
故障回溯流程：在明确故障根因后，分析整个处置流程是否合理、各流程花费了多少时间、现网其他设备平台应用是否同样有潜在问题，确认下一步改进计划是什么、责任人是谁、什么时候完成，是否需要新的工具，是否需要调整监控指标等。
待办跟踪流程：制定的待办在对应的时间点，有没有完成？什么原因？

架构审视： 对应的应用和平台是否有高可用？最多可以出现几节点故障。制定Chaos Monkey混沌工程验证是否真的和宣称的等级一致。通过控制最小化爆炸半径，提高系统健壮性。

工具审视： 各专业组通过什么样的工具能验证对应的问题不是出在该块。比如网络的拨测手段有哪些，延迟、流量、饱和度、错误等黄金指标是通过哪些监控手段实现的。

SRE主要为上面这些指标负责，对应的指标具体的意思如下：

参考链接：

SRE工作的最终目的是希望能过工具、平台、流程等结合，实现扁鹊大哥的能力。

如您感觉文章有用，可扫码捐赠本站！(If the article useful, you can scan the QR code to donate))