为了让团队同学对SRE有个统一的认识，有一些共同的套路和章法，尽量避免在工作中产生价值观和工作思路的矛盾，我一般会让新入职的同学读一下《入职必读》的几篇博客，1是提前对我们有个了解，2是告诉他们我们这的SRE要做什么和怎么做，3是便于入职后快速融入工作、团队，减少矛盾提高协作效率，最近来了一位实习生小朋友（电子科大 龚金报）读完后做了个笔记，看后觉得尤其不错，点赞之余分享一下。
一 思路层面《博文链接》
分为六个方面：知其用、摸家底、看调用、抓警告、管变更、做导航
1.1 知其用：搞清楚产品的功能用途、目标用户和在生态中的定位。
1.2 摸家底：
- 1.2.1 了解各个模块的逻辑和模块间的骨干逻辑脉络，抓重点，细节可先忽略，形成“骨干模块逻辑鸟瞰图”，
- 1.2.2 然后分模块摸清资源情况，形成鸟瞰表，
- 1.2.3 过程中遵循白名单原则，标注健康资源，剩下零碎的记在账本上。
1.3 看调用：目的是深入理解分析产品，要有主题懂得取舍，从用户的角度出发理清业务模块逻辑间流转和基础系统层面流转，同时还要弄清每个模块提供服务的方式、每个点的调用方法、记录每个模块依赖的外部产品资源。
1.4 抓告警：告警本身是对监控的一个收敛，交接时要先把业务的生死告警理清楚。
1.5 管变更：做变更监控，变更管理，尽量用技术解决问题，而不是制度，制度多是为技术争取时间。
1.6 做导航：美观实用，方便查找和监控
二 实操层面《博文链接》
2.1 故障前：预防，减少故障的发生
- 2.1.1 变更：管理变更，做好单元测试、集成测试、线上灰度再全量上线
- 2.1.2 容量：容量管理先保证有，再改进，指标用QPS（每秒请求数）、在线用户数、长链接数量，不要用机器指标。
- 2.1.3 灾备：保障在故障出现时，快速进行业务切换，保障用户的可用性；一般能热备不冷备；热备例子：负载均衡自动调度、域名解析切换链路。
- 2.1.4 巡检：每天/遇到故障，检查各个核心指标
- 2.1.5 熔断：对各模块设置容量上限，放弃多出来的请求，保证大部分用户可以使用。
2.2 故障中： 快速处理问题，止损
- 2.2.1 告警：信息准、数量少、实效性高速度快
- 2.2.2 定位：依赖于对业务构架的了解，根据核心指标screen找到故障模块和范围，根据预案把业务切掉再去排查原因。
- 2.2.3 预案：平时做好各种故障发生的预案，可以在故障发生后尽快止损减少影响。故障预案六把刀
- 2.2.4 自愈：把经验和操作用代码实现，固化到系统上，实现自动操作。
2.3 故障后： 消灭同类故障
- 2.3.1 故障管理：故障复盘，查找故障原因+后续改进措施
三 DevOps运维服务体系《博文链接》
3.1 前记：从原始运维手动操作、制度为王发展到现在DevOps运维人工自动化、技术为王，再到以后的AiOps机器自动化
3.2 定业务规范
通过DevOps要批量管理资源、服务、规范三类，资源包括像服务器、网络设备、负载均衡、证书、域名、代码、容器等，服务包括像围绕运维提供的服务监控告警、CI/CD、日志分析、服务预案、配置管理等，规范包括像流程、资源、服务的各种标准化等。规范与资源和服务都相联系，是管理资源和服务的标准。
3.3 建工作制度
好的制度是应该能够系统化、工具化、可执行、可量化的，制度不是解决一个实力，而是解决一类问题，要尽可能落到技术上。
3.4 搭DevOps系统
最理想的目标是“一站式运维”，整个工具体系分为两层，
- 1) 一层是底层的轮子层，面向的是单个主题的解决，讲究深度和系统的解决一类问题，
- 2) 上层是面向SRE的应用层，也可以说是业务层，业务层通过底层轮子封装后管理了资源、规范制度、运维服务（运维提供的服务）这三类内容，所有的轮子通过一套账号和权限体系打通。
四 故障预案六把刀《博文链接》
4.1 重启：大法，本质是初始化。
4.2 回滚：回到上个稳定健康的版本。
4.3 扩容：短暂提高系统资源池，但不能说常态，业务恢复后需再做分析。
4.4 切流：常见机房和运营商的切换，最大的挑战是容量，需理性决策，防止雪崩。
4.5 降级：可以暂时下线非核心功能，模块设计时要做到解耦充分。
4.6 限速：让流量缓慢进入系统才能接住，并维持高并发的QPS
五 微服务架构下业务单机QPS瓶颈分析《博文链接》
一般瓶颈问题从下面三个维度来分析
5.1 机器本身：cpu、内存、IO、网络
5.2 程序代码：分析程序本身的问题，跑多实例，做埋点日志
5.3 逻辑架构：从一次完整请求的角度，从头到尾理一遍外部依赖的上下游资源和调用关系，找到性能差的模块/接口。
六 运维中数据的认识和应用《博文链接》
信息归纳形成知识，处理方式归纳形成经验，经验抽象形成方法论/规律。
数据应用中最重要的三个环节：采数据、管数据、用数据。