了解站点可靠性工程师如何“左移”以增强协作、可靠性和效率。
译自 Shifting Left: How SREs and Developers Can Finally Work in Sync，作者 Matar Peles。
站点可靠性工程师（SRE）和开发人员常常面临着如何在速度和稳定性之间取得平衡的挑战。大多数情况下，开发人员倾向于专注于构建功能和编写代码，而 SRE 则确保这些功能在生产环境中平稳运行。但是，当出现问题时，界限就会模糊——这就是问题开始的地方。
“左移”运动提供了一种前进的道路。它允许团队在开发过程的早期解决可靠性和操作问题。通过共享所有权，团队可以减少摩擦并更好地协同工作。
SRE 负责维护可靠的系统、监督正常运行时间、管理事件和处理云基础设施。开发人员专注于编写代码和交付功能。但是，这些角色经常重叠，从而在它们之间产生摩擦。
这种紧张关系源于优先级错位以及缺乏对彼此工作流程的了解。开发人员优先考虑交付功能，并且可能忽略生产需求，直到出现问题。虽然他们创建应用程序，但他们通常不会为其可靠性负责。相反，SRE 努力维护正常运行时间，但可能缺乏关于最近应用程序更改的上下文。这些动态会导致效率低下，例如：
- 信息不完整导致 SRE 在事件期间由于缺乏对最近部署、依赖项或配置更改的了解而准备不足。
- 所有权分散导致责任不明确，从而导致解决关键问题的时间延迟。
- 缺乏共享框架阻碍了沟通和协调，尤其是在高压事件期间。
- 产品所有者或业务利益相关者可能会在没有明确流程的情况下对 SRE施加额外压力，从而加剧本已紧张的局面。
尽管开发人员越来越多地拥抱左移运动，专注于生产需求、安全编码和利用 AI 工具来增强其工作流程，但这些努力是不够的。开发人员必须对他们的应用程序承担全部责任，包括代码和可靠性。此外，SRE 和开发人员必须在一个共享框架上进行协作，该框架具有统一的真相来源，用于服务所有权、健康状况和依赖关系。这个基础能够实现更快、更有效的工作流程，并减轻团队脱节。
考虑一下在高峰流量期间发生严重事件的情况。SRE 可能拥有所有基础设施指标，但缺乏对最近应用程序更新或依赖项的了解。另一方面，开发人员可能无法访问生产监控工具，这使得他们无法了解问题的根本原因。这种缺乏共享责任感会将可控的问题变成长时间的停机。
让我们探索一个分步指南，用于管理事件或停机，以演示左移的影响。
预防事件始于事件发生很久之前。团队可以采取一些主动步骤来确保生产准备就绪：
- 定义所有权：使用统一的服务目录为每个服务建立明确的所有权，包括其依赖项、健康指标和升级路径。
- 自动化就绪检查：实施生产就绪的自动化检查，例如确保正确的可观察性设置、验证 CI/CD 管道和检查过时的依赖项。
- 主动监控：为潜在问题设置警报，例如错误率增加、响应时间缓慢或部署过程中的异常。这些警报允许团队在问题升级之前解决问题。
当事件发生时，快速检测和诊断至关重要：
- 统一可见性：团队使用集中式门户访问实时指标、日志和依赖关系图。这种共享视图确保每个人都拥有评估问题所需的信息。
- 所有权识别：服务目录会自动识别负责的团队或个人，并通过预配置的通信渠道（如 Slack 或 Teams）通知他们。
- 跨职能洞察：开发人员和 SRE 都可以看到有关最近部署、配置更改和应用程序更新的相关详细信息，从而能够更快地进行根本原因分析。
拥有清晰的责任归属和诊断数据，团队可以专注于解决问题：
- 自动化事件渠道：创建一个自动化通信渠道，将合适的利益相关者聚集在一起，并提供对相关工具和数据的访问权限。
- 自助修复：开发人员使用预定义的工作流程来解决问题，例如回滚错误的部署、重启服务或扩展资源。这些操作可以直接从门户执行，减少对SRE干预的依赖。
- 升级协议：如果问题需要专门的专业知识，SRE介入处理复杂问题或执行操作标准。
解决事件后，团队专注于持续改进：
- 根本原因分析：团队协作了解出了什么问题，并在服务目录中记录他们的发现。
- 工具增强：调整监控工具和自动化工作流程，以防止将来出现类似问题。
- 流程改进：整合反馈以改进响应程序、培训和文档。
最终的解决方案是重新定义所有权，并让每个人都能访问他们需要的工具。SRE应该专注于设定标准和自动化可靠性任务，而开发人员应该端到端地拥有他们的应用程序，包括正常运行时间和健康状况。
统一的服务目录可以弥合差距。它提供了对服务、其所有者及其依赖关系的清晰视图。这是实施“向左迁移”方法的重要组成部分。通过充当单一事实来源，它提供：
- 清晰的所有权：确保每个服务都有一个明确的所有者和团队负责其健康和可靠性。
- 全面的可见性：提供对依赖关系、配置和符合生产就绪标准的见解。
- 高效的协作：支持自助服务操作和自动化工作流程，以实现更快、更有效的事件解决。
虽然服务目录至关重要，但它是更广泛的生态系统的一部分，其中包括自助服务工作流程、事件管理自动化和协作工具。这些功能共同使团队能够更高效、更自信地工作。
使用统一服务目录的团队在主动预防和被动恢复方面都看到了改进。以下是这些好处的更深入了解：
- 主动预防事件：通过自动合规性跟踪，团队可以在问题升级之前识别并解决问题。例如，当应用程序不符合生产就绪标准时，例如缺少可观察性设置或过时的依赖项，团队可能会收到自动警报。通过在发布之前解决这些差距，团队避免了中断并确保了更顺利的发布。
- 更快的恢复时间：在事件发生期间，例如关键服务在高峰流量事件期间出现故障时，开发人员可以快速访问自助服务工作流程来回滚更改、重启服务或扩展资源。开发人员无需等待SRE干预，即可在门户中遵循预定义的补救路径——只需单击一下即可回滚最近的部署或扩展资源。这大大减少了平均恢复时间 (MTTR)。
- 改进的协作：通过清晰地了解所有权，团队避免了在高压情况下出现混淆。例如，当发生故障时，统一门户会立即识别服务所有者并通过自动Slack渠道引入相关利益相关者。团队可以专注于解决问题，而不是争论谁应该采取行动。
想象一下，深夜发生严重中断。统一门户无需费力查找谁拥有受影响的服务，而是会自动为事件创建一个专用的Slack频道，通知服务所有者，并提供对关键指标、日志和依赖关系图的访问权限。几分钟内，团队可以有效地协作以解决问题，从而大大减少停机时间。这种简化的流程体现了向左迁移的强大功能：为团队配备快速、自信和高效行动的工具。
向左迁移支持共享责任模型。开发人员拥有他们的应用程序，包括可靠性。SRE在需要时提供指导、工具和高级支持。这种平衡确保每个人都能专注于他们最擅长的事情。
例如，开发人员在事件期间带头管理响应。他们使用服务目录提供的工具来诊断和修复问题。SRE仅在出现复杂问题或需要确保符合标准时才介入。这种方法减少了瓶颈，并使团队能够更有效地工作。
统一的服务目录可以改变SRE和开发人员的协作方式。它促进协作，减少瓶颈并保持系统可靠性。
与同样在向左迁移的人们交流，他们也在Port’s community，或者看看如何使用Port’s live demo 向左迁移。