以正确的方式扩展站点可靠性工程 (SRE) 团队

大多数SRE团队遇到了一个时刻，他们似乎要处理的需求超出了他们的管理能力。这是这些团队可能需要扩展的时候。面临类似的挑战？让我们解开扩展团队的全部内容。

大多数SRE团队最终都会达到他们似乎无法满足对他们提出的所有要求的地步。这是这些团队可能需要扩大规模的时候。但是，重要的是要了解增加团队容量与增加团队人数不同。让我们解开扩展团队的全部内容、指标是什么、可以采取哪些步骤以及如何知道是否完成。

缩放触发器

有时很容易判断您是否需要扩展您的团队。例如：

当团队被分配更多的服务来管理时，

流量或用户显着增加，或

服务水平目标(SLO)变得更加苛刻

在上述情况下，通常很明显团队需要扩大规模。

在其他情况下，您需要缩放的迹象更加微妙，而且通常是模棱两可的。以下是您的团队需要扩展的一些指标：

工作量增加 ：没有创造长期价值且需要积极控制的重复性任务。自动化、运行手册和 回顾都会减少工作量。然而，当一个团队处于压力之下时，它会毫不懈怠地 考虑减少辛劳等提高生活质量的问题。它将不断努力保持可靠性并实现业务目标。

可靠性或性能下降： 与辛勤工作类似，需要积极管理可靠性和性能。当团队过度紧张时，他们通常会对违反SLO做出反应，而不是主动启动性能或可靠性项目。

改进项目被延迟或取消： 工作量增加、性能或可靠性下降可能是更普遍问题的征兆：忽视长期规划而倾向于对短期问题做出反应。另一个症状是当任何类型的改进项目被取消优先级以支持功能开发时。

团队士气下降： 需要扩大规模的团队中的人员通常超负荷、压力大，并且快要精疲力尽了。事实上，这是扩大团队规模的首要原因，因为人员流失是最难恢复的问题之一。

所有这些指标都不是决定性的，可能有其他原因。您需要确保您正在解决正确的问题。将人力视为解决所有问题的一揽子解决方案可能非常诱人，但它可能会使问题恶化，并给你留下一个更棘手的缩减问题。

添加人员到你的团队应该是你在用尽所有其他选项后做的最后一件事。这不仅在财务上更加谨慎，而且还确保您不会忽视随着时间的推移可能变得更加难以解决的问题。

在考虑任何技术计划时，使用人员-流程-工具 模型将其分解是很有用的。这假定影响计划的最重要因素（按重要性排序）是人员、流程和工具。让我们按时间顺序来看它们。

过程

在开始扩展工作之前，您应该知道您正在尝试改进哪些指标以及您应该如何衡量它们。这是一个工程公理，你不能优化你没有测量的东西。要查看的确切指标因团队和情况而异，但这里有一些可以开始：

针对SLO的实际性能

项目指标：

80%等待时间

80%周期时间

平均每日队列大小

平均确认时间(MTTA)

一旦你衡量了你的关键指标，就建立一个过程来经常评估你在这些指标上的表现。为此目的，可能就像在每次冲刺回顾中花几分钟时间一样简单。

不要低估流程在帮助您扩展方面的价值。许多较小的团队经常使用简单的、临时的流程。工程师经常将流程视为不受欢迎的开销。这错过了减少错误和提高效率的流程存在的理由。

管理流程

ToilLimits 确保减少琐事任务的优先级。

事后分析确定了防止事件再次发生的措施。

像看板 这样的敏捷方法确保管理流程本身是高效的。

手指图 等报告可以帮助识别瓶颈。

工程流程

警报降噪使嘈杂的警报安静下来并确定它们的优先级。这减少了管理事件所需的工作量。

警报路由确保只有适当的人会收到有关事件的通知。

自动化减少了工作量和错误。

结对 有助于知识转移并减少错误。

基础架构即代码提高了可重复性并减少了错误。

工具

SRE工具的主题非常广泛——对于本文来说太大了。因此，与其对特定工具进行可能冗长的讨论，不如讨论如何在扩展的背景下考虑工具。

不同种类的工具具有不同种类的扩展影响。拥有表明需要进行何种改进的硬数据非常重要。这些数据可能在您的项目管理或故障单系统中，但您通常需要从您的团队那里获得反馈。

一般来说，您应该期望您的团队使用的工具能产生以下几种结果：

帮助您处理同一个团队更多负载的工具

这可以是从pssh到ansible的任何东西，可以帮助您处理大量服务器、VM或容器。现代监控工具不仅在规模上表现更好，而且通常也更容易配置。Squadcast等事件管理工具对事件进行优先排序和重复数据删除，使工程师能够专注于关键任务。

通过减少错误来减少返工的工具

脚本库、运行手册和运行手册自动化系统都有助于提高任务的可重复性——允许任务按需要可靠地频繁执行。使用容器来实现不可变服务器可确保避免由配置漂移引起的细微错误。

消除某些工作的工具

像Kubernetes这样的容器编排系统消除了大量的工作——从设置流程监管者到管理负载均衡器的监管者。

像OpenTelementry这样的分布式跟踪系统减少了对复杂日志聚合系统通过分布式系统跟踪事务的需求。

帮助委派工作的工具

RunDeck等工具允许对脚本进行安全、有防护、基于角色的访问。这允许开发人员或客户支持等依赖团队独立工作，而不会增加SRE工作量。

同样，Metabase、Kibana和Grafana等工具可用于为产品管理、客户支持或管理提供对生产数据、日志或指标的自助访问。

让高级管理层能够回答他们自己的问题是一种特别有效的方法，可以减少大量高优先级、低附加值的工作。

没有银弹

避免认为工具是万灵药的想法。引入新工具可能会造成财务负担和破坏性。如果引入不明智，它们很容易让你的团队变得更糟。这就是为什么在投资新工具之前需要进行清晰的成本效益分析的原因。

人们

一旦你用尽了所有其他增加团队能力的选项，你就必须开始向你的团队添加人员。

容量规划

容量规划与其说是一门科学，不如说是一门艺术，需要结合硬数据和判断力。构建完美的容量计划没有万无一失的方法。但这里有一些提示：

使用有关现有负载的数据进行预测。这可以是理想的工时或故事点。将其与管理下的服务联系起来。您应该可以这样说，“添加另一个微服务将每季度增加大约50小时的项目工作”或“我们目前每个sprint有80个故事点需求，而60个容量点。” 您必须能够大致量化和推理当前和预计的负载。

考虑年长者与晚年者的相对生产率和成本。大三学生通常比大四学生花更长的时间完成任务。老年人通常有其他职责，如代码审查、指导或面试。与负载一样，您应该能够量化和推理容量。

高利用率，定义为任务时间与可用工作时间的比率，并不是衡量 效率的好方法。更少的空闲时间意味着更少的用于创新和改进的创造性时间。它也可能导致沮丧和倦怠。尝试计划30%的冗余。

虽然将所有这些数字插入电子表格以进行预测可能是个好主意，但不要忽视这些只是对现实的粗略近似这一事实。确保您在容量预测方面保守，在需求预测方面宽松。随意添加缓冲区。最终获得比您需要的容量略多总比略少要好。

团队组成

在规划团队的组成时，需要考虑几个主要因素：

经验：平衡团队的经验组合需要一系列权衡。一般来说，我们可以把人分为初级、中级和高级。根据您当地的劳动力市场、技术栈和业务领域，根据多年的经验和能力来定义这些桶会有所不同。拥有10年Go微服务管理经验的人可能被认为是资深人士，但在核电站系统方面拥有类似经验的人可能被认为是初级人士。

大三学生的成本更低，效率更低，而大四学生则相反。那么，为什么不完全使用这种快乐的媒介——中间体呢？这个想法忽略了前辈和晚辈所增加的特殊价值。前辈的经验让他们无需重新发明轮子就能快速解决问题，更重要的是，边做边教别人。青少年是未来的中间人，他们不需要接受在别处养成的坏习惯的培训。

最好的折衷方案是围绕中级核心构建您的团队，并使用少量初级和高级来完善它。初级、中级和高级20:60:20的比例可能是一个争取的目标。

多样性：即使您忽略了支持历史上一直受到歧视的群体的道德义务，也有充分的操作理由在您的团队中寻求多样性。多视角有助于更大的创造力和创新。还有一些轶事证据表明，与非多元化团队偶尔会成为的以睾丸激素为燃料的男孩俱乐部相比，多元化团队表现得更好，更专业。

文化契合度：“文化契合度”通常是一种方便的工具，用于排除那些不符合工程师应有的先入为主观念的人。在我的书中，文化契合度检查只有一个基本目的，那就是排除混蛋。没有什么比不断制造小冲突或贬低队友的消极个体更能削弱团队的生产力了。重要的是在招聘过程中过滤掉混蛋，如果以后发现，要迅速摆脱他们。不要放过高绩效的混蛋——他们的生产力很少能弥补他们在团队中造成的绩效下降。

候选来源

你可以从哪里雇用？一个好方法是从你公司的其他地方挖来他们。他们的数量通常是已知的，而且通常比外部雇用便宜得多。许多传统组织都有系统管理、构建或DevOps团队，这些团队的人员可以成为优秀的SRE。软件开发人员可以为团队带来工程严谨性。

不过，通常情况下，内部招聘只会将扩展问题转移到另一个团队。最有效的候选人采购机制因地而异，但这里有一些重要的机制：

员工推荐

招聘顾问

工作委员会

广告

您网站上的职业页面。

一般来说，员工推荐比所有其他机制更便宜且命中率更高，因为它们已由员工预先过滤。确保你有奖励和激励措施来鼓励他们。

通过招聘来提高能力既费时又充满不确定性。理想情况下，您应该在预计增长前几个月开始。不幸的是，我们大多数人都没有那么奢侈，因此制定应急计划来处理招聘延误至关重要。

结论

扩展SRE团队是一项具有挑战性的工作，需要进行广泛的分析和规划。增加人员是缓慢、昂贵且有风险的，因此请考虑改进流程或技术来渡过难关。当您开始招聘时，使用数据而不是直觉来计划容量需求是值得的。仔细考虑团队的组成，因为这对长期成功至关重要。

举报/反馈