SRE团队的职责是将软件开发和运维工作相结合,通过自动化和可扩展性来解决复杂的系统问题。以下是SRE概念的一些关键要点: 1 •SRE的核心目标是确保在线服务的可靠性,即服务的可用性、性能和可维护性。 •可靠性目标通常以服务等级目标(Service Level Objectives,SLOs)和服务等级指标(Service Level Indicators,SLIs)...
因为虽然是一个团队,但是不同的小组或个人的知识仍然是无法完全共享的,这使得在做工程决策、实践的时候,没法做到像 Google SRE 那样如臂指使。 稍微改进一下的做法是:团队里仍然要招聘一两个 SRE 专家,姑且称为 SRE COE,既懂开发又懂运维的那种,统筹所有工作,然后那些单方面的技能人才,辅助 SRE COE 来完成工作...
其中Infrastructure SRE主要负责最基础的硬件设施、网络,比较底层,一般都是很商业化的东西,动态性不强;Platform SRE提供中间件技术;Business SRE维护服务、应用、业务的正常运行,而这一类SRE是最偏向于我们说的传统业务开发的。
[1] 不幸之轮 ("Wheel of Misfortune")https://sre.google/sre-book/accelerating-sre-on-call/[2] 服务最佳实践指南 ("Service Best Practices guides")https://sre.google/sre-book/service-best-practices/[3] 金丝雀所有变更 (canaried those global changes)https://sre.google/workbook/canarying-relea...
SRE是天生怀疑论者,怀疑一切,眼见为实,追本溯源是本性,感觉自己的性格还蛮适合的~ 09. 拥抱风险 传统运维是厌恶风险的,但是开发和产品却更关注变化速度,他们都希望迭代速度越快越好,但是这会给系统运行带来风险,所以这天生是矛盾。 为了解决风险和变化的矛盾,google提出了SLI-->SLO-->SLA的机制。
Google SRE理论:如何提高软件系统的可靠性和效率 你是否遇到过这样的问题:你负责的软件系统经常出现故障,导致用户不满和损失;你在的项目组开发和运维团队之间存在沟通和协作的障碍,导致变更和部署的效率低下;运维人员过于繁忙,无法从事创新和改进的工作,导致技术债务的积累。
SRE(Site Reliability Engineering)是最早由Google提出,又经由Google发展完善的一个崭新运维理念。如今SRE已成为一个涵盖运维理念、思路、组织架构和具体实践的完整体系。数人云推出SRE系列教程,由SRE经验丰富的技术大牛们为大家分享运维一线的独家干货,揭示SRE背后的秘密。
上周,网上流传一份谷歌工程师的离职报告。 贾斯蒂娜(Justyna)是谷歌爱尔兰分公司的 SRE 工程师。 她在工作九年后,提出离职,并且写了一份公开的离职报告。 这份报告用工作汇报的格式总结了自己从大学就毕业入职Google到现在做到L6级别(年薪60万美元+)的9年心路历程。
首先,在文化层面,Google SRE 倡导以人为本,关注人的发展,着眼长期结果。在国内加班文化盛行,996甚嚣尘上。具体到 IT 运维领域,表现为: 技术人员工作和生活很难平衡,上班与下班没有明确界限,最终变成了只有值班,没有轮换,7x24小时响应。 工作规划以短期目标驱动,缺乏长期主义,导致技术人员每天忙于“战术性”的工作...
史军艇“不要把SRE当成是0-1的事物”SRE最早是Google在2003年定义的一个岗位，最初它出现的主要目的是：解决“研发”和“运维”之间的矛盾，逐步演变为一种工程思维。后面有了Devops概念，SRE的使命就更加明确，除了研发外，需要一个新型的Ops团队，既保证配合研发高效迭代创造前端价值，又保证业务系统稳定运行创造...