把弹性工作交给IT部门的一个小团队来"处理"，这种做法看似容易，但缺乏整体参与。弹性本质上是企业的适应力，需要全员买进，并在各部门积极推动。只有这样，企业才能真正培养面对变化的敏捷与抗风险的韧性。
译自Why People Should Be at the Heart of Operational Resilience，作者 Richard Gall 是英格兰东北部的一位作家和研究人员。他目前是爱丁堡大学的研究生，正在学习数字社会学，并且是“我们谈论何时......”的共同主持人。
在2019年的混沌工程会议上，谷歌工程师David Rensin 认为“我们的软件和硬件系统并不是我们日常生活中最复杂的分布式系统。我们的公司才是。”
Rensin 继续指出，这意味着“大多数...大型分布式系统的复杂性不在软件或硬件中，而在人类中。”
他继续讨论了一个有趣的想法，那就是将混沌工程原则带入“人际系统”——比如，在一个特别困难的系统问题的那一天，让一个团队成员缺席。
Rensin 的想法未被广泛接受，真是可惜。虽然在后疫情时代，弹性这个词似乎被更广泛地使用，但仍然存在一种观念，那就是它终究是一个技术问题。
没错，运营弹性可能业务至关重要，甚至是生死攸关。但是对于软件团队之外或边缘的人来说，很容易认为弹性和可靠性问题简单地会由对的人解决。
当然，这绝对不是事实。如果弹性是关于适应和响应变化的能力，那么它必然是一个人的问题。
“人类是软件中适应的机制，因为按照设计，我们的程序和机器本身不能自我适应。” Fastly 的高级首席Kelly Shortridge在与 The New Stack 的谈话中指出，她也是“安全混沌工程”的作者之一。
换句话说，简单地试图分离弹性的人性和技术成分是没有意义的——它们必然是紧密关联的。
对于 Jeli 的 CTOWill Gallego来说，弹性需要被理解为不同于鲁棒性。鲁棒性是软件的一个品质，而弹性是关于人与软件工件的互动如何响应变化的方式。
他在给 The New Stack 的电子邮件中表示:“鲁棒性是技术系统如何构建，以抵御预期情况。弹性是工程师即时运用专业知识来诊断故障模式，并查看可能缓解压力的模式。”
为什么人/技弹性在今天很重要？
诚然，注意到人类和技术是紧密交织在一起没有什么新颖之处。“社会技术”这个词是在 20 世纪中期由科学家 Eric Trist、Fred Emory 和 Ken Bamforth 创造的，具体描述了技术工件、组织结构和人类如何相互作用和塑造彼此。
然而，由于一些原因，它在今天具有特殊的紧迫性。
第一个原因是软件系统日益复杂。基于云的系统和服务，特别是那些使用微服务以及与这种方法相关的日益扩大的工具和平台生态系统的模块化和组合服务，这意味着这个领域的从业者通常在处理互联的服务和应用程序困境，而且通常只能部分理解。
第二个原因是数字化转型的推进在近年来由于 COVID-19 大流行的影响而加速，这意味着这些系统被深深嵌入并交织在人们的日常生活中。换句话说，世界对这些产品和服务的要求更高，并期待它们始终可用。
与此同时，当然还有一个事实，那就是软件现在以不同的方式构建。特别是DevOps改变了关于谁负责什么的期望。
根据 Blameless CEOJim Gochee的说法，随着“服务的所有权转移到构建该服务的开发人员身上”，我们现在有了一“新品种的响应者”，他们承担着过去可能由支持工程师或更近期的站点可靠性工程师(SRE)完成的工作。
接受“你建设，你运行”的精神并不一定是坏事，但将其变成一种爱好可能很容易导致我们进入一个地方，那里故障和缺陷成为个人的责任。这对任何人来说都不是好事，无论是人类还是技术。
Shortridge 说：“如果一个系统的弹性依赖于人类永远不犯错误，那么这个系统实际上是脆弱的。” “人类的成功在于我们的创造力和适应能力；我们成功不是因为我们擅长每次都以相同的方式做同样的事情，或者可以记住清单上的 50 件事而永远不会忘记。”
虽然 DevOps 本意是试图打破壁垒，但它可能促成了对失败的更广泛的组织不适——一种控制和最小化风险的愿望。Shortridge 声称：“许多组织在存在感上挣扎，希望防止任何坏事发生。”
她补充说，这最终“是一个不可能实现的目标......这是一个恶性循环，害怕出错的恐惧导致方法变得缓慢和笨重，这反过来实际上增加了出错的可能性，并阻碍了从故障中快速恢复的能力。”
Gallego 甚至更直接地陈述了这个问题：“人们会说‘安全是我们的首要任务’。但是保持完全安全的唯一方法是关闭系统并回家。安全受到环境约束和业务需求的挑战。”
鉴于当前全球经济形势对组织造成的压力，组织对失败感到焦虑并不令人惊讶。事实上，围绕开发人员生产力的近期辩论与运维弹性息息相关；认为只要开发者做正确的事情(编写代码)，组织就能成功的想法，以及我们需要消除开发者面临的障碍的想法，最后都过于强调个人的用处，而没有考虑到整个系统的健康。
这对许多组织来说可能具有挑战性，Shortridge说：“接受失败会发生，我们需要快速变化的能力，人为错误代表着更好的设计机会——这对组织来说通常是一个哲学上的飞跃。”
超越工程团队的思考
鉴于改变围绕人在弹性中角色的文化思维模式的挑战性，扩大其范围似乎有点奇怪。然而，思考工程团队(开发或运维)如何嵌入到更广泛的组织结构中，可以帮助我们广泛思考弹性。
事实上，它甚至可以帮助我们更多地强调运维弹性的社会技术性质。
Gallego 认为运维弹性“贯穿整个组织。你可能不会让你的销售团队跳进一个事件中来启动服务器，但知道你将要进行营销活动会影响网站承受更重负载的能力。所以提前进行沟通可以让人们评估系统的部分来进行压力测试，就潜在的故障模式与流量模式分享专业知识。”
他对 The New Stack 表示，这在某种程度上是 DevOps 的一个关键教训，行业应该更深入地考虑。“一旦你开始消除这些团队之间的壁垒，你会问自己:‘我们为什么不多与支持聊天？与我们的数据科学团队或我们的公关团队？’”
同样，Gochee 指出弹性需要其他团队的参与，从支持到销售。“假设这是季度末，有许多公司在试用，网站在试用期间宕机。现在这些公司就会‘嗯，我不知道，如果你有可靠的服务，我可能会退出并决定不买。’”
他说，其影响可能很大：“你刚刚影响了销售团队，这将影响奖金、佣金、工资单、生计。” 最终，这会通过层级结构上升。“它升级到首席执行官，谁通常会说，‘好的，我们有一个巨大的问题，像，这是怎么回事？为什么它没有得到解决？’”
奖励“胶水工作”
Gochee 和 Gallego 都强调了这些不同职能之间的沟通和透明度对弹性的重要性。
例如，设想一下，“你在一个角色中，听说网站宕机了”，Gochee 说。 “知道它正在及时解决问题，然后知道事后我们进行了深入调查，了解了为什么会发生这种情况，这很好。”
特别重要的是，我们不应该认为这些事情微不足道。沟通无疑总是我们面临的挑战的明显答案，但 Gallego 指出，在组织环境中，这需要实际的精力和工作。
他引用了“胶水工作”的概念。这个词被博主兼 Squarespace 高级首席工程师Tanya Reilly普及，指的是接待新团队成员、与用户和其他团队交谈并保持事情向前发展的工作，并指出这种劳动通常是“不可见的”。
更重要的是，它通常不会得到补偿。Gallego 指出：“人们不总是通过避免失败获得升职。” 技术界太常有围绕员工加班和周末跳入火场扑灭火灾的英雄文化。它们是轻而易举的，立即感受到，但当你不知道情况本可以多糟糕时，做工作以避免问题却不会激发同样的情绪。”
因此，运维弹性的一个重要步骤是确保认可和认可这种“胶水工作”。
领导力的重要性
第一步也许是创建一个完全致力于弹性的角色。
Gochee 说：“如果没有领导者来做这件事，它通常不会被完成。” “工程副总裁通常没有带宽来担任运营副总裁、基础设施副总裁或 DevOps 副总裁。他们忙于 1,000 其他事情，以至于永远无法真正完成它。”
这似乎与弹性所依赖的大量角色的重要性相矛盾。但重点是，它需要有人来领导所需的流程、工具和思维方式，以便有效地进行运维弹性。
准备、培训和心理安全
但是组织为了应对运维弹性的挑战实际需要什么？部分是关于准备。
Gochee说：“你要为此进行培训，准备工作。” “通过提供剧本，可以简化他们的工作，所以当你第一次进入一个事件时，你不需要弄清楚该做什么。”
在某种程度上，这与 Rensin 关于向人际系统注入一点点混沌的观点有些相似之处——确保人们即使在某人不可用的情况下也知道该做什么。
“这就像生活中任何类型的紧急灾难计划。” Gochee说。他解释说，拥有剧本至关重要。他们应该概述什么应该发生以及谁需要参与以减少过程中的不确定性或缺乏清晰度。
事实上，确定谁应该负责开发剧本可能很困难。这强调了拥有可以倡导弹性举措和资产的领导职位的价值。
Gochee 指出，运维弹性培训和准备的真正价值在于它为个人和团队提供的心理条件。在发生意外事件时，人们很容易恐慌：“你的杏仁核会被劫持，”他说，这会触发逃跑或战斗反应。
Gallego 和 Shortridge 也强调了心理层面，特别强调心理安全感。
Gallego说:“从事这项工作的最佳文化是将心理安全作为核心功能，停止不前。” “你能否提出富有挑战性的想法？团队的高级成员是否愿意传递权力，以让其他人成长？当事故确实发生时......它们是否被束之高阁？”
当 The New Stack 询问 Shortridge 什么样的组织在运营弹性方面表现良好时，她对 Gallego 的回应非常相似：他们拥有奖励好奇心和透明度的文化，在那里“团队以谦逊的态度不断了解自己的系统”。
她说，这些组织“犯错本身并不可耻；拒绝从错误中学习并坚持现状才是问题所在。”
不承认这一点的组织不仅伤害了员工，还破坏了弹性。这些观点在其他地方也有所反映——在今年早些时候发表在 The New Stack 上的一篇文章中，Honeycomb.io 的员工 SREFred Hebert写道，当有新的工程师加入团队时，明确表示“我们预期不知道发生了什么，这很正常，责任是共享的，我们充分意识到他们所处的情况”。
一个更好的平台，造福所有人
明确的是：虽然人的弹性至关重要，但我们不应忽视社会技术概念的技术部分。Shortridge 在这一点上尤为明确，并认为平台工程对于未来实现运维弹性至关重要。
Shortridge说：“如果我们想持续软件的弹性，我们需要确保应用程序开发人员尽可能不用考虑弹性。” “这意味着我们需要平台工程团队思考弹性，就像他们已经考虑可靠性或生产力一样，以便他们可以构建使开发人员以弹性方式快速轻松地进行开发的平台、工具和模式。”
这并不意味着在开发人员和平台工程师之间建立一个新的鸿沟。重要的是确保组织中的每个人——无论是内部还是外部的工程职能——都具有所需的工具和知识，并感到安心面对模糊不清和不确定性，以便在发生意外时做出反应。因为意外肯定会发生。
本文在云云众生（yylives.cc/）首发，欢迎大家访问。
