Pre-Con Education: CA Service Operations Insight Power User Crash Course

Pre-Con Education: CA Service Operations Insight Power User Crash CourseJeff Morris, Ahmed Kira & Kirk O’QuinnCA Technologies

Session Number OCX47E #CAWorld

OpsCenter

2 © 2014 CA. ALL RIGHTS RESERVED.

Panel Session

Kirk O’Quinn

CA Technologies

Solutions Architect

Jeff Morris

CA Technologies

Principal Engineering Services Architect

Ahmed Kira

CA Technologies

Advisor, Presales


Abstract

This 3 hour hands-on session will cover the key aspects of how CA Service Operations Insight can integrate and correlate information from your many domain management tools into cohesive service models, monitor and manage your operations at the service level, and transform your NOC into a 21st century Business Operations Center. Topics covered in this session include:

– Product Architecture and Overview

– Centralized Event Management

– UIM (Nimsoft) Integration

– Event Enrichment

– Cross-Domain Correlation

– Integrating SNMP data sources

– Notifications and Escalations

– Managing to the Service

– Service Modeling / Alert Propagation

– Advanced Topics / Troubleshooting

Jeff Morris

CA Technologies

Principal Engineering Services Architect


Quick Show of Hands

Hands up if your organization owns CA SOI and has it deployed / plans to deploy in the near future?


Agenda

SOI OVERVIEW

SOI ARCHITECTURE & CORE CONCEPTS

TROUBLESHOOTING

CENTRALIZED EVENT MANAGEMENT (+LAB)

MANAGING TO SERVICE (+ LAB)

ADVANCED TOPICS

1

2

3

4

5

6

SOI Overview


The Problem: Too many tools, Services Cross Too Many Silos

Silo Domain Managers do not provide a service-wide perspective

Service #1

Service #2

Service #3

Service #4

Service #5

Service #6

Client Systems

Applications

Databases

Servers

Storage

Networks

Silos


IT Operations without Service Operations ManagementThe “Blame Avoidance” Game


Service Operations Management Designed for the Today’s Dynamic Business and IT Environment

Service operations management

Comprehensive domain management Service-aware domain discovery, root

cause analysis, performance management, triage and remediation

Unified event management Query, normalize, correlate cross-domain

events Manage and escalate alerts by policies

Dynamic business service modeling Real time cross-domain service discovery,

modeling and maintenance

Automated actions Initiates automated escalation,

synchronization and workflow based on service impact and risk

Integrated service level performance management

Service performance and comparison management

Contractual service level management

Service analytics and alerts Analytics and alerting for service quality,

availability, impact and risk


Repeatable

Defined

Managed

OptimizedA five-phase approach

11

SOI: It is all about achieving IT maturity

Service-oriented → Lean →Event-oriented →

Initial

Silo-oriented → Business-oriented →

Ph

ase

Att

rib

ute

s

Individual capabilities, not processes

1

4

3

5

2

CA Service Operations Insight


Step 1: Consolidated Alarm Management in SOI

Alert

Queue

List

Alarms


Step 2: Service Modeling

UCS Blade & Chassis

Virtual Machines

Networking

Business Transactions

ApplicationComponents

ESX Host

Ant TrailIndicating

Root Cause Location


Business

services listed

according to:

Business

importance

Quality level

Risk to quality

Business and IT

subservices

Real-time

service

status

indicators

Historical

service

status

details

Step 3: Service Visualization for all Stakeholders

SLA Health

Quality Risk

Availability

14

SOI Architecture and Core Concepts


SOI Core Concepts

2 Configuration Item

3 Infrastructure Alert

4 Service

5 Service Alert

To plan a successful installation, you need to understand the terms and concepts used in CA SOI.

1 Catalyst / USM


SOI Architecture

19 © 2014 CA. ALL RIGHTS RESERVED.19

CA Catalyst: Vendor Agnostic IntegrationMultiple CA and 3rd Party Integrations available today or in development

CA Catalyst


Unified Connector Framework

Unified Connector Framework

ProductAdaptor

CIs, Events, ServicesActions on Silo

MDR

CA Catalyst Bus

EI

USMEI provides policy based data transformation and normalization services for the UCF

The Unified Connector Framework (UCF) exposes standarized interfaces for building high quality, consistent integrations, whether CA or 3rd party

UCF, Product Adaptor and EI Policy = Catalyst Connector

22 © 2014 CA. ALL RIGHTS RESERVED.22 © Computer Associates 2010

Catalyst integration platform

MDR1

MDR2

MDR3


A configuration item (CI) is a representation of an IT element managed by a domain manager converted to USM format.

Configuration Item

Element Managed by Domain Manager (CA Spectrum)

Corresponding CIin CA SOI


Correlation Definition

Correlation identifies related CIs managed across multiple domains. Correlation happens automatically in CA SOI. No additional OOTB configuration is required.

Each domain ‘projection’ of the CI is added to a single ‘USM Notebook’

In this example, APM, eHealth and Spectrum are all projecting what they know about the system ‘TIXCHANGE-3.ca.com’ into USM, and those projections have been automatically correlated together into a single logical representation


Reconciliation Definition

Reconciliation determines which pieces of domain data are the most reliable, and assigns them to the logical ‘reconciled’ (merged) representation of the CI


An infrastructure alert is a fault condition detected by a domain manager – these are automatically forwarded to SOI by the connectors.

Within SOI, alerts are automatically associated with the corresponding CI, and will be mapped to an SOI Severity.

Infrastructure Alert


Service

The concept of a service model, or service, is central to CA SOI (We’ll be exploring them in much more detail later)


CA SOI generates service alerts based on the impact of related infrastructure alerts.

Service alerts have a corresponding Root Cause alert to quickly identify the highest impacting infrastructure condition affecting the service

Service Alert

Centralized Event Management


ServiceImpacting

Alerts

Alerts

Events

Red

uce Q

uan

tity

, In

crease Q

uali

ty

The Event Management Pyramid

Root Causes


Unified Alert Management Architecture

Non-Service Impacting Alerts


Leverages existing Catalyst Connectors as ‘Event Collectors’– Connectors modified to store historical events and expose interfaces

to enable federated queries and remote configuration of policies

Unified Event and Alert Management Architecture

Defining an Alert Queue


What is an Alert Queue?

Filtering Mechanism for Alerts within the SOI Console

Traditional Event Management Concept

Allows different teams to be focused on alerts for CIs which they are responsible– (i.e. Windows, Linux server teams)


Alert Queues Tab Operations

Use the toolbar or the right-click context menu to:

Define a new queue

Edit an existing queue

Delete an existing queue


Define an Alert Queue


Assign Escalation Policy to Alert Queue


Assign User Groups to Alert Queues


Confirm and Save the Queue


Confirm New Queue Exists


Control Alert Queue Access

Two methods are available for defining Alert Queue access:

Using the Alert Queue wizard when defining a new queue and when editing an existing queueOn the Users tab, select a User

Group and add queue access using the Alert Queues Access tab

The Alert Queues Access tab provides similar functionality as the Service Access tab

Creating Escalation Policies and Actions


Escalation Policies and Actions

Escalation Policy– Filter or criteria for related alerts

– Alert queue can be defined as the filter

– Additional Time criteria for when to take action

Escalation Actions– Action to be taken on all alerts matching

– E-mail, create SD Ticket, run custom script, Clear Alert, etc.


Escalation ManagementEscalation Policies Policy can be triggered based on any property of the alarm including the user defined

properties that can be set through enrichment

You can define escalation policy to include or exclude alarms for escalation based on:– Class or Instance of impacted CI

– Symptoms or root cause conditions

– Alarm severity or service impact

– Alarms impacting CIs or services in Maintenance

– Alarms that have not been acknowledged, assigned or ticketed within a given timeframe, or simply based on the age of the alarm itself

Policy can take account of service business hours and can be assigned a schedule (calendar) to determine whether it should be applied


Escalation ManagementEscalation Actions Once an alarm has been identified as a candidate for escalation, you can then

assign appropriate actions to take, including:– Sending an email

– Raising a trouble ticket

– Executing a command

When invoking an action you can substitute in elements of the alarm or the impacted CIs and Service as parameters

The results of any action are stored in the alarm as an annotation so you have the full audit trail associated with the alarm and any attempts to diagnose or remediate the condition

SD tickets and alarms are synchronized so if either is assigned, or closed, that can be reflected back to the other


Define an Escalation Policy

Specifying automatic actions to occur in response to variousconditions helps ensure the policies are escalated

in a timely and effective manner.


An escalation policy can be global or service specific.

Policy Types


Global escalation policies are applied to services on an all or none basis.

Service specific escalation policies are selectively applied to services.

Policy Types Continued


Policy Criteria

Escalation policies can be based on different criteria.

Act on alerts based on attribute value

Act on alerts based on alert type

Act on alerts based on time threshold


Schedule

The escalation schedule identifies when the policy is active.


One or more actions can be performed when an escalation policy is triggered.

Policy Actions


E-mails can be customized and tailored using data from the alert triggering the action

E-Mail Actions


Schedule Maintenance

Services and CIs require regular maintenance.

Maintenance schedules identify regular maintenance time periods.

Specifying how maintenance mode affects the impact of CIs and services enables you to define an effective escalation policy.


The Operational Mode indicates the current maintenance status.

Production

Maintenance

Operational Mode

Maintenance Mode Icon


Maintenance Mode Impact Propagation

Global settings control impact propagation for CIs in maintenance mode.

Propagate Maintenance Impact = Yes

Propagate Maintenance Impact = No


Maintenance Mode Alert Escalation

Alert escalation behavior for CIs and services in maintenance mode is specific to each escalation policy.


Define Maintenance Schedules

The Maintenance Schedules subview provides the means to create new schedules.

Event Policy – Filtering / Enrichment


Event Streams Can Be Overwhelming

Managing events is like managing a fire hose…

Too much volume

Impurities

Inconsistent composition


Event Filtering and Normalization is Key to Success

Ultimately, the Alert Console should contain:

Minimum volume

Maximum quality (articulation of problem)

Consistent composition (same schema)

SOI Alert Console


Open the Event Policy DialogDefine Event Search Criteria


Specify Simple Event PatternsDefine Event Search Criteria

When searching for multiple events using the Any criterion, the search is satisfied if an event occurs that meets any of the specified search patterns.


Open Create Event Policy DialogDefine Enrich Event Policy

Click the Create Policy button


Define Event Policy

Cross-Domain Event Correlation

Define SOI Alert Queues based on Spectrum Global Collections or Custom Attributes


Interface to Map Additional Attributes from CA Spectrum to CA SOI

New Configuration file AdditionalAtrributes.xml

Following format used to add the additional model attributes

<Models>

<Attribute id="attribute id" name="attribute name"/>

</Models>

Example:

<Models>

<Attribute id="0x23000d" name="Location"/>

<Attribute id="0x23000c" name="ContactPerson"/>

<Attribute id="0x12adb" name="CollectionsModelNameString"/>

</Models>

Connector needs to be restarted to apply the changes


Interface to Map Additional Attributes from CA Spectrum to CA SOI

Map the new attributes in CA Spectrum policy file to transfer these attributes to Catalyst

<Field output=“CIUserAttribute1" format="{0}" input=" Location "/>

You can also map to user-defined USM property, in case relevant target property is not found


CA SOI UI Showing Additional Attributes

Showing Location, ContactPerson and CollectionsModelNameString in user attributes


Creating a new alert queue based on new attribute

Creating Alert queue to show alerts on CIs belonging to global collection ‘uiop’

Event Management Lab (20 minutes)


Event Management Lab

Experiment with Alert Queues

Create an Escalation Policy / Action for your Alert Queue to send yourself an e-mail notification

(Optional) Experiment with Event Policy– Filter or Enrich an incoming event

– Should impact your Alert Queue

Break (10 minutes)

Service Modeling Principles


What is a Service?

Different meanings to different people– Often considered somewhat synonymous with application

Business Service– A suite of application components and associated infrastructure working together to provide a

specific named value to the organization and/or its customers

– i.e. “On-Line Bill Pay“

IT Service – Somewhat more low-level – may not have a front end

– Components of many business services

– i.e. “VOIP"

75


Service Topology

Service propagation based on:

- Alarm Severity

- CI Significance

- Relationship type

• Letter (O) depicts relationship type

• Number (8) depicts significance of child CI on scale of 1-10


CI Severity

Severity indicates the condition of a CI.Severity Color Description

Normal (0) Green Operational

Minor (1) Yellow A nominal displacement of CI function that may or may not merit inspection

Major (2) Orange A serious causal change typically leading to degradation of function

Critical (3) Red High probability of imminent failure and severe degradation of service

Down (4) Burgundy The CI is incapable of providing function or service


CI Severity Continued

Severity values do not propagate from child to parent.– The impact of CI severity is propagated.

– The impact is derived from the fault condition asserted on a CI and the significance value assigned to that CI.

Parent

Children

Severity values are assigned to CIs with directly associated alerts


Significance

A value that states how important a CI is to a related item


Significance Continued

Default significance values are established for each CI class type.


Impact

Identifies what CI fault conditions really mean to the service that the CIs support

Impact Color Description

0 Green Operational

1 – 10 Yellow Slightly degraded

11 – 20 Orange Moderately degraded

21 – 30 Red Severely degraded

31 – 40 Burgundy Down

Severity

Normal (0)

Minor (1)

Major (2)

Critical (3)

Down (4)

Impact

0

1 – 10

11 – 20

21 – 30

31 – 40

x =


Impact Continued

Impact values are propagated.

Impact is propagated to related CIs.


Groups

Groups are intermediate objects that relate CIs to one another by some role or function.

Group


Propagation Types

Propagation Types determine how impact values are propagated.– Aggregate

– Bound

– Custom

– Operative


Aggregate Propagation

Aggregate propagation indicates a general-purpose relationship that propagates impact from one CI to another.


Bound Propagation

Bound propagation indicates a bidirectional relationship between two CIs.


Custom Propagation

Custom propagation indicates that one CI may depend on several other CIs for some behavior or function.


Operative Propagation

Operative propagation indicates a related item is affected only if the impact value of a CI exceeds a defined threshold.


Relationship Types

Relationships refine how impact values are propagated.


Custom Propagation Policy

Custom policy further refines how impact is propagated for the IsAffectedBy and IsEvolutionOf relationship types.


Normal GranularityService Granularity

Normal granularity

Direct alerts from low level CIs explicitly included in the Service model are assigned to the low level child object

• Direct alerts are alerts that are instantiated directly against the object

• Low level CIs belong to classes that fall beneath the Top Level classes


Service Granularity

Low granularity (LoFi)– Direct alerts are assigned to low level child objects

The assigned low level child alerts behave as standard managed alerts

– Alerts from low level child CIs not included in the Service model are intercepted and propagated to the parent CI

– The association is established by matching the device ID

– The Low Fidelity Impact icon denotes the presence of a low granularity alert

Low Fidelity Impact icon


Service Granularity

Low Granularity Example

Direct alert

LoFi alert

Importing a Service


Import Services

Domain managers such asCA Spectrum Infrastructure Manager, CA APM, and CA CMDB have service concept.

Previously defined services in domainmanagers can be imported intoCA SOI.– This leverages your existing investment.

– This establishes that CA SOI should manage the service.

– The imported services can be modified and extended.


Auto Import Services

When Auto import is set to Yes for a connector:

– All existing domain manager services are immediately imported.

– Any new domain manager services are also imported after they become known to the connector.

Some connectors are not Auto import capable.

The Auto import toggle buttons are located here.


Manual Service Import

Accomplished using the Import Services dialog.

Service Discovery Policies


Working with Service Discovery

Service Discovery allows you to define policies that will automatically build and maintain services in real time

1 Understanding SD Policy Types

2 Navigating the SD Policy Editor


SD Policies

Three types of policies are supported:– Dynamic Services

Define policies to place relevant CIs (system-wide) in a service

– Automatic Relationships

Define policies to connect matching CIs (system-wide)

– Unmanaged Relationships

Define policies that establishes managed relationships from existing unmanaged relationships


Navigate the SD Policy Editor

SD policies are defined in the Policy Editor.


SD Policy Editor UI

Access from the SOI Console

To access the SD Policy Editor,

click Tools > Service Discovery Policies.

At startup, with the root node selected,

the right pane displays SD policy

descriptor revision details.


SD Policy Editor UI

During Operation, when a policy group is selected in the left pane, the right pane displays the list of policies that fall beneath the selection.


SD Policy Wizards

Context sensitive menus provides access to SD policy wizards.– The menus are triggered from the navigation tree node.

– The Create, Add, and Modify actions launch the respective policy editor wizard.


Define Dynamic Service Policy

1 Define Service

2 Confirm

3 Confirm Step Validation

SD policies determine what services are

automatically created and maintained.


Step 1: Define Service

Panel space is reserved for messages

Required input fields are marked with an asterisk (*)


Step 2: Confirm


Step 3: Confirm Step Validation

Warning messages identify when the validation process identifies

problematic service definition policies.


Define Automatic Relationship Policy

1 Source Criteria

2 Target Criteria

3 Match Criteria

SD policies determine what relationships areautomatically created and maintained.

4 Relationship Scope

5 Confirm


Step 1: Source Criteria

Panel space is reserved for messages



Step 2: Target Criteria


Step 3: Match Criteria


Step 4: Relationship Scope

All Services or Specific Services



SD Engine Relationship Scope Processing1. Identify CI pairs fitting the SOURCE, TARGET, and MATCH criteria

2. For each CI pair, identify Services containing the SOURCE CI that fit the Relationship Scope specification

1. Add the SOURCE->TARGET relationship defined by the policy to each Service within the identified set


Step 5: Confirm


Define Unmanaged Relationships

Domain manager knowledge of unmanaged relationshipscan be easily used to extend the managed relationship

hierarchy within CA SOI services

1 Default Behavior

3 Define Unmanaged Relationship Policy

2 Unmanaged Relationship Discovery


ServiceComputer

SystemPort

Published by the connector

Created in CA SOI

Unmanaged Relationship• Invisible in CA SOI Service Topology

Managed Relationship• Scoped to the Service

Default Behavior

Relationships published by connectors are unmanaged– MDRs are not aware of the services in which CIs are used and so are

unable to scope the relationships to CA SOI services.

– The unmanaged relationships are not part of nor visible in the CA SOI service topology.

– Alert impact from unmanaged CIs is not propagated to the service.


ServiceComputer

System

Unmanaged Relationship Discovery

Establishes managed relationships from unmanaged relationships– Looks for unmanaged relationships whose source CI is in a Service

– Creates a managed copy of the relationship scoped to the same service as the source CI

Implemented as a new Service Discovery policy type

Port

Published by the connectorCreated in

CA SOI

Managed Relationship• Starts in a managed CI• Scoped to the service• Created by the policy


Step 1: Relationship Criteria



Step 2: Source Criteria

Class value of Entity covers all other classes


Step 3: Target Criteria

Class value of Entity covers all other classes


Step 4: Match Criteria (Optional)

Match Criteria are not required for Unmanaged Relationships policy



Identify which Services to apply the policy against


Step 6: Confirm

Service Modeler Demo /Instructor-Led Lab (5-10 minutes)


Manual Service Creation

Manually create this service. Append service name with your initials

1. Create Child Service: OnlineOrderingCustomer

2. Create OnlineOrderingService

3. Create 2 groups4. Drag and drop CI’s to define

service

Service Modeling Free Lab (20 minutes)


Service Modeling Lab

Create a manual service model Use the relationships and propagation rules to manage state propagation of

infrastructure events

Create a Custom (Group) Policy in your Service Model

Create an Escalation Policy / Action to Escalate only when the service state is degraded

Advanced Topics

Using Event Enrichment to change severity of Alerts


Example Alarms for which Severity could be updated to ‘Down’


Solution: Update Spectrum alarm severity

Alarm Severity update treated as an enrichment policy

Enrich Spectrum DEVICE HAS STOPPED RESPONDING TO POLLS events to change the Severity of the alert from Critical to Down


Update Spectrum alarm severity

Open the Event Policy editor, enter the search criteria for Event Pattern 1 :– Summary="DEVICE HAS STOPPED RESPONDING TO POLLS" or Summary="CHASSIS DOWN”

NOTE: you can match on multiple events with the logical OR syntax, so one policy can match many events.

and then click the Search button and verify your pattern matches as expected

Click on ‘ Create Policy’


Update Spectrum alarm Severity

From the Create Event Policy page, enter a policy name such as ChangeSev2Down, then choose Filter Events - Include Events radio button, and then click Next >



Complete the enrichment page as follows:

Type: Script

Script Path: none

Script Name: none



Configure the Severity as desired (Minor, Major, Critical, Fatal (aka Down))



From the Select Data Sources Page, select the Save and Deploy policy radio button, select the Event Management MidTier Connector data source from the Available Data Sources list, click the right arrow to move it to the Selected Data Sources list, and then click Finish.

Wait 1 minute for the event policy to reload automatically OR restart the CA SAM Integration Services (IFW) and CA SAM Event Management services.

Integrating SNMP Events(time permitting)


SNMP Connector Overview

A generic data collection connector, receives SNMP traps from any SNMP-capable product, transforms the traps, and maps the generic SNMP attributes to the USM model

Each domain manager requires a separate connector policy that dictates the varbind to SOI attribute mappings

Connector policy is XML-based and extremely flexible, offering ability to parse, normalize data


Steps for Creating SNMP Connector Policy

1. Direct SNMP traps from domain manager to the SNMP Connector

2. Review the raw trap data received by Connector

3. Modify <SOI>/resources/Core/CatalogPolicy/snmp_policy.xml to

determine how CIs will be created from traps

4. Create the snmp_policy.APPLICATION.xml to determine format of the

Alerts created from traps

SOI 3.2 includes a UI for creating and configuring this policy

5. Review results


1. Review Raw SNMP Trap Data Received by Connector


2. Modify snmp_policy.xml to Create CIs


3. Modify the Alert EventClass to Format Alerts


SOI 3.2 Event Policy UI EnhancementQuickly and Easily Map Raw SNMP Trap Values Through the UI

Troubleshooting


Six core Services– SOI Manager (“CA SAM Application Server”)

Tomcat application and core engine for SOI (listens on port 7090 for debug/admin pages)

– UI Server (“CA SAM User Interface Server”)

Presentation Layer – hosts web GUI and launch point for console

Also a Tomcat instance (by default listens on port 7070)

– IFW aka Integration Services (“CA SAM Integration Services”)

Java application that hosts all connectors running on a given machine

Communicates to SOI MGR via ActiveMQ messaging buss

– Event Management (“CA SAM Event Management”)

Controls communication with the local Event Store, event queries, etc.

Must be deployed wherever there is an IFW instance

– UCF Broker (“CA UCF Broker”)

Supports the “Unified Connector Framework” (aka Catalyst)

Southbound integrations – listens on port 8020

– Store Indexer (“CA SAM Store Indexer”)

Indexing of USM data for display in USM Web View

Must install on same host as “UI Server”

SOI Installed Services Tour


Troubleshooting SOI Connectors

Connector architecture is very asynchronous– First must isolate the root cause domain

SOI Manager,

Connector Framework (IFW)

Domain Manager

– Use DEBUG mode of Log files to isolate


Where are the Log Files?

<SOI>\tomcat\logs

– Log files for SOI manager

<SOI>\jsw\logs

– Service Logs

<SOI>\log

– Connector Logs

<SOI>\log\debugData

– Detailed debugging files containing CI files for the different connectors

<SOI>\SAMUI\log

– Logs for UI server


Configure Connector debugData

Config file - <SOI>/resources/log4j.xml

Make sure the following “logger” sections are uncommented

Files will be located in <SOI>/log/debugData directory


For More Information

To learn more about DevOps, please visit:

http://bit.ly/1wbjjqX

Insert appropriate screenshot and text overlayfrom following “More Info Graphics” slide here;

ensure it links to correct pageDevOps






For Informational Purposes Only

This presentation was based on current information and resource allocations as of August 2014 and is subject to change or withdrawal by CA at any time without notice. Not withstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this presentation remain at CA’s sole discretion. Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA will make such release available (i) for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as part of CA maintenance and support, and in the form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis. In the event of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall govern.

Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this presentation “as is” without warranty of any kind, including without limitation, any implied warranties or merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA is expressly advised in advance of the possibility of such damages. CA confidential and proprietary. No unauthorized copying or distribution permitted.

Terms of this Presentation

Copyright © 2014 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belongto their respective companies. CA confidential and proprietary. No unauthorized copying or distribution permitted.

Technology

Pre-Con Education: CA Service Operations Insight Power User Crash Course