作为个搞运维的,我竟一点都不了解 SRE ……(sre是运维吗)

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

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

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

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

SRE在国内现在也叫应用运维,是面向用户稳定性的,也就是说对用户的服务质量负责,这也给了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工作最重的阶段,也是占用精力、工作量最大的部分,在大型互联网系统的背景下,每一块要做深、做透都是一个很大的主题,针对此阶段可以看一下博文《大型系统的运维要从哪些方面抓起——全面质量管理》,质量越好,意味着故障越少,下面就从故障全生命周期的角度对这块的工作做个梳理。

作为个搞运维的,我竟一点都不了解 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的产品去做,写到这里,希望对你有所帮助。

作为个搞运维的,我竟一点都不了解 SRE ……(sre是运维吗)

作者丨矢量比特

来源丨公众号:运维网咖社(ID:ShiLiangBit)

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

更多内容

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

作为个搞运维的,我竟一点都不了解 SRE ……(sre是运维吗)

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

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

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

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

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年5月22日 上午9:26
下一篇 2022年5月22日 上午9:28

相关推荐