用 Span 对 C# 进程中三大内存区域进行统一访问

当出现故障时，区分清楚责任，到底是稳定性工作没有做到位，还是做到位了，但是团队同学疏忽了，还是说只是单纯的业务变化。

3 开发和SRE的区别

都是做技术的，很多开发刚刚转向负责稳定性时，有些弯转不过来。

举个例子：对于“问题”，传统的开发人员更多的倾向于是“bug/错误”，而SRE倾向于是一种“风险/故障”，所以，两者对“问题”的处理方法是不一样的：

• 开发：了解业务 -> 定位问题 -> 排查问题 -> 解决问题
• SRE：了解业务归属 -> 快速定位问题范围 -> 协调相关人投入排查 -> 评估影响面 -> 决策恢复手段

可见，开发人员面对问题，会首先尝试去探究根因，研究解决方案;而SRE人员首先是评估影响，快速定位，快速止损恢复。目标和侧重点的不同，造成了SRE思考问题的特殊性。

所以，成为一名SRE，就一定要从态度和方式上进行转变，切换到一个“团队稳定性负责人”的角度上去思考问题。

4 SRE心态上的一些释疑

下面这些疑惑，有很多是我最初做稳定性的时候面临的问题，这里给大家分享和解释一下我的解决方法：

疑惑1：做好了是应该的，出了问题就要负责任

不出问题，就是稳定性的基线，也是SRE的基本目标，所以这个话虽然残酷，但是也不能说错，关键在于：你要如何去做。

如果抱着一个“背锅” / “打杂”的思想去做稳定性，那么“做好没好处、做不好背锅”这句话就会成为击垮心理防线的最重的稻草。

应对这种心态的最关键一点，在于“做好”不出问题这条基线，要从下面3个方面去做：

(1)及时、快速的响应

这是最关键的一点，作为一个SRE，能够及时、快速的响应是第一要务，遇到报警、工单、线上问题，能够第一时间冲上去，不要去问是不是自己的，而是要问这个事情的影响是什么，有没有坑，有没有需要优化的风险?这是对自己负责;

同时，快速的响应，还需要让你的老板第一时间知悉，这个不是在老板面前爱表现拍马屁，而是要让你的老板第一时间了解风险的发生，一个好的团队leader，一定是对质量、稳定性和风险非常敏感的leader，所以，你要将风险第一时间反馈。这是对老板负责。

反馈也是有技巧的，不仅仅是告知这么简单，你需要快速的说明以下几个信息：

• 尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了(这一步叫“响应”)。
• 组织人员，快速定位问题，告知问题初步定位原因。(这一步叫“定位”)
• 初步影响范围是什么?给出大致数据。(这一步方便后面做决策)
• 有哪些需要老板、产品、业务方决策的?你的建议是什么?(这一步很关键，很多时候是：两害相权取其轻，你的评估和建议，直接影响老板的决策)
• 当前进展如何，是否已经止血?(这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况)

（编辑：吉安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!