SRE理解

背景

之前有一段时间做过半个月的SRE，当时并没有完全理解这个岗位是做什么的。后面兜兜转转又做回了SRE，这里总结下工作几个月来对SRE的理解，以及一些工作内容，同时还参考了别人对SRE的介绍。

SRE定义

SRE(site reliability engineer)在各种社区上被说成是运维，是背锅的。或者干脆说SRE是devops是运维这种；这里简单说下我对SRE的理解，SRE主要是负责三个核心内容:

• 稳定
• 成本
• 效率

首先来说下稳定性，这里的稳定性更多的是关于SLO一块为主。SLO也就是常说的几个9，比如某服务在一年的时间里面是4个9，那为了实现这个目标，就需要做多活和容灾等等。这里就不展开细说，可以留在下次水下，总的来说SRE在稳定性方面的工作就是围绕着SLO展开。也包括了日常值班和节假期值班。

成本方面涉及到多方面，比如说FinOPS思想，如何用更少的机器支持更多的服务？或者如何让资源得到最大的利用？又或者说之前提高的SLO，假设现在4个9可以满足，但是被强行要求上5个9，那付出的人力成本和机器成本也就越多。像成本一块考虑的也会多得多。

最后来说下效率，效率这边和devops有些重复，可能有时候做了devops相关的事情。比如说CICD流水线这种，也有在运维中过程中去自动化一块重复的事情，解决一些琐事。比如说集群巡检，日常清理等等。

SRE总体来说是一个非常具有挑战性的岗位，但是很多人对这个各位的误解也很多，认为就是运维，做的内容都是一些低级重复的工作。其实SRE是需要运维经验丰富的软件开发工程师或者具有开发能力的运维工程师。

当然不同的公司对SRE定义也不一样，这里借用laixintao大佬博客中提到各家公司对SRE的定位:

比如蚂蚁金服有两种 SRE，一种是负责稳定性的，就是大家所理解的 SRE；另一种叫做资金安全 SRE，并不负责服务正常运行，而是负责金钱数目正确，对账没有错误，工作内容以开发为主，主要是资金核对平台和核对规则（没有做过，只是个人理解）。某种意义上说，已经不算是 SRE 而是专业领域的开发了。

Netflix （2016年）的模式是谁开发，谁维护。SRE 负责提供技术支持，和咨询服务。Netflix 在全球 170 个国家有服务，Core SREs 只有 5 个人。

微软有专门的 [Game Streaming SRE](https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-game-streaming-sre/DevOps at Microsoft - Xbox game streaming SRE.pdf)，负责 XBox 在线游戏的稳定性。

所以不同公司对SRE工作内容是不一样，取决于这家公司性质是什么的。比如我当前所做的主要是保证开发集群，测试集群，验收集群的K8S以及中间件稳定性。相对生产集群来说SLO要求不会太高，面向的也是开发和测试人员。

在工作过程中可以接触到新的知识和新的项目，也可以造轮子，会比较有意思。以成本和效率为主。这里并没有说稳定性不重要，而是相对生产集群来说会要求的轻松一点。而生产集群第一位就是稳定性，之后才会去考虑其他东西。相对来说会比较无聊。这里只是个人体验。

这里可以将SRE简单分几类:

1. Infrastructure：主要负责最基础的硬件设施，网络，类似于 IaaS，做的事情可参考 DigitalOcean
2. Platform：提供中间件技术，开箱即用的一些服务，类似于 PaaS，做的事情可参考 Heroku, GCP, AWS 等
3. 业务 SRE：维护服务，应用，维护业务的正常运行

我应该是偏向于Platform和业务相关。

SRE工作内容

根据之前在SRE中的定义，这里也将三类工作内容简单来进行一个描述，同时配合一些公司的招聘来理解。

Infrastructure SRE

依旧是大佬博客中他对Infrastructure SRE的理解，不过前提是需要自建data center(DC)才会需要Infrastructure SRE。

1. 负责服务器的采购，预算，CMDB 管理。要知道（能查询到）每一台的负责人是谁，在干什么。这个非常重要，如果做不好，会造成极大的资源浪费。
2. 提供可靠软件的部署环境，一般是虚拟机，或者 bare mental。
3. 操作系统的版本统一维护，Linux 发行版的版本，Kernel 的版本等。
4. 维护机器上的基础软件，比如 NTP，监控代理，其他的一些代理。
5. 提供机器的登录方式，权限管理，命令审计。
6. 维护一套可观测性的基础设施，比如监控系统，log 系统，trace 系统。
7. 维护网络，大公司可能都会自己设计机房内的网络。其中包括：
   1. 网络的连通，这个是必要的。对于上层用户（Platform SRE）来说，交付的服务应该是任意两个 IP 是可以 ping 通的，即管理好 3 层以下的网络。
   2. NAT 服务
   3. DNS 服务
   4. 防火墙
   5. 4 层负载均衡，7层负载均衡
   6. CDN
   7. 证书管理

一些对Infrastructure SRE招聘要求:

1. 负责服务器各类场景技术评估、监控、调优、诊断及硬件优化和故障定位分析
2. 负责服务器生命周期过程技术优化、硬件原理和主要特性、完善技术可用性实践
3. 评估硬件功能方案、基于新产品的运维场景下、完善各个过程的新产品适配可用维保障
4. 负责设备生命周期自运营维护；完善运维过程的硬件/系统的技术方案输出和标准化
5. 熟悉X86平台服务器和主要部件的架构和主要特性、及硬件底层的故障判断和分析能力；

职位要求
1. 熟练使用Linux系统，具备Python/shell等脚本语言，部署开发、测试环境 ；
2. 精通X86服务器硬件组件/子系统CPU，Disk,Memory PSU等验证方案者优先；
3. 具有较强的分析问题解决问题的能力，具有良好的团队沟通协作能力；
4. 熟悉自动化运维技术，能充分利用自动化运维来提高工作效率；
5. 学习能力强，技术兴趣广泛；责任心强，对工作充满热情。
6. 熟悉服务器厂商售后及机房现场管理。

可以看到基本上都是以硬件为主。

Platform SRE

同样的Platform SRE和Infrastructure SRE都有类似的地方，就是如果是购买第三方服务，比如说阿里云，腾讯云，AWS等等。其实就不需要相关SRE了。但是如果是自建的就需要相关SRE来维护和提供稳定性。

Infrastructure SRE 维护的是基础设施，Platform SRE 使用他们提供的基础设施建立软件服务，让公司内的开发者可以使用开箱即用的软件服务，比如 Queue，Cache，定时任务，RPC 服务等等。

主要的工作内容有：

1. RPC 服务：让不同的服务可以互相发现并调用
2. 私有云服务
3. 队列服务，比如 Kafka 或者 RabbitMQ
4. 分布式的 cronjob 服务
5. Cache
6. 网关服务：反向代理的配置
7. 对象存储：s3
8. 其他一些数据库：ES，mongo 等等。一般来说，关系型数据库会有 DBA 来运维，但是 NoSQL 或者图数据库一般由 SRE 维护。
9. 内部的开发环境：
10. SCM 系统，比如自建的 Gitlab
11. CI/CD 系统
12. 镜像系统，比如 Harbor
13. 其他的一些开发工具，比如分布式编译，Sentry 错误管理等等
14. 一些离线计算环境，大数据的服务

招聘要求:

1、负责接入层在向云原生转型过程中的规划、设计、部署、以及业务性能调优；
2、负责接入层管控层面的整体方案设计和推进，结合云原生的容器调度体系（K8S），在业务高稳定性同时，做到docker镜像化，自动化运维，探索研究新的技术方向，例如infra as code，不断提升运维工作效率；
3、负责接入层在各项大促（例如双十一）期间的稳定性、规模化以及性能保障，确保峰值时期的平稳运行。
4、负责接入层技术支持和日常运维工作，对突发事件的快速响应、定位及处理，排除故障，保障系统稳定性；
职位要求
1、精通TCP/HTTP(2)/DNS协议原理；
2、熟悉golang/C/Java/Python/Shell中的任意一种以上；
3、熟悉常见的配置管理和运维工具，如：Ansible、Puppet、SaltStack、Fabric、Kubenetes、Docker等；
4、熟悉nginx、lvs、envoy、service mesh等技术，对ngx_lua有实践者优先
4、熟悉阿里云ECS、OSS、SLB、CDN等云产品优先；
5、熟悉云计算平台OpenStack、Kubernetes、Mesos、Swram及docker/kvm/xen等虚拟化技术优先；
6、热爱技术，自我驱动，主动思考，不断钻研和探索新领域，有较好的技术敏感度、风险识别能力和全局意识；
7、高度的责任心，良好的沟通能力和团队协作精神，有较强的跨团队协调能力且抗压能力强。

1. 推进基础设施云原生架构演进，如基础设施即代码（IAC）、Serverless、GitOps等；
2. 标准化调度系统监控，日志采集，包括SLA的制定与故障定位；
3. 建设自动化及工程化的解决方式，以减少在传统运维层面的人力投入，做到无人值守。
4. 建设基础设施的高可用技术风险体系，如变更防御、异常定位和自愈系统。
职位要求
1. 有强烈的技术热情，工作责任感，有开源社贡献优先；
2. 至少精通一门编程语言，Golang/Java优先；
3. 熟悉云原生相关技术，熟练掌握Docker、K8S 等主流云技术，有Terraform使用和研发经验优先；
4. 熟悉Linux系统和Shell，对网络、存储等基础设施领域有一定的了解和知识储备；
5. 熟悉运维自动化部署平台研发，具有大规模集群架构设计经验优先；
6. 有良好的沟通，团队协作能力，熟悉DevOps流程。

可以看到其中提到了关于私有云，也就是如果是自建DC的话，就需要自建去实现一套私有云服务，如果做不错的话，说不定还可以对外提供这种服务。实现营收。

业务SRE

这一块我目前并没有接触，所以对于这一段理解的并不深。简单来说就是围绕着业务展开，保障业务在运行;

这一层的 SRE 更加贴近于业务，知道业务是怎么运行的，请求是怎么处理的，依赖了哪些组件。如果 X 除了问题，可以有哪些降级策略。参与应用的架构设计，提供技术支持。

主要的工作内容有：

1. 参与系统的设计。比如熔断、降级，扩容等策略。
2. 做压测，了解系统的容量。
3. 做容量规划。
4. 业务侧的 Oncall。

日常工作

之前提到过，我更偏向于Platform SRE，偶尔扮演下业务SRE。我的工作占比大概是60%开发，40%运维，不过也不一定，有时候可能大部分时间是开发或者运维。开发的内容也比较多，涉及到各种语言，主要还是python和golang，偶尔还会写下前端。基本都是内部工具，比如基于开源项目做一些修改，像使用enovy给redis实现proxy，官方虽然有这个方案，但是某些命令不支持，这个时候就需要去实现。或者实现某些operator，以及魔改这些operator。

运维方面主要是帮助开发解决中间件一些问题，简单的有为什么连接不上，可能是他们使用的不对，有时候比较困难的是为什么超时了，这个时候就需要排查各方面问题等等。以及修正监控之类的。

其他人的工作内容

像一些其他同事还需要参与值班和OnCall:

Oncall 简单来说就是要保证线上服务的正常运行。典型的工作流程是：收到告警，检查告警发出的原因，确认线上服务是否有问题，定位到问题，解决问题。

也需要去优化告警，有些时候可能是告警设置的不合理，就需要去调整告警阈值。

都需要做的事情

制定以及交付SLO和SLI

面对不同的场景交付的SLO也是不一样的。像生产集群可能是需要4个9，那SLI也会选的不一样。而开发和测试集群要求不高的话，3个9，关注点也不一样。在选定SLO的时候会考虑以下问题:

1. 如何定义这个可用率？
2. 可用率计算的最小单位是什么？
3. 可用率的周期是怎么计算的？
4. 如何对 SLI 和 SLO 做监控？
5. 如果错误预算即将用完，有什么措施？比如减少发布？如果 SLI 和 SLO 没有达到会怎么样

故障复盘

类似于b站这种对外的报告(https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg) 也有在内部进行的，当然并不是所有的事故都会写复盘报告。一般情况下是生产集群或者发生严重事故(P0或者P1)就需要一个故障复盘来作为教训，避免下次有类似的情况发生。

容量规划

容量规划涉及到成本一块，如何为某个服务提供多少资源是一个问题，假设为某服务提供2Core2GRAM10GDisk，后续如果发生高并发或者突发情况，这个时候资源就不够用，就需要马上扩容。或者说给的资源太多，造成了浪费。所以容量规划是一个非常难做的事情。

用户支持

这里的用户除了买了服务这种，还有下游服务；这一块是技术咨询，以及用户要求的线上问题排查。日常需要写好文档，可能相同的问题会问个10遍20遍，如果有文档的话就可以方便的帮助用户解答。文档也需要经常更新。最好效果是通过文档就可以解决用户的问题。

参考

• https://www.kawabangga.com/posts/4481
• https://tech.meituan.com/2017/08/03/meituanyun-sre.html
• https://cloud.tencent.com/developer/article/1935721