SRE术语介绍
1. SRE理念
SRE（Site Reliability Engineering）是一种通过应用软件工程方法和原则来管理复杂系统的实践。它的主要目的是提高IT系统的可靠性，以确保系统的高可用性、高性能和高效率。
SRE的最初概念来自于Google，旨在通过将开发和运维等团队的能力和职责合并，来改进IT系统的可靠性。与传统的运维团队不同，SRE不仅更加注重系统的稳定性，还关注系统的自动化、监控和性能调优等方面。
SRE的核心理念包括：
- 把软件工程的思想应用到运维过程中。
- 确保系统可靠性，而不是仅仅满足系统的基本需求。
- 自动化是实现可靠性的关键。
- 计算服务和商业服务之间需要进行平衡，并将IT系统视为业务系统的一部分。
- 持续改进是确保IT系统高效运行的关键。
SRE的实践涉及许多方面，包括负载均衡、监视、容器化、故障排除和性能优化等。此外，它还与DevOps的实践密切相关，强调团队协作和渐进式交付的重要性，以支持不断增长的团队规模和企业需求。
总之，SRE是一种致力于提高IT系统可靠性的实践，通过应用软件工程方法和原则，结合开发和运维等团队的能力和职责，来支持IT系统的高可用性、高性能和高效率。
2. SRE与传统运维的区别
| SRE | 传统运维 | |
|---|---|---|
| 目标 | 确保生产环境中的服务可靠性，包括服务的可供性、性能、安全性和可扩展性等 | 通常更关注部署、操作、维护和支持IT系统 |
| 基础架构管理 | 构建和管理高度可用、可扩展和弹性的基础架构 | 管理传统基础设施，由物理服务器、存储设备、网络设备等 |
| 架构设计 | 基于软件工程和最佳实践来设计、部署和管理分布式系统架构，以确保服务的高可靠性和高可用性 | 添加或删除硬件、基础设施维护、数据存储管理、更新补丁、备份等操作 |
| 自动化 | 开发一套工具和流程来自动化构建、测试和部署代码 | 通常更注重处理当前的运维问题，例如自动化处理实时应用程序故障，配置文件和日志等 |
| 方法论 | 采用基于数据、度量和统计学的方法近似求解和持续优化系统的可靠性和可用性 | 沿用传统的监控和管理方法，并注重现场运维问题的解决 |
总结：SRE在目标管理，架构设计和自动化等都基于体系化的方法论来实现
3.SRE团队角色与职责
角色和职责
SRE团队的主要角色是负责维护和管理关键的企业IT系统，以确保系统的高可用性、高性能和高效率。SRE团队的职责包括但不限于：
- 编写、维护和优化IT系统代码和脚本自动化程序；
- 设计和实施自动化工具和流程，以加速部署和故障排除；
- 监视、分析和处理系统故障，以保持高可靠性；
- 分析和优化IT系统性能，以确保响应性和最佳可靠性；
- 与公司其他部门协作并支持公司业务目标。
与其他团队的协作
SRE团队需要与其他团队进行紧密协作，以确保系统的高效和高可用性。以下是SRE团队如何与其他团队（如开发团队和运营团队）进行协作：
- 与开发团队协作：SRE团队与开发团队合作，确保新的软件版本部署后不会对IT系统产生影响或增加系统的脆弱性。
- 与运营团队协作：SRE团队与运营团队协作，在日常维护、故障排除和监控方面共同努力。SRE团队可以提供运营团队所需的自动化工具和流程，以更加快速地解决故障和提高系统效率。
- 与公司其他部门或客户协作：SRE团队可以与公司的其他部门合作，以了解公司的业务需求，并确保IT系统与之保持一致。这将确保IT系统不仅高效满足业务需求，还符合用户需求和期望。
3.故障分析
故障分析
SRE团队需要识别和记录故障的本质，了解故障原因包括：
- 监测各种指标，例如服务等级水平，系统可用性、负载均衡等；
- 搜集并分析系统日志，提取故障数据；
- 评估事件时间线来确定故障发生的时机；
- 评估系统配置来确定是否有配置错误；
- 确保各种硬件、软件和网络都正常运行
故障排查
SRE团队需要细致地分析问题并进行调试。这可能需要查看日志，检查代码或进行网络分析等。有几种调试工具，可以用来有效地进行调试：
- 分析日志，以识别问题的根源；
- 掌握网络工具，例如tcpdump，以监控网络流量；
- 运行诊断工具，例如strace，以跟踪程序的系统调用；
- 打开调试界面，以了解代码的运行方式。
处理与解决
当SRE团队识别出故障的原因和问题时，他们需要采取相应的措施来解决这些问题。这可能包括：
- 执行故障修复流程；
- 更改IT系统的配置并重新部署；
- 实施相关的代码更改，以避免类似故障的再次发生；
- 实现工具、标准和策略以加强IT系统的稳定性
故障复盘
对于故障复盘通常需要进行黄金三问：
- 什么是问题？
这是最基本的问题，要求团队识别出故障的本质原因，以便能够更好地确定问题，并开始查找故障根源。在此过程中，团队应该分析各种日志数据，并查收相关组件（硬件和软件），以确定故障的源头。
- 为什么会发生这个问题？
确定造成故障的根本原因并不是那么容易的。它可能与不恰当的软硬件安装，配置错误，过载服务器或错误的代码有关。SRE应该设法在所有可能的方面进行分析，了解每件事的完整事实，并挖掘故障的潜在原因。找到这个问题的主要原因非常重要，因为这有助于设计不再发生类似问题的解决方案，而不是仅解决故障。
- 能怎么做来避免再次发生类似的问题？
找到问题的解决方案和实施计划的构建是最后一步。重要的是要防止将来的故障，而不是简单地解决当前的问题。为了避免类似问题的发生，团队可能需要重新安排程序员的代码，修复底层硬件问题或改善系统设计等。通过这种方式来构建新的流程和规则，以确保以后的故障会更少发生。
三个黄金问题是故障复盘的重要组成部分，它们构成了故障复盘过程中的基本框架，并且帮助团队理解故障的原因、如何避免故障再次发生，以及如何开展解决方案以维护IT系统的稳定性和可靠性。
4. SLI/SLO/SLA
SLI（Service Level Indicator）
服务水平指标（SLI）是一组被选定的指标和度量标准，用于衡量IT系统的性能和可靠性。例如，对于在线购物网站，其关键的SLI可能包括反应时间、吞吐量和订单错误率等。通过监测这些服务水平指标，SRE团队可以了解系统的实际表现，并及时采取行动以改进。
SLO（Service Level Objective）
服务水平目标（SLO）是一组针对SLI设定的指标和标准，用于评估IT系统的性能和可靠性。例如，对于在线购物网站，SLO可能是平均反应时间在5秒以内，吞吐量达到1000个请求/分钟，订单错误率低于0.1%。 这些目标的设定有助于确保够达到业务和用户需求。
SLA（Service Level Agreement）
服务水平协议（SLA）是一份合同，其定义了服务提供方和客户之间的关系，指定了服务质量标准，并确立了补偿计划。SLA通常基于SLO，业务需求和客户期望，确保IT系统可以始终高效地运行并满足客户的需求。SLA通常指定一组标准，如反应时间、可用性、恢复时间等，并在某些情况下规定补偿服务中断或故障的时间段。
总之，SLI、SLO和SLA密切相关。SLI被监控和度量是确保IT系统高效运行的关键，而SLO定义了业务目标和用户需求。SLA则是对此的具体表现，确立服务质量标准和表示双方之间的合同，以确保业务连续性和客户满意度。
5.日志与监控
设置正确的警报和通知机制：
- 确定阈值。首先，应该设置指标的合理阈值。例如，对于响应时间指标，我们可能希望设置5秒以下的目标，因为我们知道超过该阈值可能会导致用户不满意。
- 设置正确的通知方法。其次，完善的通知方法应该保证在出现问题时及时通知责任人员。这可能是减少业务影响的关键。通知也应该保证可靠，例如向多个人发送告警，并确保各团队在接收到警报及时响应。
如何使用监控数据进行故障分析和系统调整：
- 单一服务多维指标、多角度指标。企业应该使用监视工具（如Prometheus、Datadog和New Relic）来监视数字、日志和度量等多种指标。此外，还需要对多个维度进行分类，如服务器、网络、应用程序和用户等。
- 故障分析。如果监视工具能够捕获到排查问题的详细历史记录，则更容易分析故障。这样，在关键指标出现问题时，可以更轻松地追踪软件和硬件配置更改。传统的错误日志也是分析故障的好方法，企业应该更深入地理解错误记录中的信息。
- 系统调整。使用监视的数据还可以做出正确的调整。例如，在发现某个服务器负载过重时，可以将需要的工作流程和应用程序快速移到其他服务器上。
总之，实现适当的警报和通知机制以及分析和调整监视数据是确保IT系统始终高效的关键措施。通过使用不同的监控工具和日志分析方法，企业可以快速地分析信息并采取必要的纠正措施，从而确保系统健康并满足用户需求。
