Availability

People tend think of availability in absolute terms. For example whether something is "up" or "down".  However in today's fast-paced world, this is not how people actually perceive whether something is "available".  In fact, availability is a relative notion.

To be sure in the world of computer operations, one view of availability is the centrally administrated view. In this view, there is central "policy" that governs the set of availability objective rules. This type of policy is seen in "glass-room" environments where operations management personnel dictate the definition of availability.

However, availability is also a function of each individual user's point-of-view. For example, if you are at the head of a line, your view of service availability is quite different than someone who is at the back of a line with 10 people in it.

There are other important ways that the definition of availability depends on the user point-of-view. For example, a financial analyst monitoring the availability of a funds transfer application has a totally different notion of availability criteria than an operator who is worried about the state of physical objects such as controller paths and mirrored disk drives.

In a large enterprise, the number of business analysts who require "point-of-view" availability monitoring can easily out-number the people in the operations management staff. Thus "point-of-view" availability represents an important class of availability monitoring. There may be dozens of analysts at workstations throughout a large enterprise who are monitoring "availability". Each of these users can have an entirely different view of availability based on their own definition of availability. Thus, different users must be able to customize their definition of object availability.

If graphical-user-interface availability displays are to be useful, it must be possible to segregate information. For example, a financial analyst may need to know whether the total dollar amount transferred in the last hour in a FUNDS transfer application met expectations, while another may need to know how many ATM transactions occurred. Most often neither care about each other's notion of availability, and they don't typically want their color-coded alert displays to be cluttered with alert information based on the other person's notion of availability.

Customization of availability must also provide inclusion/exclusion of properties that may, or may not be used to determine availability. For example, many users may care whether a certain application process is running, but only a few may care whether the application runs in CPU 15.

In order to address such requirements, ASAP provides a range of customization options that define which entities and attributes are analyzed, as well as the state determination rules used to determine availability. These properties and rules can be customized in ASAP, and thus can be used to control the state propagation engine.

If the general notion of availability were a fixed concept, state determination and propagation would be a relatively straightforward process. However, different users can and do have different definitions of service-level availability. In fact, a user's definition of availability changes many times during the day. The ASAP Client, Server, and Extension architecture is designed to operate with these requirements in mind.

In the previous discussion, we saw how there is not  a single definition of availability for all users. Furthermore, state determination rules can and do change for a single user in a matter of seconds. One instant a user may view availability in terms of whether the Execution Priority and preferred CPU number for application processes meet their objectives. The next minute that same user may not want these attributes factored into state determination at all, but rather may need to view state determination for processes based on Busy utilization and Queue lengths.

Since the definition of availability is not fixed, it follows that object state determination rules must be variable. Thus ASAP must be able to instantly change its state determination rules based on a users relative notion of availability at any given moment. One instant using one set of attributes, and at another instant, include or exclude a different set of object attributes. These capabilities must be provided for both centrally administered policies, as well as for customized user availability definitions.

As a result of these requirements ASAP provides customized state determination based on:

1) Central Policy database objectives as described above, or 
2) Customized user defined state determination rules, or 
3) Combinations of both 1) and 2).

Using these customization techniques object classes such as the Process entity can have the state determination for its Priority attribute be based on centrally administered policy, but have the state of its Busy attribute be based on an individual user's customized thresholds. The computation of the overall state of the object is computed based on combinations of selected attributes, and by analyzing unique state determination rules assigned to each entity attribute.

ASAP provides the following types of object-attribute state determination rules:

• Allow inclusion/exclusion of attributes for the determination of an object's state
• Use Centrally administered objectives for an attribute's state determination
• Use Custom user specified thresholds for an attribute's state determination
• Use Application assigned state for an attribute's state determination

Since the definition of availability is dependent upon a user's point-of-view, ASAP is designed to: 

1) Allow users to define the rules that determine the state of each object attribute
2) Integrate attribute states to determine the overall state of each object
3) Propagate object state information upward through object class hierarchies

Questions/comments - support
Lastmod: June 14, 2019