作为个搞运维的，我竟一点都不了解 SRE ……（sre是运维吗）

关于SRE和运维体系的文章很多，但大多数学院风浓厚，本文试着从一个出身运维一线SRE管理者的角度进行总结阐述，给你一份可实操接地气的运维体系，所有感悟来自小米和新浪的多年运维实战，希望对你有所启发。

在面向大型、复杂互联网系统的治理时，尤其离不开SRE，当体量上来后，系统的用户量、模块、调用链、指标、主机、域名、4/7层、日志等等都会到一个巨大的级别，甚至还要继续增长，如何保证运维架构的合理、资源和服务管理的有序，如何经营好这些资源，用最低的成本保障好系统的质量、做好Ops，这是一个巨大的挑战，理论上开发只要管好代码，其他之外的事情都应该要SRE承担起来的。

很多人对SRE的理解是不全面的，停留在对原始运维的认识上，认为运维只是打杂的，是开发的跟班，外加背锅侠，但随着全球大型互联网系统的出现，系统的用户量、资源、技术栈都在成指数级别的增加，带来的是系统运行环境和系统本身复杂程度的骤增，量变产生质变，以用户稳定性为目标，业务对资源的规划管理周转效率、持续集成上线效率、质量管理效率等提出了全新的要求，这也就倒逼了运维在业务、人员素质、技术上的革新，产生了SRE工程师。

可以试着想想，同样是管理服务器，管理1台和管理1万台分布在全球的混合云能是一个样子么？分析1秒/M和1秒/T的实时数据，同样是分析，能是一个样子么？所以说，体量和复杂度上不来，是体现不出技术价值的，因为根本遇到不到瓶颈，同样，SRE就是过来用技术、运营手段，从稳定性视角给大型互联网在线系统做熵减的。

SRE在国内现在也叫应用运维，是面向用户稳定性的，也就是说对用户的服务质量负责，这也给了SRE更高的要求，要有全局视角，要对系统的全生命周期进行管理，把质量和成本工作做到前面，需要一系列的流程.制度.规范和一系列的工具提高管理、质量、自动化效率。今天来理一下SRE的工作体系，希望你对SRE有一个全面的认识。

我把大型互联网系统的全生命周期拆解成了5个阶段，分别是代码编写、资源规划、系统上线、运行保障、系统下线，每个阶段SRE要做的事情做了灰色框框的标注，其中有些SRE和开发的边界是存在灰色地带的，怎么分工视具体情况来定，但至少SRE都要参与，最下面支撑层是运维的制度、流程、规范，然后是DevOps运维自动化工具。下面我们来拆开揉碎了说一下。

一、代码编写阶段

代码编写阶段，SRE的主要工作是搭建和维护代码管理系统，为CI/CD做好准备，目前最常用的就是GitLab了。

二、资源规划阶段

1、方案评估

根据需求规划系统的基础资源，包括机型（或容器规格）、机房、资源数量、存储、4/7层接入方案、域名证书以及是否用CDN等。

2、资源申请

将评估后的资源各自走审批流程。

3、资源管理

对业务使用的海量主机、容器、域名、证书、LB、CDN、存储、网络、专线等资源进行管理，体量上来后一定要建设CMDB用系统管，各类信息做到可快速检索，一般大厂存储、CDN、网络、专线都有专门团队负责，SRE只要管好自己业务的使用即可，强调一点，资源一定要制定一套科学的命名规则。

4、权限管理

大型系统人多、环境复杂，SRE需要对权限做详细的规划，制定SRE、开发序列对应每种资源新手和老工程师的权限规则，理想情况开发只要管好代码即可，任何prod环境操作都只能由SRE处理，开发是不允许有root权限的，开发和测试环境视情况处理，所有操作做好审计方案。

5、资源操作

因为面向的是大型互联网系统，要保障对海量资源进行高效批量的操作，就需要借助一些技术工具了，比如主机操作类似ansilbe、saltstack，为了安全管理也要结合安全跳板机的使用，容器、LB、证书签发等也都有对应的技术方案，这些是需要SRE来Ops的。

三、系统上线阶段

1、环境规划

一个成体系的系统一般会有4套环境：开发环境（dev）、测试环境（stag）、预发布环境（prew）、生产环境（prod），环境之间相互独立，视情况做网络隔离，我在新浪碰到了几次开发同学把测试环境的数据发布到了生产环境，造成很差的用户体验，所以规划的时候，低安全等级的网络到高安全等级加墙还是有必要的，SRE提前把环境规划好、上线流程制定好，会减少很多变更类故障。

2、环境搭建

主机环境配置，看似有了公有云、容器后，只要把镜像做好，这块工作要简单很多，但其实也不然，首先相对云主机而言，物理机的性能高成本低，量能跑起来的前提下用物理机最划算，所以公有云一般作为弹性资源；二是经过论证，不是所有的服务都适合上容器，所以现实情况还是会有大量的物理机运维，各种装包、配置、内核和系统调优、维修、过保机器替换等，反而是在原来的基础之上增加了打容器镜像的工作，这就是实际情况，环境搭建、系统调优、软件包升级的工作量还是很大，而且这块工作经常会出现各种奇葩的事情，特别是搭建GPU机器学习的环境，不是这个库不对那个依赖版本不对的，一搞就是半天，不过从趋势上看这块工作我觉得会越来越标准化。

接入层配置，包含从域名、证书、解析、负载均衡4/7层、后端这一套配置流程，其中4/7层选择、调度策略、连接数是否够用等等都是需要根据具体业务情况制定技术方案。

3、CI/CD

协同开发制定CI/CD的技术方案，为Dev提供部署系统（大厂有专门团队研发），制定上线审批流程，按理生产环境的上线应由SRE操作，但因为开发和SRE的数量差距大，成长期的系统迭代又快，由谁上线就视情况处理了，我们这处理方式是牵涉到代码变更的上线由开发操作，其余的迁移扩缩容等由SRE处理。

四、运行保障阶段

SRE是质量担当，面向的就是用户稳定性，所以系统运行保障是SRE工作最重的阶段，也是占用精力、工作量最大的部分，在大型互联网系统的背景下，每一块要做深、做透都是一个很大的主题，针对此阶段可以看一下博文《大型系统的运维要从哪些方面抓起——全面质量管理》，质量越好，意味着故障越少，下面就从故障全生命周期的角度对这块的工作做个梳理。

1、故障前——目标：减少问题流入“故障中”

1）变更管控

故障不是无缘无故的就生发了，很多发生在于变化，变化当中很大的一个又是迭代上线，从每年故障的历史数据看，有很大一部分故障都是由于上线变更造成的，所以SRE要严格管控变更，制定各种情况下的流程制度规范，做好质量的运营工作。

2）容量管理

服务的扩缩容会一直持续到产品下线，容量的管理关乎到质量和成本，很多时候对于容量是模糊和缺失的，具体表现就是发生了容量故障、看到了cpu和内存报警了才想到扩容，公司要优化成本抓机器使用达标率才知道缩容，基本是被动的，而且没有量化数据，SRE需要主动的将容量管理起来，容器场景下可能要高效很多，但依旧是需要持续管理、动态规划的。

3）灾备建设

灾备意味着做多保险，合理的灾备可以保障在故障出现时，快速进行业务切换，保障用户的可用性，所以SRE一定要协同开发对业务做好灾备建设。一般而言灾备分为热备和冷备，冷备是指准备好资源平时空放，只有故障时才用一下，造成很大的资源浪费，所以一般能做热备的就不做冷备。从内容上讲，SRE要做的灾备分为接入层灾备、机房灾备、主机灾备、数据灾备，另外灾备和成本是一对矛盾平衡。

4）业务巡检

巡检是SRE一定要重点投入的工作，它的意义在于发现潜在的问题，将尚未形成故障的问题提前暴露，提前解决。巡检分为对机器和业务指标的巡检，机器指标类似CPU、内存、IO、网络等，业务指标类似ERROR、QPS、时延等等，在做决策时机器和业务指标要结合使用，因为SRE和开发的视角不同，可以各自都做，即使有部分重合，那也没关系，另外巡检一定要根据业务流做到全链路、全模块。

5）活动重保

重大活动的重点保障是SRE没有任何疑义要承担起来的工作，要拉通各个部门，制定详细的重保方案，每次重保要当成一个独立的项目来做，有开始有结束做到闭环。

6）故障演练

SRE要牵头主导业务上的故障演练，周期性的针对各种场景做一下预演，一来检验下系统的真实容灾情况，二来要锻炼一下SRE的预案执行能力，如果有问题就倒逼各方改造，切忌不要找存在感，把演练变成真的故障，要提前制定好技术方案，找用户量少的时间段操作。

7）日志管理

大型系统下的日志是海量的，要在日志标准化的同时，特别注重技术方案，对日志进行科学合理的采集、管理、使用，在分工上，像系统、Nginx类的日志肯定是要SRE处理的，至于代码的埋点日志等看具体情况怎么分工合作，像小米有数据工厂的团队，SRE只要关注怎么使用就可以，不用自己维护、搭建、研发大数据相关的东西。

8）技术调优

SRE是需要参与和主导各种技术调优工作的，要时刻为了自己所管业务的优秀用户体验而努力，我把调优分为系统和架构调优两块，系统调优包括像各种内核参数、各种系统应用的参数优化等等，架构调优更偏业务，像为了保障小爱南方用户的体验，SRE主导了小爱南方用户架构调优，牵头对小爱后端架构进行梳理、分级、结构化，抽象出了语音接入层概念，并与开发同学达成共识，对架构进行了优化改造。

9）服务管治

我认为，服务是大型互联网场景下SRE的重要管理单元，特别是大型系统在微服务的设计理念下，服务众多、开发人员庞大加之人员变动快，如何从运维的准入开始将庞大的服务档案信息管理好，是非常重要而且需要下大功夫的，档案信息包含了该服务的功能简介、负责人、域名、部署情况、机房分布、主机信息、核心监控指标、服务分级等等，对于需要交给SRE运维的服务，由开发人员提出运维准入申请，定义好服务级别（不同的级别代表了不同的SRE参与程度和系统的重要程度），审批通过后按照约定好的SLA进行运维，而SRE需要从服务的维度，将服务相关的信息串联管理了起来，以便遇到问题可以快速的查看使用。

10）Oncall管理

Oncall对于SRE应该都不陌生，SRE这个工作是下班不下岗的，需要对稳定性做到7*24小时的负责，想要睡个好觉，就得把服务稳定性做上去，否则半夜或者休息日处理问题，不能怨别人，Oncall分为告警值班和日常工单两部分，告警值班要遵循“接告警、助排查、勤通告、做闭环”的原则，日常工单包含了开发和其他各种部门的咨询、业务需求，不限于漏洞修复、主机迁移、服务升级、网络割接、等保评审等等。

2、故障中——目标：快速发现故障，止损

1）监控告警

监控告警是SRE的基础工作，既要提供技术方案又要做好监控告警的配置管理。告警作为故障的第一事件，一定要围绕3个点准、少、快，准是告警的信息准，少是告警的数量少都是收敛后的有效告警，快指的是告警的实效性高速度快；告警要根据事件的影响程度分级，告警短信和邮件里尽可能携带更多的判断信息，做的好的甚至可以做一下故障参考预判。大型互联网系统一定要注重「生死告警」的使用。

2）故障定位

SRE需要寻找各种办法缩短故障定位（SRE做的是宏观定位，能为预案提供决策即可）时间，只有故障快速定位到了，才能为下一步预案执行提供依据，减小故障影响时间。在大型互联网系统下故障定位是最难做的，因为系统模块多、模块间的关系依赖复杂，故障瞬间大量告警蜂拥而至，要通过现场分析告警、监控图定位到哪个模块、哪个机房出问题耗费时间太长了，在这一阶段我们总结的最佳实践是建设链路架构监控，链路是表达服务、关系、核心指标最好的技术方案。

3）预案执行

故障期间，所有前面的工作都是为了这最后一步做准备——预案执行，预案执行才是真正止损恢复业务的，SRE作为Ops是预案的主要执行方，所以一是要将各种场景下的预案尽可能准备好，二是要尽可能依靠工具提高预案的执行效率。

3、故障后——目标：消灭同类故障

1）故障复盘

故障管理是整个故障的善后工作，追责任的部分除外，那他的意义就是防止同类故障再次发生。故障复盘一般会以复盘会的方式约所有相关方进行全过程回顾，最后形成的文档叫“故障报告”，故障复盘会也是最考验SRE软能力的一个场景，特别是SRE牵头主导组织的，一定要引导大家解决问题，不要变成一场甩锅大会，分析好故障原因，制定好后续的改进措施。

五、系统下线阶段

系统下线阶段的主要工作就是资源释放，不仅仅要释放服务器，关联的域名、LB、ACL等等资源要全部释放，干干静静的来、干干静静的去。

以上基本就是SRE在产品全生命周期里的工作内容了，期间每个点都可以结合自动化运维的新技术去做创新、提效，在整个产品周期里，SRE需要有质量、成本、运营意识，要有自动化、服务思维，真正把运维的产品作为自己owner的产品去做，写到这里，希望对你有所帮助。

作者丨矢量比特

来源丨公众号：运维网咖社（ID：ShiLiangBit）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

更多内容

四期精选“运维”主题直播回看：

围绕故障管理，谈SRE体系建设：http://z-mz.cn/1Gt4k

民生银行数据库智能运维实战：http://z-mz.cn/kPx8

逆袭生产力担当，云原生时代的运维新归宿：http://z-mz.cn/3cxel

金融业运维转型变革与新型技术落地探究：http://z-mz.cn/4THMq

关注公众号dbaplus社群回复【220316】，可获取配套PPT哦~