Your SlideShare is downloading. ×
Integrating The Datacenter OpalisRobot MOM Operator
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Integrating The Datacenter OpalisRobot MOM Operator

211
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
211
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in MOM and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to MOM. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update MOM with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in MOM, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with MOM 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop MOM from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line momentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Go through this, but not in too much detail – this is more technical info than business impact. Don’t both talking about events – these are low-level, really granular things that occur constantly. Go straight to alerts. Robot can react to alerts that are raised in AppManager and take corrective action automatically. Once the problem has been resolved, Robot can update the alert so that operators can see that robot has taken care of the problem automatically. If you’re near the screen you can point to the second and third lines as you describe this. Robot can also send alerts to AppManager. This allow you to create things like scheduled workflows – a job that runs every day at 2 AM – that update AppManager with their status for complete visibility. An example might be a data transformation job (an ETL job for BI customers) that indicates that it’s started, in AppManager, and that update the status (via the update alert object) when it finishes running. Maintenance mode is a new feature with AppManager 2005. For tasks that require shutting down services, robot can put a server into maintenance mode at the beginning of the workflow to stop AppManager from raising alerts associated with the machine. One example of this would be the customers who use robot to reboot citrix server farms. Putting the servers into maintenance mode before rebooting them prevents alerts that would happen when the machines go off-line AppManagerentarily.
  • Get this earlier
  • This is an example of how MOM might integrate with a workflow in robot. Walk through the 3 workflows: The first shows a business process that processes orders coming in. If there’s an error processing an order, an alert is sent to MOM so that operators are aware of the problem The operator doesn’t have to fix the problem however – the second workflow has robot monitoring for this alert, automatically acknowledging the alert and then going through the standard procedure to resolve the problem. This is the exact same set of steps a human admin would go through every time they’re faced with this same problem When the problem is successfully resolved, robot resumes the business process in the third workflow. Some key things to mention here: - robot not only solves the problem, it provides complete visibility via MOM as well as automatically logging a help desk trouble ticket. Robot follows the same practices that your regular human admins would have to Robot can escalate the problem if it’s unable to solve it using the corrective workflow Robot manages both key business processes as well as managing those processes
  • Transcript

    • 1. OpalisRobot MOM Operator
    • 2. OPR Basic Components Foundation Objects Developer Client and Operations Console Windows & Unix Servers, PCs & Other Devices OpalisRobot Execution Server Connector Objects WEB Console
    • 3. OpalisRobot
      • MOM Objects
      • Monitor Alert
      • Update Alert
      • Create Alert
      • Maintenance Mode
      MOM Connector MOM Server MCF Alerts MOM – OpalisRobot Integration MOM OnePoint DB Maintenance Mode Events
    • 4. OpalisRobot MS MOM Operator
        • Monitor MOM Event
        • Setup and filter MOM Events from OpalisRobot
      • Monitor MOM Alert
        • OpalisRobot can respond to a MOM Alert
      • Update MOM Alert
        • Automatically change the resolution status of an Alert
      • Send MOM Alert
        • Provide workflow success/failure notices via MOM
      • Maintenance mode management
        • Suppress Alerts in MOM during server maintenance
    • 5.
      • Customer problem/pain point
        • MOM admins and Help Desk personnel must manually synchronize data between systems (phone calls and data entry)
        • Tickets not always opened in timely manner if at all (not ITIL)
        • Existing integrations involve time consuming scripts or code
        • Limited flexibility in filtering which Events should have tickets opened (Event storms cause Trouble Ticket storms)
      • Opalis Solution
        • Filter Events based on ID, Name, Severity, then auto-create relevant trouble tickets
        • Use DB lookups to determine who to assign trouble ticket to, whether to notify (phone, pager) based on time of day, type of Event
        • Add relevant data to WorkLog of ticket for HelpDesk personnel
        • Acknowledge that MOM Event is being handled (co-ordinate MOM and help desk staff)
      MOM CAP Use Case 1 Service Management Integration
    • 6.
        • OpalisRobot Value-add
        • MOM admin is auto informed that Event has been acknowledged
        • Ticket instantly created
          • No manual work
          • No time lag
          • Filtered for relevancy
        • Additional info + data can be added to ticket for help desk personnel
      MOM CAP Use Case 1 Help Desk Integration
    • 7.
      • Customer problem/pain point
        • When a server fails or maintenance occurs, “Event Storms” occur, overwhelming the system and adminstrator’s console
        • Maintenance windows are often at inconvenient hours and without Robot they require human attendance
        • Only MOM Admins have access to ON/OFF switch in many shops, but it’s the IT guys that need to flick the switch
      • Opalis Solution
        • Set Scheduled Maintenance Object provides automation for unattended maintenance windows
        • Set Ad-Hoc Maintenance Object will dynamically set a single server or groups of servers into quiet mode for repairs (groups important for larger customers)
        • Robot can monitor for ‘Event Storms’ and auto-suppress Events when repeat counts get too high
        • Robot can watch email from IT admins who are in the field and need to suppress Events on a particular machine with no Admin Console
      MOM CAP Use Case 2 Maintenance Mode Management
    • 8. MOM CAP Use Case 2 Maintenance Mode Management
    • 9.
      • Customer problem/pain point
        • Not all shops have 24x7 admins or people at the MOM Consoles – they need to forward relevant info to relevant people
        • Existing integrations involve time consuming scripts or code
        • Limited conditional logic for deciding priority levels of tickets, who to assign it to, what type of escalation (email/phone/pager)is needed based on day/time
        • Traditional forwarding systems are NOT ACTIONABLE
      • Opalis Solution
        • Simple interface for creating rich conditional logic for prioritizing which Events to forward to which admin by the appropriate system (email, pager, phone) at various times of day/week
        • Provides Actionable notification – admin can reply to email/phone to acknowledge Event, perform corrective action, maintenance mode
        • Robot provides a remote interface for non-admin IT types
      MOM CAP Use Case 3 Actionable Notification & Escalation
    • 10. MOM CAP Use Case 3 Actionable Notification & Escalation
    • 11.
      • Reduce IT Latency
        • Instantaneously respond to Events
        • Auto diagnose and notify/escalate
        • Perform corrective actions
        • Integrate with Trouble Ticketing for data synchronization, administrator coordination
      • Automate Maintenance Windows
        • Use Maintenance Mode toggles to eliminate 3AM administrator attended sessions
        • Use 100% of time available during Maintenance Window
        • Dynamically suppress Event messages on ailing servers
      • Centralize System Monitoring
        • Route messages from custom Apps or 3rd Party systems to MOM console
        • Provide OpalisRobot Policy success/failure notices via MOM
      MOM Operator Benefits
    • 12.
      • Achieve ITIL Compliance
        • ITIL = “Standardize the process, execute that process, then document that you have followed the process”
        • Robot executes standardized, repeatable Policies that are auto documented (log files, DB, or event logs)
      • Improve Productivity
        • Automate repetitive tasks, let humans deal with exceptions
        • Improve system availability and performance for SLAs
      MOM Operator Benefits
    • 13. OpalisRobot Virtual Server CAP v2.0 Turns of a Virtual Machine Adds a VM to the VM list Lists all VMs on server Checks the status of a VM Powers on a Virtual Machine Removes a VM from the VM list
    • 14. OpalisRobot SMS CAP v1.1 Create an advertisement using a predefined package, program and collection
    • 15. Product Use Cases
    • 16. Common Starting Points
      • Multi-Step, Complex RunBook Procedures
        • Problem Management
          • Event driven from a monitor (MOM)
            • Acknowledge, diagnose, resolve
            • Escalation + Notification
        • Maintenance Procedures
          • Backups
            • File Storage
            • Oracle/SQL Server DBs
          • Reboot procedures
            • Windows servers with leaky apps
          • Event log archiving and purging
        • Data & File Automation
          • Application feed procedures
    • 17. Typical Customer Use Cases
    • 18. MOM Maintenance Mode Policy
    • 19. MOM Alert Escalation
    • 20. MOM & SMS Deployment
    • 21. Automated Diagnosis
    • 22. Corrective Action + Resolution
    • 23. VERITAS BackUp Policy