36 | SRE的工作职责

1 SRE简介

SRE是一个最早由 Google 提出的概念。标准化，自动化，可扩展，高可用是主要的工作内容。这个岗位被提出的时候，想解决的问题是打破开发人员想要快速迭代，与运维人员想要保持稳定，拒绝频繁更新之间的矛盾。

2 SRE分类

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

2.1 Infrastructure职责

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

2.2 Platform SRE

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

2.3 业务 SRE

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

总结：对于一个专业的 SRE 来说，上述技能也不应该有明显的界限。

3 SRE日常工作

3.1 部署服务

Day 1：将服务部署上线的那一天。
Day 2+：服务部署之后，还会进行很多更新，升级，配置更改，服务迁移等等。

Day2+ 的操作也不简单，主要要关注稳定性。对于重要的变更操作要设计好变更计划，如何做到灰度测试，如果出了问题应该如何回滚，如何保证回滚可以成功（如何测试回滚）等等。

==部署的操作最好都是可以追踪的，因为并不是所有会引起问题的操作都会立即引起问题。==比如一个操作当时做完没有什么问题，但是过了一段时间，偶然的重启或者内存达到了某一个指标触发了问题。如果能记录操作的话，我们可以回溯之前做过的变更，方便定位问题。

3.2 Oncall

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

原则：

1. 定位问题没有一概而论的方法了，需要根据看到的实时，结合自己的经验，然后做推测，然后使用工具验证自己的推测，然后确定问题的根因。
2. 解决问题是可以有方法论的，叫做 SOP，标准操作流程 。即：如果出现了这种现象，那么执行那种操作，就可以恢复业务。SOP文档应该提前制定，并且验证其有效性。
3. 正确的做法是先根据现象看现有的 SOP 能否恢复业务。比如说当前错误只发生在某一个节点上，那么就直接下线这个节点，具体的原因后面再排查。恢复当前的故障永远是第一要务。

3.3 制定和交付 SLI/SLO

3.4 故障复盘

故障复盘需要有文档记录，包括故障发生的过程，时间线的记录，操作的记录，故障恢复的方法，故障根因的分析，为什么故障会发生的分析。文档应该隐去所有当事人的姓名对公司的所有人公开。

故障在复盘的时候应该将当事人的名字用代码替代，可以营造更好的讨论氛围。

不应该要求所有的故障复盘都产生 Action。之前一家的公司的故障复盘上，因为必须给领导一个“交待”，所以每次都会产生一些措施来预防相同的故障再次发生，比如增加审批流程之类的，最后所有人都会忘记这里为什么会有一个审批，但是又没有人敢删掉。你删掉，出了事情你负责。

对策：
1.提高操作人的责任心，操作之前多确认。上线评估好，影响的范围，做好回滚的计划。

3.5 容量规划

容量的规划需要根据监控、资源连接数、CPU负载、网络流量、磁盘IO、磁盘容量、内存等。能大致预测到业务的增张的速度，提早做好规划，容量要做到X5。

对策：
1.多做压测，评估资源配置的支持情况，如CPU4核8g，能支持多大的并发量
2.通过混沌工程，提前暴露出系统的短板，提前做好预案

3.6 用户支持

用户支持也是日常的一部分。包括技术咨询，以及用户要求的线上问题排查。

对策：
1.整理成文档，如团队内，软件部署操作手册、运维上线操作手册、运维问题排查手册及发布日志等
2.用户帮助文档，如系统操作手册等
3.好文档少用专业术语；操作步骤要清晰，命令要完全；实际有变化，文档要及时更新

4 关于SRE其他思考

4.1 学习

学习主要是靠自己的，和别人没有太大的关系。重要的是不断学习，使用正确的做事方式，向优秀的项目和优秀的开发者学习。模仿不是学习。孟母三迁，人与类居，物以群分，就是这个道理。

4.2 脏活累活

用最快的速度解决掉，多做有生产力的事情。能自动化的地方，就通过脚本实现。

4.3 背锅

互相甩锅的工作环境无疑是非常糟糕的工作环境。碰到这种情况，直接换个工作环境，就可以。工作首先是开心，其次是其他的。为了那点，小钱不至于。

对策：
1.平时不断提升自己。充实自己；
2.做IT技术，平均一年或者两年左右换一次工作；这样有利于技术的提升，还能接触到不同的业务及技术。

4.4 转行

对策：
1.艺多不压身，平时多积累；
2.找到自己的人生赛道，发挥自己的特长；
3.方向要正确，公司可以更换，除非自己身居关键位置，或者薪资待遇很OK，或者沉淀几年，有助于自己的成长，否则，其他是是妄想。

4.5 面试

https://github.com/bregman-arie/devops-exercises

4.6 排查错误

对策：
1.平时多积累
2.多尝试，多试错，多操作，多总结
3.积极主动多做自己没有做过的事，积累经验
4.多动手操作
5.要善于追根究底

4.7 代码

对策：
1.先学会一门代码，做好项目后；然后在往其他语言拓展

4.8 大公司和小公司

小公司一般都有一个救火英雄式的人物，在公司的时间比较长，知道所有组件的部署结构，什么都懂。跟着这种人学习会成长很快。
大公司细分领域很多。本文前面列出的内容可能每一项在大公司中都是一个团队，对某个领域可以深入研究。

对策：
1.根据自己情况，小公司成长比较快，接触的东西多；
2.大公司比较单一，但是大公司的企业文化、工作方式等，都可以学习，假如后续想开创自己的事业，可以多留意下。

4.9 公司发展

打铁还需自身硬，不断提升自己，只要自己能力强，到哪都可以。

1.公司的行业很好，有前景，如人工智能、物联网等
2.福利待遇很好，如五险一金都是全额上，薪资待遇高，准时发放薪资等
3.工作环境很好，如办公环境高档写字楼，场所宽敞明亮、同事很nice,互帮互助等
4.企业文化好，如员工有种到家的感觉等
5.学习文化，如不定期的举办相应的学习讲座，给员工创造不同的学习机会等等