SRE体系01----综述

SRE的定义

SRE的全称是Site Reliability Engineer,即网站可靠性工程师,概念起源于Google公司。简单的说就是对负责确保企业的计算机软硬件系统可靠稳定运行,使其能持续对外提供服务的工程师的称呼

SRE的工作

核心工作:解决效率与稳定性之间的矛盾
SRE体系01----综述_第1张图片
一般国内的公司都有开发组(dev)和运维组(ops),小型公司可能没有运维组,由开发兼任。以前的系统普遍规模不是很大,系统架构简单,并发不高,所以开发和运维之间的矛盾并不明显。但随着技术发展和业务需求增多及规模变化,企业的计算机系统发生了以下的转变:

  • 从过去的烟囱式架构向分布式架构转变
  • 从单体应用向微服务转变
  • 从单一实体数据中心向混合云模式转变
  • 从瀑布式开发向敏捷式开发转变,伴随的是release频率高速上升

以上的这些变化均是为了满足日益增长的用户规模和快速变化的用户需求,但是也带来了新的问题:

  • 效率:开发人员看重的是效率。我的代码提交后要尽快测试,尽快上线,能够随时修改和发布新功能,确保我能按时完成用户需求
  • 稳定: 运维人员看重的是稳定性,任何一个业务系统,如果不能稳定的对外提供服务,那么它将毫无商业价值

企业通常对两个团队的考核指标是不同的,这就造成了两者之间的矛盾。对开发往往考核的是需求量、代码量、Bug量等指标,而对运维的考核是有没有达成设定的SLO,通常用服务的可用时间来表示:

可用率 系统每年允许的故障时间
99% 3.65天
99.9% 8.76小时
99.99% 52.6分钟
99.999% 5.26分钟

对运维工程师来说,稳定高于一切,只有稳定的系统才能产生商业价值。一个系统如果在生产环境中正常运行了,就不应当做任何变动。80%以上的生产事故都是由变更引起的,包括但不限于修改业务配置,上线发布新版本等行为。

因此运维部门通常都会设置一些规范来防范不必要的事故和风险。但在工作中这些规范起到的效果微乎其微。开发人员通常都是被催着上需求,对于他们而言,尽快的上线交付才是目标,并不关心是否会影响业务系统稳定性,风险意识薄弱,企业的运维规范会增加在他们看来不必要的审核拖慢交付速度,基本都是敷衍了事。双方的职责和关注点不一样,矛盾也不可避免。

SRE正是为了解决这类矛盾而诞生的,它的工作内容便是在确保符合公司实际需求的稳定性前提下,不断的提升开发人员效率,设计管理系统来维护企业的业务系统稳定运行以替代传统的人工操作

你可能感兴趣的:(运维微服务容器)