【编者的话】本文是作者多年SRE实践的经验总结,阐明了为什么要选择SRE及SRE的目标,并从六个角度指明如何实践SRE:合作和沟通、人员团队结构、工具和平台、版本工程学、监控、事后回顾。
本文是我对SRE实践的介绍,这些实践来自于我组建过的不同SRE团队,这些团队负责管理SAAS平台快速添加特性。
为什么选择Site Reliability Engineering (SRE)?
处于成长期的基于SAAS/PAAS的公司需要:
上述目标需要SRE实践,如果还没到位的话。下面是我的概述,如果你需要深入研究SRE,可以参考一些关于SRE实践的书籍和博客。
SRE的任务是什么?
方便以下工作:
- 快速开发
- 免回归的版本周期
- 通过自动化解决复杂问题
- 跨部门共享生产知识
“SRE就是要把风险降到最低。”
实现SRE的重点应该放在哪里?
你如何快速驱动SRE变化取决于你的工程团队结构、文化和SDLC过程的成熟度。在较高的层次上,以下领域将是开始使用SRE的一个很好的框架。
1. 合作和沟通
SRE是一种工程文化,并不是特定于任何垂直功能。只有所有的工程领导者团结在一起,形成一个共同的愿景,这才会成功。
合作:
- 在工程部门之间设置共享的目标和对象。
- 领导者接纳并执行。
- 为各种服务设定“服务水平目标”(SLO)文化。在可靠性和稳定性(it成本)方面,我们要走多远?
- 明确定义产品/服务所有权,包括将SLO作为生产准备要求的一部分。
沟通:与工程团队的所有成员保持一致的沟通。每个领导者都应该以自己喜欢的方式来推动这一进程。
- 要从利弊两方面分析我们为什么要做这件事?(要提到商务司机。)
- 对每个团队/成员的期望是什么?新的结构在未来会是什么样的?
- 领导如何帮助避免扩大知识差距或减轻未来的挑战/风险?
- 带有时间表路线图的高层次里程碑——我们如何到达那里?
“聚焦在切实可以实现的目标上。”
2. 人员和团队结构
混合人才使用,优化到最佳结构。
- 文化:寻求帮助、合作、教导和负责任
- 雇佣合适的人才(面向未来的以及经验丰富的人才)。
- 组织团队以利于平滑传播知识。
- 雇佣员工是为了解决复杂问题,而不是为了扩大规模(通过自动化来扩大规模)。
- 团队应该对解决复杂的问题感到兴奋。
- 50%的SRE时间应用于质量工程工作。
SRE文化应该是一种力量倍增器。
3.工具/平台
从POC开始(从小处开始),并在此基础上不断发展。
- 使用星型方法来实现任何更改。在没有明确目标和预期结果的情况下,不要引入任何改变(无论多么小)。
- 实现成功:倾听用户(工程师),适应并推动采用的想法。
-
模板
- 带有关键性能指标的仪表板(保持简单,愚蠢)。
- 最佳实践的剧本
- 用于监视和安全的通用插件/模板。
-
自动化工具/剧本是版本控制的,并遵循自助模式。
“自动化的重点是解决复杂的问题。”
4. 版本工程学(RE)
发布工程不应该是事后的想法。相反,这是为了一致地测试和验证发行版而构建的主要支柱之一。这是SRE的核心功能:
-
原则:
-
质量和安全应该移到SDLC的左边,并且应该是版本工程自动化的一部分。 - 每个版本都应该通过kpi的镜头进行验证,并与设定的SLO进行比较。
- 负载和容量在放行前要进行测试和认证。
- 构建一个测试环境来检测零MTTR,从而避免生产错误。
- 产品准备就绪后才发布服务。
“服务的可靠性在于了解用户的容忍度。”
5. 监控
- 在客户端和服务端使用工具收集时间序列数据
- 使开发人员能够轻松地向监控系统添加各种指标。
- 为每个常用指标构建一组可重用的SLI模板;这也使得每个人更容易理解特定SLI的含义。
“如果你不能监控某样东西,那它就没有生产的必要。”
6. 汇报/ RCA(事后的)
- 每次都修正(战术和战略)。
- 不要责怪任何人,专注于解决方案、过程和技术。
- 通过适当的发布周期,有一个过程来跟踪问题和采取的修复行动。
- 定期召开架构和产品评审会议。
“你不可能在没有经历过问题的情况下找到正确的解决方案。”
注意:无所畏惧和协作是组成一个有效的SRE团队的关键特征。
原文链接: SRE: Key Insights "Done the Right Way"(翻译:池剑锋)