版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。
版权
SRE是什么?
SRE(Site Reliability Engineering),站点可靠性工程,起源于2003年。在系统管理员模式下,通常是通过人工操作完成任务,而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。
DevOps是在2008年年末流行起来,强调自动化替代人工操作,以及利用软件工程手段执行运维任务。DevOps的核心是"全栈交付", SRE的出发点是“保障和提升系统稳定性”,两者要做的事情其实本质上差别不大,但是角度不同。可以认为DevOps是SRE核心理念的普适版本,SRE是DevOps模型在Google的具体实践。

Google SRE方法论

确保长期关注研发工作
Google将SRE团队的运维工作限制在50%以内,剩余时间花在研发项目上。实践中,SRE管理人员要经常度量团队成员的时间分配,有必要的话,可采取措施将过多的运维压力转移给研发团队。
在保障服务SLO的前提下最大化迭代速度
对于迭代创新速度与产品稳定程度之间的矛盾,可以使用“错误预算”工具处理。”错误预算”起源于这样的理念:任何产品不能,也不应该做到100%可靠。对用户来说,99.999%和100%的可用性是没有实质区别。其中,错误预算 = 1 - 可靠性目标。可以将错误预算用于新功能上线或者产品创新,如:最大化新功能的上线速度,同时保证服务质量。
监控系统
监控系统不应该依赖人来分析警报信息,而是由系统自动分析,仅当需要用户执行某种操作时,才需要通知用户。
应急事件处理
可靠性是MTTF(平均失败时间)和MTTR(平均恢复时间)的函数,通过事先预案并将最佳方法记录在“运维手册”上通常可以使MTTR降低3倍以上。
资源部署
新资源的部署与配置是相对比较危险的操作,必须要小心谨慎地执行。
效率与性能
任何盈利性服务都关心高效利用各种资源,SRE最终负责容量的部署和配置,因此SRE必须承担起任何有关利用率的讨论和改进。
SLA、SLO、SLI
SLI, Service level Indicate, 服务质量指标
该服务的某项服务质量的一个具体化指标,请求延迟为大部分服务的一个关键SLI,除此之外有错误率,吞吐率,可用性等。这些指标的计算过程:在某一个度量时间范围内将原始数据收集起来,计算速率,平均值、百分比等汇总数据。通常用9的数量来描述可用程度,99%可用性被称为9个9,99.999%被称为5个9.
SLO, Service Level Object, 服务质量目标
服务的某个SLI的目标值,SLO的定义是 SLI