×

微信扫一扫,快捷登录!

SRE report 核心要点1

标签: 暂无标签

P4

介绍

从问题开始,“当您向软件工程师要求设计运营团队时会发生什么?”结果为:“ SRE团队负责其服务的可用性,延迟,性能或绩效,效率,变更管理,监控,紧急响应和容量规划。”如果SRE是较大DevOps原则的较窄实现,则主要区别是SRE的核心重点是可靠性。


利用上面的问题和答案,今年的SRE 2020报告突出显示了目的,无论相关从业者如何称号,它们都可能是相关实践者所共有的:设计可观察的系统以防止服务中断而不是对其做出反应。它从一个明确确定的收敛点开始,然后向后工作,因此,无论大小组织,都可以根据此2020基线进行评估。


如果通用的目的是要解决复杂的问题,那么旅程如何?在微服务世界中,在边缘计算的推动下,旅程比以前包含更多的组件,并且现在需要从家庭现实中重新评估这些组件。这包括可能被忽略或不存在的表面区域。考虑诸如士气,员工体验和人类健康之类的事物,并与传统的资产类(例如组织结构,工具堆栈以及硬件和软件)一起使用。


------------

从问题开始,“当你要求软件工程师设计一个Ops团队时会发生什么?”答案是“SRE团队负责其服务的可用性、时延、性能、效率、变更管理、监控、应急响应和容量规划。”如果SRE是广义DevOps原则下的一种狭义实现,那么SRE的核心重点是视可靠性。


利用上面的问题和答案,今年的SRE2020报告强调了一个可能在从业者中普遍存在的目标(请忽视他们的头衔):设计可观测系统以防止服务中断,而非仅对其作出响应。它从一个明确的汇聚点开始,然后向后回溯,这样无论什么规模的组织都可以根据2020的基线进行评估。

如果解决复杂的问题是共同的目标,那么这段旅程会怎样?在一个由边缘计算推动的微服务世界中,这段旅程比以往涉及到更多的组件,这些组件现在需从员工居家工作的现实中重新评估。

这包括可能被忽略或不存在的方面,将士气、员工体验和人类健康等因素与组织架构、工具集和硬软件等传统资产类别结合起来考虑。


P5

重点小菜1

存在可观测性组件;

可观察性不


确定您提供的服务在哪里收敛到典型的[数字化]体验消费点;从那里向后工作。确保不仅为您的代码包括考量,而且还为网络,第三方和所有交付链组件包括考量,以评估通过体验镜头应用三个可观察性支柱的效果如何。问:“体验的体验是因为代码,互联网和网络,第三方或其他交付链组件而导致的吗?”。


----------

确定您提供的服务在哪里汇聚成典型的“数字化”消费体验点,并从那里回溯。确保您不仅考虑您的代码,还考虑了网络、第三方和所有交付链组件,以评估通过体验镜头应用三个可观察性支柱的效果如何。探究一个问题:“客户的体验是取决于代码、互联网和网络、第三方还是其他交付链组件?”






上一篇:SRE知识体系全图
下一篇:SRE report 主要观点 2
admin

写了 864 篇文章,拥有财富 29588,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部