SRE最好从整个软件研发周期的最开始去联合相关的干系人去制定相关的SLI，在未来软件进入生产之后，更好的提供一份比较科学严谨的SLO以及SLA，以及避免在可能在欠缺SLI的情况下导致我们不得不为相关的指标增加开放工作，而且SRE应该为研发团队宣导相关SLI的历练，让研发在实现功能的同时考虑功能相关的SLI数据的埋点上报。这需要我们跟研发团队保持良好的沟通和宣导。

服务时间：

性能和弹性是两个冲突的点。如果我们一味的追求性能，必然导致我们的应用不是太弹性。如果太弹性也就意味着我们的应用性能不是那么强。

这两者的取舍应该取绝于，我们的单体QPS以及用户的对于延迟的容忍度。

这个定义一般是定义我们的SLO，他可以是当前服务承载的容量，也可以是CPU使用率。饱和度最大值应该是我们服务不可用的时候的所表现的测量点。

我们系统的可观测性信号由以下几点：

这几个信号会帮助我们显著了解我们系统的稳定性，并能很好的帮助我们在故障的情况下，快速发现并且快速排障。

而且这几个信号我们也应该进行数据标准的统一让几者可以关联起来，更好的帮助观察和故障排查。这也是现代可观测性建设的核心目标之一。

我们应该建设一个具备相关信号的可观测性平台以及推动研发进行相关的可观测性信号能力的接入以及开发。

最好联合相关团队进行宣导，以及最好有在迭代中有10%的人力投入能够做到相关的支持。

1）指标

指标是一个很重要的概念，我们常常忽视他的存在。指标的定义，与监控系统所支持的数据模型结构，有着非常密切的关系。监控数据的来源，从数据的类型可以分为：数值，短文本字符串，日志(长文本字符串)。通常所讲的指标，都是对当前系统环境具有度量价值的统计数据，使我们能够明确知道当前系统环境的运行状态。

指标的定义应该遵循SMART原则：

指标数据模型(OpenMetric)：

metric_name{<label name>=<label value>, ...} value timestampnode_disk_read_bytes_total{device="sr0"} 4.3454464e+07node_vmstat_pswpout 0http_request_total{status="404", method="POST", route="/user"} 94334

指标类型：

2）跟踪（Trace)

跟踪对于当下复杂的分布式应用来说是非常必要的。它们可能分布在上千个服务器、不同的数据中心和可用区中，如何监控服务之间的依赖关系和调用链，以判断应用在哪个服务环节出了问题，哪些地方可以优化？

当前最佳的分布式Trace协议选择应该是Opentelemetry。

Causal relationships between Spans in a single Trace        [Span A]  ←←←(the root span)            |     +------+------+     |             | [Span B]      [Span C] ←←←(Span C is a `child` of Span A)     |             | [Span D]      +---+-------+               |           |           [Span E]    [Span F]

Temporal relationships between Spans in a single Trace––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time [Span A···················································]   [Span B··········································]      [Span D······································]    [Span C····················································]         [Span E·······]        [Span F··]

3）日志（Log)

日志也是我们观察系统的一个重要信号，担心当今软件形势的发展，让我们的日志收集和存储受到了巨大的挑战。当我们的应用越来越多的从主机往k8s这种架构转型的时候，我们的日志采集受到了比较大的挑战，而且服务产生的日志也越来越多的，对于海量的日志的检索，我们需要探寻更多的方案。

4）Profile

对于当下云原生的技术的发展，如何对云原生架构下的应用进行profile，也是我们的一个重要挑战，所幸的是由于bpf技术的相关发展，我们可以更好的利用底层技术，去快速的利用bfp相关的技术进行应用的profile从而帮助应用更好的调优。

5）Crash

crash是我们线上环境出现问题之后的重要现场，我们理应建设好相关的crash分析流程，来更好的跟相关信号进行打通关联，从而跟好的做到自动化的问题发现，报告生成。

我们可以简单的用 SLO目标 + 错误预算 = 100% 来简单的计算出我们的错误预算。我们的一些日常工作例如版本迭代、变更、故障处理都算在错误预算里面，也就是只要会影响SLO的操作，都应该属于我们错误预算的一部分。如果我们超出了错误预算，也就意味着我们的SLA会收到用户质疑，也就意味着我们应该开始排查为啥错误预算的消耗过高，也就是我们应该给错误预算一个阈值范围，在一定范围的功能发布，变更操作都属于正常的，一旦超过某个值，也就意味着我们的系统可能出现了不稳定的情况，这个时候我们应该马上进行总结，寻找问题的原因，快速解决它。我们应该同真个团队寻找到一个合理的平衡点。

作为SRE，我们应该对工作有个要求：

所以需要人操作的地方一般属于我们的事务工作，但是我们也不需要将全部的时间投入到事务工作上，比如变更需要手工执行命令，手动的通知开放。这个时候我们应该理一理我们的时间投入情况，如果事务性的工作太多，是不是我们没有梳理好整个发布流程，变更流程。我们没有沉淀出相关的自动化流程。所以一旦发现我们的事务性工作占据太多的时间，一定要停下来梳理，哪些可以自动化的，哪些可以半自动化的。争取将人工参与的部分降到一个合理的地步。

风险识别与管理，我在大学的时候学的是安全工程，这是一门专门学习如何进行风险识别与管理的学科，但是那都是对于现实层面的风险识别识别与管理，例如机械、工业、化学、交通等领域的，但都有着类似的方法论。

说到风险，我们就要认识一下海恩法则：

通过海恩法则，我们要认识到事前的风险识别与管理能极大的帮助我们避免相关问题的出现。所以需要我们对于应用架构有着极为深度的了解。并从可用性的角度，去判别应用风险的可能点。

我们列出一份详尽的系统风险评估文档。从不同的角度列举不同风险的可能点以及事故预言。在现代云原生的发展下，我们更加可以利用混沌工程等故障去模拟相关风险的产生。

事故是不可避免的，其实事故不可怕，可怕的是我们没有对事故进行总结学习。只有出现了事故，我们才能对于现有体系的问题进行修复总结，避免同一个事故再发生，所以我们需要对于事故有着细致的报告和总结复盘。

事故报告是我们了解事故全景的重要手段，我们需要通过事故报告了解到：

有了以上的信息，我们才可以详细的知道一个事故的全部面貌，最好我们有一个统一的知识库去存档这些，帮助以后我们了解相关的改进背景以及处理方案有着极好的作用。

研究故障或者失败的逻辑非常重要，复制成功者所做所为，不一定回让你成功，而避免失败者的做事套路，将一定会增加你的成功概率。

底层逻辑：

良好的事故复盘能够有效的帮助团队，回顾整个事故的点线面，这样学习式的复盘，能更好的给每个人以比较深刻的印象，最好的是学习之后，能够整理出相关合理的流程帮助未来的事故不在发生以及推动相关工具建设，告警设置以及故障经验。

SRE还有重要的工作是相关系统的研发，因为很多重要平台都是通过SRE孵化出来的，例如可观测系统、海量分布式作业平台，CMDB系统等。因为这些平台的使用才能更好的帮助整个团队提高研发效能水平。

SRE也需要有着相当不错的架构设计能力，因为SRE需要评估研发团队的架构以及SRE团队研发平台的架构。

而且SRE也需要从架构层面去衡量整个系统的可靠性，可观测性等能力，并给出相关的指导意见。

软件工程更是SRE需要深入了解到，因为我们需要参与到研发流程的建设，不管是瀑布式的研发模式，还是现在DevOps敏捷迭代的开发模式，我们都应该完整的了解软件工程。

从我的经历来看，一般SRE团队内部没有专职的项目管理的成员，所以一般需要某一个成员兼职项目管理的角色，这名成员一般要根据项目周期、时间风险、人力投入、技术分析、周边团队协作方面去规范项目进度。一般需要需要经验丰富的人担任。

SRE自身的软件交付质量，也需要有相关的测试流程去把握，但是对于SRE团队来说，最好是做到核心路径的单元测试覆盖，这样在重构或者功能迁移的时候，能快速回归测试迭代，最后通过完整的集成测试帮助上线前的交付验证，避免出现问题。

因为SRE团队一般成员较少，所以自身的研发DevOps流水线一定要建设得比较好，才能高效的产出交付功能，不然就会陷入研发怪圈。

相关推荐：