论文地址:STELLA:SNAFU-catchers研讨会关于应对复杂性的报告,伍兹,2017,应对复杂性研讨会

    “应对复杂性”是对我们在未来十年中所面临的系统和软件挑战的一个三个字的概括,我可以想象。今天的选择是一份2017年研讨会的报告,由John Allspaw向我推荐

    伍兹定理:随着系统复杂性的增加,系统中任何一个个体自身模型的准确性都会迅速下降。
    记住,这里的“代理”可能是一个人——例如,试图形成一个足够的心理模型来区分事件——或者是一个软件代理。

    关于复杂预算的命题
    尤其是当我们有人在循环中时(从“自动化的讽刺”中得到的一个教训是我们总是有人在循环中),那么我脑海中一直在玩的一个概念就是“复杂性预算”。每次你给一个系统引入复杂性时,你都会花费一点预算。透支(也就是说,引入一个要求,让一个人需要理解比合理的更复杂的东西),你就不再控制你的系统了。人类当然可以在团队中工作,其结构类似于系统本身,所以我并不是说每件事都必须放在一个头脑中,但每一个需要被理解为一个整体的部分确实需要。

    这是个有趣的想法,但问题是很难付诸行动。是的,我们有一整套系统和软件技术来尝试和应对复杂性,但要驯服它并以反直觉的方式行事是很难的。我们都熟悉本质复杂性和偶然复杂性的概念,但最困扰我的是随着系统的增长而出现的复杂性。我们做线性工作,随着时间的推移向系统添加组件,但这会导致复杂性的超线性增长。
    只考虑这些组件之间的交互,对于n个组件,存在O(n^2)交互。举一个包含三个组件a、B和C的小例子。现在您可能会说,系统的设计使得a只与B对话,B只与C对话。但是a和C是否共享相同的存储、计算或网络资源,例如?如果是这样的话,他们仍然可以有很多方式进行交互——所有这些共享资源都形成了侧通道,而这些侧通道上的不可预见的交互常常会让你绊倒。
    如果我们考虑部分故障等,那么对于n个组件,在最简单的故障停止模型中,现在有O(2^n)个可能的状态需要考虑。我们甚至还没有考虑到一些新出现的现象,比如相变和排列,或者系统从复杂的区域翻转到混沌,或者比“上”或“下”更精细的成分状态渐变。
    。这里的要点可能是,即使正在处理的组件本身并不比系统中的任何现有组件复杂,也不需要比任何现有组件更努力地独立开发和理解,从你的整体复杂度预算来看,它的成本比之前的所有成本都要高。这是我们在我的经验中发现的反直觉的东西。

    三个异常
    报告描述了三个异常(混乱)的细节。你可以在第3节找到细节,我不想在这里重复,因为我们有很多地方(44页)要涵盖。不过,在每一个案例中,我都注意到了这个陷阱的一个特点。

    • 在第一个陷阱中,Chef在所有服务器上推出了一个关键软件的错误版本。在事件发生期间,该系统仍然可以运行,只是因为其中一些服务器上的自动更新机制被破坏了。“具有讽刺意味的是,该系统能够在少数几个服务器上‘非正常’地运行,因为它们没有‘正确’配置,这一点并没有在运营商身上消失。”我在这里的空白处写着“多样性有助于恢复”(DRY的另一种有趣解释!)。
    • 在第二个问题中,最突出的是系统仪表板和第三方SaaS供应商都坚持说,使用关键的即服务组件一切都很好,而事实并非如此,也就是说,有一个错误的表示必须被识别和克服。
    • 在第三个陷阱中,一个关键特征是症状最初出现的地方与实际的根本原因相距甚远。

    本文第3.4.1节列出了所有异常具有的一些共同特征,包括:

    由系统组件之间的意外交互引起

    • 没有一个“根本原因”
    • 在系统中潜伏了一段时间的“事故等待发生”
    • 只因与正常运行条件略有不同而触发
    • 最初被设计用于处理部分故障等的系统机制缓冲,但最终耗尽了这些机制

    在事故中发生了什么
    更有趣的是,在各自的组织中,当他们试图应对正在上演的戏剧性事件时,发生了什么,而不是实际的异常现象本身。
    发展的方法是确定人们如何理解正在发生的事情,他们如何探索可能的来源,他们如何权衡替代的纠正措施和作出牺牲的决定,他们如何部署资源,管理副作用,补偿不断恶化的条件,修改他们对问题的理解,并与其他人协调如果我们要增强这些重要系统的弹性,这一点至关重要。
    第一个观察结果是“系统”包含了所有对操作状态有贡献的东西。这不仅是您立即想到的正在运行的组件,还包括工具链、部署过程、监视工具以及围绕它们的所有其他东西。与系统交互的人需要保持足够的心智模型,以了解这一切是如何工作的,从而能够执行他们的任务。
    在一个瞬息万变的世界里,要跟上时代的步伐所需的努力可能会令人望而生畏。

    参与者如何做到这一点?实际上体现系统的软件和硬件不能被直接看到或控制(这个论点有点像哲学上的论点,我们不能直接体验一个物体,除非通过我们的感官),而是通过这些部分暴露给我们的各种接口来体验它。这组接口统称为“表示线”,因此,线下的内容是通过观察者对这些表示的观察,由观察者形成的心理模型推断出来的。

    这样做的一个重要后果是,与系统交互的人们严重依赖于他们对该系统的心理模型,这些模型肯定是不完整的、有缺陷的,并且很快就会过时。当一个技术系统出乎我们的意料时,通常是因为我们对该系统的心理模型有缺陷。

    有规律的(情景的)意外,然后是基本的意外。情境意外与之前关于系统的信念是一致的,但是基本的意外反驳了其中的一个或多个信念。因此,虽然有可能预测到情景意外,但你不能预测基本的意外(因为根据定义,你没有能够推断出这种结果的模型)。

    信息技术的异常常常是根本性的意外……从根本性的意外中学习需要模型的修改和回响的变化。

    在意外之后,参与者们开始处于不确定的状态——到底发生了什么?实际上需要干预吗?如果是,应该是什么?通过各种搜索机制收集信息是开始形成(部分)情境心理模型的关键。这种搜索活动是“轻松和迭代的”,成功管理异常的能力很大程度上取决于可用的系统表示以及如何使用它们来构建模型和形成假设。

    专家们证明了他们有能力利用其不完整、零碎的系统模型作为勘探起点,并在异常响应期间快速修改和扩展其模型,以便了解异常情况,并制定和评估可能的解决方案。

    正如我们上次在“综合数据结构转换”中所看到的那样,同样的过程正在进行:假设生成、推演以反驳某些论点并为其他论点生成子问题,以及枚举搜索以测试剩下的可能性!

    团队倾向于自我组织,很少有明确的结构。

    我想在报告的这一部分中强调的最后一点是,我相信你们中的许多人都会对以下现象感同身受:

    一般来说,破坏持续的时间越长,造成的损害就越大。干扰传播和级联;后果增长……不确定性和不断升级的后果结合在一起,将操作环境变成了一个压力锅,研讨会参与者一致认为,这种情况在某种程度上是有压力的,可以促进重大的风险承担。

    六大主题
    报告最后提出了讨论中出现的六个相互关联的主题。

    一。总结会的价值

    总结会对于指出对系统工作方式的误解,以及洞察技术和组织过程的脆弱性,都是很有价值的。“它们还可以导致对促进这些条件的技术、组织、经济甚至政治因素的深入了解。”
    但总结会可能很难做好,虽然技术上侧重于表面,但它们是其核心复杂的社会事件。我们常常没有给他们所需要的时间和空间。
    投资于适应能力是很难做到的,更难以维持。很明显,面临压力的组织很难投入所需的资源进行频繁、深思熟虑的事后调查

    2。责罚与制裁
    我们认为“无可指责”的总结会检查是一种理想。但这个词经常被曲解。责怪是将不希望的结果归因于某个特定的来源。制裁是对特定个人的惩罚。
    组织经常声称他们的评论是“无可指责的”,尽管在许多情况下,他们实际上是不神圣的。实际上,很难完全放弃制裁。问责往往是指责和制裁的好借口。

    三。控制协调成本
    随着调查的进行,很可能会有更多的人被卷入其中。在他们能为解决这个难题做出什么贡献和让他们加快速度所需的成本之间有一个权衡。降低协调成本的一种方法是提前制定计划。不幸的是,当我们的计划遇到现实时,效果往往不太好:
    许多aids的发展都是建立在假设异常是如何表现出来的,以及什么是有用的,后来证明是不正确的基础上的。在办公室里,清单和决策树看起来清晰明了,但在实际事件中却可能无济于事,甚至产生误导。

    我们上周看到的另一个问题是,即使你确实打电话给专家,他们也面临着高度挑战性的情况,即要尽快了解正在发生的事情,并且在管理事件方面已经做了很多工作,他们需要定期与系统联系,以拥有足够的技能和背景。

    简单的问题在没有专家帮助的情况下会很快得到解决……当最初的反应失败时,专家通常会被召集,因此专家通常会遇到困难的问题。尽管最初的反应是不同的,但异常现象仍然存在,已经采取了步骤,进行了调查,尝试了诊断和解决办法。再加上异常本身就是级联的,最初响应者的活动创造了一个有自己历史的新局面。

    四。改善可视化
    在许多事件中,我们发现自己处于复杂或混乱的Cynefin域中。在这里,适当的模式分别是探测、感知和响应,或者是行动、感知和响应
    很多异常反应都是围绕着感觉加工,也就是说,检查和对比大量的数据来提取有意义的模式……支持异常反应中认知任务的表征可能与现在用于“监控”的表述大不相同。当前的自动化和监视工具通常配置为收集和表示有关预期问题区域的数据。这是意料之外的问题,往往是最烦人和难以管理。

    5。奇怪的循环
    当系统中提供函数的某个部分最终也取决于它提供的函数时,就会出现一个奇怪的循环。在正常操作下,这是可以的…直到有一天它不是!“奇怪的循环现象在现代计算中很常见,因为它有复杂的工具链和复杂的依赖关系。”
    很明显的一点是(a)业务关键型软件的复杂性意味着存在奇怪的循环;和(b)奇怪的循环依赖性使得异常难以解决。目前尚不清楚的是,如何管理业务关键型软件中奇怪的循环依赖所带来的风险。

    6。技术债务
    如果技术债务是我们在系统中所知道的,并计划有一天有希望解决的问题,那么暗债务是它更邪恶的表亲——潜伏在我们的系统中,但我们并不一定意识到它。暗债在创建时是不可识别的,并产生复杂的系统故障。它的影响不是减缓发展,而是产生异常。“没有具体的对策可以用来对付暗债,因为它是看不见的,直到一个异常显示其存在。”

    如果你只拿走一件事…
    业务关键型软件的弹性来源于工作人员的能力,以及对平台、工作区和组织的精心配置,以便这些人员能够完成这项工作。在一个复杂的、不确定的世界里,没有人能够对系统建立精确的模型,只有适应能力才能区分成功者。