Introducing CA SOI › CA SOI Workflow

CA SOI Workflow

CA SOI adds a service and operations management layer above the existing domain managers in your enterprise. CA SOI uses connectors and the overall CA Catalyst infrastructure to connect to the domain managers. Each domain manager is unique in the type of resources it manages, how it represents those resources, the alerts it raises, and so on. CA SOI translates this disparate data to standardized information to simplify the data visualization and issue resolution process.

The typical CA SOI service creation and administration workflow, from initial configuration to modeling to detailed reporting, is as follows:

1. Configure security: After installation, an administrator sets up security that defines the users and roles that will interact with the system.
2. Define event policies: Create the event policies optimize the quality of resultant alerts. For example, enriching alerts with contact information or creating an alert that is based on correlated conditions.
3. Define the Alert Queues: Establish the queues and policies that determine how operators visualize and manage alerts.
4. Define the service: Build service models in the Service Modeler that you open from the Operations Console. The Service Modeler lets an administrator build new service models by any combination of the following actions:
   • Importing CIs from the integrated domain managers
   • Importing existing service models from the domain managers or CA CMDB
   • Modifying any existing service models regardless of origin.

   Service modeling also includes the following features:

   • Creating associations and policy between CIs and services
   • Defining the user that is notified when an infrastructure or service alert is raised for the service
   • How any alert condition propagates
   • Whether and when the alert is raised as an incident in a supported helpdesk product.
   • Defining service level agreements that are associated with the service
5. Define service access: After a service definition, the administrator defines user groups that can view the service and its associated data. The access privileges determine the features user group can access: CA SOI features, services, customers, and alert queues. For example, a person responsible for monitoring the Payroll Service may need to view or access only HR-related services. Likewise, if CA SOI is monitoring services for several internal or external customers, each customer should have access to their own information only.
6. Publish the service: The administrator publishes a fully configured service so that CA SOI can begin to manage or instrument the service:
   1. The instrumentation process begins by determining the current active infrastructure alerts for each CI associated with the service model across all integrated domain managers. This process determines the overall state of the CI based on the highest impacting infrastructure alert condition.
   2. Next, the propagation type and policy determine how the infrastructure alerts propagate across the model, and ultimately how they impact the service itself. If the service is impacted, one or more service alert conditions appear and the root cause information helps to diagnose and fix the problems. CA SOI also determines how an alert condition could impact a service by considering service quality, service risk, and overall service availability.
   3. Alerts can enable a launch-in-context to the application reporting a fault condition, letting operators to gather more information to help diagnose and resolve an issue.

   Note: For complete information about service modeling, see the Service Modeling Best Practices Guide.

7. Define customers: The administrator defines the customers to determine the system degradation impact to a specific customer.

   Note: For complete information about working with customers, see the Service Modeling Best Practices Guide.

8. Manage alerts: As CA SOI detects infrastructure or service alert conditions, alerts appear on the Operations Console. The alerts are associated with services and alert queues and behave according to the associated escalation policies. A single infrastructure alert condition can affect multiple services (if the associated CI supports more than one service) or alert queues. Therefore, more than one alert escalation policy can be associated with the alert. Alert escalation policies automate the following escalation actions:
   • Alerting key personnel when alerts impact a service for which they are responsible.
   • Sending notifications when alerts have not been assigned or acknowledged during a specified time interval.
   • Raising a help desk incident for an infrastructure or service alert condition.
   • Running a command to help diagnose or fix the issue.
   • Running a CA Process Automation process.

   Note: For complete information about managing alerts, see the Event and Alert Management Best Practices Guide.

9. View service information: Conditions that impact a service are reflected across all views that may be supported for that service. The conditions are in the Operations Console and the Dashboard.
10. Report service details: You can run, configure, and schedule predefined reports on the service models to help managers make business decisions. The reports also show operators historical service and resource status. Reports can help you understand the impact of fault conditions and predict future issues that are based on past performance by spotting trends and chronic fault conditions.