-
SRE究竟是如何在Google起源的?
SRE就是让软件工程师来设计一个新型运维团队的结果
-
SRE团队成员具有如下特点:
(a)对重复性、手工性的操作有天然的排斥感。
(b)有足够的技术能力快速开发出软件系统以替代手工操作。
-
Google的经验法则
SRE团队必须将50%的精力花在真实的开发工作上
-
DevOps
核心思想是尽早将IT相关技术与产品设计和开发过程结合起来,着重强调自动化而不是人工操作,以及利用软件工程手段执行运维任务等
-
SRE团队要承担以下几类职责:
可用性改进,延迟优化,性能优化,效率优化,变更管理,监控,紧急事务处理以及容量规划与管理
-
Google SRE的几个核心方法论
(a)确保长期关注研发工作
(b)在保障服务SLO的前提下最大化迭代速度
(c)监控系统
(d)应急事件处理
(e)变更管理
(f)需求预测和容量规划
(g)资源部署
(h)效率与性能
-
事故事后总结应该包括以下内容:
(a)事故发生、发现、解决的全过程,
(b)事故的根本原因,
(c)预防或者优化的解决方案。
-
如果100% 不是一个正确的可靠性目标,那么多少才是呢?这其实并不是一个技术问题,而是一个产品问题。要回答这个问题,必须考虑以下几个方面:
(a)基于用户的使用习惯,服务可靠性要达到什么程度用户才会满意?
(b)如果这项服务的可靠程度不够,用户是否有其他的替代选择?
(c)服务的可靠程度是否会影响用户对这项服务的使用模式?
-
监控系统应该只有三类输出
(a)紧急警报(alert)
(b)工单(ticket
读书笔记(SRE:Google运维解密):第1章 概览
最新推荐文章于 2024-08-19 11:08:23 发布
本文介绍了SRE在Google的起源,SRE团队的特点,以及他们的主要职责,如可用性改进、监控、应急事件处理和容量规划。核心方法论包括关注研发、保障服务SLO、自动化运维任务等。事故事后总结注重根本原因分析和改进方案。可靠性不追求100%,而是根据用户需求和替代选择来平衡。监控系统应有紧急警报、工单和日志输出。变更管理推荐自动化,评估恢复效率的指标是MTTR。资源使用由用户需求、可用容量和软件效率驱动。

最低0.47元/天 解锁文章
417

被折叠的 条评论
为什么被折叠?



