平衡快节奏的业务需求同时保持生产服务稳定的需求并非易事。SRE 是 DevOps 的一种自以为是的实现，由 Google 工程副总裁 Ben Sloss 定义为当您要求软件工程师设计操作功能时应该注意什么。它甚至还带有一个完全免费的手册和工作簿。
尽管 SRE 旨在成为如何以正确方式运行复杂系统的处方，但可靠性在不同情况下可能意味着不同的事情。而且，通常，除非出现问题，否则很难将可靠性工作优先于功能和错误修复。
SRE 如何鼓励团队思考他们的运营？SRE 如何让可靠性成为每个人日常实践的一部分？SRE 如何有效地影响人们认真对待可靠性并将 SRE 的概念和实践融入他们的日常工作中？事实证明，这是每个 SRE 面临的最重要的问题之一。
影响力与权威
在尝试传播一种做法并培养变革时，您通常可以走以下两条路线之一：影响力或权威。影响力是对某人或某事的性格、发展或行为，或影响本身产生影响的能力。在您的上下文中，目标是提供最佳实践、资源和工具，希望团队采用它们。
相反，权威是下达命令、做出决定和强制服从的权力。应用到您的上下文中，它将规定团队必须遵循并采用几种操作实践。
这两种方法都可能很有价值，具体取决于上下文。例如，对于关键系统（例如医疗保健、航空），可能需要授权以确保一定程度的安全。另一方面，权威可能对团队不利，使他们感觉不到决策过程的一部分，没有考虑到他们独特的背景，并疏远了他们。
如何提高 SRE 影响力
在提高影响力方面，您可以采取多种方式。应用到 SRE 上下文中，您可以采用几种策略来帮助您在构建复杂系统时将可靠性作为讨论的一部分。
确保人们理解你的目的和动机
当人们不理解你的动机和目标时，他们自然会变得防御；这是人的本性。如果人们了解您要实现的目标，那么传播可靠性心态会容易得多。
如果你是一个核心 SRE 团队，请明确你的团队在做什么。澄清它是一个负责生产服务的运营团队，还是一个更专注于指南和工具的团队。创建人们可以异步访问的工件（例如内部文档、博客文章），这样可以很容易地理解您的工作目标。就您的工作和路线图进行内部演示，并让您的团队（例如邮件列表、频道）进行咨询，甚至只是进行非正式聊天。
一般来说，如果人们知道您的全部内容并且可以在必要时与您联系，他们会更容易接受并解决您的疑虑。
推动理解 SRE 工作与业务目标直接相关
从根本上说，系统的可靠性取决于其执行用户需要它执行的操作的能力。然后，它将取决于用户的快乐程度，并且您知道那些快乐的用户对业务有好处。接受可靠性是任何服务最重要的要求之一，用户决定其可靠性。
SRE 工作将与业务目标密切相关。满意的用户将产生价值（例如收入、产品受欢迎程度），而可靠性是这种认知的巨大贡献者。重要的是要推动这种理解，即您不会仅仅为了挑剔而专注于可靠性，而是因为这种关注将使您的业务繁荣发展。
创造一种共同语言来谈论可靠性
您可能遇到过一种情况，您正试图与与您说不同语言的人交流。也许你去了外国，你在问路，但你不会说当地语言。最终，你让任何你想与之交谈的人都明白，你只是想要那个令人敬畏的景点的方向，他们会尽最大努力为你指明正确的方向。看似简单，其实是一个困难的交换。
同样，如果您在没有明确的方式来讨论和衡量可靠性的情况下与产品开发团队联系，那么您将很难对此进行推理。创建一种共享语言来谈论可靠性、评估可靠性并确定工作的优先级有利于任务的成功。可靠性堆栈将为您提供一个框架的基础，该框架将使可靠性对话变得更加容易。SLI 将为您提供必要的可靠性测量，而 SLO 将允许您在一定时间内评估系统的可靠性。有了这些部分，错误预算将更容易确定解决可靠性问题的工作优先级。
获得支持
因为总会有要修复的错误和要交付的功能，所以可靠性通常是事后才考虑的。获得支持将确保团队牢记可靠性，并代表您倡导它。
确定将帮助您传播信息并将可靠性视为一项明显要求的关键利益相关者。这将高度依赖于您的组织，但在深入研究流程和工具之前，您应该首先关注人。需要首先让产品开发团队加入，这样管理层才能感觉到可靠性不仅很重要，而且团队正在认真对待它，并且愿意优先考虑可靠性工作。或者，也许您需要以另一种方式解决它，获得高管的支持，以便开发团队了解对可靠性的需求，并放心花时间在上面工作。
无论哪种路线在您的环境中更有意义，当关键利益相关者支持你的工作时，肯定会帮助大家提高可靠性意识。
让您的工作可量化
SRE 工作实际上是工作。有工程工作，但也有很多与宣传、指导或咨询相关的工作。每个人都应该清楚你在做什么，你的目标是什么，你想要实现什么，你的路线图是什么。
无论产品开发团队使用什么工具和流程，您都应该了解和使用类似的工具和流程。这将有助于标准化工作的跟踪和优先级。它将使团队能够轻松地了解您关注的内容，如果他们需要您提供您没有优先考虑的事情，或者您的共同目标是否可能受到损害。
确保您的工作可见将向团队保证您没有任何隐藏的议程，并且怀着相同的目标工作。
广泛沟通；始终处于销售模式；搭建桥梁
搭建桥梁非常重要。如果人们信任你，他们会更容易听到你的想法。如果你开始远离他们，告诉人们他们需要解决什么问题并优先考虑，否则你会遇到很多阻力。
首先与团队坐下来了解他们的工作，他们的产品是什么，他们有什么痛点，以及他们想要改进什么。积极倾听可以带你走很长的路。提出问题，澄清问题，并了解什么是利害攸关的。您会希望团队将您视为合作伙伴，希望让他们的生活更轻松，而不是对手。
如果您一开始就设置可靠性阈值，那么可以很快形成我们与他们的心态。无论是冗长的手动流程还是自动阻止检查，执行起来可能以牺牲团队的善意为代价。相反，与他们合作以确保这些问题是有效的，共享将解决这些问题的工程工作，并提前就何时以及是否会设置可靠性阈值进行沟通。
自助服务，而不是琐事缠身
SRE 工作永无止境。这是需要与组织一起扩展的日常实践。扩展它的最佳方法之一是自助服务。
您应该构建工具，使团队可以轻松地将可靠性问题纳入他们的工作中。例如，您可能正在构建和维护将必要的指标导出到监控系统或标准化日志记录的库。或者，您可能正在构建有助于诊断系统问题的自动化功能。或者，您可以构建自动化手动任务并解决系统中已知问题。最重要的是，不能让琐事成为瓶颈。而是团队尽可能使用自助服务独立完成工作并为业务创造价值。
结论
SRE 涉及大量工程工作，同时包含大量沟通。很多沟通的目的是影响团队认真对待可靠性并将其作为工作的一部分。
确保团队了解您的工作目标对于让人们参与其中至关重要。您应该广泛沟通、创建工单、进行内部会谈、与团队合作并让您的工作可见。确保团队了解可靠性是通过用户对您的服务的满意度来衡量的，可靠性工作的重点是确保他们感到满意，并且业务将以此为基础。
让人们参与进来，得到他们的支持。如果您有支持者，您的信息和目标将更容易传播。确定关键利益相关者，与他们合作，了解他们的关注点，并与他们建立对可靠性的共同理解，他们会很乐意与他人分享。拥有一个共享的语言或框架，如可靠性堆栈，将使讨论、评估和优先考虑可靠性工作变得更加容易。
归根结底，您希望交付价值并使团队能够专注于为业务交付价值。构建有助于提高可靠性的工具，这很容易使用。通过自动化帮助团队解决痛点。构建自我修复工具以帮助解决系统中的已知问题。并确保你不会成为团队抱怨和害怕的另一个痛苦。您应该被视为一个合作伙伴，一个怀着相同目标工作并在必要时提供帮助的团队。
