CN112840326A - 用于自动化操作管理的测试引擎 - Google Patents

Abstract

公开了涉及计算机系统的操作管理的技术。计算机系统可以访问定义用于操作场景的命令集的操作信息。计算机系统可以访问要在目标计算机环境中使用的用于实现该操作场景的操作实体集的蓝图。该计算机系统可以实现目标计算机环境的操作场景。该实现可以包括执行控制器模块的层级结构，该控制器模块具有在层级结构的顶层处的协调器控制器模块，该协调器控制器模块可执行来通过向层级结构的下一层处的控制器模块发出指令来执行命令集。该层级结构可以包括控制器模块，该控制器模块可执行来根据相应的蓝图来管理该操作实体集，以便完成该操作场景，包括通过改变该操作实体集中的一个或多个的状态。

Description

用于自动化操作管理的测试引擎

背景技术

技术领域

本发明总体上涉及计算机系统的操作管理。

现有技术描述

历史上，管理系统，例如确保服务或平台正在运行并且可用，已经涉及执行各种运行列表(命令序列)。对于用户将运行列表的命令手动输入到命令行中来说，这样的运行列表通常很长并且耗时。最后，编写遍历整个运行列表的软件脚本，代替用户输入命令。但是，这些软件脚本通常会崩溃，从而使管理系统处于未知状态。结果，用户仍然必须通过确定系统的当前状态，然后将系统重置到软件脚本可以再次运行的状态来参与。此外，由于系统通常涉及多个子系统，所以必须维护和执行多个运行列表，每个运行列表具有它们自己的用于管理系统的步骤和方式。

附图说明

图1是示出根据一些实施例的能够管理操作实体的系统的示例元件的框图。

图2是示出根据一些实施例的操作实体的示例元件的框图。

图3A是示出根据一些实施例的用于操作实体的定义和蓝图的示例元件的框图。

图3B是示出根据一些实施例的用于操作实体的实体描述符的示例元件的框图。

图3C是示出根据一些实施例的操作实体的关系信息的示例元件的框图。

图3D是示出根据一些实施例的示例操作实体的示例关系的框图。

图4是示出根据一些实施例的控制器模块的示例元件的框图。

图5和图6是示出根据一些实施例的涉及管理系统的操作实体的示例方法的流程图。

图7是示出根据一些实施例的控制API的示例元件的框图。

图8是示出根据一些实施例的路由引擎、路由层和可路由实体的示例元件的框图。

图9和图10是示出根据一些实施例的涉及实现与操作实体相关联的指令的示例方法的流程图。

图11-13是示出根据一些实施例的涉及路由与操作实体相关联的指令的示例方法的流程图。

图14是示出根据一些实施例的工作流引擎的示例元件的框图。

图15和16是示出根据一些实施例的涉及实现工作流的示例方法的流程图。

图17是示出根据一些实施例的推理引擎的示例元件的框图。

图18和图19是示出根据一些实施例的涉及生成工作流的示例方法的流程图。

图20A和图20B是示出根据一些实施例的授权服务的示例元件的框图。

图21是示出根据一些实施例的授权表的示例元件的框图。

图22是示出根据一些实施例的由授权服务创建的令牌的示例元件的框图。

图23是示出根据一些实施例的涉及授权服务的示例方法的流程图。

图24是示出根据一些实施例的测试引擎的示例元件的框图。

图25是示出根据一些实施例的涉及测试引擎的示例方法的流程图。

图26是示出根据一些实施例的示例计算机系统的框图。

本发明包括对“一个实施例”或“实施例”的引用。短语“在一个实施例中”或“在实施例中”的出现不必指同一实施例。具体的特征、结构或特性可以以符合本发明的任何合适的方式组合。

在本发明内，可将不同实体(其可不同地称为“单元”，“电路”，其它组件等)描述或主张为“经配置”以执行一个或多个任务或操作。这种表达，配置为[执行一项或多项任务]的[实体]，在这里用来指结构(例如，物理的东西，如电子电路)。更具体地，该表达用于指示该结构被布置为在操作期间执行一个或多个任务。可以说某结构被“配置成”执行某个任务，即使该结构当前没有被操作。“配置成经由网络通信的网络接口”旨在涵盖(例如)具有在操作期间执行此功能的电路的集成电路，即使讨论中的集成电路当前未使用(例如，电源未连接到其上)。因此，被描述或叙述为“配置成”执行某个任务的实体是指物理实体，诸如装置、电路、存储可执行以实现该任务的程序指令的存储器等。该短语在这里不用于指无形的东西。因此，“配置成”构造在本文中不用于指代软件实体，例如应用程序编程接口(API)。

术语“配置成”并不意味着“可配置成”。例如，未编程的FPGA将不被认为是“配置成”执行某个特定功能，尽管它可以是“可配置成”执行该功能并且可以在编程之后“配置成”执行该功能。

如在此所使用的，术语“第一”，“第二”等被用作它们在名词前面的标记，并且不暗示任何类型的排序(例如，空间的、时间的、逻辑的等)，除非特别陈述。例如，在具有八个处理核的处理器中，术语“第一”和“第二”处理核可用于指八个处理核中的任何两个。换言之，例如，第一处理核和第二处理核不限于处理核0和1。

如本文所用，术语“基于”用于描述影响确定的一个或多个因素。该术语不排除另外的因素可能影响确定的可能性。即，确定可以仅基于指定的因素或基于指定的因素以及其他未指定的因素。考虑短语“基于B确定A”。该短语指定B是用于确定A或影响A的确定的因素。该短语不预示A的确定也可以基于一些其他因素，例如C。该短语还旨在涵盖其中仅基于B来确定A的实施例。如本文所用，短语“基于”因此与短语“至少部分地基于”同义。

具体实施方式

一些开发人员不是使用从运行列表中输入命令的软件脚本，而是开始使用大型部署系统，例如

来管理他们的系统。

提供了一个以容器为中心的管理环境，用于自动化容器的部署和管理，这些容器是具有应用程序及其相关性的便携式、自给自足的单元。因此，开发者可以使用

来部署包括例如数据库服务器的容器。然而，由于各种原因，利用

管理整个系统是不完善的。

被设计为在工作节点(例如，虚拟机)之上管理容器。例如，Kubernetes不能用于管理硬件或信息实体，例如逻辑数据库或配置规范。

不提供可见性和/或控制容器内的所有东西。例如，

无法与容器中实体化的数据库服务器连接。因此，单独使用

无法实现管理目标，例如启动容器内的系统，排除这些系统的故障以及收集这些系统上的元数据。其他方法，例如

与

具有相同的缺陷，因为它们缺乏控制系统中可以找到的全部组件的能力。

虽然在传统上管理系统非常困难，但测试这些系统或发生的故障排除问题同样困难。如前所述，当运行列表失败时，通常难以辨别系统的当前状态，因为运行列表不提供关于它在崩溃之前离开系统的状态的信息。另外，在必须被测试的系统内通常存在大量的复杂性。结果，如果由于系统的复杂性而被忽视，系统的某部分可能不被测试，并且那些被测试的部分可能没有被充分地测试。

本发明描述了用于管理系统的技术，其克服了现有方法的一些或全部缺陷。在下面描述的各种实施例中，以正式的、结构化的方式描述系统内的操作实体(例如，数据库服务器、逻辑数据库等)，并且随后由控制器模块管理。一般而言，系统内的许多操作实体是硬件或存储在硬件上的信息。如果操作实体仅仅是系统的物理的、有形的组件，则在本发明内将其称为“硬件实体”。物理服务器机架和刀片是硬件实体的示例。如果操作实体不是硬件，则它可以包括存储在硬件上的信息即数据。该信息可以是可执行的或不可执行的。可由系统执行以执行操作的信息在本发明内称为“软件实体”。数据库服务器实例、警报服务器实例和度量服务器实例是软件实体的示例。另一方面，在本发明内，不可执行的系统内的信息被称为“信息实体”(或可选地，“面向信息的实体”)。数据库备份镜像和包括用于多租户数据库的租户的数据的租户构造是信息实体的示例。

这三种实体类型——硬件、软件和信息可被认为是可在系统内找到的任何操作实体的“构建块”。出于本发明的目的，系统内的任何操作实体可以使用三个构建块实体类型中的一个来描述，或者使用包括这些构建块中的两个或更多个的组合实体类型(或者可替换地，“形成”)来描述。形成实体的一个示例可以是“数据库系统”的操作实体，因为数据库系统可以包括处理器和存储介质(硬件实体)，在该处理器上执行的数据库服务器(软件实体)，以及由该数据库服务器管理的逻辑数据库(信息实体)。形成实体的另一示例可以是“存储区域网络”的操作实体，因为存储区域网络可以包括存储介质、网络交换机(其本身可以是硬件和软件实体的形式)以及存储在存储介质上的数据对象(信息实体)。

在各种实施例中，系统的预期/期望状态最初被定义为系统的操作者希望系统处于的状态。定义系统的预期状态可涉及创建定义和蓝图，所述定义和蓝图定义组成系统的各种操作实体以及这些操作实体之间的关系。这些定义和蓝图可能遵循提供描述操作实体的结构化方式的通用架构。如将进一步解释的，定义和蓝图可以向控制器模块传达信息，该信息使得该控制器模块能够管理对应于定义和蓝图的操作实体。例如，如果控制器模块正在管理数据库服务操作实体，则控制器模块可以从链接到该数据库服务的蓝图中获悉该数据库服务应当包括三个正在运行的数据库服务器。如果控制器模块观察到数据库服务仅包括两个正在运行的数据库服务器，则控制器模块可以启动第三数据库服务器以达到该数据库服务实体的预期状态。

从两个正在运行的数据库服务器到三个正在运行的数据库服务器的转换可以被视为系统在两个状态之间的状态转换。因此，系统的操作管理可被视为或与堪比其中系统可存在于不同状态中并通过不同状态转换的状态机。如上所述，定义和蓝图可以定义系统内实体的预期状态，从而将系统定义为一个整体。在各种实施例中，系统的控制器模块将系统从一个状态转换到另一状态，直到系统到达预期状态。控制器模块然后可以继续监测系统以确保系统保持在预期状态中。如果系统离开预期状态(例如，一个实体因故障而退出)，则控制器模块可以实现一个或多个命令以通过向系统内的组件发出指令来将系统移回到预期状态。在一些情况下，可以以允许用户读取命令(即，人类可读命令)的方式来编写命令，并且因此控制器模块可以将该命令翻译成系统中的组件可理解的指令；在一些情况下，命令可以是可理解的指令，因此控制器模块可以不必翻译它——控制器模块可以将命令作为指令发送到组件。如本文所使用的，术语“组件”旨在涵盖操作实体和控制器模块。因此，术语“组件”可以指操作实体或控制器模块。

为了促进系统状态之间的转换，在各种实施例中，实现控制应用程序编程接口(API)提供了解系统的当前状态且在需要时对系统进行改变的方式。控制API可以通过一组API调用来提供对系统中的操作实体的结构化访问，该组API调用提供用于了解操作实体的状态以及用于调用由该操作实体支持的功能的机制。在各种实施例中，控制器模块主持控制API，并因此使得用户和/或其它控制器模块能够经由控制API访问由那些控制器模块管理的操作实体。

在各种实施例中，系统中的控制器模块和操作实体可以形成层级结构，其中协调器控制器模块可以驻留在层级结构的顶层并且可以通过层级结构向下向驻留在较低层中的控制器模块和操作实体发出指令(其可以包括控制API调用)。作为示例，协调器控制器模块可以经由命令行工具从用户接收与特定实体有关的命令。因此，协调器控制器模块可以通过层级结构的层次将指令(基于命令)路由到管理控制器模块，管理控制器模块可以通过对特定实体进行适当的控制API调用来实现指令。该调用可以使特定操作实体转换到另一状态。

该范例允许实现操作场景。概括地说，这里使用的术语“操作场景”是指用于执行某个动作的一系列步骤。例如，一个操作场景可以包括启动数据库服务，而另一个操作场景可以包括更新数据库服务。可以使用包括有序命令集的工作流来实现操作场景，该有序命令集可以经由一组控制API调用来执行。例如，用于更新数据库服务的工作流可以包括用于将数据库服务的操作实体从“在线”转移到“离线”的命令、用于将它们从它们的当前版本转移到更新的版本的命令，以及用于将它们从离线转移回在线的命令。在一些实施例中，协调器控制器模块访问工作流信息，并基于工作流信息通过层级向下发出指令，以改变适当的操作实体，从而完成相应的工作流。

可替换地，可以通过为适当的实体定义一组预期状态来实现操作场景。然后，协调器控制器模块可以从该组预期状态中确定用于达到这些状态的命令。例如，预期状态(或目标)可能是具有包括三个数据库服务器的正在运行的数据库服务。因此，协调器控制器模块可以生成具有用于启动三个数据库服务器的控制API调用的命令。该过程可以被称为关于预期状态的协调器“推理”。因此，在一些情况下，该推理允许用户定义目标，而不必表达实现该目标所需的特定步骤或动作，而这些步骤或动作可以由协调器执行的“推理”来确定。在一些情况下，该方法可能比定义工作流更健壮(robust)，因为系统可能以其自身的预期状态结束(例如，容器的消失可能满足不具有该容器的预期状态。

这些技术可能优于现有方法，因为这些技术允许以自动方式描述并随后管理整个系统。诸如

的现有方法允许定义和实例化容器，但不提供用于控制系统中的全部组件(例如，硬件、容器内的软件、诸如逻辑数据库之类的信息构造，等)的机制。另外，这些技术允许定义系统的预期状态，并因此允许以自动方式控制系统，这降低了对管理系统的人为干预的依赖性。即，系统内的控制器模块可以连续地监测系统以确保系统处于预期状态。如果系统改变到不同的、非期望的状态，则在许多情况下控制器模块可以在没有人为干预的情况下将系统转换回预期状态。这种自动方式可以减少在管理系统中涉及的人的数量。此外，使用用于描述实体的公共格式可以简化操作，增加测试操作场景的能力，并且减少在生产环境中管理软件所需的代码量。这些技术还可以应用于可变部署，其中可以改变部署(例如，通过将一组节点添加到应用程序服务器池中)而不重新创建整个部署，并且可以应用于不可变部署(例如，其中为部署的每个改变重新创建整个部署)。这些技术还提供了集成故障测试(与必须使用完全独立的工具相比)、集成安全性和集成故障排除。

现在转向图1，描绘了系统100的框图。在所示实施例中，系统100包括操作实体110、控制器模块120(包括协调器控制器模块120)、数据库130和授权服务140。同样如图所示，数据库130包括操作信息135，并且授权服务140包括测试引擎150。在一些实施例中，系统100可以与所示不同地实现。作为示例，系统100可以包括多个协调器控制器模块120、另一层操作实体110和/或控制器模块120、多个数据库130等。

在各种实施例中，操作实体110包括一个或多个元件以及与这些元件相关的信息集合。元件的实例可以包括例如物理处理器、物理存储器、虚拟机、虚拟机镜像、逻辑数据库、数据库快照、容器、容器镜像、数据库服务、操作系统、工作流、数据库中心、网络边界/域等。如前所述，存在三种基本类型的操作实体110：硬件实体110、软件实体110和信息实体110。在各种实施例中，操作实体110的类型取决于构成该操作实体的元件。例如，只包括物理处理器的操作实体110被认为是硬件实体110。这三种基本类型可用于制造形成操作实体110。形成实体110是两个或多个实体的集合，每个实体与其它实体具有零个或多个关系。形成实体110的示例是数据库系统实体110，其包括处理器和存储介质(硬件实体110)，在该处理器上执行的数据库服务器(软件实体110)，以及由该数据库服务器管理的逻辑数据库(信息实体110)。

操作实体110可以包括或关联于描述该操作实体的信息集合。该信息可以包括：定义，其可以定义什么元素和变量可以用于构成操作实体110的特定种类；以及蓝图，其可以定义操作实体110的该种类的实例。例如，定义可以将数据库服务实体110定义为包括数据库服务器实体110，而蓝图可以将特定数据库服务实体110定义为包括15个数据库服务器实体110。在各种实施例中，与操作实体110相关联的信息进一步界定控制API的函数。这样的信息可由控制器模块120用来例如通过将操作实体转换到不同状态来了解操作实体110可要求哪些函数来管理该操作实体。

在各种实施例中，控制器模块120是可执行以管理控制器模块120和/或操作实体110的集的一组软件例程。在一些实施例中，控制器模块120以通用方式定义，使得系统100中的每个控制器模块120支持相同的功能，尽管它们可以以不同的角色在系统100中服务。控制器模块120还可以工作在各种环境中，包括裸金属，亚马逊web服务(AWS)和

例如，在

环境中，控制器模块120可以充当与数据库容器内的其它控制器模块120交互的

操作器。在AWS上，AWS云可以被定义为分发虚拟机实体110的操作实体110。在每个虚拟机实体110内部可以是管理该虚拟机实体的内容(操作实体110)的控制器模块120。

为了管理操作实体110和/或控制器模块120，控制器模块120可以在其控制或授权下访问用于每个操作实体110的控制API。在各种情况下，控制API的控制API调用对于所有操作实体110可以是相同的，尽管用于那些控制API调用的函数的实现在操作实体110之间可以是不同的。通过发出控制API调用，控制器模块120可以获得与操作实体110(例如，蓝图)有关的信息，并且可以在状态之间转换该操作实体。作为示例，控制器模块120可以向数据库服务器实体110发送“转换”控制API调用，以将数据库服务器元件从离线转换到在线。

在各种实施例中，控制器模块120维护与由该控制器模块管理的操作实体110和/或控制器模块120有关的信息。在一些情况下，当被启动时，控制器模块120可以访问向该控制器模块120提供初始信息的属性文件；这样的信息可以识别要侦听的端口号以及受控制器模块120控制的任何操作实体110。由控制器模块120维护的信息还可以包括从操作实体110收集的信息，诸如由那些操作实体支持的蓝图、定义和通告的控制API调用。

如前所述，操作实体110和控制器模块120可以形成层级结构。在层级结构顶部的控制器模块120被称为协调器控制器模块。协调器控制器模块120可以具有实现高层次目标的任务，并且因此可以协调层级结构的其他层中的其他控制器模块120以实现该目标。作为示例，协调器控制器模块120可以具有更新整个数据库舰队实体(database fleet entity)110的任务。结果，协调器控制器模块120可以调节数据库舰队实体110内的每个数据库集群实体110的更新。这可以利用管理那些数据库集群实体110内的操作实体110的其他控制器模块120。然而，那些控制器模块120可以隐藏在从协调器控制器120更新那些数据库群集实体110时发生的事情的细节。在一些实施例中，系统100可以包括多个层级结构，这些层级结构中的每一个都可以包括它们的协调器控制器120。

在各种实施例中，数据库130是以允许信息的访问、存储和操作的方式组织的信息集合。数据库130可以由单个存储设备或多个存储设备来实现，所述单个存储设备或多个存储设备在诸如存储附连网络之类的网络上连接在一起，并且被配置为冗余地存储信息以防止数据丢失。数据库130可以包括支持软件，该支持软件允许控制器模块120对数据库130中的信息执行操作(例如，访问、存储、操纵等)。在各种实施例中，数据库130存储与系统100内的操作实体110有关的定义、蓝图、操作信息135和/或其它信息。当管理操作实体110时，控制器模块120可以从数据库130访问信息，使得它可以适当地管理该操作实体。

在各种实施例中，操作信息135是定义目标环境137的操作场景的信息集合。如上所述，操作场景是用于执行某个动作(或高层次目标)的一系列步骤。在一些实施例中，在工作流文档中定义操作场景，其中给定工作流文档可以指定用于实现对应操作场景的一系列步骤的命令集。给定的操作场景可以与目标环境137相关联，使得操作场景可以改变该目标环境的状态。

在各种实施例中，目标环境137是控制器模块120和/或操作实体110的集，其可以作为操作场景的一部分来操作。例如，在将数据库舰队实体110更新到较新版本的操作场景中，数据库舰队实体110(包括其所有操作实体110和控制器模块120)被认为是该操作场景的目标环境137。另一操作场景可涉及具有不同操作实体110和/或控制器模块120的不同目标环境137。

在各种实施例中，授权服务140可操作以通过认证(“谁正在试图改变状态”)、授权(“是否允许它们改变状态？”)，以及审核(记录认证和授权的结果)向控制器模块120和/或操作实体110发出的命令来保护系统100免受不适当使用(无论是恶意的还是非恶意的)。例如，服务140可以审核由用户向协调器控制器120发出的命令，以防止执行任何未授权的发出命令。服务140还可以审核由协调器控制器120向其他控制器模块120(或向操作实体110的其他控制器模块120)发出的命令，以确保用户没有试图通过绕过协调器控制器120来获得授权访问。如将在下面关于图20-23讨论的那样，在各种实施例中，授权服务140维护定义用于在目标计算环境内实现各种操作场景的可允许动作的安全规则集，并验证所发出的命令符合由安全规则集定义的可允许动作。

在各种实施例中，测试引擎150是可操作以将故障条件注入到系统100中的测试组件，以便识别系统100无法正常工作的状态。通常，这些故障可能涉及碰撞、挂起、错误、锁步排序问题、时间注入等。例如，测试引擎150可以禁用由系统100使用的数据库服务器以查看这样的动作是否将系统100置于不能恢复的状态。如下面将结合图24和25更详细地描述的那样，在各种实施例中，测试引擎150与一个或多个控制器模块120和/或操作实体110接口，以确定系统100的当前状态。例如，测试引擎150可以在注入故障条件之前收集关于系统100的当前状态的信息，然后在注入之后收集关于当前状态的信息，以便确定系统100的状态如何被改动。在一些实施例中，测试引擎150还可以监测系统100的状态，以便在控制器模块120发出特定命令时注入特定故障条件。即，当请求流经授权服务140时，测试引擎150可使用架构中的这一点来协调故障注入(例如，在改变之前，在改变之后，以及在改变期间)。例如，测试引擎150可以根据授权服务140所处理的请求来确定操作实体110正在经历更新，然后可以尝试注入可能导致更新失败的故障条件，以便确定系统100是否能够在更新处理期间处理故障条件。在所示实施例中，测试引擎150被示出为集成到授权服务140中，因为当各种组件向服务140请求执行各种动作的许可时，这种集成可允许测试引擎150更深入地了解系统100的当前状态。在一些实施例中，外部测试系统可以与测试引擎150交互至协调器改变并将故障注入到系统100中。

现在转向图2，描绘了操作实体110的框图。在所示实施例中，操作实体110包括蓝图210、一个或多个元件220以及控制API实现230。如图所示，操作实体110与控制器模块120接口。在一些实施例中，操作实体110可以包括与外部控制器模块120接口的控制器模块120。作为示例，操作实体110可以是具有与协调器控制器模块120通信的控制器模块120的软件容器。在一些实施例中，操作实体110可以与所示不同地实现，例如，蓝图210可以存储在数据库130而不是操作实体110处(或者它可以存储在实体110和数据库130两者处)。

如先前所解释的，为了使系统100的操作实体110能够被管理，在各种实施例中，可以使用包含关于操作实体本身及其与其他实体110的关系的信息的蓝图210和定义(其关于图3A被更详细地讨论)来描述实体110。这样的信息可以将如何管理不同的操作实体110传达给控制器模块120。

在各种实施例中，蓝图210是定义操作实体110的特定实现的各方面的信息集合。蓝图210可以定义系统100的管理员希望操作实体110存在的操作实体110的期望或预期状态。例如，一个特定蓝图210可以将数据库舰队实体110描述为包括15个数据库服务器，而另一个特定蓝图210可以将数据库舰队实体110描述为包括10个数据库服务器。如关于图3A-3D更详细地讨论的那样，在各种实施例中，蓝图210包括可以定义可用于管理操作实体110的一组选定属性的值的实体描述符，可以描述操作实体110与其他实体之间的关系的关系信息，以及可以用于配置操作实体110的实体特定变量。用于操作实体110的蓝图210可以由系统100的用户，开发该实体的用户(例如，编写软件的用户)，控制器模块120等来提供和/或更改，这可以包括其任何组合。例如，当将对应的操作实体110更新为新版本时，管理控制器模块120可以改变实体描述符中的版本信息。

在各种实施例中，蓝图210可被部署为产生由该蓝图定义的操作实体110的实例。例如，操作者可以为数据库服务实体110提供蓝图210，该蓝图可以将该数据库服务实体的预期状态定义为具有15个数据库服务器。负责部署该蓝图的控制器模块120可以观察系统100的状态以确定数据库服务实体110是否存在。如果数据库服务实体110不存在，则管理控制器模块120可以根据数据库服务实体110的蓝图210(例如，通过与能够产生15个数据库服务器的特定操作实体110通信)来实例化数据库服务实体110。

在一些实例中，蓝图210可形成层级结构，其中实现顶层蓝图210可涉及实现较低层蓝图210。因此，蓝图210可以包括对其他蓝图210的引用。返回前一示例，数据库服务实体110的蓝图210可包括对数据库服务器实体110的特定实现的蓝图210的引用。这样，当实例化数据库服务实体110时，管理控制器模块120可以经由数据库服务实体110的蓝图210查找数据库服务器实体110的蓝图210，使得它可以使数据库服务器实例化。

在各种实施例中，元件220包括硬件(例如，物理处理器和存储器)，软件(例如，数据库服务器)，信息构造(例如，逻辑数据库)，或其任何组合(例如，元件220可以是操作实体110，该操作实体包括其自己的作为硬件、软件和信息构造的元件220的集合)。元件220的示例包括但不限于物理处理器和存储器、架顶式网络交换机、操作系统，虚拟机、虚拟机镜像、数据库服务器、逻辑数据库、数据库快照、容器、容器镜像、工作流、数据库中心、租户快照和租户。在各种情况下，控制器模块120可经由控制API实现230与元件220连接。

在各种实施例中，控制API实现230是可执行以执行控制API的一个或多个函数的一组软件例程(参考图7更详细地讨论)。控制API实现230可以用作元件220/蓝图210和控制器模块120之间的接口。考虑控制API包括“创建”函数并且存在数据库服务器实体110的示例。该数据库服务器实体110可以包括为该创建函数定义一组创建逻辑数据库实体110的操作的控制API实现230。因此，管理数据库服务器实体110的控制器模块120可以发出创建函数API调用以调用控制API实现230的逻辑来创建逻辑数据库实体110。这种逻辑可以指示数据库服务器(元件220)创建该逻辑数据库实体。在各种实施例中，控制API实现230可在操作实体110之间不同，其中每一操作实体110可唯一地实现由控制API支持的函数中的一者或多者。

在各种实施例中，控制API实现230被实现为封装并隐藏元件220的潜在复杂度的包装。例如，数据库服务器可以包括负责启动和停止数据库服务器的服务或命令行工具，并且控制API实现230可以位于服务的顶部，使得如果控制器模块120调用控制API的转换函数将数据库服务器转换到在线，则控制API实现230可以处理与数据库服务器的服务的通信以启动数据库服务器。启动数据库服务器的复杂性可从控制器模块120隐藏，控制器模块120可仅必须进行适当的控制API调用。

在一些实施例中，操作实体110可以向控制器模块120通告由控制API实现230实现并因此可调用的控制API的函数。在一些情况下，操作实体110可以在实例化之后通告该信息；在其他情况下，该信息可以根据请求由控制器模块120通告。例如，控制器模块120可以向操作实体110发出“描述”函数API调用以接收关于控制API实现230的信息。在一些实施例中，控制器模块120可以被实例化以包括关于控制API实现230的信息，并且可以不必与操作实体110通信以接收这样的信息。

通过了解操作实体110的控制API实现230，控制器模块120可能够处理指令。作为示例，控制器模块120可以接收创建逻辑数据库实体110的指令。控制器模块120可以管理数据库服务器实体110，数据库服务器实体110通告它可以创建逻辑数据库实体110。同样地，控制器模块120然后可以向该数据库服务器实体110发出创建函数API调用以创建逻辑数据库实体110。然而，如果由控制器模块120维护的信息指示由于被管理的操作实体110不支持适当的函数而不能处理指令，则控制器模块120可以拒绝该指令。在一些情况下，控制器模块120可以通知发出控制器模块120指令已经完成或不能完成。

现在转向图3A，示出了数据库130内的蓝图210和定义310的框图。在所示实施例中，蓝图210和定义310都包括实体描述符320、关系信息330和包括期望状态变量345的变量340。在一些实施例中，蓝图210和/或定义310可以与所示不同地实现。例如，如图所示，蓝图210可以对应于比一个定义310更多的定义310。

在各种实施例中，定义310是描述操作实体110的各方面的信息集合。类似于蓝图210，定义310包括实体描述符320、关系信息330和变量340，如图所示。与蓝图210相反，定义310可以不定义操作实体110的特定实例，而是可以描述在对应蓝图210中可以包括什么值。即，定义310可以描述蓝图210应该看起来是什么。例如，数据库舰队实体110的定义310可以将数据库舰队描述为包括数据库服务器实体110，而相应的蓝图210可以将特定数据库舰队实体110定义为包括15个数据库服务器实体110。在各种情况下，定义310可用于确认允许对应的蓝图210。继续前面的例子，如果蓝图210将某个数据库舰队实体110定义为除了15个数据库服务器实体110之外还包括应用程序服务器实体110，则该蓝图210可被拒绝，因为数据库舰队实体110的定义310没有将数据库舰队实体110描述为包括应用程序服务器实体110。在一些实施例中，定义310可以包括一组具有预定值的属性以及当部署蓝图时控制器模块120将该组属性的值写在对应的蓝图210的一组属性，。

在一些实施例中，蓝图210可对应于多个定义310。例如，特定平台服务实体110的蓝图210可将该平台服务实体描述为具有数据库服务器实体110和应用程序服务器实体110。这样，蓝图210可以与数据库服务器实体110的定义310和应用程序服务器实体110的定义310相关联。在各种情况下，如果蓝图210不满足与该蓝图相关联的定义310所指定的所有关系，则蓝图210可能不是有效的。例如，应用程序服务器实体110的定义310可以将应用程序服务器实体110描述为依赖于度量服务器实体110。这样，前一示例的蓝图210可能无效，除非它描述了度量服务器实体110。因此，蓝图210可描述如何将操作实体110集放在一起以满足在对应定义310中定义的关系。

在各种实施例中，实体描述符320是描述相应操作实体110的各种属性的信息的集合。这些属性在所有操作实体110上可以是相同的，但是所给出的值可以在操作实体110之间不同。例如，实体描述符320可以包括指示操作实体110是硬件、软件还是信息的种类属性。因此，处理器实体110的实体描述符320可指示硬件，而度量服务器实体110的实体描述符320可指定软件。在各种实施例中，实体描述符320向控制器模块120传送关于可以如何管理对应的操作实体110的信息。继续前面的例子，控制器模块120可以知道它不能克隆处理器实体110，因为它的实体描述符320为种类属性指定硬件。参考图3B更详细地讨论实体描述符320的各种属性。

在各种实施例中，关系信息330是指定特定操作实体110与其它操作实体110之间的关系的信息集合。操作实体110之间的关系可以使用各种属性来定义，这些属性在所有关系中可以是共同的，但是其值在关系之间可以不同。例如，关系信息330可包括每一关系的“类型”属性。应用程序服务器实体110的关系信息330可以指定应用程序服务器实体110和数据库服务器实体110之间存在“依赖”类型关系。类似于实体描述符320，关系信息330可以向控制器模块120传送关于可以如何管理对应的操作实体110的信息。在各种情况下，操作实体110之间的关系可以影响可以实现操作场景的顺序，其中可以执行对应于该操作场景的命令。继续前面的示例，控制器模块120可以知道数据库服务器实体110应该在应用程序服务器实体110之前被实例化，因为应用程序服务器实体110依赖于该数据库服务器实体110。关于图3C更详细地讨论了关系信息330的各种属性。

在各种实施例中，变量340是对管理相应的操作实体110有用的附加信息的集合。如图所示，变量340包括期望状态变量345。在各种实施例中，期望状态变量345指定对应操作实体110的预期状态。例如，数据库服务器实体110的期望状态变量345可指定值“在线”。变量340可用于指定当前状态，诸如网际协议(IP)端口、IP地址、配置变量等的一个或多个服务端点。例如，变量340可以指定特定数据库服务器实体110应当使用的永久数据存储。在各种实施例中，变量340本质上可以是分层级的。变量340还可包括属性，例如它们是在部署时定义还是在另一时间点定义。例如，IP地址变量340可以与指示在相应操作实体110的部署期间将填充IP地址变量340的属性相关联。

现在转向图3B，描绘了实体描述符320的框图。在所示实施例中，实体描述符320包括通用唯一类型(UUT)321、生命周期322、版本323、种类324、通用唯一标识符(UUI)325、上下文标识符326、供应商327、名称328和创建日期329。实体描述符320可以包括比示出的更多或更少的信息。例如，实体描述符320可以不包括名称328。

在各种实施例中，通用唯一类型321指定指示操作实体110的类型或种类的数据值。UUT 321的示例包括但不限于“数据库服务器”、“应用程序服务器”、“逻辑数据库”、“物理主机系统”、“数据库备份”、“租户”、“工作流”、“日志扩展”和“数据扩展”。在一些实施例中，UUT 321可以用作用于查找对应定义310和/或蓝图210的密钥。例如，关系信息330可以使用其UUT 321来指定关系的操作实体110。这可以允许管理控制器模块120访问对应的定义310和蓝图210以获得与管理那些实体110有关的信息。如关于图8更详细地讨论的，UUT321(在各种情况下，具有生命周期322和版本323)还可用于将指令路由到特定操作实体110。此外，UUT 321可以显示给用户，使得用户可以理解系统100内存在什么操作实体110。

在各种实施例中，生命周期322指定指示操作实体110处于其生命周期内的阶段的数据值。生命周期阶段的示例包括但不限于规范、快照和实例。例如，数据库备份镜像可以是数据库的快照阶段。生命周期322可影响可相对于操作实体110执行的操作的类型。例如，当数据库服务器实体110处于其实例阶段时，控制器模块120能够指示该数据库服务器实体创建数据库备份镜像；然而，如果该数据库服务器实体110处于其规范阶段，则控制器模块120可以不指示该数据库服务器实体创建数据库备份镜像。在各种实施例中，生命周期322可以与UUT 321一起用作用于查找对应定义310和/或蓝图210的密钥。在一些实施例中，生命周期322提供不同生命周期阶段之间的路径，并可用于通过控制API调用将操作实体转换通过状态来将操作实体110的流水线例如从源代码自动化到现场生产软件。

在各种实施例中，版本323指定指示操作实体110的版本的数据值。例如，特定数据库服务器实体110的版本323可以指定版本“3.2.4”。类似于生命周期322，版本323可影响可相对于操作实体110执行的操作的类型。例如，操作实体110的较新版本可包括控制API的一个或多个函数的附加实现。在一些实施例中，版本323可以与UUT 321和生命周期322一起用作用于查找特定定义310和/或蓝图210的密钥。

在各种实施例中，种类324指定指示操作实体110的形式或表现(即，硬件、软件、信息或形式)的数据值。如同实体描述符320的其它属性一样，种类324可影响操作实体110可如何由控制器模块120管理。例如，如果操作实体110采用软件的形式，则它可以是可复制的；然而，采用硬件形式的另一操作实体110可能是不可复制的。在各种实施例中，种类324影响什么值可用于实体描述符320中的其它属性。作为示例，采取软件形式的操作实体110可以具有快照生命周期阶段，但是作为硬件的操作实体110可以不具有快照生命周期阶段。

在各种实施例中，通用唯一标识符(UUID)325指定独立于由蓝图210或定义310指定的任何其他信息唯一地识别操作实体110的数据值。作为示例，特定操作实体110可具有的UUID 325为“C7366F4-4BED-8BF0-BF281”。UUID 325可使特定操作实体110能够被控制器模块120或用户直接引用。这可以消除在控制器模块120管理多个相同类型的操作实体110(例如，两个数据库服务器实体110)的情况下的模糊性。如稍后将更详细讨论的，给定命令可使用其UUID325来具体识别操作实体110。同样地，控制器模块120可以基于由该命令识别的UUID 325将给定命令路由到适当的管理控制器模块120。

在各种实施例中，上下文标识符(CID)326指定指示与操作实体110相关联的上下文的数据值。例如，CID 326可以为与相应的操作实体110相关联的组织/租户指定组织ID。在一些实施例中，CID 326可以用于将操作实体110的度量与系统100的特定租户相关联。

在各种实施例中，供应商327指定识别与操作实体110相关联的供应商的数据值。在各种实施例中，名称328指定识别操作实体110的名称(诸如产品名称、工作流名称、租户名称等)的数据值。在各种实施例中，创建日期329指定识别操作实体110被创建的时间的数据值(例如，自时间UTC(epoch UTC)起的纳秒)。

现在转向图3C，示出了关系信息330的框图。在所示实施例中，关系信息330包括关系331。如进一步示出的，关系331包括UUT 321、生命周期322、版本323、关系类型332、方向333、基数334和属性336。关系331可以包括比所示更多或更少的信息。例如，关系331可以不包括版本323。

在许多情况下，系统100内的操作实体110可以以某种方式相关。作为示例，从另一操作实体110收集度量信息的操作实体110依赖于该另一实体的存在。在各种实施例中，操作实体110由控制器模块120管理的方式依赖于存在于该操作实体与其它操作实体110之间的关系331。如图所示，实体的关系331在关系信息330中定义并包括多个变量。

在各种实施例中，为了识别特定操作实体110与之相关的操作实体110，关系331指定UUT 321、生命周期322和版本323。例如，控制器模块120可以控制数据库服务器实体110。因此，对应于控制器模块120与数据库服务器实体110之间的关系的关系331可以指定“数据库服务器”的UUT 321，“实例”的生命周期322以及“3.21”的版本323。在一些实施例中，关系331可以指示UUID 325，UUID 325具体识别与该关系相关联的操作实体110。

在各种实施例中，关系类型332指定指示特定操作实体110与一个或多个其它操作实体110之间的关系类型的数据值。关系的类型包括但不限于“主管”关系、“控制”关系、“依赖”关系、“由…组成”关、“包含在”关系、“部分”关系和“提供”关系。在各种实施例中，主管关系(host relationship)是特定操作实体110主管一个或多个其它操作实体110的关系。例如，数据库服务器实体110可以主管逻辑数据库实体110。在各种实施例中，控制关系是特定操作实体110控制一个或多个其它操作实体110的关系。作为示例，控制器模块120可以控制度量服务器实体110和数据库服务器实体110。在各种实施例中，依赖关系是特定操作实体110依赖于一个或多个其它操作实体110的关系。作为示例，度量服务器实体110可以依赖于现有的数据库服务器实体110，使得它可以收集度量。在各种实施例中，“由…组成”关系是其中特定操作实体110由一个或多个其它操作实体110组成的关系。例如，数据库服务实体110可以由两个数据库服务器实体110组成。在各种实施例中，“包含在”关系是特定操作实体110包含在一个或多个其它操作实体110中的关系。例如，数据库服务器实体110可以包含在容器实体110中。在各种实施例中，提供关系是识别可由特定操作实体110提供的一个或多个操作实体110的关系。作为示例，容器环境实体110可以提供(或实例化)容器实体110。在一些实施例中，可能存在特定操作实体110描述其自身的“我是”关系。例如，数据库服务器实体110可以具有“数据库服务器”的“我是”关系值。

在各种实施例中，方向333指定指示特定操作实体110与一个或多个其它操作实体110之间的关系的方向的数据值。方向333可指示特定操作实体110是否从属于另一操作实体110。考虑数据库服务器实体110和逻辑数据库实体110之间存在关系的示例。从数据库服务器实体110的角度定义的关系331可以指定“主管”的关系类型332和“错误”的方向333。但是从逻辑数据库实体110的角度定义的关系331可以指定“主管”的关系类型332和“准确”的方向333。对这两个关系331的结果解释可以是，数据库服务器实体110主管逻辑数据库实体110，并且逻辑数据库实体110由数据库服务器实体110主管。作为另一示例，方向333可指示控制器模块120控制数据库服务器实体110(在该控制器的关系信息330中)以及数据库服务器实体110由该控制器模块控制(在该数据库服务器的关系信息330中)。

在各种实施例中，基数334指定指示与对应关系类型332相关联的操作实体110的数目的数据值(其可排除对其定义对应关系331的特定操作实体110)。例如，数据库服务实体110可以由三个数据库服务器实体110组成。结果，基数334可以从数据库服务实体的角度为数据库服务实体110和三个数据库服务器实体110之间的关系331指定值“3”。

在各种实施例中，属性335指定对管理对应的操作实体110有用的附加数据值。属性335可以指定由相关操作实体110用于通信的协议，存在那些操作实体的关系的状态，那些操作实体位于系统100内的位置等。作为示例，属性335可以指示特定关系的操作实体110启动并正在运行。随着系统100内不同关系的状态改变，控制器模块120可更新关系信息330(例如，更新属性335)。

在一些实施例中，以类似于实体描述符320的方式，关系331可以将信息传送到控制器模块120以帮助其理解如何管理操作实体110。考虑度量服务器实体110依赖于数据库服务器实体110的示例。当希望启动度量服务器实体110时，根据度量服务器实体110依赖于数据库服务器实体110，控制器模块120可以确定需要首先启动数据库服务器实体110。因此，控制器可使用关系信息330连同来自定义310和蓝图210的信息来推断关于如何在状态之间(例如，从离线到在线)转换操作实体110。在各种情况下，关系信息330可用于计算系统的资源利用。例如，容器实体110可由主机系统实体110包含，容器实体110因此使用该主机系统的资源的一部分。类似地，包含在容器实体110内的软件使用该容器的资源的一部分。该信息可用于提供和自动化容量规划。

现在转向图3D，示出了示例性操作实体110之间的关系的框图。在所示实施例中，操作实体110A是应用程序服务器实体，操作实体110B是数据库服务器实体，操作实体110C是度量服务器实体。如图所示，操作实体110B依赖于操作实体110A，并且在操作实体110A和110C之间存在互相依赖。如所讨论的，操作实体110之间的关系可以影响控制器模块120如何管理那些操作实体。例如，当实例化操作实体110A-C时，控制器模块120可以在操作实体110B之前实例化操作实体110A，因为操作实体110B依赖于操作实体110A的存在。

现在转向图4，示出了控制器模块120的框图。在所示实施例中，控制器模块120包括操作实体信息410、控制API信息420、操作实体管理器引擎430、工作流引擎440和推理引擎450。在一些实施例中，控制器模块120可以与所示不同地实现。例如，控制器模块120可以不包括推理引擎450。

如前所述，控制器模块120可以管理操作实体110和控制器模块120。为了管理它们，在各种实施例中，控制器模块120维护操作实体信息410和控制API信息420。在一些情况下，控制器模块120可以将信息410和420保存在本地存储装置中；在其他情况下，可以在数据库130处维护信息410和420，这可以使得控制器模块120能够在由于本地存储装置可能不是持久的而崩溃时在停止的地方继续。即，如果控制器模块120发生故障(或者其容器发生故障)，则存储在其本地存储装置中的信息可能随其一起消失。因此，可以在数据库130处维护与控制器模块120的操作实体110的管理有关的任何信息，数据库130可以是非易失性持久存储装置。在其他情况下，控制器模块120可以将信息410和420维护在其本地存储装置和数据库130中。

当被实例化时，在各种实施例中，可以向控制器模块120提供提供初始信息的属性文件。该初始信息可以识别控制器模块120的本地存储装置和/或数据库130的位置，该位置包括与该控制器模块相关的操作实体信息410和控制API信息420。在一些情况下，属性文件可以指示控制器模块120负责管理的操作实体110，并且可以指示针对那些实体110和其他控制器模块120监听的端口。在各种实施例中，控制器模块120使用其属性文件来访问信息410和420。

在各种实施例中，操作实体信息410是描述由控制器模块120管理的操作实体110的信息。信息410可包括受管理的操作实体110的蓝图210和定义310。在各种实施例中，操作实体管理器引擎430使用操作实体信息410来确定其操作实体110的预期状态。利用这种知识，管理器引擎430可将其操作实体110(例如，通过发出控制API调用)向其预期状态转换。在一些实例中，控制器模块120可以被实例化，使得其包括操作实体信息410；在又一些实例中，控制器模块120可向其操作实体110发出控制API调用，以便从其取得信息410(例如，蓝图210)。

在各种实施例中，控制API信息420是指示由控制器模块120管理的操作实体110实现的控制API的函数的信息。如先前所论述，在各种实施例中，操作实体110包括实现控制API的一个或多个函数的控制API实现230。通过控制API实现230，控制器模块120可与操作实体110的元件220连接。因此，控制API信息420可指示由控制API实现230实现的一个或多个函数。在一些情况下，控制器模块120可以被实例化，使得其包括控制API信息420；在一些情况下，控制器模块120可向其管理的操作实体110发出(控制API的)“描述”函数调用，以便从其接收控制API信息420。注意，在各种实施例中，每个操作实体110可以实现“描述”函数调用。

在各种实施例中，控制API信息420包括将关于操作实体110的某些信息映射到操作实体110实现的函数的函数映射。在各种情况下，映射到函数的信息可以包括操作实体的UUT 321和生命周期322。注意，在一些实例中，操作实体110可以包括用于不同生命周期阶段的相同API函数调用的不同实现。如关于图8更详细地讨论的，控制器模块120可以使用操作实体的UUT 321、生命周期322和/或UUID 325来路由命令。

在各种实施例中，操作实体管理器引擎430是可执行以管理操作实体110的一组软件例程。注意，在各种情况下，控制器模块120可以被认为是操作实体110，它可以与定义310和蓝图210相关联。这样，管理器引擎430也可以管理控制器模块120。为了管理操作实体110和控制器模块120，在各种实施例中，管理器引擎430包括各种模块，诸如调度器模块、清扫器模块、健康评估模块和调查器模块。

在各种实施例中，调度器模块是确定何时对由控制器模块120管理的操作实体110做出改变的一组功能。在各种实施例中，调度器模块通过调度要由管理器引擎430的其它组件执行的动作来致使执行动作。调度器模块可以是声明性的(例如，该操作实体110应该处于该预期状态)或强制性的(例如，“创建DB的快照”)。为了调度动作，调度器模块可以将具有调度的时间的所请求的动作(例如，来自用户的命令)写到本地存储装置和/或数据库130。调度器模块还可以将调度的动作的进度和结果写入本地存储装置和/或数据库130。这样的信息可以被写到数据库130，使得如果控制器模块120崩溃，则控制器模块120的新实例可以拾取另一个崩溃的位置。在各种情况下，调度器模块可调度清扫器模块探查操作实体110的时间。

在各种实施例中，清扫器模块是探测正被管理的操作实体110以收集关于那些操作实体的健康的信息(例如，关于资源利用率与容量，主要健康指标等)的一组功能。在一些实施例中，清扫器模块从本地存储装置(可能是永久的)或数据库130读取操作实体信息410。从操作实体信息410，清扫器模块可以了解由其控制器模块120管理的操作实体110以及如何连接到它们。清扫器模块然后可以探测那些操作实体。在一些实施例中，清扫器模块向所列出的操作实体110中的每一个发送状态请求消息，该状态请求消息请求详述该操作实体110的当前状态的信息。代替最初发送状态请求消息的清扫器模块，在一些实施例中，操作实体110可以周期性地向清扫器模块发送信息，该信息指示它们的当前状态。在各种实施例中，清扫器模块存储从操作实体110接收的信息作为操作实体信息410的一部分。这样的信息可以指示资源利用，资源容量，该操作实体110的状态(例如，离线、在线等)，该操作实体与其他操作实体110的关系(例如，其他操作实体110不是响应者)的状态等。该清扫器模块可以存储可能已经被触发为有待调查的“事故”的任何警告。作为示例，如果清扫器模块没有从操作实体110听到，则它可以存储操作实体可能不是健康的指示。可以从本地存储装置和/或数据库130中移除不再在操作上相关的信息(例如，旧的、不相关的记录)。

在各种实施例中，健康评估模块是使用由清理器模块获得的信息来评估被管理的操作实体110的健康的一组功能。在各种实施例中，健康评估模块从本地存储装置或数据库130读取操作实体信息410。健康评估模块然后可以基于操作实体信息410确定是否创建报告以触发调查器模块调查操作实体110。例如，健康评估模块可以评估操作实体110的资源利用，并且如果资源利用相对于其应当的资源利用过高或过低，则健康评估模块可以为该操作实体110创建报告。在各种实施例中，健康评估模块可尝试基于历史操作实体信息410来预测其它事件。例如，如果操作实体110展示遵循以操作实体110失效结束的某一趋势的迹象，那么健康评估模块可创建报告以抢先地调查该操作实体。

在各种实施例中，调查器模块是检查操作实体110的一组功能。调查器模块可以检查尚未调查的报告。对于每个报告，调查器模块可以收集关于相关操作实体110的信息；此类信息可由系统100的其它组件或用户利用以排除任何问题。例如，调查器模块可以收集详细说明由操作实体110在操作实体110故障之前执行的操作的日志信息。在各种情况下，调查器模块可以访问任何不健康的实体的关系信息330。例如，调查器模块可以访问数据库服务器实体110的关系信息330，该数据库服务器实体110不是健康的并且依赖于也可能并不健康的另一服务实体110。数据库服务器实体110并不健康的事实可能仅仅是症状，并且调查的地点可能确实是它所依赖的服务。因此，调查器模块可以使用控制API向下钻入该服务的健康状态，确定它是否引起数据库服务器实体110的问题。在一些实施例中，调查器模块可以尝试对其发现的任何问题进行故障排除。例如，调查器模块可以发出命令集来重启/重新初始化已经崩溃的操作实体110。调查器模块可以在自动调查完成之后更新报告的状态和所有权(例如，如果自动调查未能对问题进行故障排除，则所有权可以被转移给用户。

因此，在各种实施例中，清扫器模块收集关于由其控制器模块120管理的操作实体110的健康信息。健康信息可由健康评估模块评估以确定那些操作实体110是否存在问题。如果存在潜在问题，则可将这些问题报告给调查器模块以供进一步分析。

在一些实施例中，操作实体管理器引擎430可以接收与操作实体110的管理有关的指令(在一些情况下，在管理器引擎430下面的那些指令)。对于与不在管理器引擎430下的操作实体110有关的指令，管理器引擎430可以将指令路由到适当的控制器模块120用于处理。在一些情况下，管理器引擎430可基于包括在那些指令中的信息(例如，对应操作实体110的UUID 325值)来路由指令。例如，管理器引擎430可以基于UUID 325值来确定管理对应于该UUID 325值的操作实体110的特定控制器模块120。因此，管理器引擎430可以将相应的指令路由到该控制器模块120用于处理。

对于属于管理器引擎430的管理下的操作实体110的指令，管理器引擎430可以处理这些指令，这些指令可以包括改变一个或多个操作实体110的状态。在各种情况下，管理器引擎430可访问控制API信息420，以便确定控制API的哪些函数可用于调用。指令可以识别对应的操作实体110以及要针对该操作实体执行的功能。因此，如果操作实体110已实现适当控制API函数(如可从控制API信息420确定)，那么管理器引擎430可向操作实体110发送控制API调用以执行该控制API函数。在一些实例中，管理器引擎430可调用另一操作实体110的控制API函数实现以对原始操作实体110做出改变。在发出控制API调用时，管理器引擎430可执行所接收的指令。

在各种实施例中，工作流引擎440是可执行以实现工作流的一组软件例程。如上所述，可以在包括用于实现该操作场景的一系列步骤的命令集的工作流中描述操作场景。这些命令可以识别要在某些操作实体110上执行的操作(例如，状态改变)。在各种实施例中，工作流引擎440通过向操作实体110和/或控制器模块120发出执行工作流的命令的指令来实现工作流。作为示例，工作流引擎440可以向控制器模块120发出指令以将(由控制器模块120管理的)操作实体110的状态从“离线”改变为“在线”。在各种情况下，工作流引擎440可以从数据库130获得工作流；在一些情况下，工作流引擎440可以从推理引擎450获得工作流。

在各种实施例中，推理引擎450是可执行以基于高层次目标生成工作流的一组软件例程。推理引擎450可以最初从用户接收实现特定高层次目标的请求。例如，用户可以请求将数据库服务器实体110从一个版本升级到另一个版本。在各种实施例中，推理引擎450关于所请求的高层次目标的“原因”以便生成具有实现该目标的命令集的工作流。在一些实例中，推理引擎450的输出(例如，工作流)可被提供给工作流引擎440以经由该输出实现高层次目标。推理引擎450可以极大地减少必须由系统100的开发者编写的特定操作代码的量。关于图17更详细地讨论推理引擎450。

现在转向图5，示出了方法500的流程图。方法500是由计算机系统(例如，系统100)执行的用于管理目标计算机环境(例如，目标环境137)的操作场景(例如，在操作信息135中)的方法的一个实施例。方法500可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些情况下，可以响应于计算机系统接收到来自用户的请求来执行方法500。在一些实施例中，方法500可以包括附加步骤。作为示例，计算机系统可以访问定义(例如，定义310)以验证蓝图(例如，蓝图210)。

方法500开始于步骤510，其中计算机系统访问定义用于操作场景的命令集的操作信息(例如，操作信息135)。该操作场景可以包括改变包括在操作实体集中的一个或多个软件实体的状态以将一个或多个软件实体从第一软件版本转换到第二软件版本。

在步骤520中，计算机系统访问将在目标计算机环境中用于实现操作场景的操作实体集(例如，操作实体110)的蓝图(例如，蓝图210)。对于所述操作实体集中的第一操作实体，给定蓝图可指示第一操作实体与操作实体集中的一个或多个其它操作实体之间的一组关系(例如，关系331)。操作实体集可以包括硬件实体(例如，处理器集)，软件实体(例如，在该处理器集中的至少一个上执行的数据库服务器)，以及信息实体(例如，由数据库服务器管理的逻辑数据库)。

在步骤530，计算机系统实现目标计算机环境的操作场景。在各种情况下，实现操作场景可以包括执行控制器模块(例如，控制器模块120)的层级结构，该层级结构可以包括在层级结构的顶层处的协调器控制器模块，该协调器控制器模块可执行为通过向层级结构的下一层处的控制器模块发出指令来执行命令集。在各种情况下，控制器模块层级结构可包括控制器模块，控制器模块可执行以根据相应蓝图管理该操作实体集，以便完成操作场景，包括通过改变操作实体集中的一个或多个的状态。在一些情况下，操作实体集中的第一操作实体可以与操作实体集中的第二操作实体处于层级结构内的不同层级。因此，可执行以管理操作实体集的控制器模块中的模块可以处于层级结构的不同层级。

在一些实施例中，给定的操作实体实现由控制应用程序编程接口(API)支持的函数集(例如，控制API实现230)中的一个或多个。该一个或多个实现的函数可以允许控制器模块改变给定操作实体的状态。在各种情况下，蓝图中的一个特定蓝图可以与给定操作实体相关联，并且可以指定表示与给定操作实体相关联的当前生命周期阶段(例如，规范阶段)的生命周期值(例如，生命周期值322)。生命周期值可以由控制器模块使用来确定一个或多个实现的函数中的哪一个对于该生命周期阶段是可调用的。

在一些实施例中，给定操作实体与唯一地识别该给定操作实体的唯一标识符(例如，UUID 325的值)相关联。指令中的特定一个可与给定操作实体相关联。在一些实例中，发出特定指令可包括基于唯一标识符来确定控制器模块中管理该给定操作实体的特定一个且将特定指令发出到特定控制器模块。特定指令可以包括使软件实体(例如，数据库服务器)实例化另一个信息实体(例如，逻辑数据库)。

在一些实施例中，为第一操作实体指定的该组关系影响命令集中的命令可以被执行的顺序。在一些情况下，该组关系可以包括第一操作实体与操作实体集中的第二操作实体之间的关系。同样地，执行指令中的特定一个以改变第一操作实体的状态可以包括在改变第一操作实体的状态之前改变第二操作实体的状态。在一些情况下，第一操作实体和第二操作实体之间的关系可以是依赖关系，其中第一操作实体依赖于第二操作实体的存在。

现在转向图6，示出了方法600的流程图。方法600是由计算机系统(例如，系统100)执行的用于管理操作实体集(例如，操作实体110)的方法的一个实施例。方法600可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法600可以包括附加步骤。作为示例，计算机系统可以维护存储操作信息(例如，操作信息135)的数据库(例如，数据库130)。

方法600在步骤610开始，计算机系统执行控制器模块(例如，控制器模块120)的层级结构，该层级结构具有在层级结构的顶层处的协调器控制器模块，该协调器控制器模块可操作来与层级结构中的其它控制器模块通信以管理操作实体集。在各种情况下，操作实体集可以包括硬件实体、软件实体和信息实体。

在步骤620中，协调器控制器模块访问操作信息(例如，操作信息135)，该操作信息指定具有用于实现涉及操作实体集的操作场景的一系列步骤的命令的工作流。

在步骤630中，协调器控制器模块实现工作流的命令以实现操作场景。在一些情况下，实现这些命令可以包括向这些其他控制器模块中的一个或多个发出指令以改变操作实体集中的一个或多个的状态。层级结构内的特定控制器模块可操作以根据定义操作实体集的属性(例如，UUT 321，生命周期322，版本323等)的相应蓝图(例如，蓝图210)来管理操作实体集。在一些实施例中，属性包括关系属性(例如，关系类型332，方向333等)，关系属性定义与操作实体集中的一些操作实体之间的关系(例如，关系331)有关的信息。这些关系可以影响一个或多个操作实体的状态将基于指令而改变的顺序。

在一些情况下，一个或多个其他控制器模块可操作来将从协调器控制器模块接收的一个或多个指令路由到管理操作实体集的特定控制器模块。在一些情况下，一个或多个其他控制器模块可操作以基于与操作实体集相对应的唯一标识符集(例如，UUID 325)来路由一个或多个指令。

现在转向图7，示出了控制API 700的框图。在所示实施例中，控制API 700包括描述函数710、获取函数720、转换函数730、创建函数740、销毁函数750、扰动函数760、验证函数770和分析函数780。在各种实施例中，控制API 700可以包括比所示出的函数更多的函数。例如，控制API 700可包括日志函数，该日志函数使控制器模块120能够取得由操作实体110维护的日志信息。

在各种实施例中，控制API 700是可被调用以从操作实体110访问信息，改变操作实体110的一个方面(例如，将该实体转换到另一状态)，和/或改变由操作实体110管理的另一操作实体110的函数或API调用的集合。控制API 700可包括在系统100中的所有操作实体110上共同的选定函数集，但其功能是针对每一操作实体110个别地界定。例如，控制API实现230A和230B各自可以定义创建函数740以创建操作实体110，但是由控制API实现230A创建的操作实体110的特定类型可以不同于由控制API实现230B创建的特定类型。在各种实施例中，操作实体110可支持相同类型的函数的多个不同实现。作为示例，数据库服务器实体110可以支持创建函数740的两个实现：一个用于创建逻辑数据库实体110，另一个用于创建备份镜像实体110。在一些情况下，操作实体110可能不支持由控制API 700提供的所有函数。例如，可以不为逻辑数据库实体110实现扰动函数760。

在各种实施例中，描述函数710返回关于操作实体110的信息。该信息可以包括操作实体110的蓝图210、定义310和/或关于其控制API实现230的信息。考虑其中控制器模块120希望发现特定操作实体110所依赖的操作实体110的示例。该控制器模块120可以调用该特定操作实体110的描述函数710来接收其蓝图210，该蓝图可以识别该特定操作实体110的关系331。在一些情况下，描述函数710可被调用以确定其他函数(例如，函数720，730等)中的哪些已在操作实体的控制API实现230中实现。因此，在一些实施例中，每个操作实体110定义描述函数710，使得控制器模块120可以具有学习那些操作实体110的有保证的方式。

在各种实施例中，获取函数720获取用于操作实体110的一个或多个变量340。作为示例，控制器模块120可以调用操作实体110的获取函数720来访问指示该操作实体是“在线”还是“离线”的特定变量340。当调用获取函数720时，控制器模块120可将所请求的变量340指定为对获取函数720的输入。在一些情况下，控制器模块120可调用描述函数710以确定可经由其控制API实现230从特定操作实体110请求什么变量340。在一些实施例中，由提取功能720返回的信息可以指示返回变量340的某些属性。这些属性可以包括变量340的名称，它的值，该变量的最小和最大可能值，数据类型(例如，bool，integer，string，float，等等)，信息类型(例如，计数器，速率，等等)，单位类型(例如，秒，千字节，等等)，以及标志(例如，可变的，规范的，等等)。例如，获取函数720可以返回指定变量340的信息，该变量340具有“状态”名称，“在线”值和“可变”标志。

在各种实施例中，转换函数730将操作实体110的一个或多个变量340(或其它信息，例如包括在实体描述符320和/或关系信息330中的值)从第一值转换或改变为第二值。例如，可以调用数据库服务器实体110的转换函数730以将状态变量340从“离线”改变为“在线”。数据库服务器实体110的控制API实现230可以调用使得数据库服务器实体110从离线转换到在线的软件例程。控制API实现230然后可以将状态变量340从“离线”更新为“在线”。控制API实现230可以隐藏将数据库服务器从调用转换函数730的控制器模块120转换到在线状态的潜在复杂度。即，从控制器模块120的角度来看，调用转换函数730可以改变变量340，而控制API实现230可以实际实现由该变量中的改变所表示的改变。同样地，在各种实施例中，转换函数730使控制器模块120能够将操作实体110从第一状态转换到第二状态。

使用转换函数730的其它示例可包括将操作实体110更新为新版本，禁止操作实体110创建其它操作实体110，改变操作实体110的配置规范，关闭操作实体110等。在各种实施例中，实现操作场景可涉及向多个操作实体110发出多个转换函数730调用以改变其状态。

在各种实施例中，创建函数740使操作实体110创建另一操作实体110。例如，数据库服务器实体110可以实现创建函数740以创建逻辑数据库实体110。结果，如果需要，控制器模块120可以调用创建函数740来创建逻辑数据库实体110。在各种实施例中，操作实体110可以控制其它操作实体110，因为它可以对那些操作实体或代表那些操作实体执行动作。在各种情况下，控制另一操作实体110的操作实体110可以具有创建、销毁、列出和/或描述该其它操作实体的能力。在一些情况下，操作实体110可通过克隆与另一操作实体相同的操作实体110来创建另一操作实体110。在一些情况下，操作实体110可以通过沿着其生命周期阶段转移其他操作实体来创建另一操作实体110。例如，通过将数据库持久性从实例阶段转换到快照阶段来创建数据库持久性的快照。在各种实施例中，创建函数740接收源信息作为识别在其上创建新操作实体110的基础(例如，磁盘镜像文件)的输入。

在各种实施例中，销毁函数750销毁/从系统100移除操作实体110。在一些情况下，控制器模块120可以调用特定操作实体110的销毁函数750，以响应于系统100中不再需要该操作实体而销毁该操作实体。例如，当存在高需求业务时创建的数据库服务器实体110可以在存在较少业务时被销毁。在一些情况下，如果操作实体发生故障，则操作实体110的销毁函数750可被调用。然后，控制器模块120可以实例化相同类型的操作实体110中的另一个。

在各种实施例中，扰动函数760通过使操作实体异常运转来扰动操作实体110。例如，特定操作实体110的扰动函数760可以将故障注入该操作实体。这些故障可以包括例如导致特定操作实体110崩溃、挂起或关闭。如关于图24更详细地讨论的，扰动函数760可以通过引起系统100中的问题来帮助测试系统100，以便查看系统100是否可以从那些问题中恢复。

在各种实施例中，验证函数770验证操作实体110的正确性。例如，控制器模块120可调用操作实体110的验证函数770以确定该操作实体的配置和/或环境是否正确(例如，确定配置是否使用适当的值)。在各种实施例中，分析函数780收集操作实体110的度量信息。作为示例，控制器模块120可以调用操作实体110的分析方法以从该操作实体110获得错误日志。

现在转向图8，示出了路由引擎810和可路由实体830的框图。在所示实施例中，控制器模块120包括具有路由引擎810的操作实体管理器引擎430。如进一步示出的，可路由实体830A相对于控制器模块120位于本地(例如，位于相同网络上)，而可路由实体830B相对于控制器模块120位于远程。

如前所述，操作实体110和控制器模块120可以形成在顶层处具有协调器控制器模块120的层级结构。当实现操作场景时，协调器控制器模块120可以通过层级结构向管理操作实体110的控制器模块120发出指令。这种控制器模块120可通过发出控制API调用以调用由那些受管理的操作实体110实现的控制API 700的适当函数来执行所接收的指令。通过调用控制API 700的函数，控制器模块120可改变操作实体110的状态。

可以从各种源接收和/或访问指令。在一些情况下，最初可以从命令行工具接收指令，该命令行工具将(由用户或专设脚本输入的)人类可读命令翻译成控制器模块120所理解的指令。从输入到命令行中的命令导出的指令最初可由协调器控制器模块120接收，该协调器控制器模块120可通过操作实体110和控制器模块120的层级结构传播指令。在各种情况下，可以从存储在数据库130中的工作流信息中导出指令。因此，在被指令(例如，经由命令行工具发出指令)之后，协调器控制器120可从数据库130访问工作流信息，并通过层级结构传播与工作流信息相关联的指令。在一些情况下，工作流信息可包括可由控制器模块120翻译成用于实现这些命令的指令的人类可读命令。

当控制器模块120接收到指令时，控制器模块120可以做出路由决定。如果指令对应于由控制器模块120管理的操作实体110，则控制器模块120可以向该操作实体110发出适当的控制API 700调用。但是如果指令对应于由另一控制器模块120管理的操作实体110，则第一控制器模块120可以将该指令路由到另一控制器模块。为了路由指令和调用控制API700的函数，在各种实施例中，控制器模块120包括路由引擎810。

在各种实施例中，路由引擎810是可执行以路由指令并调用控制API 700的函数的一组软件例程。可以基于包括在这些指令中的信息来路由指令。这样的信息可以包括操作实体110的UUT 321，操作实体110的生命周期322，操作实体110的UUID 325，管理操作实体110的控制器模块120的UUID 325，包括操作实体110和控制器模块120的容器实体110的UUID 325，变量340名称，源和/或可以包括在蓝图210和/或定义310中的其他信息，例如操作实体110的名称328。作为示例，指令可以对应于获取函数720，并且可以指定要获取的变量340名称(例如，“状态”)，要从其获取该变量的操作实体110的UUID 325，以及管理该操作实体并因此应该调用该操作实体的获取函数720的控制器模块120的UUID 325。

在各种实施例中，在接收到指令之后，路由引擎810确定是应该将指令路由到另一控制器模块120还是应该调用控制API 700的某一函数。为了确定该指令是否应该被路由，在一些实施例中，路由引擎810确定该指令是否为控制器模块120指定UUID 325。如果该指令为控制器模块120指定UUID 325，但是指定的UUID 325属于另一个控制器模块120，则路由引擎810可以路由该指令。在一些情况下，如果操作实体110的控制器模块120无权访问该操作实体的控制API实现230，则路由引擎810可确定操作实体110对于其控制器模块120不是本地的。路由引擎810可基于由其控制器模块120维护的本地控制API实现230的映射来做出该确定。在一些情况下，UUID 325加上指令中识别的控制API调用可用作映射中的密钥。如果映射不具有用于此密钥的条目，那么路由引擎810可路由指令。

在一些实例中，路由引擎810可通过将指令放送到其控制器模块120管理的每个控制器模块120来路由该指令。在一些实例中，如果指定的UUID 325属于由路由引擎的控制器模块120管理的控制器模块120，则路由引擎810可以将该指令直接提供给该控制器模块。路由引擎810可使用蓝图210来确定谁管理该指令所针对的操作实体110。指令可以不指定用于控制器模块120的UUID 325；然而，该指令仍可指定操作实体110的UUID 325。同样地，路由引擎810可基于操作实体信息410确定其控制器模块120是否管理该操作实体。如果其控制器模块120不管理该操作实体，则路由引擎810可以向其控制器模块120管理的每个控制器模块120放送该指令。在一些实施例中，路由引擎810通过使用操作实体的UUID 325(或使用诸如UUT 321之类的其它信息)尝试在操作实体信息410中查找操作实体的信息来确定其控制器模块120是否管理操作实体110。在一些实施例中，可以使用路由表，该路由表通告每个控制器模块120的能力以及它们所管理的操作实体110。因此，路由引擎810可以使用该路由表来确定将指令路由到哪里。

如果所接收的指令对应于由路由引擎的控制器模块120管理的操作实体110，则路由引擎810可检查该操作实体是否实现用于处理由指令指示的动作/操作的控制API 700的函数。如先前所论述，在各种实施例中，控制器模块120可在控制API信息420中存储将控制API700的函数映射到操作实体的UUT 321和生命周期322的函数映射。因此，路由引擎810可基于函数映射、UUT 321和生命周期322来构建已由操作实体110实现的控制API 700的函数列表。在指令未指定用于操作实体110的UUT 321和生命周期322的情况下，路由引擎810可使用可在用于该操作实体的指令中指定的UUID 325来查找操作实体的蓝图210。路由引擎810然后可以从所访问的蓝图210中提取UUT321和生命周期322。如果没有找到蓝图210，则路由引擎810可以将错误返回指令的发出者。在各种实施例中，路由引擎810通过选择在函数映射中指示的对应于相关操作实体110的UUT 321和生命周期322的函数来构建函数列表。

在构建实现的函数列表之后，在各种实施例中，路由引擎810确定该列表中是否包括用于实现指令所请求的操作的函数。例如，如果指令识别用于将特定变量340转换到新值的转换操作，则路由引擎810可基于列表确定操作实体110是否实现用于转换该特定变量的转换函数730。如果是，则路由引擎810可调用该转换函数；否则，路由引擎810可以将错误返回指令的发出者。以这种方式，路由引擎810可以处理接收的指令。

当路由指令或调用控制API 700的函数时，路由引擎810可调用路由层820。在各种实施例中，路由层820是一组软件例程、硬件或其组合，其可操作以将指令路由到另一组件(操作实体110或控制器模块120)和/或调用控制API 700的函数。路由层820可从控制器模块120接收向另一特定控制器模块120发送指令或调用由特定操作实体110实现的用于控制API 700的特定函数的请求。因此，该请求可指定指令，控制器模块120的UUID 325，操作实体110的UUID 325和/或函数调用。路由层820可以基于从控制器模块120接收的请求的内容来确定是路由指令还是调用函数。如果请求指定指令，则路由层820可定位适当的控制器模块120(例如，基于UUID 325的网络)并将指令发送到该控制器模块。如果该请求指定了功能，则路由层820可以定位适当的操作实体110(例如，基于UUID 325)并调用由该操作实体实现的功能。

在各种情况下，路由层820可能必须与远程的操作实体110或控制器模块120(例如，与路由引擎810相关联的本地网络之外的操作实体110)通信。如这里所使用的，如果操作实体110或控制器模块120不在同一本地网络内，则操作实体110或控制器模块120被称为“远程”到另一操作实体110或控制器模块120。为了确定操作实体110或控制器模块120是本地的还是远程的，在各种实施例中，路由层820访问与该操作实体或控制器模块相关联的可路由实体830的信息(例如，蓝图210)。

在各种实施例中，可路由实体830是专用操作实体110，其识别另一操作实体110或控制器模块120是否远离路由层820。在一些情况下，可路由实体830可以包括蓝图210或定义310，其指定远程主机端口(例如，作为变量340)。在一些实施例中，如果可路由实体830识别远程主机端口，则路由层820确定相关联的操作实体110或控制器模块120是远程的；否则是本地的。例如，与可路由实体830A相关联的信息(例如，蓝图210)可以指示操作实体110A是本地的，而与可路由实体830B相关联的信息可以指示操作实体110B是远程的。基于该信息，路由层820可以选择适当的通信协议用于与操作实体110或控制器模块120通信。为了访问适当的可路由实体830，在各种实施例中，路由层820访问对应的操作实体110或控制器模块120的关系信息330。关系信息330可以识别对应的操作实体110与相关的可路由实体830之间的关系331。例如，操作实体110可以被“包含”在可路由实体830内。基于此，路由层820可以从本地存储装置和/或数据库130中查找该可路由实体830的蓝图210。

在各种实施例中，控制器模块120不知道操作实体110或控制器模块120是远程的还是本地的。该控制器模块120可以替代地依赖于路由层820来做出该确定。从控制器模块的观点来看，与本地操作实体110和远程操作实体110的通信可以是相同的(其可以看起来好像所有操作实体110都是本地的)。这可以允许将与操作实体110通信的过程简化为一个控制API而不是使用两个不同的控制API。

现在转向图9，示出了方法900的流程图。方法900是由控制器模块(例如，控制器模块120)执行的方法的一个实施例，用于向操作实体(例如，操作实体110)发出指令，作为用于目标计算机环境(例如，目标环境137)的操作场景(例如，操作信息135)的一部分。方法900可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些情况下，方法900可以响应于控制器模块接收来自用户或另一个控制器模块的指令而被执行。在一些实施例中，方法900可以包括附加步骤。例如，控制器模块可以将指令路由到另一个控制器模块用于实现。

方法900开始于步骤910，其中控制器模块执行发现过程。作为发现过程的一部分，在步骤912，控制器模块识别目标计算机环境的层级结构内要由控制器模块控制的组件。控制器模块可以通过访问限定唯一标识符(例如，UUID 325)的操作实体信息(例如，操作实体信息410)来识别层级结构内的组件，该组件对应于层级结构内要由控制器模块控制的组件。在各种情况下，层级可以包括控制器模块和操作实体两者。

作为发现过程的一部分，在步骤914中，控制器模块发现识别的组件的功能能力。给定组件可实现由控制应用程序编程接口(API)(例如，控制API 700)支持的多个函数(例如，函数710，720，730等)中的一个或多个函数。该一个或多个函数可以允许控制器模块改变给定组件的状态。控制器模块可产生映射，映射将操作实体集中的给定操作实体映射到由控制API所支持的多个函数中的给定操作实体实现的函数集。控制器模块可以控制一个特定操作实体以及另一个特定操作实体。在各种情况下，特定操作实体可以实现与其他特定操作实体不同的所述多个函数的集。

在各种实施例中，发现组件的功能能力可以包括通过调用由控制API的特定操作实体实现的描述函数(例如，描述函数710)来发现特定操作实体的功能能力。响应于调用所述描述函数，控制器模块可接收来自特定操作实体的响应，所述响应识别由特定操作实体实现的控制API的多个函数中的函数集。

在步骤920中，控制器模块实现目标计算机环境的操作场景的一部分。该操作场景可以包括将在发现过程期间识别的组件从第一版本更新到第二版本。作为实现操作场景的所述部分的一部分，在步骤922中，控制器模块从控制控制器模块的组件(例如，另一控制器模块120)接收指定特定操作和用于执行特定操作的特定操作实体的指令。

作为实现操作场景的所述部分的一部分，在步骤922中，控制器模块使用识别的组件的特定操作、特定操作实体以及发现功能能力来产生对指令的响应。生成对指令的响应可以包括控制器模块从函数集中识别可调用以使特定操作实体执行特定操作的特定函数。控制器模块可以基于指示生命周期阶段的生命周期值来确定来自函数集的特定函数。在一些情况下，该指令可以定义与特定操作实体相关联的唯一标识符，并且因此控制器模块可以基于唯一标识符来访问对应于特定操作实体的蓝图。蓝图可以指定生命周期值。特定函数可以是转换函数(例如，转换函数730)，该转换函数可调用以将特定操作实体从第一状态转换到第二状态。控制器模块可向特定操作实体发出控制API调用以调用特定函数来执行特定操作。控制器可以进一步向控制特定控制器模块的组件发送指定指示特定操作是否成功执行的结果的消息。

在一些情况下，控制器模块可接收指定另一操作的另一指令以及用于执行所述另一操作的另一操作实体。控制器模块可基于另一指令确定另一操作实体由另一特定控制器模块控制。同样，控制器模块可将其它指令路由到其它特定控制器模块。

现在转向图10，示出了方法1000的流程图。方法1000是由控制器模块(例如，控制器模块120)执行的方法的一个实施例，用于向操作实体(例如，操作实体110)发出指令，作为用于目标计算机环境(例如，目标环境137)的操作场景(例如，操作信息135中)的一部分。方法1000可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1000可以包括附加步骤。例如，控制器模块可以将指令路由到另一个控制器模块用于实现。

方法1000开始于步骤1010，在包括控制器模块和操作实体的层级结构内，控制器模块接收指定要由操作实体执行的操作作为操作场景的一部分的指令。在一些情况下，可从控制控制器模块的层级结构内的另一控制器模块接收指令。

在步骤1020中，控制器模块从控制应用程序编程接口(API)(例如，控制API 700)支持的允许改变给定操作实体的状态的多个函数中发现由操作实体实现的函数集(例如，函数710，720等)。发现函数集可以包括控制器模块从操作实体接收识别由操作实体实现的函数集的放送。

在步骤1030，控制器模块确定函数集是否包括可调用以使操作实体执行操作的函数。

在步骤1040中，响应于确定可调用以使操作实体执行操作的特定函数，控制器模块调用特定函数。该特定函数可以是可调用以使该操作实体被销毁的销毁函数。在各种情况下，控制器模块可以向发送指令的其他控制器模块发送指示指令被成功实现的消息。

现在转向图11，示出了方法1100的流程图。方法1100是由控制器模块(例如，控制器模块120)执行的方法的一个实施例，该方法用于向操作实体(例如，操作实体110)发出指令，作为操作场景(例如，操作信息135中)的一部分。方法1100可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些情况下，方法1100可以响应于控制器模块接收来自用户或另一个控制器模块的指令而被执行。在一些实施例中，方法1100可以包括附加步骤。例如，控制器模块可以与其操作实体通信以确定控制API(例如，控制API700)的哪些函数(例如，函数710，720等)已经由那些操作实体实现。

方法1100在步骤1110开始，其中控制器模块接收识别要从第一状态转换到第二状态的特定操作实体的指令，作为操作场景的自动实现的一部分。控制器模块可以被包括在具有控制器模块和操作实体的组件的层级结构内。在各种情况下，层级结构可以包括在层级结构的顶层处的协调器控制器，该协调器控制器可执行来通过向层级结构的下一层处的控制器模块发出指令来实现该操作场景。因此，指令可以由控制器模块从协调器控制器模块接收，作为实现操作场景的一部分。操作场景可以包括启动数据库服务，该数据库服务具有能够代表执行控制器模块的计算机系统的用户执行数据库事务的一组数据库服务器。

在步骤1120，控制器模块通过呼叫路由层(例如，路由层820)来使得针对特定操作实体执行指令。在一些情况下，呼叫可以不指定特定操作实体是否相对于控制器模块的本地环境是远程的。在各种实施例中，控制器模块独立于特定操作实体是在本地环境内还是远离本地环境而对路由层进行相同的呼叫。该呼叫可以指定由特定操作实体实现的用于执行指令的特定函数。在一些情况下，路由层可以通过调用特定函数来执行路由操作。在一些情况下，可以呼叫路由层以使得路由层调用特定操作实体的特定函数，从而实例化数据库服务器，作为启动数据库服务的一部分。在又一些情况下，路由层可通过将指令路由到管理特定操作实体的另一控制器模块来执行路由操作。

在各种实施例中，路由层可操作以确定特定操作实体是在本地环境内还是远离本地环境。路由层可以使用该确定来执行与特定操作实体相关的路由操作。在一些实施例中，路由层可操作来访问与特定操作实体相关联的可路由实体(例如，可路由实体830)的蓝图(例如，蓝图210)。路由层可以首先访问特定操作实体的蓝图，该蓝图指定特定操作实体与可路由实体之间的关系(例如，关系331)的关系信息(例如，关系信息330)。该关系可以使路由层访问可路由实体的蓝图。

在各种实施例中，路由层基于蓝图是否指定远程主机端口来确定特定操作实体远离本地环境。路由层可基于指示特定操作实体远离本地环境的确定来选择第一路由协议以将指令路由到另一控制器模块。在各种情况下，第一路由协议可以不同于可用于在本地环境内路由指令的第二路由协议。

现在转向图12，示出了方法1200的流程图。方法1200是由计算机系统执行以实现路由层将指令路由到操作实体(例如，操作实体110)作为操作场景(例如，操作信息135中)的一部分的方法的一个实施例。方法1200可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1100可以包括附加步骤。

方法1200在步骤1210开始，其中路由层接收将指令路由到要从第一状态转换到第二状态的特定操作实体的请求。该请求可以不指定特定操作实体是否相对于从其接收请求的控制器模块的本地环境是远程的。

在步骤1220中，路由层基于为特定操作实体维护的信息来确定特定操作实体是在本地环境内还是远离本地环境。该信息可以定义用于特定操作实体的蓝图(例如，蓝图210)。在各种情况下，蓝图可以定义特定操作实体和与第二蓝图相关联的可路由实体之间的关系(例如，关系331)，第二蓝图指示特定操作实体是在本地环境内还是远离本地环境。路由层可以基于该关系来访问该第二蓝图并且基于所访问的指定远程主机端口的第二蓝图来确定特定操作实体是远离本地环境的。

在步骤1230中，路由层基于该确定将指令路由到特定操作实体。作为路由指令的一部分，路由层可以调用由特定操作实体实现的特定函数(例如，转换函数730)，用于将特定操作实体从第一状态转换到第二状态。在一些情况下，作为路由指令的一部分，路由层可将指令发送到从其接收请求的控制器模块相对的控制器的层级结构的下一层内的另一控制器模块。该另一控制器模块可以直接管理特定操作实体。

现在转向图13，示出了方法1300的流程图。方法1300是被执行用于向操作实体(例如，操作实体110)发出指令作为操作场景(例如，操作信息135中)的一部分的方法的一个实施例。方法1300可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1300可以包括附加步骤。作为示例，控制器模块可以在其授权下与操作实体通信以确定控制API(例如，控制API700)的哪些函数(例如，函数710，720等)已经由那些操作实体实现。

方法1300始于步骤1310，其中计算机系统(例如，系统100)执行包括控制器模块和操作实体的组件的层级结构。在各种情况下，层级结构可以包括在层级结构的顶层处的协调器控制器，该协调器控制器可执行来通过向层级结构的下一层处的控制器模块发出指令集来执行操作场景。

在步骤1320中，层级结构的控制器模块接收识别操作实体中要从第一状态转换到第二状态的特定操作实体的指令。

在步骤1330，控制器模块通过呼叫路由层(例如，路由层820)来执行指令。该呼叫可以不指定特定操作实体是否相对于控制器模块的本地环境是远程的。在一些实施例中，独立于特定操作实体是否相对于控制器模块的本地环境是远程的，控制器模块对路由层进行相同的呼叫。

路由层可操作以确定特定操作实体是在本地环境内还是远离本地环境。路由层可使用所述确定来将指令路由到特定操作实体。在各种情况下，路由层可以响应于特定操作实体与远程主机端口相关联而确定特定操作实体远离本地环境。路由层可以利用第一路由协议来将指令路由到远离本地环境的多个操作实体，并且利用不同的第二路由协议来将指令路由到本地环境内的多个操作实体。在一些情况下，路由指令可包括将指令路由到直接管理特定操作实体的层级结构的下一层内的另一控制器模块。

现在转向图14，示出了工作流引擎440的框图。在所示实施例中，工作流引擎440包括工作流处理引擎1420和反转引擎1440。如进一步所示，数据库130包括工作流1410和工作流状态信息1430，它们可被存储在如图所示的操作实体110处。在一些实施例中，工作流引擎440可以与所示不同地实现。例如，工作流引擎440可以包括工作流状态信息1430。

如前所述，可以使用命令集来实现操作场景，命令集对应于执行某个预期目标(例如，最近，将操作实体集110更新为新版本)的一系列步骤。在各种实施例中，工作流1410指定对应于特定操作场景的有序命令集。因此，实现工作流1410的命令集可导致执行相关联的操作场景。在一些情况下，工作流1410可由用户提供并存储在数据库130中；工作流1410也可由如关于图17更详细地讨论的推理引擎450来提供。控制器模块120可以响应于工作流请求1405来访问工作流1410(例如，从数据库130访问)。

在各种实施例中，工作流请求1405是指示工作流引擎440实现指定工作流1410的请求。工作流请求1405可识别允许控制器模块120访问对应工作流1410的名称或标识符。工作流请求1405可经由命令行工具从用户接收和/或从另一控制器模块120接收。例如，协调器控制器120可以从用户接收工作流请求1405。在一些情况下，实现工作流1410可涉及实现其它不同的工作流1410。在一些实施例中，工作流1410可被堆叠以形成工作流的层级结构，其中顶层工作流1410执行高层次任务，而低层工作流1410各自执行该高层次任务的子任务。继续先前的示例，实现在接收的工作流请求1405中指定的特定工作流1410可以涉及协调器控制器120，使得较低层的控制器模块120实现对应于特定工作流1410的一组工作流1410。为了实现给定的工作流1410，在各种实施例中，控制器模块120包括工作流处理引擎1420和反转引擎1440。

在各种实施例中，工作流处理引擎1420是可执行以实现工作流1410中指定的有序命令集的一组软件例程。工作流处理引擎1420可以通过向系统100内的组件发出指令来实现命令集。如前所述，在一些实施例中，命令可以是人类可读格式或可由操作实体110和控制器模块120理解的格式。结果，由工作流处理引擎1420发出的指令可以是实际的对应命令或将该命令翻译成操作实体110和控制器模块120可理解的格式。工作流处理引擎1420可以以先前讨论的方式(例如，通过与路由引擎810交互以呼叫路由层820)发出指令。

在各种实施例中，当实现命令的有序集时，工作流处理引擎1420维护工作流状态信息1430。在各种实施例中，工作流状态信息1430指定工作流1410的实现的当前状态和/或目标环境137的当前状态。例如，工作流状态信息1430可识别已被实现的工作流1410的命令。因此，响应于命令被完成，工作流处理引擎1420可以更新工作流状态信息1430以反映该完成的命令。工作流状态信息1430可通过识别目标环境内的操作实体110和控制器模块120的状态来识别该目标环境137的状态。例如，工作流状态信息1430可以指示哪些操作实体110是“在线的”以及哪些是“离线的”。工作流状态信息1430还可指示工作流是正向运行还是反转运行。如下所述，响应于在实现工作流1410中发生的错误，反转引擎1440可使用工作流状态信息1430来响应该错误。

在各种实施例中，反转引擎1440是可执行以将系统100的状态反转回到工作流1410启动之前存在的初始状态的一组软件例程。在一些情况下，在实现工作流1410时可能发生错误。例如，每当工作流引擎440试图实现命令时，该命令可能无法完成。作为另一示例，工作流引擎440(及其控制器模块120)可能崩溃、挂起或经历另一类型的故障。如果在实现工作流1410时发生错误，则在各种情况下，工作流引擎440可以通过再次实现相应的命令来重新尝试相关步骤。然而，在一些情况下，反转引擎1440可尝试将系统100的状态反转回到与工作流1410相关联的初始状态。

为了使系统100的状态反转，反转引擎1440可以以反向顺序遍历命令集。在各种实施例中，工作流1410中指定的命令集可以正向顺序遍历，以便将目标环境137从初始状态转换到预期状态，并且可以反向顺序遍历以将目标环境137从当前状态(例如，预期状态)转换到初始状态。通过以相反的顺序遍历命令，反转引擎1440可以返回到已知状态，而不是使系统处于中断或未知状态。因此，响应于错误(例如，未完成命令)，反转引擎1440可反转遍历已实现的那些命令，撤销由那些命令引起的一个或多个状态改变。例如，如果特定命令使操作实体110从“离线”转换到“在线”已完成，则反转引擎1440可使操作实体110转换回“离线”(例如，通过调用控制API 700的函数或向管理操作实体110的控制器模块120发出指令)。在一些情况下，工作流命令不能被反转，这可以通过与命令相关的元数据来表示。因此，工作流引擎440可以停止并警告用户该问题。

在各种情况下，在实施工作流1410时，控制器模块120(例如，协调器控制器模块120)可能发生故障(例如，崩溃)。在这种情况下，一旦控制器模块120已经恢复(例如，新的控制器模块120被实例化)，可能需要恢复该工作流1410的实现。因此，在恢复或被恢复时，控制器模块120可尝试访问工作流状态信息1430以确定是否存在工作流1410的正在进行中的实现。如果有一个正在进行中，则控制器模块120可随后恢复工作流1410的实现。在一些情况下，控制器模块120可尝试执行工作流1410中的下一命令；在其他情况下，控制器模块120可以反转已经完成的命令以将目标环境137返回到初始状态。控制器模块120然后可以重新尝试整个工作流1410。

因为控制器模块120可能发生故障，所以在各种实施例中，工作流状态信息1430被存储在控制器模块120外部的位置，使得如果控制器模块120发生故障，工作流状态信息1430不会丢失。状态信息1430是否存储在外部位置还可取决于由控制器模块120管理的实体110是否具有“状态”以及该控制器模块的寿命是否被绑定到该实体。作为示例，如果控制器模块120在与无状态应用相同的容器内，则它可以不在外部存储工作流状态信息1430，而是可以将其存储在本地存储装置中。如果存在导致容器退出的问题，则该实体110和控制器模块120都将被销毁，并且在该情况下工作流的状态将无实际意义。但是，如果正被改变的状态持续在该容器外部，则控制器模块120可将工作流状态信息1430存储在容器外部的位置。如图14所示，工作流状态信息1430可以存储在操作实体110和数据库130处。在一些实施例中，如果控制器模块120管理包括数据库作为元件220的操作实体110，则控制器模块120可利用该数据库来存储工作流状态信息1430。当控制器模块120被启动时，它可以调用它所管理的操作实体110的描述函数710，以便了解这些操作实体。如果操作实体110在存储工作流状态信息1430，则它可将该信息通知控制器模块120。以此方式，控制器模块120可以连同对应的工作流状态信息1430一起了解工作流1410的正在进行中的实现。

现在转向图15，示出了方法1500的流程图。方法1500是由协调器控制器(例如，控制器模块120)执行以在目标计算机环境(例如，目标环境137)上实现工作流的方法的一个实施例。方法1500可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1500可以包括附加步骤。作为示例，协调器控制器模块可以接收执行操作场景的请求(例如，工作流请求1405)。在一些情况下，该请求可以指定与允许访问工作流信息的工作流相对应的名称值。

方法1500在步骤1510开始，其中协调器控制器模块访问工作流信息(例如，工作流信息135)，该工作流信息定义了具有命令集的工作流(例如，工作流1410)，该命令集对应于用于在目标计算机环境上自动实现操作场景的一系列步骤，该目标计算机环境具有初始状态以及包括控制器模块和操作实体的一组组件。在一些情况下，操作场景可包括启动具有能够代表计算机系统的用户执行数据库事务的一个或多个数据库服务器的数据库服务。

在步骤1520中，协调器控制器模块通过向该组组件中的组件发出指令以使得执行一系列步骤来实现工作流的命令集。实现命令集可引起目标计算机环境中相对于初始状态的一个或多个状态改变。在各种实施例中，命令集被定义为使得命令集中的命令可以被实现为将目标计算机环境从初始状态转换到指定的结束状态，并且被反转以将目标计算机环境从当前状态转换回初始状态。目标计算机环境中的一个或多个状态改变可以包括其中该组组件中的特定组件实例化目标计算机环境中的新组件的状态改变。在一些情况下，新组件在目标计算机环境中可具有与特定组件不同的角色。

在步骤1530中，协调器控制器模块维护识别目标计算机环境的当前状态的状态信息(例如，工作流状态信息1430)，该当前状态允许协调器控制器模块响应于在命令集实现中的错误。响应于检测到未能执行一系列步骤中的特定步骤，协调器控制器模块可以通过向该组组件中的一些部件重新发出与该特定步骤相对应的一个或多个指令来重新尝试该特定步骤。在一些情况下，错误可阻止命令集完成。因此，协调器控制器模块可以通过反转目标计算机环境中的一个或多个状态改变以将目标计算机环境返回到初始状态来响应错误。在一些实施例中，使一个或多个状态改变反转包括反向遍历命令集中的命令已经完成的顺序。在执行遍历的同时，协调器控制器模块可以撤销由已经完成的那些命令引起的一个或多个状态改变。

在某些情况下，错误包括在实现命令集时协调器控制器模块崩溃。状态信息可以允许恢复的协调器控制器模块随后恢复命令集的实现。在一些实施例中，由协调器控制器模块在协调器控制器模块外部的位置(例如，数据库130)处维护状态信息，使得协调器控制器模块崩溃不会导致状态信息丢失。状态信息可以由协调器控制器模块在目标计算机环境内的操作实体处维护。

现在转向图16，示出了方法1500的流程图。方法1600是为了在目标计算机环境(例如，目标环境137)上实现工作流而执行的方法的一个实施例。方法1600可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1600可以包括附加步骤。作为示例，协调器控制器模块可以接收执行操作场景的请求(例如，工作流请求1405)。在一些情况下，该请求可以指定与允许访问工作流信息的工作流相对应的名称值。

方法1600始于步骤1610，其中计算机系统执行具有控制器模块和操作实体的组件层级结构。在各种情况下，层级结构可以包括在层级结构的顶层处的协调器控制器，该协调器控制器可执行以通过执行与操作场景的一系列步骤相对应的命令集来实现操作场景。

在步骤1620中，响应于接收到实现用于具有初始状态和层级结构的一组组件的目标计算机环境的特定操作场景的请求，协调器控制器模块实现具有对应于特定操作场景的命令的工作流。

在步骤1622中，作为实现工作流的一部分，协调器控制器模块向层级结构中的一些控制器模块发出指令，以使得工作流的命令被执行，从而相对于初始状态对目标计算机环境做出一个或多个状态改变。在一些情况下，发出指令可以使得层级结构内的特定控制器模块实现不同的第二工作流。工作流和第二工作流可以形成工作流层级结构，该工作流层级包括工作流层级结构的顶层处的工作流和工作流层级结构的下一层处的第二工作流。在一些情况下，特定控制器模块可以通过向相对于包括特定控制器模块的层级的组件层级结构的下一层中的组件发出指令来实现第二工作流。

在步骤1624中，作为实现工作流的一部分，协调器控制器模块维护状态信息(例如，工作流状态信息1430)，该状态信息识别允许对实现工作流中的错误的响应的目标计算机环境的当前状态。在一些情况下，错误可以包括在实现工作流时协调器控制器模块挂起。因此，状态信息可以允许恢复的协调器控制器随后恢复工作流的实现。在一些实施例中，状态信息为包括在目标计算机环境中的该组组件指定配置变量(例如，变量340)。

现在转向图17，描绘了推理引擎450的框图。在所示实施例中，推理引擎450包括直接推理引擎1710和间接推理引擎1720。如图所示，推理引擎450可以向工作流引擎440提供工作流1410以供实现。

在一些实施例中，推理引擎450可以与所示不同地实现。例如，推理引擎450可以在没有工作流引擎440的情况下操作。即，推理引擎450可以生成并实现将系统100移动到预期状态的步骤。这可以涉及推理引擎450评估系统100的状态，发出控制API 700支持的命令，并且然后重新分配系统100的状态直到达到预期状态。例如，推理引擎450可以接收推理请求1705以将应用版本从“A”转换为“X”。因此，推理引擎450可发出将应用程序版本从“A”转换为“X”的转换命令。但如果例如与转换命令相关联的数据库服务器崩溃，则推理引擎450可识别系统100的该新状态。因此，推理引擎450可以生成并发出将数据库服务器的状态从“离线”转换为“在线”的新命令。推理引擎450然后可以重新尝试将应用版本从“A”转换到“X”。以这种方式，推理引擎450可以以与工作流引擎440非常相似的顺序来实现步骤，但是这些步骤可以在运行中或在预先批量地生成。

在各种实施例中，直接推理引擎1710是可执行以生成工作流1410的一组软件例程。如图所示，推理引擎450可以接收推理请求1705。代替指定要实现的工作流1410，推理请求1705可以指定要实现的高层次目标(例如，希望的被管理的系统的状态)或诸如转换版本命令之类的命令。例如，推理请求1705可以指定数据库服务实体110应当被实例化，其包括一个或多个数据库服务器实体110和一个或多个度量服务器实体110。然而，该推理请求也可以不指定用于实例化数据库服务实体110的命令。因此，直接推理引擎1710可应用直接推理概念以生成可被实现以实现高层次目标的工作流1410。在各种情况下，直接推理引擎1710可以使用诸如包含在蓝图210中的关系信息330等信息来识别操作实体110是如何相关的。基于操作实体110是如何相关的，直接推理引擎1710可以确定特定操作实体110应该在其他操作实体110之前被实例化。基于该推理，直接推理引擎1710可以生成命令的有序集。

继续前面的示例，推理请求1705可以为数据库服务实体110指定UUT 321或UUID325。直接推理引擎1710可以使用该信息来访问该数据库服务实体110的蓝图210。该蓝图可以指示数据库服务实体110包括数据库服务器实体110和度量服务器实体110。基于数据库服务实体的蓝图210，直接推理引擎1710可以访问数据库服务器实体110的蓝图210和度量服务器实体110的蓝图210。这些蓝图210可以指示数据库服务器实体110和度量服务器实体110之间的关系331。在一些情况下，关系331可以指示度量服务器实体110依赖于数据库服务器实体的存在，以便度量服务器实体110正确地操作。因此，直接推理引擎1710可以基于该关系确定数据库服务器实体110需要在度量服务器实体110之前被实例化。基于该确定，直接推理引擎1710可以生成包括用于实例化数据库服务器实体110的命令的命令集，其中对命令集排序使得该命令先于用于实例化度量服务器实体110的另一命令出现。

在各种实施例中，间接推理引擎1720是可执行以生成工作流1410的一组软件例程。与直接推理引擎1710相比，间接推理引擎1720可以应用间接推理概念以生成工作流1410。例如，数据库表可能具有大量昂贵的扫描，并且可能的解决方案可能是创建索引。因此，间接推理引擎1720可以确定应该为该数据库表创建索引(例如，通过分析指示索引对于具有昂贵扫描的其他数据库表是有益的信息)。间接推理引擎1720可以生成具有为该数据库表创建索引的命令集的工作流1410。在推理引擎450已生成工作流1410之后，可将工作流1410提供给工作流引擎440以供实现。在一些情况下，工作流1410可被存储(例如，在数据库130处)，使得工作流1410可被取得以再次实现高层次目标而不必重新生成。

现在转向图18，示出了方法1800的流程图。方法1800是由协调器控制器(例如，控制器模块120)执行以在目标计算机环境(例如，目标环境137)上生成并实现工作流(例如，工作流1410)的方法的一个实施例。方法1800可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1800可以包括附加步骤。作为示例，协调器控制器模块可以将所生成的工作流存储在数据库中以允许在不必重新生成工作流的情况下重新实现操作场景。

方法1800开始于步骤1810，其中协调器控制器模块接收实现将目标计算机环境从第一状态转换到不同的第二状态的操作场景的请求(例如，推理请求1705)。目标计算机环境可以具有包括控制器模块和操作实体的一组组件。在各种情况下，接收的请求可以不指定用于将目标计算机环境从第一状态转换到第二状态的命令。该请求可以将要在目标计算机环境中实例化的第一和第二组件识别为操作场景的一部分。操作场景可以包括启动数据库服务，该数据库服务具有能够代表计算机系统的用户执行数据库事务的一组数据库服务器。

在步骤1820，协调器控制器模块生成定义特定命令集以将目标计算机环境从第一状态转换到第二状态的工作流，包括通过改变该组组件中的组件的状态。在各种情况下，协调器控制器模块可以访问与该组组件、第一组件和第二组件相对应的蓝图(例如，蓝图210)。蓝图可以定义影响特定命令集的实现顺序的组件之间的关系。例如，关系可以包括依赖关系，其中第一组件依赖于第二组件的存在，以便第一组件以有效方式操作。这样，特定命令集可以包括实例化第一组件的第一命令以及实例化第二组件的第二命令。特定命令集可以基于依赖关系来排序，使得在实现中第二命令在第一命令之前。

在步骤1830，协调器控制器模块通过向该组组件中的一个或多个控制器模块发出将目标计算机环境转换到第二状态的指令来实现特定命令集。在一些情况下，特定命令集可以被定义为使得特定命令集可以以将目标计算机环境从第一状态转换到第二状态的正向顺序来实现，并且可以以将目标计算机环境转换到第一状态的反向顺序来实现。响应于检测到在实现特定命令集中的错误，协调器控制器模块可以根据反向顺序将目标计算机环境从当前状态转换回第一状态。在一些情况下，改变该组组件中的组件的状态可以包括将操作实体从第一版本更新为第二版本。

现在转向图19，示出了方法1900的流程图。方法1900是为了在目标计算机环境(例如，目标环境137)上生成并实现工作流(例如，工作流1410)而执行的方法的一个实施例。方法1900可以通过执行存储在非暂时性计算机可读介质上的程序指令集来执行。在一些实施例中，方法1900可以包括附加步骤。例如，协调器控制器可以将所生成的工作流存储在数据库中以允许在不必重新生成工作流的情况下重新实现操作场景。

方法1900始于步骤1910，其中计算机系统执行具有控制器模块和操作实体的组件层级结构。层级结构可以包括在层级结构的顶层处的协调器控制器，该协调器控制器可执行以通过执行与操作场景的一系列步骤相对应的命令集来实现操作场景。

在步骤1920中，响应于接收到实现将目标计算机环境从初始状态转换到结束状态的特定操作场景的请求(例如，推理请求1705)，协调器控制器模块生成定义将目标计算机环境从初始状态转换到结束状态的特定命令集的工作流。在各种情况下，请求可能不识别特定命令集。特定运行场景可以涉及创建运行实体。同样地，生成工作流可以包括访问操作实体的蓝图(例如，蓝图210)。在一些情况下，蓝图可以识别除操作实体之外要创建的第二操作实体。因此，协调器控制器模块可以基于操作实体和第二操作实体之间的关系确定创建操作实体和第二操作实体的顺序。可以基于确定的顺序来生成特定命令集。

在步骤1930，协调器控制器模块通过向组件的层级结构中的一个或多个控制器模块发出指令以将目标计算机环境转换到结束状态，包括通过改变层级结构的组件中的组件的状态，来实现特定命令集。

现在转向图20A，描绘了授权服务140的框图。如上所述，确保行动者不能够向系统100发出未授权指令以实现一些不期望的结束是重要的。为了保护系统100，授权服务140可用于审核与系统100连接的行动者所请求的动作。在所示实施例中，授权服务140包括授权引擎2010、授权表2020和测试引擎150，并且可以与包括审核报告2030的数据库130连接。如图20A所示，在一些实施例中，授权服务140是与控制器模块120分离的授权组件，用于审核向控制器模块120和/或操作实体110发出的命令。在其它实施例中，授权服务140可与所示不同地实现。例如，如下面将结合图20B所讨论的，授权服务140可以被集成到控制器模块120(或协调器控制器模块120)中，授权服务140可以不包括测试引擎150等。

在各种实施例中，授权引擎2010是可执行以执行发出命令的审计的指令集。例如，特定用户可能已经向协调器控制器120发出了将特定数据库群集从在线转换为离线的命令。在协调器控制器模块120开始执行该命令之前，授权引擎2010可以确认特定用户(或者控制器模块120，如果它已经发出了该命令的话)是否被授权发出这样的命令。在所示实施例中，授权服务140接收经由授权请求2005发出了什么命令的指示。因此，当控制器模块120从实体(例如，用户，高层次控制器模块120等)接收执行一个或多个动作的命令时，控制器模块120可以发送请求2005以授权执行所接收的命令，并识别关于该命令的各种信息，诸如要执行的动作，命令的发出者，或关于该命令的其他上下文信息。在所示实施例中，授权引擎2010对照授权表2020中定义的安全规则集来评估授权请求2005中所包括的信息，以便验证所发出的命令符合安全规则集所定义的可允许动作。下面将参考图21更详细地讨论授权表2020的一个示例。

作为审计过程的一部分，在各种实施例中，授权引擎2010(或服务140或系统100的其它组件)可认证与授权请求2005相关联的各种实体，这可在接收请求2005之前(或之后)发生。在一些实施例中，这包括认证命令的初始发出者(例如，用户或控制器模块120)。因此，如果用户是发出者，则可以向用户呈现请求用户名和密码的认证提示以确认他或她的身份。在一些实施例中，这包括认证做出授权请求2005的控制器模块120。在一些实施例中，为了实现该认证，可以向操作实体110、控制器模块120和/或认证服务140提供由组件110、120和140维护的用于公用密钥对的证书。组件110、120和140然后可交换这些证书以彼此相互认证并建立安全通信链路。例如，控制器模型120和授权服务140可以在椭圆曲线Diffie-Hellman(ECDH)交换中交换证书，以相互认证和建立用于传输层安全(TLS)会话的共享秘密，通过该共享秘密可以安全地交换授权请求2005和授权响应2015。

在各种实施例中，由授权引擎2010执行的审计还包括在数据库130中维护审核报告2030的日志。因此，当接收到授权请求2005时，授权引擎2010可以在审核报告2030中记录关于请求2005的各种信息。该信息可以包括谁发出诸如用户或组件名称(例如，协调器控制器模块120的标识符值)之类的命令以及谁是诸如控制器模块120或操作实体110的名称或UUID之类的命令目标。该信息可以包括命令所指示的一个或多个动作。该信息可以包括发出命令的时间。该信息可以包括命令来源的指示，例如IP地址，UDP或TCP端口号等。授权引擎2010还可以记录关于对应的授权响应2015的信息，诸如给定请求2005是否被授权或拒绝以及在这样的事件中拒绝的原因。在一些实施例中，数据库130可以限制授权服务140对审核报告2030的访问，使得允许服务140编写审核报告2030而不删除任何报告2030。因此，即使授权服务140被泄露或者服务140的授权管理者试图滥用他或她的访问权限，也可以保留审核报告2030。

基于其对给定请求2005的授权表2020的评估，授权引擎2010可以发出指示所接收的命令是否被授权的相应响应2015。如将在下文中关于图22所讨论的，在一些实施例中，授权引擎2010可在其授权响应2015中包括可由后续组件(例如，控制器模块120和/或操作实体110)使用的签署令牌以确认在所发出的命令中识别的一个或多个动作的执行已被服务140授权。在这样做时，初始控制器模块120(例如，协调器控制器模块120)可以处理与授权服务140的交互以获得令牌，然后可以将该令牌传递给执行这些动作的一个或多个其他组件，这些组件验证对这些动作的批准已经被授权而不必再次联系授权服务140以获得相同的批准的动作。

现在转向图20B，描绘了授权服务140的另一框图。在图20A所示的上述实施例中，授权服务140的组件不同于控制器模块120和/或操作实体110。然而，在一些实施例中，授权服务140的组件可以散布在组件120和/或110之间。例如，如图20B所示，授权引擎2010的实例可以包括在控制器模块120中，以便验证由控制器模块120接收的命令符合由授权表2020内的规则定义的可允许动作。在所示实施例中，授权服务140还包括分配器2040，其维护授权表2020A的主副本，并将授权表2020B的副本分配给授权引擎2010的每个实例，以便于其本地执行的评估。在一些实施例中，授权表2020B的本地副本可仅包含适用于该引擎2010的规则，而不是包含在授权表2020A中的每个规则的完整副本。在各种实施例中，分配器2040还签署授权表2020B的每个副本以保持其完整性。在一些实施例中，授权服务140可以以与所示不同的方式实现。例如，授权引擎2010的每个实例可以负责维护其自己的表2020，而不是从集中式实体接收表2020的副本，授权引擎2010的实例也可以位于操作实体110内，等等。

现在转向图21，描绘了授权表2020的框图。如图所示，授权表2020可以包括规则2100的列表，如上所述，当确定是否批准授权请求2005时，授权引擎2010可以对规则2100的列表进行评估。在所示实施例中，规则2100包括许可2102、对象2104、动作2106和其它参数2108。在其他实施例中，规则2100可以包括用于评估所发出的命令的其他合适的标准。

在各种实施例中，许可2102定义给定规则2100是授予权限还是限制权限。例如，规则2100A的许可指示其对于对象2104John是限制性的，而规则2100B的许可指示其对于对象2104Jan是许可的。

在各种实施例中，主体2104关于给定规则2100识别发出者/请求者(即，发出正被评估的命令的人)。例如，规则2100B和2100C的对象2104指示两个规则2100都属于请求者Jan。因此，当接收到对要发给层级结构中的组件之一的给定命令的请求2005时，授权引擎2010可以验证该命令的请求者是否对应于由对象2104识别的授权请求者。虽然图21中描绘的示例是用户名，但是也可以使用其他形式的标识，诸如IP地址，UUID等。

在各种实施例中，动作2106识别相对于给定规则2100可接受或不可接受的动作。例如，规则2100B和2100C的动作指示允许对象Jan请求动作“创建”和“转换”。在规则2100A的情况下，使用星号来拒绝关于对象2104John的所有动作。因此，当针对给定命令接收到请求2005时，授权引擎2010可以除了验证元件2102和2104之外还验证要由该命令执行的动作是否是授权动作2106之一。

在各种实施例中，参数2108包括与给定动作2106相关联的各种附加标准。例如，规则2100B指定“DB”和“实例”的参数以指示针对“Jan”的动作“创建”限于数据库的实例。参数2108的其它实例可包含时间限制(例如，何时可(或不可)请求动作)，目标限制(例如，识别可(或可不)执行动作的目标的特定UUID)，IP地址限制等。

在各种实施例中，授权服务140提供用户界面，其可以是命令行界面或图形用户界面，以允许安全小组设置各种规则2100。在一些实施例中，安全小组不同于管理系统的潜在用户。规则2100还可以被周期性地签名、下载和验证以确保它们没有被篡改。

现在转向图22，描绘了使用令牌的交换2200的框图。如上所述，在一些实施例中，授权服务140可以发出令牌2200，该令牌2200可由控制器模块120和/或操作实体110使用以确认与所接收的命令相关联的一组动作已经由授权服务140授权。例如，第一控制器模块120A可以接收第一发出命令2210A以创建数据库的多个实例，并且为了实现该命令2210A，意图向处理数据库实例中的相应一个的创建的每个控制器模块120(或操作实体110)发出第二命令2210B。在所示实施例中，控制器模块120A可以发出与接收到的第一命令2210A相对应的授权请求2005。响应于批准请求2005，授权服务140可发送回包括指示创建数据库实例所需的各种动作已被授权的令牌2200的授权响应2015。控制器模块120A然后可将令牌2200包括在向后续控制器模块120和/或操作实体110发出的第二命令2210B集中，该命令集可从令牌2200确定哪些动作已被授权并开始执行它们，而不必为了允许执行这些动作而重新联系授权服务140。

令牌2200可包括便于确认命令2210的执行已被授权服务140授权的任何合适的内容。在所示实施例中，令牌2200包括访问权限2202、时间戳2204和签名2206。在其他实施例中，令牌2200可以包括比所示出的更多(或更少)的组件。在一些实施例中，令牌2200可被实现为JSON web令牌(JWS令牌)，Kerberos令牌，X.509证书或用于签署认证的某种其它标准格式。

在各种实施例中，访问权限2202指示已经被授权服务140批准执行的一组特定动作，并且通常可以包括来自上述规则2100的各种元素。因此，给定权限2202不仅可以识别给定动作2106，还可以指示被允许发出该动作2106的命令的特定对象2104。因此，响应于从控制器模块120A接收到执行特定动作的命令2210B，控制器模块120B可验证控制器模块120A的访问权限2202识别为允许请求特定动作。在一些实施例中，访问权限2202还可以识别被授权执行特定动作的目标，其可以使用IP地址，UUID等来识别。因此，接收令牌2200的控制器模块120B可以确认它在令牌2200中被识别为授权目标以执行在命令2210B中识别的特定动作。

在各种实施例中，包括时间戳2204和签名2206以便于由诸如控制器模块120或操作实体110等后续接收者验证令牌2200。通常，时间戳2204可以是对所发出的令牌2200有效多长时间的某种限制。因此，在一个实施例中，时间戳2204可以是指示何时发出令牌2200的时间值，并且组件120和110可用于仅在时间戳2204之后的某个窗口内接受令牌2200。在另一个实施例中，时间戳2204可以是指示必须执行由访问权限授权的动作的窗口的开始时间和停止时间。在又一实施例中，时间戳2204可指示令牌2200不再有效之后的期满时间值。签名2206一般可用于确保令牌2200的完整性被保留，或者换句话讲，令牌2200未被篡改(或者是伪造的)。因此，在一些实施例中，签名2206通过由授权服务140维护并具有组件120和110已知的相应可信公用密钥的私有密钥根据令牌2200的内容生成。响应于接收到令牌2200，组件110或120可在执行所发出的命令2210B中识别的任何动作之前使用公用密钥针对令牌2200的内容来验证签名2206。

现在转向图23，示出了方法2300的流程图。方法2300是由具有与诸如授权服务140等目标计算环境相关联的授权服务的计算机系统执行的方法的一个实施例。在各种实施例中，方法2300的性能可以提高目标计算环境的安全性。

方法2300在步骤2310开始，其中计算机系统存储安全规则集(例如，授权表2020中包括的规则2100)，该安全规则集定义在组件(例如，操作实体110，控制器模块120等)的层级结构内的用于在目标计算环境内实现操作场景的可允许动作。在步骤2320中，计算机系统在目标计算环境内实现操作场景，其包括向层级结构内的组件发出命令集，并验证命令集符合由安全规则集定义的可允许动作。

在各种实施例中，发出命令集包括：层级结构的第一组件向执行验证的授权服务(例如，授权服务140)发送对特定发出命令的授权请求(例如，授权请求2005)，并且响应于授权服务确定特定命令符合由安全规则集定义的可允许动作，第一组件接收授权执行该命令的响应(例如，授权响应2015)。基于授权响应，第一组件执行在所发出的命令中识别的一个或多个动作。在一些实施例中，验证包括授权服务在发送授权响应之前认证授权请求的源。在一些实施例中，验证包括授权服务将识别授权请求的接收的报告(例如，数据库130中的审核报告2030)存储在日志中。在一些实施例中，接收的授权响应包括指示层级结构中的第二组件被授权执行特定动作的令牌(例如，令牌2200)，并且执行一个或多个动作包括第一组件向第二组件发出包括令牌的命令(例如，第二发出命令2210B)，令牌可由第二组件验证以确认特定动作的执行已被授权。在一些实施例中，令牌识别授权服务的特定动作(例如，访问权限2202中)，第一组件，以及签名(例如，签名2206))。

在各种实施例中，规则集包括识别经授权的请求者(例如，对象2104)和与经授权的请求者相关联的一个或多个经授权的动作(例如，动作2106)的规则，并且验证包括接收要向层级结构中的一个组件发出的命令的指示，验证命令的请求者是否对应于授权的请求者，以及验证要由命令执行的动作是否是授权的动作之一。

在各种实施例中，方法2300还包括层级结构中的第一组件接收向层级结构中的第二组件发出命令的请求，并且验证包括第一组件在第一组件向第二组件发出命令之前验证(例如，使用授权表2020B)所请求的命令符合由安全规则集定义的可允许动作。在一些实施例中，第二组件是可操作以执行所发出的命令的操作实体(例如，操作实体110)。在一些实施例中，第二组件是可操作以使一个或多个操作实体执行所发出的命令的控制器模块(例如，控制器模块120)。

现在转向图24，描绘了测试引擎150的框图。如上所述，执行适当的测试对于确保系统可靠运行是重要的。然而，在许多情况下，可能难以测试系统在其寿命期间可能经历的每个可能状态，特别是当手动执行这种测试时。如下面将讨论的，在各种实施例中，测试引擎150用于通过注入各种故障条件来自动化系统100的测试，以便识别系统100不能正常工作的状态。在所示实施例中，测试引擎150包括扫描引擎2410、预扫描图2420、后扫描图2430和扰动引擎2440。在其它实施例中，测试引擎150可与所示不同地实现。

在各种实施例中，扫描引擎2410处理关于控制器模块120和操作实体110的信息的收集，以便于测试引擎150的操作。在一些实施例中，该收集从执行其中扫描引擎2410试图了解系统100内的各种控制器模块120和操作实体110的发现操作开始。因此，扫描引擎2410可以最初发送请求2412，请求协调器控制器模块120描述其自身并识别其他控制器模块120，其他控制器模块120直接(或者在一些实施例中间接地)与协调器控制器模块120交互。在一些实施例中，协调器控制器模块120可以发送包括图形数据结构的响应2414，图形数据结构识别系统100的控制器模块120和操作实体110以及描述它们的布置。基于该接收的信息，扫描引擎2410然后可以向新发现的控制器模块120和操作实体110发送描述请求2412。这些组件然后可发送对应的描述响应2414，其可包括各种合适信息中的任一种。例如，给定的控制器模块120或操作实体110可以包括其自身的一般描述，其可以包括识别其在系统中的角色并且包括诸如其通用唯一标识符(UUID)，供应商，版本，与其他控制器模块120和/或操作实体110的关系，属性，配置变量等的信息。在一些实施例中，给定的控制器模块120还可以在响应2414中识别其支持的各种应用可编程接口(API)功能。例如，控制器模块120可支持来自扫描引擎2410的API调用以取得关于受控操作实体110的信息，例如获取配置信息、日志、度量、事实等。在各种实施例中，控制器模块120还可以在它们的响应2414中识别支持什么可注入故障条件以及可以由测试引擎150请求什么可注入故障条件。例如，控制多个数据库操作实体110的控制器模块120可以通告它支持终止数据库实例(或终止包括数据库实例的容器)、停止数据库实例的执行、缺乏数据库实例等。

在各种实施例中，扫描引擎2410还收集关于在注入故障条件之前系统100的状态和在注入故障条件之后系统100的状态的各种状态信息。因此，扫描引擎2410可以通过如上所述的请求2412的发出和响应2414的接收来收集该信息。在一些实施例中，控制器模块120还可以向扫描引擎2410提供实时遥测数据。例如，维护数据库实例的控制器模块120可以指示有多少数据库实例当前在操作中，并且当该数目改变时通知扫描引擎2410。如上所述，在一些实施例中，扫描引擎2410可以通过测试引擎150集成到授权服务140中来接收信息。例如，如果控制器模块120已经发出了提供另一数据库实例的命令，则当控制器模块120向授权服务140发送授权请求2005以请求实现该命令的许可时，扫描引擎2410可以获知该发出的命令。在所示实施例中，可以将关于故障条件注入之前的状态收集的元数据组装成预扫描图2420，并且可以将关于故障条件注入之后的状态收集的元数据组装成后扫描图2430。如下文所述，扫描引擎2410(或其它实施例中的测试引擎150的某一其它组件)可比较这些曲线图2420和2430以探知注入的故障条件如何影响系统100。在一些实施例中，为了促进此元数据的组织和图形2420和2430的后续比较，扫描引擎2410将图形2420和2430组装为相应的图形数据结构。因此，预扫描图2420中的每个节点可以对应于系统100内的相应的控制器模块120或操作实体110，并且可以包括在注入之前收集的关于该模块120或实体110的状态的各种元数据。节点之间的边可以对应于存在于控制器模块120和操作实体110之间的关系。后扫描图2430中的每个节点可以被类似地组织并且包括关于给定控制器模块120或操作实体110在注入故障条件之后的状态的元数据。然后，扫描引擎2410可以通过识别在预扫描图2420和后扫描图2430之间已经改变了哪些节点，然后检查改变的节点的内容以确定从注入故障条件产生的具体细节，来确定给定注入故障条件如何影响系统100。

在各种实施例中，扰动引擎2440负责选择用于注入的故障条件并将扰动指令2418发送到适当的控制器模块以引起它们的注入。这些故障条件可对应于可使系统100经历故障的任何合适的条件。例如，在一些实施例中，扰动引擎2440可以发出扰动指令2418以终止、暂停、停止、挂起或结束操作实体110来查看其对系统100的影响。在一些实施例中，扰动引擎2440可以发出扰动指令2418以改变操作实体110可用的资源，从而使实体110缺乏或过载。例如，扰动引擎2440可以改变可用于操作实体110的处理资源，使得操作实体110被指派较低的执行优先级，被较不频繁地调度用于执行，被分配较少处理器用于执行等。扰动引擎2440可以通过给操作实体110分配更少易失性或非易失性的存储、将页面交换到存储器等方式改变其可用的存储资源。扰动引擎2440可通过减少可用于与操作实体110通信的网络带宽，增加与操作实体110通信的等待时间，丢弃与操作实体110的通信，断开操作实体110的网络连接等来改变可用于操作实体110的网络资源。在各种实施例中，扰动引擎2440可以注入故障条件以干扰系统100内的操作实体110的相互依赖性。例如，应用程序服务器(第一操作实体110)可以依赖于存储在数据库服务器(第二操作实体110)中的数据。为了测试应用程序服务器的弹性，扰动引擎2440可破坏数据库中的数据(或仅使数据库崩溃)以确定对应用程序服务器的影响。作为另一实例，两个或多个操作实体110可在锁定步骤中一起工作以实现某一目的，且扰动引擎2440可尝试停止实体110中的一者的操作以确定是否可成功实现死锁。作为另一个示例，操作实体110可以依赖于存储在配置文件中的配置数据，并且扰动引擎2440可以改变(或者甚至破坏)该数据以干扰其操作。扰动引擎2440还可以注入其他真实世界的故障条件，例如引起电源故障，断开刀片服务器，引起网络交换机故障等。如上所述，这些故障条件可以在实际系统运行/运转时(与在系统操作的某些理论模型上操作相反)注入实际系统。

扰动引擎2440可以采用任何合适的选择算法来确定注入什么故障条件。在一些实施例中，扰动引擎2440可以随机地选择故障条件并发出相应的指令2418以将那些故障条件注入。在各种实施例中，可以指示扰动引擎2440以系统100的特定方面(例如特定操作实体110或实体组110)为目标，并且选择与该方面相关联的故障条件。在各种实施例中，扰动引擎2440监测向控制器模块120和/或操作实体110发出的命令，并且基于发出的命令选择用于注入的故障条件。例如，可以指示测试引擎150以针对系统100执行的更新处理为目标。响应于控制器模块120提供关于更新处理已经向其发出了特定命令的指示2416，扰动引擎2440可以选择相应的故障条件并发出适当的扰动指令2418，以便尝试干扰更新处理。选择的故障条件可以例如包括结束在更新处理期间正被更新的操作实体110的执行，诸如使包括正在经历更新的数据库实例的容器崩溃。作为另一示例，选择的故障条件可以包括增加与操作实体110的通信的网络等待时间，该操作实体110在试图引起与更新相关联的故障的更新处理期间正被更新。在一些实施例中，扰动引擎2440可以维护识别先前注入的故障条件的历史信息，并且针对被考虑用于选择的故障条件的每个集合来确定相应的熵得分，该熵得分指示该故障条件相对于如从历史信息确定的先前注入的故障条件有多不同。扰动引擎2440然后可以选择具有指示其与先前选择的最不同(或至少充分不同)的熵得分的故障条件。在一些实施例中，扰动引擎2440可以维护识别在系统100中产生故障的先前注入的故障条件的历史信息，并且可以在尝试校正这些条件之后重新选择这些故障条件，以便确定这些校正是否已经成功。

如上所述，扫描引擎2410(或某一其它组件)可比较来自预扫描图2420和后扫描图2430的元数据，以便更好地了解系统100。在一些情况下，可以执行该比较以确定什么可能受特定注入故障条件影响。这样的确定可以包括扫描引擎2410识别哪些操作实体110直接受注入的故障条件影响，以及识别哪些操作实体110可能由于实体110之间的不可预见的关系而间接受注入的故障条件影响。例如，发出扰动指令2418以使一个操作实体110崩溃可能揭示另一操作实体110崩溃，并且因此可能存在一些未被觉察的依赖性。这种确定还可以用于确定没有操作实体110受注入的故障条件影响(或者至少没有影响到经历故障的点)。例如，扫描引擎2410可以确定将网络连接的带宽减少特定量不会导致使用网络连接的操作实体110的故障。在一些情况下，可执行该比较以确定系统100对故障条件的弹性。例如，可以指示控制器模块120维护操作实体110的特定数目的实例。扰动引擎2440然后可以发出扰动指令2418以终止操作实体110的实例之一，以便确定控制器模块120是否响应于终止而实例化操作实体110的另一个实例。在该示例中，成功的结果可以是，当预扫描图2420和后扫描图2430时没有识别出差异，意味着系统100能够在控制器模块120能够成功地实例化操作实体110的新实例以替换先前被终止的实例之后恢复。

在许多情况下，以这种方式使用测试引擎150可以允许系统100被彻底测试，以便更好地理解系统100的操作。利用从测试引擎150获得的知识，管理员能够更好地识别潜在的弱点并采取纠正措施来解决这些弱点。管理员还可以更有信心地知道，经过良好测试的系统可以在出现不利条件时按照设计运行。此外，测试引擎150可自动且彻底地探索部署在系统100内的任何组件(独立于类型)的故障行为。

现在转向图25，示出了方法2500的流程图。方法2500是由测试诸如包括测试引擎150的计算机系统等目标计算环境的计算机系统执行的方法的一个实施例。在许多情况下，方法2500的性能可用于识别当被校正时改善目标计算环境的弹性的问题。

方法2500始于步骤2510，其中计算机系统在具有包括控制器模块(例如，控制器模块120)和操作实体(例如，操作实体110)的组件层级结构的目标计算环境内实现操作场景。在各种实施例中，该实现包括向目标计算环境内的组件发出命令集。在步骤2520，计算机系统接收已经发出命令集中的特定一个命令的指示(例如，命令指示2416)。在步骤2530中，响应于接收到该指示，计算机系统指示(例如，经由扰动指令2418)控制器模块之一相对于操作实体之一注入故障条件以测试目标计算环境。

在各种实施例中，方法2500还包括计算机系统在注入故障条件之前收集关于目标计算环境的第一状态的元数据(例如，预扫描图2420)，在注入故障条件之后收集关于目标计算环境的第二状态的元数据(例如，预扫描图2430)，以及比较关于第一状态的元数据和关于第二状态的元数据以确定故障条件的影响。在一些实施例中，计算机系统根据收集的关于第一状态的元数据组装第一图形数据结构，根据收集的关于第二状态的元数据组装第二图形数据结构，并且将第一图形数据结构与第二图形数据结构进行比较。在一些实施例中，计算机系统基于接收到的指示确定特定命令与更新处理相关联，以更新层级结构中的一个或多个组件，并选择故障条件以试图干扰更新处理。在一个这样的实施例中，选择的故障条件包括结束在更新处理期间正被更新的操作实体的执行。在一个这样的实施例中，选择的故障条件包括增加与在更新处理期间正被更新的操作实体通信的等待时间。

在各种实施例中，方法2500还包括计算机系统执行发现操作(例如，经由请求2412和响应2414)以识别由控制器模块支持的可注入故障条件集，并且基于特定发出的命令，选择可注入故障条件集中的一个以供指示的控制器模块的注入。在一些实施例中，发现操作包括计算机系统联系层级结构的协调器(例如，协调器控制器模块120)以确定一个或多个控制器模块的身份，协调器是向其他控制器模块发出命令的控制器模块。在一些实施例中，发现操作包括计算机系统基于确定的身份向一个或多个控制器模块发送请求，请求一个或多个控制器模块识别由一个或多个控制器模块支持的可注入故障条件。在一些实施例中，该计算机系统维护识别先前注入的故障条件的历史信息，并且基于该历史信息确定可注入故障条件集中的每一个的相应差异分数，每个差异分数指示该故障条件相对于先前注入的故障条件的差异。在这样的实施例中，进一步基于确定的差值分数来选择用于注入的故障条件。

示例性计算机系统

现在转向图26，描绘了可以实现系统100、操作实体110、控制器模块120、数据库130和/或授权服务140的示例性计算机系统2600的框图。计算机系统2600包括处理器子系统2680，其经由互连2660(例如，系统总线)耦合到系统存储器2620和I/O接口2640。I/O接口2640耦合到一个或多个I/O设备2650。计算机系统2600可以是各种类型的设备中的任一种，包括但不限于服务器系统、个人计算机系统、台式计算机、膝上型或笔记本计算机、大型计算机系统、平板计算机、手持式计算机、工作站、网络计算机、诸如移动电话等消费设备、音乐播放器或个人数据助理(PDA)。尽管为了方便在图26中示出了单个计算机系统2600，但是系统2600也可以被实现为一起操作的两个或多个计算机系统。

处理器子系统2680可以包括一个或多个处理器或处理单元。在计算机系统2600的各种实施例中，处理器子系统2680的多个实例可以耦合到互连2660。在各种实施例中，处理器子系统2680(或2680内的每个处理器单元)可以包含高速缓存或其它形式的板上存储器。

系统存储器2620可使用可由处理器子系统2680执行的存储程序指令来使系统2600执行本文所述的各种操作。系统存储器2620可以使用不同的物理存储介质来实现，例如硬盘存储，软盘存储，可移动磁盘存储，闪存，随机存取存储器(RAM-SRAM、EDO RAM、SDRAM、DDR SDRAM、RAMBUS RAM等)，只读存储器(PROM、EEPROM等)，诸如此类。计算机系统2600中的存储器不限于诸如存储器2620等主存储器。更确切地说，计算机系统2600还可以包括其他形式的存储器，例如处理器子系统2680中的高速缓冲存储器以及I/O设备2650上的辅助存储器(例如，硬盘驱动器，存储阵列等)。在一些实施例中，这些其他形式的存储装置也可以存储可由处理器子系统2680执行的程序指令。在一些实施例中，当被执行时实现操作实体110、控制器模块120、数据库130、授权服务140和/或测试引擎150的程序指令可以被包括/存储在系统存储器2620内。

根据各种实施例，I/O接口2640可以是被配置为耦合到其他设备并与之通信的各种类型的接口中的任何一种。在一个实施例中，I/O接口2640是从前侧到一个或多个后侧总线的桥接芯片(例如，Southbridge)。I/O接口2640可以经由一个或多个相应的总线或其它接口耦合到一个或多个I/O设备2650。I/O设备2650的示例包括存储设备(硬盘驱动器、光驱动器、可移动闪存驱动器、存储阵列、SAN或它们相关联的控制器)，网络接口设备(例如，连接到本地或广域网络)，或其他设备(例如，图形，用户接口设备等)。在一个实施例中，计算机系统2600经由网络接口设备2650(例如，被配置为通过WiFi、蓝牙、以太网等进行通信)耦合到网络。

本申请的对象的实现包括但不限于以下示例1至20。

1.一种方法，包括：

由计算机系统在具有包括控制器模块和操作实体的组件的层级结构的目标计算环境内实现操作场景，其中所述实现包括向所述目标计算环境内的组件发出命令集；

由所述计算机系统接收已发出所述命令集中的特定一个命令的指示；以及

响应于接收到所述指示，由所述计算机系统指示所述控制器模块之一相对于所述操作实体之一注入故障条件以测试所述目标计算环境。

2.根据示例1所述的方法，进一步包括：

由所述计算机系统在注入所述故障条件之前收集关于所述目标计算环境的第一状态的元数据；

由所述计算机系统在注入所述故障条件之后收集关于所述目标计算环境的第二状态的元数据；以及

由所述计算机系统比较关于所述第一状态的元数据和关于所述第二状态的元数据以确定所述故障条件的影响。

3.根据示例2所述的方法，进一步包括：

根据所述收集的关于所述第一状态的元数据组装第一图形数据结构；

根据所述收集的关于所述第二状态的元数据组装第二图形数据结构；以及

其中所述比较包括将所述第一图形数据结构与所述第二图形数据结构进行比较。

4.根据示例1所述的方法，进一步包括：

由所述计算机系统执行发现操作以识别由所述控制器模块支持的可注入故障条件集；以及

基于所述特定发出命令，由所述计算机系统选择所述可注入故障条件集中的一个用于由所述指示的控制器模块进行注入。

5.根据示例4所述的方法，其中所述发现操作包括：

由所述计算机系统联系所述层级结构的协调器以确定一个或多个所述控制器模块的身份，其中所述协调器是向其他控制器模块发出命令的控制器模块。

6.根据示例5所述的方法，其中所述发现操作包括：

基于所述确定的身份由所述计算机系统向所述一个或多个控制器模块发送请求，所述请求要求所述一个或多个控制器模块识别由所述一个或多个控制器模块支持的可注入故障条件。

7.根据示例4所述的方法，进一步包括：

由所述计算机系统维护识别先前注入的故障条件的历史信息；以及

基于所述历史信息，由所述计算机系统确定所述可注入故障条件集中的每一个的相应差异分数，其中每个差异分数指示所述故障条件相对于所述先前注入的故障条件的差异；以及

其中基于所述确定的差值分数来选择用于注入的故障条件。

8.根据示例1所述的方法，进一步包括：

基于所述接收的指示，由所述计算机系统确定所述特定命令与更新处理相关联，以更新所述分层结构中的一个或多个组件；以及

由所述计算机系统选择故障条件以试图干扰所述更新处理。

9.根据示例8所述的方法，其中所述选择的故障条件包括结束在所述更新处理期间正被更新的操作实体的执行。

10.根据示例8所述的方法，其中所述选择的故障条件包括增加与在所述更新处理期间正被更新的操作实体通信的等待时间。

11.一种其上存储有程序指令的非暂时性计算机可读介质，所述程序指令能够使计算机系统执行包括以下各项的操作：

接收关于目标计算环境内的组件的层级结构的信息，其中所述信息包括关于向所述组件中的一些发出实现操作场景的命令集的信息；

基于所述信息，确定所述命令集中的特定命令已经被发出；以及

响应于所述确定，指示所述层级结构中的所述组件中的第一组件相对于所述组件中的第二组件注入故障条件以测试所述目标计算环境。

12.根据示例11所述的计算机可读介质，其中所述操作进一步包括：

在注入所述故障条件之前，扫描所述目标计算环境以确定所述目标计算环境的第一状态；

在注入所述故障条件之前，扫描所述目标计算环境以确定所述目标计算环境的第二状态；和

比较所述第一和第二状态以确定所述目标计算环境的弹性。

13.根据示例12所述的计算机可读介质，其中所述目标计算环境被配置成维护操作实体的特定数目的实例；

其中所述故障条件包括终止所述操作实体的所述实例之一；以及

其中确定所述弹性包括确定所述层级结构的控制器模块是否响应于所述终止而实例化所述操作实体的另一实例。

14.根据示例11所述的计算机可读介质，其中所述第一组件是控制所述第二组件的控制器模块，并且其中所述第二组件是操作实体。

15.根据示例14所述的计算机可读介质，其中所述故障条件包括破坏存储在数据库中并由所述操作实体访问的数据。

16.一种其上存储有程序指令的非暂时性计算机可读介质，所述程序指令能够使计算机系统执行包括以下各项的操作：

向测试引擎提供关于包括在目标计算环境的组件层级结构内的控制器模块的信息，其中所述组件层级结构的组件可操作以响应于发出的命令集来实现所述目标计算环境内的操作场景；

从所述测试引擎接收注入基于正发出的所述命令集中的特定命令而确定的故障条件的指令；以及

由所述控制器模块引起相对于所述组件层级结构的操作实体注入所述故障条件以测试所述目标计算环境。

17.根据示例16所述的计算机可读介质，其中所述操作进一步包括：

在引起所述注入之后，向所述测试引擎提供关于所述控制器模块的附加信息，其中所述附加信息可用于确定所述目标计算环境内的故障条件的影响。

18.根据示例16所述的计算机可读介质，其中所述操作进一步包括：

响应于所述控制器模块接收所述特定命令，向所述测试引擎提供所述特定命令的指示，其中所述指示可由所述测试引擎使用以选择要注入的故障条件。

19.根据示例16所述的计算机可读介质，其中所述故障条件包括减少所述操作实体可用的存储器或处理资源的量。

20.根据示例16所述的计算机可读介质，其中所述故障条件包括减少所述操作实体可用的网络带宽的量。

尽管上面已经描述了特定实施例，但是这些实施例并不旨在限制本发明的范围，即使仅针对特定特征描述了单个实施例。除非另外说明，否则本发明中提供的特征的示例旨在是说明性的而不是限制性的。以上描述旨在涵盖对于受益于本发明的本领域技术人员而言容易理解的此类替代、修改和等效物。

本发明的范围包括在此公开的任何特征或特征的组合(明确地或隐含地)，或其任何概括，无论其是否减轻在此提出的任何或所有问题。因此，在本申请(或要求其优先权的申请)执行任何这样的特征组合期间，可以制定新的权利要求。特别地，参考所附权利要求，来自从属权利要求的特征可以与独立权利要求的特征组合，并且来自各个独立权利要求的特征可以以任何适当的方式组合，而不仅仅是在所附权利要求中列举的特定组合。

Claims (20)

1.一种方法，包括：

由计算机系统在具有包括控制器模块和操作实体的组件的层级结构的目标计算环境内实现操作场景，其中所述实现包括向所述目标计算环境内的组件发出命令集；

由所述计算机系统接收已发出所述命令集中的特定一个命令的指示；以及

响应于接收到所述指示，由所述计算机系统指示所述控制器模块之一相对于所述操作实体之一注入故障条件以测试所述目标计算环境。

2.根据权利要求1所述的方法，进一步包括：

由所述计算机系统在注入所述故障条件之前收集关于所述目标计算环境的第一状态的元数据；

由所述计算机系统在注入所述故障条件之后收集关于所述目标计算环境的第二状态的元数据；以及

由所述计算机系统比较关于所述第一状态的元数据和关于所述第二状态的元数据以确定所述故障条件的影响。

3.根据权利要求2所述的方法，进一步包括：

根据所述收集的关于所述第一状态的元数据组装第一图形数据结构；

根据所述收集的关于所述第二状态的元数据组装第二图形数据结构；以及

其中所述比较包括将所述第一图形数据结构与所述第二图形数据结构进行比较。

4.根据权利要求1至3中任一项所述的方法，进一步包括：

由所述计算机系统执行发现操作以识别由所述控制器模块支持的可注入故障条件集；以及

基于所述特定发出命令，由所述计算机系统选择所述可注入故障条件集中的一个用于由所述指示的控制器模块进行注入。

5.根据权利要求4所述的方法，其中所述发现操作包括：

由所述计算机系统联系所述层级结构的协调器以确定一个或多个所述控制器模块的身份，其中所述协调器是向其他控制器模块发出命令的控制器模块。

6.根据权利要求5所述的方法，其中所述发现操作包括：

基于所述确定的身份由所述计算机系统向所述一个或多个控制器模块发送请求，所述请求要求所述一个或多个控制器模块识别由所述一个或多个控制器模块支持的可注入故障条件。

7.根据权利要求4至6中任一项所述的方法，进一步包括：

由所述计算机系统维护识别先前注入的故障条件的历史信息；以及

基于所述历史信息，由所述计算机系统确定所述可注入故障条件集中的每一个的相应差异分数，其中每个差异分数指示所述故障条件相对于所述先前注入的故障条件的差异；以及

其中基于所述确定的差值分数来选择用于注入的故障条件。

8.根据权利要求1至7中任一项所述的方法，进一步包括：

基于所述接收的指示，由所述计算机系统确定所述特定命令与更新处理相关联，以更新所述分层结构中的一个或多个组件；以及

由所述计算机系统选择故障条件以试图干扰所述更新处理。

9.根据权利要求8所述的方法，其中所述选择的故障条件包括结束在所述更新处理期间正被更新的操作实体的执行。

10.根据权利要求8所述的方法，其中所述选择的故障条件包括增加与在所述更新处理期间正被更新的操作实体通信的等待时间。

11.一种其上存储有程序指令的非暂时性计算机可读介质，所述程序指令能够使计算机系统执行包括以下各项的操作：

接收关于目标计算环境内的组件的层级结构的信息，其中所述信息包括关于向所述组件中的一些发出实现操作场景的命令集的信息；

基于所述信息，确定所述命令集中的特定命令已经被发出；以及

响应于所述确定，指示所述层级结构中的所述组件中的第一组件相对于所述组件中的第二组件注入故障条件以测试所述目标计算环境。

12.根据权利要求11所述的计算机可读介质，其中所述操作进一步包括：

在注入所述故障条件之前，扫描所述目标计算环境以确定所述目标计算环境的第一状态；

在注入所述故障条件之前，扫描所述目标计算环境以确定所述目标计算环境的第二状态；和

比较所述第一和第二状态以确定所述目标计算环境的弹性。

13.根据权利要求12所述的计算机可读介质，其中所述目标计算环境被配置成维护操作实体的特定数目的实例；

其中所述故障条件包括终止所述操作实体的所述实例之一；以及

其中确定所述弹性包括确定所述层级结构的控制器模块是否响应于所述终止而实例化所述操作实体的另一实例。

14.根据权利要求11至13中任一项所述的计算机可读介质，其中所述第一组件是控制所述第二组件的控制器模块，并且其中所述第二组件是操作实体。

15.根据权利要求14所述的计算机可读介质，其中所述故障条件包括破坏存储在数据库中并由所述操作实体访问的数据。

16.一种其上存储有程序指令的非暂时性计算机可读介质，所述程序指令能够使计算机系统执行包括以下各项的操作：

向测试引擎提供关于包括在目标计算环境的组件层级结构内的控制器模块的信息，其中所述组件层级结构的组件可操作以响应于发出的命令集来实现所述目标计算环境内的操作场景；

从所述测试引擎接收注入基于正发出的所述命令集中的特定命令而确定的故障条件的指令；以及

由所述控制器模块引起相对于所述组件层级结构的操作实体注入所述故障条件以测试所述目标计算环境。

17.根据权利要求16的计算机可读介质，其中所述操作进一步包括：

在引起所述注入之后，向所述测试引擎提供关于所述控制器模块的附加信息，其中所述附加信息可用于确定所述目标计算环境内的故障条件的影响。

18.根据权利要求16或17所述的计算机可读介质，其中所述操作进一步包括：

响应于所述控制器模块接收所述特定命令，向所述测试引擎提供所述特定命令的指示，其中所述指示可由所述测试引擎使用以选择要注入的故障条件。

19.根据权利要求16至18中任一项所述的计算机可读介质，其中所述故障条件包括减少所述操作实体可用的存储器或处理资源的量。

20.根据权利要求16至18中任一项所述的计算机可读介质，其中所述故障条件包括减少所述操作实体可用的网络带宽的量。

Images