Component-based risk evaluation techniques using processing flow signatures

Techniques are disclosed relating to component-based risk evaluation using flow signature values. In various embodiments, the disclosed techniques include a server system providing a service usable to provide various computing operations for requesting users, where the server system includes various components with associated component identifier values. In various embodiments, different sequences of the components are usable to perform different ones of the various computing operations. In response to a request from a client device, the server system may perform a requested computing operation via a processing flow that utilizes a particular sequence of components. In various embodiments, the server system generates a particular flow signature value for that particular processing flow, including by generating a flow identifier value by combining component identifier values for the particular sequence of components.

BACKGROUND

Technical Field

This disclosure relates generally to computer system reliability, and more particularly to component-based risk evaluation techniques that utilize processing flow signature values.

Description of the Related Art

A server system may provide various services (e.g., web services) in which the computing resources of the server system perform computing operations on behalf of a requesting entity, such as an end user. A given service may be made up of many individual computing operations that may be performed for an end user. In performing a given one of these computing operations, the server system may use a processing flow that utilizes a combination of many different components. These components may be shared by multiple different processing flows to support the various computing operations. Accordingly, as the server system services a request, the associated processing flow may utilize a combination of many different components to generate the desired result for the user. In some instances, however, this component-based approach may present various technical challenges, particularly as the number of components utilized by the server system increases.

DETAILED DESCRIPTION

A server system may provide various services (e.g., web services) in which the computing resources of the server system (including hardware or software elements of the server system) perform computing operations on behalf of a requesting entity, such as an end user. Non-limiting examples of web services a server system may provide include email services, streaming media services, map-based services, online payment services, retail services, etc.

A given service may be made up of many individual computing operations (also referred to herein as “experiences”) that may be performed for an end user. Consider, as a non-limiting example, an embodiment in which a server system (e.g., implemented using multiple different, geographically diverse datacenters) provides an online payment service to many users (e.g., millions of users). In this example embodiment, the online payment service may allow end users to perform various computing operations, such as creating a user account, adding funding sources, sending and receiving funds to other user accounts, etc.

In performing a given one of these computing operations, the server system may use a processing flow that utilizes a combination of multiple (and, potentially, many) “components.” As used herein, the term “component” refers to a hardware or software element used to perform a portion of the computation used to complete the requested computing operation. Various non-limiting examples of components are described in detail below. In the context of a configuration management system utilized by the server system, a “component,” as used herein, may also be referred to as a “configuration item” (or “CI”), where the configuration management system may use various processes to monitor the status of the individual CI's in use in the system. In this disclosure, the term “processing flow” refers to sequence of components used by the server system to perform a requested computing operation (e.g., transferring funds between user accounts, as one non-limiting example).

A server system may include a large number (e.g., thousands, tens of thousands, etc.) of distinct components. These components may be created by, and shared between, different teams or divisions within the entity operating the server system such that different components are “owned” or managed by different internal entities. In such an embodiment, when designing the processing flows that will be used to perform the computing operations offered, different combinations of components may be selected, used, and shared to support the various computing operations. Accordingly, as the server system services a request, the associated processing flow may utilize a combination of many different components to generate the desired result for the user. Note, however, that there may be changes to any number (e.g., thousands) of these components on a daily basis, for example as part of ongoing software development efforts. Further, in some instances, the number of components used in a given processing flow can be large (e.g., 100, components, 1,000 components, 10,000 components, etc.).

While this component-based approach does facilitate scalability by allowing components to be created, managed, and shared between internal entities and experiences, it also presents various technical problems. For example, the processing flow for a given computing operation may change over time. Consider, as a non-limiting example, a particular component that is used in the processing flow associated with ten different computing operations included in the service provided by the server system. In this example, if there is a change to this particular component, it will affect the ten different processing flows associated with these ten different computing operations. Accordingly, if this change to the particular component negatively impacts the performance of this particular component, the performance of each of these ten different processing flows may also be negatively impacted (or prevented altogether).

Using prior techniques, there is little to no visibility about the underlying components included in a given processing flow, the changes made to those components, the performance of those components, the decommissioning of components, etc. Further, using prior techniques, these components may be treated as a group or “batch” (e.g., tier-1 databases) rather than as individual components. Accordingly, it may be difficult or impossible to determine, for a given computing operation, the identity and status of the underlying components included in the processing flow used to perform that given computing operation. Further, using prior approaches, there is no suitable technique that may be used to quantify the risk (e.g., to the server system, the service(s) it provides, the business it supports, etc.) associated with the constant changes to the components in the system.

In various embodiments, the disclosed techniques address these technical problems by using component-based risk evaluation techniques that use processing flow signature values to monitor and analyze the processing flows—and therefore the components—utilized by the server system. For example, in various embodiments, the disclosed techniques include assigning some or all of the components within a server system with a corresponding component identifier value. In some embodiments, for example, a component identifier value is an immutable name that uniquely identifies a particular component. As a requested computing operation is performed by the server system, these component identifier values may be used to create a flow identifier value indicative of the sequence (that is, the identity and order) of components included in the particular processing flow used, by the server system, to perform the requested computing operation. Stated differently, as different components in the processing flow are used, the identifier values for these different components are logged and combined (e.g., concatenated) to form a flow identifier value that indicates the sequence of components used by the server system to perform a given processing flow. Various embodiments further include creating a processing flow signature value by performing a hash operation on (that is, computing a hash value from) this flow identifier value. In one non-limiting embodiment, the disclosed techniques store a processing flow signature value, optionally along with one or more other items of information, associated with some or all of the processing flows performed by the server system. Non-limiting examples of additional information that may be logged includes: a flow identifier value corresponding to the flow signature value, a timestamp indicating a time at which the processing flow was performed, a counter indicating the number of times that the processing flow with a particular flow signature value was performed within a given time period, etc.

Maintaining these items of information may provide various technical benefits. For example, when a processing flow is completed and a new processing flow signature value generated, that processing flow signature value may be compared to processing flow signature values generated for previous instances of that processing flow. In the event that the new signature value fails to match the previous signature values, the disclosed techniques may determine that there has been a change to one or more of the components included in that processing flow. Once this change has been detected, various embodiments include using the flow identifier values for this processing flow to identify which of the underlying component(s) has changed. Non-limiting examples of changes to the components may include: additions of new components to the processing flow, modification of existing components in the processing flow, and removal or decommissioning of components included in the processing flow. Once the relevant components have been identified (e.g., in a real-time or near real-time manner), further investigation into the nature and extent of the changes to these components can be performed. Accordingly, various disclosed embodiments provide improved visibility into the identity and status of the combination of components included in the various (and, potentially, numerous) processing flows used by the server system. Additional technical benefits provided by various disclosed embodiments are described in more detail below.

Referring now toFIG.1, block diagram100depicts a server system110that includes a set of components112A-112N (or, collectively, components112), a flow prospecting module120, a flow analysis module130, and a data store140. In various embodiments, server system110provides one or more computing resources as part of a service (e.g., a web service) that may be used directly by end users or that may be integrated with (or otherwise used by) services provided by third-parties. As one non-limiting example, server system110, in some embodiments, provides an online payment service that may be used by end users to perform online financial transactions (e.g., sending or receiving funds) or utilized by merchants to receive funds from users during financial transactions. Note, however, that this embodiment is described merely as one non-limiting example. In other embodiments, server system110may provide any of various suitable services, such as an email service, a streaming media service, etc. Additionally note that, in some embodiments, a “server system” (such as server system110) may be implemented using a single machine. In other embodiments, however, a “server system” may be implemented using multiple machines executing (e.g., at one or more datacenters) for the benefit of a single entity. For example, in some embodiments, server system110may be implemented using multiple machines located at one or more geographically remote datacenters.

FIG.1further includes client device102operated by user106. Client device102may be any of various suitable computing devices, such as a smartphone, laptop computer, desktop computer, tablet computer, etc. that user106may use to access the service(s) provided via server system110. For example, in various embodiments, client device102executes a software application104, such as a web browser or a service-specific software application, usable to access one or more computing resources provided by the server system110. In the depicted embodiment, user106uses client device102to send a request160to perform a computing operation via a service provided by server system110. As a non-limiting example, consider an embodiment in which the requested computing operation specified by request160is to check an account balance of a user account of the user106.

In various embodiments, the server system110utilizes different combinations of components112to perform the various computing operations available via the service the server system110provides. For example, to service request160, the server system110implements a processing flow that utilizes a sequence of components112to perform a series of tasks (or “sub-operations”) necessary to complete the requested computing operation. Non-limiting examples of these tasks could include any of various different computational sub-operations, such as user-verification, risk evaluation, data retrieval, routing, load balancing, etc., that need to be completed in order to accomplish the broader computing operation requested by the user. As a simplified example for the purposes of illustration, assume that the processing flow utilized by the server system110uses the following sequence of components112to perform the requested computing operation for request160: component112A,112B,112D,112E, and112N. (Note that, in many embodiments, a processing flow may include a sequence of any number (e.g., hundreds, thousands, etc.) of components112.) Once the processing flow has completed execution (e.g., by successfully performing the requested operation, through an unexpected termination of the processing flow, etc.), the server system110may provide a response162to the client device102.

Non-limiting examples of “components” that may be included in a processing flow include an asset, a container that is running a service, a virtual machine, a third-party library, a physical asset, business logic that is embedded into an application, a Kubernetes cluster, etc. Consider, as a non-limiting example, an instance in which a service (provided by the server system110) runs an API that may be used by requesting entities (e.g., end users, third-party systems, etc.) to send a request to that service. In this example, the service running the API would be considered a “component.” Further, assume that this API has a particular configuration such that it accepts, in a properly formatted API request, a particular set of parameters. This configuration for the API, in various embodiments, will have an associated component identifier value. If that configuration is later changed (e.g., to modify the particular set of attributes included in an API request), that change would result in the assignment of a new identifier value for that component. When the flow signature value (e.g., hash value) for a processing flow that includes this service is later computed, this change to the configuration will result in a change to the signature value. As described herein, that change in signature value may be investigated further to identify the source of this change (the update to the API specification, in the current example).

Various embodiments include utilizing identifier values associated with components in the server system to track which components within the infrastructure of the server system110are in use for the various processing flows. As one non-limiting example, a processing flow may include the sequence of components112(or simply the set of components112that have been assigned a component identifier value) used by the server system110from the ingress point of a request (e.g., a request160from a user106), to a database, through one or more software applications or microservices, to a point of egress at which a response is provided to the user. In various embodiments, the disclosed techniques include generating flow signature values for the processing flows utilized by the server system110to service client requests. In some embodiments, for example, the server system110generates a flow signature value as a hash value based on a concatenation (or other combination) of the identifier values for the sequence of components in the utilized processing flow. By using the component identifier values for each of the components in a processing flow and using these component identifier values to create the flow signature value, the disclosed techniques are capable of modeling the processing flow for a given computing operation. These flow identifier values and flow signature values may be generated and stored over time for many (or all) of the different processing flows used by the server system110, which, in various embodiments, helps to identify any changes in the components112included in a processing flow.

In various embodiments, the disclosed techniques may be said to operate in two complementary (and, optionally, simultaneous) phases: a prospecting phase, and a reconciliation phase. In various embodiments, the reconciliation phase and prospecting phase may be said to operate as state machines within an overall autonomous system. During the prospecting phase, the flow prospecting module120generates flow signature values for the permissible processing flows that are permitted via the server system110. That is, flow prospecting module120generates flow signature values for the sequences of components112that are permitted based on the logic and constraints of the individual components112. In various embodiments, the prospecting operations may be repeated (e.g., on a periodic basis) to generate new and updated flow signature values as components are added to or removed from the server system110. Flow prospecting module120and various embodiments of the prospecting phase are described in detail below with reference toFIG.4.

The prospecting phase may be thought of as a “non-production” phase because, in various embodiments, the prospecting operations are performed independent of the requests being received and serviced by the server system110. The reconciliation phase, by contrast, may be thought of as a “production phase” because, in various embodiments, the reconciliation operations discussed herein are performed based on the instantiated production environment used by server system110to service requests from clients. For example, as a request is serviced, a flow signature value may be created based on the component identifiers for the sequence of components used to service that request. This process of generating flow signature values for the processing flows used by the server system110may be performed for all (or any desired subset) of the requests received by the server system110. Note that, in embodiments in which server system110hosts a large-scale service, server system110may receive many (e.g., millions) requests each day. In various embodiments, flow signature values generated either by the flow prospecting module120during a prospecting operation, or by the server system110while performing computing operations to service requests from requesting users, may be stored as part of flow signature data144in data store140included in (or accessible to) server system110.

In various embodiments, the disclosed techniques include analyzing these flow signature values generated during the reconciliation phase, which may provide various technical benefits—particularly in the context of server systems providing large-scale services used by many users. For example, in various embodiments the disclosed techniques improve the ability to monitor the use of, and detect risks associated with, the various (and often numerous) processing flows and components112utilized by the server system110.

Various embodiments of flow analysis module130and the disclosed flow analysis techniques are described in detail below with reference toFIG.3. In various embodiments, these flow analysis techniques may provide various technical benefits to the server system110. For example, in various embodiments the flow analysis techniques include using the flow signature values to detect changes to the components112included in the processing flows used by server system110. As described below, this may enable the efficient tracking and monitoring of components112utilized in business-critical processing flows such that, when a change is made to one or more components112, this change may be detected in a fast and efficient manner. Further, in various embodiments, the flow analysis operations include tracking the number of times that different processing flows are used during a given time interval, which may be particularly useful for tracking changes in “velocity” with respect to the server system110as a whole and with respect to specific processing flows.

Additionally, in some embodiments, the flow analysis techniques include detecting “unexpected” processing flows performed by the server system110. For example, as explained below, the flow analysis module130may compare the flow signature values generated during the reconciliation phase to the flow signature values generated during the prospecting phase and, if there is not a match, the processing flow associated with that flow signature value may be deemed “unexpected” and flagged for further investigation. By contrast, using prior techniques it may be difficult or impossible to detect when an “unexpected” processing flow has been used by the system. Further, in various embodiments, the flow analysis techniques include identifying a particular component (or components) as a point-of-failure in a processing flow. For example, as described below, in addition to a flow signature value, in various embodiments each processing flow will also have an associated “return code” (e.g., an HTTP status code) indicative of the outcome of the processing flow that may be used to determine whether a requested operation was successfully performed. If not, various embodiments include using the flow signature value (or the underlying flow identifier value) to identify a component that acted as a point-of-failure for the processing flow. This approach to identifying a point-of-failure component may provide significant technical benefits, for example by allowing a malfunctioning component in a processing flow—out of, for example, thousands of possible components—to be identified in a fast and computationally efficient manner.

Referring now toFIG.2, block diagram200depicts an embodiment in which server system110generates a flow signature value220while implementing a processing flow to service a request160for a user106.

As noted above, in various embodiments the server system110utilizes different combinations of components112to perform computing operations provided via the service that it hosts. The various components112used by a particular processing flow may be utilized in a particular sequence so as to perform a series of tasks needed to complete the requested computing operation. As shown inFIG.2, in some embodiments these components112may be referred to as “hops” to signify that a component112in a processing flow is one step of many taken to complete a requested operation.

In various embodiments, each component112in the processing flow assists in creating a flow identifier value for that processing flow. For example, in some embodiments the flow identifier value for a particular processing flow is a combination (e.g., a concatenation) of the components112used in that processing flow in the order in which the respective components112were utilized. For example, in various embodiments, a flow identifier value (e.g., an alphanumeric value) is created by appending the component identifier value (e.g., a unique, immutable name) of each successive component112in the processing flow, and a flow signature value220is created by taking a hash of the flow identifier value. Accordingly, in various embodiments this flow signature value220is specific to the sequence of components112used in the corresponding processing flow, and the same flow signature value220will be generated each time that same processing flow (that is, the exact same sequence of components112) is used by the server system110to service a request.

With reference to the non-limiting example shown inFIG.2, for instance, the depicted processing flow first utilizes component112A. In some embodiments, once component112A completes its task, it may add its unique component identifier value to a flow identifier value for the particular processing flow. In this non-limiting example, the component identifier value for component112A would be the first and only identifier value included in the flow identifier value at this point. In various embodiments, the flow identifier value may be passed (e.g., in an HTTP header field, such as a cookie) from component112to component112in the flow such that each subsequent component112can append their respective identifier value to the end (or beginning, in some implementations) of the running flow identifier value.

In the depicted embodiment, the last hop in the processing flow is component112N. In various embodiments, the final component112in a processing flow may both add its identifier value to the flow identifier value and, once completed, generate a flow signature value220based on the flow identifier value. In various embodiments, the flow signature value220may be a hash value generated by taking a hash of the flow identifier value. As one non-limiting example, in some embodiment the md5 message-digest algorithm may be used to generate a flow signature value220based on the flow identifier value. Note, however, this is merely one non-limiting example and, in other embodiments, any suitable hashing algorithm may be used. Further, in other embodiments, the flow signature value220may be generated using other suitable encoding techniques (e.g., encoding techniques that do not utilize a hash function).

In the depicted embodiment, the flow signature value220is stored, along with a return code230(e.g., an HTTP status code), in flow results210. As an example, for a particular utilization of a processing flow, the flow results210may include a corresponding data record that specifies the flow signature value220and the associated return code230(optionally along with one or more other items of information, e.g., a timestamp, as desired). For example, various embodiments include storing, in flow results210, one or more of the flow identifier value, the processing flow signature value220, the return code230, and a timestamp associated with some or all of the processing flows performed by the server system110for a given period of time (e.g., week, month, year, etc., or indefinitely).

In various embodiments, a flow signature value220and return code230may be stored in flow results210for each (or any desired subset) of the processing flows utilized by the server system110for subsequent analysis. For example, as shown inFIG.2, in various embodiments the flow results210may be accessed and analyzed by the flow analysis module130. Various non-limiting embodiments of flow analysis module130are described in detail below with reference toFIG.3. For the purposes of the present discussion, however, note that flow analysis module130, in various embodiments, is operable to analyze the flow signature value220and return code230and, based on that analysis, generate a flow state determination240. In various embodiments, this flow state determination240may include one or more items of information corresponding to the processing flow, which may be used for various flow analysis techniques described herein, for example to monitor and detect changes in flow velocity, detect unexpected processing flows, and identify point-of-failure components.

Referring now toFIG.3, block diagram300depicts an embodiment of flow analysis module130evaluating flow results210associated with the processing flows used by the server system110to perform requested computing operations. In the depicted embodiment, flow analysis module130is depicted as a state machine that includes state logic310and a set of states320. (Note that, although only 3 states are explicitly depicted inFIG.3for clarity, this is simply one non-limiting embodiment. In other embodiments, flow analysis module130may reach any suitable number of states based on the state logic310.)

In various embodiments, state logic310utilizes flow signature data144(e.g., including the flow signature values generated during the prospecting phase) to analyze the flow signature value220and return code230and generate an appropriate flow state determination240. As a non-limiting example, for each result (e.g., stored as a character string formatted as a “flow signature value220: return code230” value) in flow results210, the state logic310may split the result such that flow signature value220is added to a set “E” (corresponding to “experiences”), the return code230is added to a set “RC,” and a counter associated with that particular flow signature value220and return code230combination is incremented. Further, in some such embodiments the state logic310may then evaluate each of the “experiences” in the set E. For example, as described in more detail below, if the return code230indicates that a requested operation was not successfully completed, the flow analysis module130module may increment a counter associated with that return code230and trigger an event-response workflow. If, however, the return code230indicates that the requested operation was successful, the flow analysis module130may determine whether the flow signature value220matches a flow signature value220generated during prospecting. If so, an appropriate counter may be incremented to track that occurrence. If not, the flow analysis module130may initiate an impact analysis workflow for further investigation. Various non-limiting embodiments of these flow analysis operations are now described in more detail below.

For example, as shown inFIG.3, in various embodiments the flow analysis module130determine an appropriate flow state determination240by determining whether the return code230for the processing flow indicates whether the request was successful or not. In some embodiments, for example, the return codes may be HTTP status codes that indicate whether a requested operation specified by a request (e.g., request160) has been successfully completed. In such embodiments, for example, the 2xx class of status codes (e.g., the 200 OK status code) indicates that the request was successful, while the 5xx class of status codes (e.g., the 500 Internal Server Error status code) indicates that the server was unsuccessful in complete the requested operation.

If the return code230indicates that a processing flow was unsuccessful (indicated by State 3 inFIG.3), the flow analysis module130may generate a flow state determination240C indicating that the requested operation was unsuccessful. In the depicted embodiment, for example, this flow state determination240may be provided to an event response workflow330for further investigation. In various embodiments the flow analysis techniques include identifying a particular component112(or components112) as a point-of-failure in a processing flow. For example, if the return code230indicates that a requested operation was not successful, the flow analysis module130(or another module in server system110) may use the flow signature value220to identify a component112that caused the processing failure. As a non-limiting example, while servicing a request, one of the components112in the processing flow may be malfunctioning, causing the processing flow to fail to complete the requested computing operation. In some such embodiments, the disclosed techniques may stop appending component identifier values to the flow identifier value at a point of failure such that, when a processing flow fails, the disclosed techniques may identify the final component112specified in the flow identifier value as a point of failure for the processing flow. As another non-limiting example, if a particular processing flow for a particular computing operation is intended to include a sequence of 40 different components112and the flow identifier value indicates that the flow stopped at the 15th component-component112M-this component112M may be identified as a potential source of the failure. In various embodiments, this may enable problematic components112to be identified and remedied more quickly than using prior techniques, thereby improving the operation of the server system as a whole.

If, however, the return code230indicates that the requested operation was successfully performed, the flow analysis module130may determine an appropriate flow state determination240by comparing a flow signature value220to the flow signature data144to determine whether the flow signature value220matches a flow signature value220generated during the prospecting operations. If there is such a match (indicated by State 1 inFIG.3), that flow signature value220may be said to be “expected” because it matches a flow signature value for a processing flow that was deemed to be permissible by the flow prospecting module120during prospecting. InFIG.3, for example, in response to determining both that the return code230indicates the requested operation was successful and that the flow signature value220matches a flow signature value previously generated during the prospecting operation, the flow analysis module130may generate a flow state determination240A indicative of this result. As noted above, in various embodiments the flow analysis operations include tracking the number of times that different processing flows are used during a given time interval. For example, inFIG.3, based on a determination that the processing flow was successful (based on return code230) and that the flow signature value220was “expected,” the flow analysis module130increments a counter associated with the flow signature value220that tracks the number of times that flow signature value220was generated during a particular time period.

In various embodiments, the flow analysis module130may be operable to detect “unexpected” processing flows performed by the server system110. For example, if there is not a match between the flow signature value220and any of the flow signature values generated during prospecting (indicated by State 2 inFIG.3), that flow signature value220may be said to be “unexpected” because it does not match a flow signature value for a processing flow that was deemed to be permissible by the flow prospecting module120during prospecting. InFIG.3, for example, in response to determining that the return code230indicates the requested operation was successful and that the flow signature value220does not match a flow signature value220previously generated during the prospecting operation, the flow analysis module130may generate a flow state determination240B indicative of this result. In the depicted embodiment, for example, this flow state determination240may be provided to an experience impact analysis325for further investigation. For example, this unexpected processing flow could correspond to a malicious operation that was successfully performed via the server system110, or the unexpected processing flow could simply correspond to a computing operation that was not yet discovered during the prospecting phase. By autonomously identifying and flagging these processing flows for further investigation, the disclosed techniques enable for the fast and computationally efficient resolution of potential problems as those problems arise. Further note that, in various embodiments, the flow analysis operations also include tracking the number of times that “unexpected” processing flows are detected. For example, inFIG.3, the flow analysis module130increments a counter associated with the “unexpected” flow signature value220to track the number of times that this flow signature value220was generated during a particular time period.

Information about an occurrence of the flow signature value220, including the flow signature value220, the return code230, a timestamp, the counter, etc., may be stored as part of flow signature data144. Such information may be particularly useful, for example, in detecting changes in velocity associated with various processing flows (both “expected” and “unexpected”) utilized in the server system110over time. For example, in some embodiments, the flow analysis module130may track the number of times a particular processing flow is used, by the server system110, during successive time intervals and identify changes in that processing flow's use over time. This information may be valuable on its own, providing the organization operating the server system110with insight regarding how frequently the different processing flows are used and how that use changes over time.

Further, in some embodiments, the flow signature values220or velocity information may be used to detect changes in processing flows or the respective components112included therein. For example, in some embodiments, the components112included in a given processing flow may change and, when this change occurs, there will be a resulting change in the flow signature value220for that processing flow. By monitoring the flow signature values220, the disclosed techniques facilitate the detection of changes in processing flows (e.g., components added to the flow, components removed from the flow, changes in the sequence of components in the flow, changes to the configuration of components in the flow, or any combination thereof). Accordingly, once a change in the flow signature value220has been detected, one may determine that there has been a change in the underlying processing flow, which may be investigated further. In various embodiments, detecting and identifying changes in a processing flow based on a change in its signature value is both less error-prone and less computationally demanding than other available techniques (e.g., comparing the list of component identifiers for the components included in the processing flow).

In some embodiments, the server system110may maintain (or have access to) a list (implemented using any suitable data structure or collection) that maps a component identifier value to a corresponding component112. For example, this operation may be performed by component system of record402described below with reference toFIG.4. In various embodiments, once it has been determined that there has been a change to the processing flow (based on a change in the associated flow signature value220), various embodiments include determining which of the component(s)112in that processing flow have changed. For example, in some embodiments, this determining includes comparing the flow identifier value (e.g., the set of concatenated component identifier values) for the current instance of the processing flow to the flow identifier value for a previous instance (e.g., the most-recent previous instance) of the processing flow to determine how these values differ. Once the changed component(s)112have been identified, the extent of those changes may be investigated. For example, a change management system may be consulted to determine what changes were made to a given component112in the flow.

Various embodiments further allow the entity operating the server system110to define thresholds used to determine whether a change is significant enough to warrant further investigation or action (that is, if the risk posed by this change is deemed “acceptable”). For example, in some embodiments, certain important or business-critical components112or processing flows may be flagged (e.g., within the data structure providing the mapping of component identifier value to corresponding component112) such that, when a change is detected in these processing flows or components112, an indication of this change may be generated.

Note that, although only three states320are explicitly shown inFIG.3, this non-limiting embodiment is depicted merely as an example and, in other embodiments, state logic310may reach one or more additional states based on the analysis of the flow signature values220and return codes230. For example, in some embodiments one or more additional states320may leverage volumetric differences between the active cycle (e.g., a current time period) and results from one or more previous cycles (e.g., flow signature values220and return codes230generated during previous time periods or during prospecting). As a non-limiting example, in some embodiments the flow analysis operations may detect changes in velocity associated with one or more processing flows, where “velocity” refers to the number of times a processing flow is utilized by the server system110during a given cycle. Note that, in various embodiments, these other states320(e.g., states beyond the three depicted inFIG.3) may add determination for reoccurrence, flapping states, and anomalous availability or security results of the flow signature values220.

Further note that, although the flow analysis module130is shown as part of the reconciliation phase in the production environment, this depicted embodiment is provided as merely one non-limiting example. In other embodiments, some or all of the flow analysis operations described herein may be performed in a non-production environment (e.g., as part of the prospecting phase).

Referring now toFIG.4, block diagram400depicts a flow prospecting module120during a prospecting phase, according to some embodiments. In various embodiments, the flow prospecting module120generates flow signature values220for the permissible processing flows that are permitted via the server system110.

In the embodiment depicted inFIG.4, block diagram400includes a component system of record402, which, in various embodiments, is a data management system that acts as an authoritative source for data relating to the components112utilized by the server system110. In various embodiments, through continued development efforts within an organization (e.g., by various software development or business teams within a company), both logical and IT components112may be added to the server system110. InFIG.4, for example, business users404within the organization may develop logical components112and IT users406within the company may develop IT components112. As these components112are created and on-boarded, unique, immutable component identifier values410for the components112may be added to the component system of record402. That is, in various embodiments, as a component112is added to the server system110, a unique, immutable component identifier410B may be added to the component system of record402for that component112.

In various embodiments, the flow prospecting module120is operable to compute flow signature values for the processing flows that are permitted, using different combinations of the components112, via the server system110. That is, in various embodiments the flow prospecting module120is a software agent that computes flow signature values220for any possible flow that is allowed by the configuration deployed by the users204or206of the organization operating the server system110. For example, in some embodiments the flow prospecting module120takes the configuration information provided by the human users204or206and applies automation to identify every permitted sequence of components112, generating a flow signature value220for each such sequence. In various embodiments, each flow signature value may be said to represent a corresponding itemized capability of the server system110and the sum of all of its constituent components112in sequential order.

In various embodiments, this process may be autonomously repeated such that, as the component system of record402is updated, new corresponding flow signature values220are created. That is, in various embodiments the flow prospecting module120is constantly running and generating a (potentially very large) list of flow signature values220(e.g., as hash values) indicative of the permissible processing flows that are possible via the components112in the server system110. In some embodiments, these flow signature values220may be stored in tables (or in any other suitable data-storage format) and may be used, for example, by the flow analysis module130, for example as described above with reference toFIG.3.

As shown inFIG.4, in various embodiments the prospecting phase receives feedback from the flow analysis module130. In various embodiments, the flow analysis module130provides the flow state determinations240for subsequent use in the prospecting phase or for use in subsequent flow analysis operations. For example, in various embodiments the flow signature data144may be used to store counter information associated with the different flow signature values220for expected processing flows. Further, as depicted inFIG.4, information relating to “unexpected” processing flows may be utilized by the system. For example, inFIG.4, flow state determination240B corresponding to an “unexpected” processing flow may be provided to a remediation or certification workflow420for further analysis. In some embodiments, the output of this remediation or certification workflow420may be utilized, for example, by business users404to revise aspects of one or more components112(e.g., logical components) used by the server system110.

Example Methods

Referring now toFIG.5, a flow diagram illustrating an example method500for performing component-based risk evaluation using processing flow signatures is depicted, according to some embodiments. In various embodiments, method500may be performed by server system110ofFIG.1to generate a flow signature value220based on a sequence of components112used, by the server system110, to perform a requested computing operation. For example, server system110may include (or have access to) a non-transitory, computer-readable medium having program instructions stored thereon that are executable by the server system110(e.g., by one or more computer systems included in the server system110) to cause the operations described with reference toFIG.5. InFIG.5, method500includes elements502-512. While these elements are shown in a particular order for ease of understanding, other orders may be used. In various embodiments, some of the method elements may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired.

At502, in the illustrated embodiment, the server system110provides a service that is usable to perform various computing operations for requesting users106. As described above, in various embodiments the server system110includes a set of (potentially numerous) components112that have corresponding unique component identifier values. In various embodiments, different combinations of the components112are usable to perform the various computing operations included in the service hosted by server system110.

At504, in the illustrated embodiment, the server system110receives, from a client device102, a request to perform a particular computing operation. As a non-limiting example in embodiments in which the server system110hosts an online payment service, the requested computing operation may be to transfer funds from one user account to another. At506, in the illustrated embodiment, the server system110performs the particular computing operation via a particular processing flow. In various embodiments, the processing flow includes a particular sequence of components112performing a series of tasks that are associated with the particular computing operation.

At508, in the illustrated embodiment, the server system110generates a particular flow signature value220for the particular processing flow. InFIG.5, element508includes sub-elements510-512. Note, however, that this embodiment is provided merely as one non-limiting example and, in other embodiments, generating the particular flow signature value for the particular processing flow may include additional or different sub-elements than those shown inFIG.5. At510, in the illustrated embodiment, the server system110generates a flow identifier value for the particular processing flow by combining component identifier values for the particular sequence of components used to perform the series of tasks. At512, in the illustrated embodiment, the server system110performs a hash operation based on the flow identifier value to generate the particular flow signature value. As a non-limiting example, in some embodiments the flow signature value is generated as an md5 hash value, though any suitable hashing technique may be used, as desired.

As noted above, various disclosed embodiments include performing flow analysis operations based on the flow signature values generated by server system110. In various embodiments, method500may include one or more such flow analysis operations. For example, in some embodiments, method500includes determining that the particular flow signature value for the particular processing flow matches a previously generated flow signature value (e.g., generated during a prospecting phase) corresponding to a permissible processing flow that is permitted by the server system110and, in response, incrementing a counter associated with the particular flow signature value. In such embodiments, the counter may indicate the number of times, during a particular time period, that the particular processing flow was utilized by the server system110.

Further, in various embodiments, method500includes flow analysis operations related to tracking the “velocity” associated with one or more processing flows utilized by the server system110. For example, in some embodiments method500includes the server system110generating, during a first time period, a plurality of instances of the particular flow signature value while servicing repeated requests, from a plurality of users, to perform the particular computing operation, and, for each of the plurality of instances, incrementing a counter indicating a number of times, during the first time period, that the particular processing flow was utilized by the server system. In such embodiments, method500may further include comparing the first counter to a second counter associated with the particular flow signature value, where the second counter indicates a number of times, during a second time period, that the particular processing flow was utilized by the server system110and, based on the comparing, detecting a change in frequency of the particular processing flow between the first and second time periods.

Additionally, in various embodiments, method500includes determining that a particular flow signature value does not match any signature values included in a list of previously generated (e.g., during a prospecting phase) flow signature values corresponding to permissible processing flows that are permitted by the server system110. For example, as described above, in some embodiments the flow analysis module130may determine that a processing flow is “unexpected” in response to the corresponding flow signature value220not matching any of the flow signature values generated by the flow prospecting module120during its prospecting operations.

In some embodiments, method500includes detecting when a requested operation was not successfully performed. For example, in some embodiments, method500includes detecting, based on a return code230associated with the particular flow signature value220, an unsuccessful outcome of the particular computing operation and, in response to the detecting, identifying a particular component, of the particular sequence of components, as a point of failure for the particular processing flow. In some embodiments, for instance, identifying the particular component includes determining a final component identifier value included in the flow identifier value for the particular processing flow and, using this final component identifier value, identifying a final component in the particular sequence of components used in the particular processing flow.

Further, as noted above, in various embodiments method500includes performing various prospecting operations (e.g., by a flow prospecting module120). In some such embodiments, method500includes accessing a set of component identifier values associated with a set of components utilized by the server system110to provide the service and generating a list of flow signature values corresponding to permissible processing flows that are permitted using the different combinations of the plurality of components in the server system. In some such embodiments, method500further includes autonomously generating the updated list of flow signature values on a periodic basis, including by accessing an updated set of identifier values associated with an updated set of components utilized by the server system to provide the service and generating a corresponding updated list of flow signature values corresponding to permissible processing flows that are permitted using different combinations of the updated set of components.

Example Computer System

Referring now toFIG.6, a block diagram of an example computer system600is depicted, which may implement one or more computer systems, such as server system110(or one or more computer systems included in server system110) ofFIG.1, according to various embodiments. Computer system600includes a processor subsystem620that is coupled to a system memory640and I/O interfaces(s)660via an interconnect680(e.g., a system bus). I/O interface(s)660is coupled to one or more I/O devices670. Computer system600may be any of various types of devices, including, but not limited to, a server computer system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, server computer system operating in a datacenter facility, tablet computer, handheld computer, workstation, network computer, etc. Although a single computer system600is shown inFIG.6for convenience, computer system600may also be implemented as two or more computer systems operating together.

Processor subsystem620may include one or more processors or processing units. In various embodiments of computer system600, multiple instances of processor subsystem620may be coupled to interconnect680. In various embodiments, processor subsystem620(or each processor unit within620) may contain a cache or other form of on-board memory.

System memory640is usable to store program instructions executable by processor subsystem620to cause system600perform various operations described herein. System memory640may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system600is not limited to primary storage such as system memory640. Rather, computer system600may also include other forms of storage such as cache memory in processor subsystem620and secondary storage on I/O devices670(e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem620.

I/O interfaces660may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface660is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces660may be coupled to one or more I/O devices670via one or more corresponding buses or other interfaces. Examples of I/O devices670include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, I/O devices670includes a network interface device (e.g., configured to communicate over Wi-Fi, Bluetooth, Ethernet, etc.), and computer system600is coupled to a network via the network interface device.

“In this disclosure, various “modules” operable to perform designated functions are shown in the figures and described in detail. As used herein, a “module” refers to software or hardware that is operable to perform a specified set of operations. A module may refer to a set of software instructions that are executable by a computer system to perform the set of operations. A module may also refer to hardware that is configured to perform the set of operations. A hardware module may constitute general-purpose hardware as well as a non-transitory computer-readable medium that stores program instructions, or specialized hardware such as a customized ASIC.