Typical Scenario:
The monthly figures are in and productivity results are printed in bold. Yet again, as a system administrator, you notice that the lack of Downtime planning has lead to your key productive systems being unavailable of over 30 hours against the permitted 20 hours.
Your have spent hours clearing your Alert Inbox every Monday which has been flooded with spurious alerts indicating system non availability - during all pre planned Downtimes.
You spend close to 3 productive hours every week on Excels, planning a Downtime, seeking approvals from all key stakeholders, notifying the necessary business & system users and yet find your Help Desk working 2/5ths of their time on system unavailability tickets
If you are looking for an option, to get over this mess and get around these unproductive and repetitive layers of chaotic excel work, read on further to discover Downtime Manager (DTM) provided with the System Landscape Management Work Centre of SAP Solution Manager.
Released with Solution Manager Support Package 15, the chief idea behind the inception of Downtime Management was to suppress the spurious alerts generated during planned system unavailability. Growing on this idea, DTM, in its basic flavor, now offers system administrators
- Planning -To obtain a complete & drilled down view of their systems (ABAP and Java systems, their server, instances and logon groups)
- Scheduling -Allows them to schedule 2 unique types of Downtimes (explained in detail)
- Notifying - Send relevant notifications via email, SMS or system message to keys users
- Alert Suppression- Suppressing monitoring, or at least alerting triggered by CCMS during planned Downtimes otherwise
Planning in DTM:
In the "Planning" stage, DTM provides the user with the list of all satellite systems monitored by the Solution Manager. This includes both ABAP and Java systems, listed along with all the servers, instances, and logon groups.
- The "Filter" options help to classify systems based on the component (system, servers, and instances) or on the types of downtimes planned on them - (1)
- The system tray neatly lists all the systems, with the last executed and latest planned downtimes on them - (2)
Hence at any given point of time, the system administrator has a holistic view of his systems, which allows him to optimally plan Downtimes among related systems. Overlaps, if any, can be identified.
Scheduling in DTM
Downtimes can be scheduled as Single Downtime and Recurring Downtime.
- A single Downtime (3) - is a planned unavailability of a target system that has a one time occurrence.
- A recurring Downtime (4) - is the planned unavailability of target system that occurs at regular intervals across a long period of time, typically your planning period. The planning sequence can be based on a monthly or a weekly recurrence pattern using the established NetWeaver "Appointment Calendar" platform.
- Example of a Weekly recurring Pattern: Every Month on the 1st from 20/12/2008 to 20/07/2009 from 01:00:00 to 02:00:00
- Example of a Monthly recurring Pattern: Every Second week on a Sunday from 20/12/2008 to 20/07/2009 from 01:00:00 to 02:00:00
Upon choosing a recurrence pattern, two events occur,
- First, the DTM produces a simple verbal "Description of the Pattern" - (5)
- Second, it produces a "Recurrence Plan" having the entire sequence of Downtimes - with the scheduled dates and the time slots - (6)
This is referred to as a "family" of Downtimes, each of them having a unique "Event ID", but at the same time have a common "Sequence ID" This reduces the administrator's calendar work neatly by a factor of over 95 %.
Example: The administrator can plan a Recurring Downtime every last Sunday of the month. He /she can choose - a monthly recurrence scheme- every 5th Sunday - between two calendar dates. Most normal months tend to have 4 Sundays, with the "4th" Sunday being the last Sunday in that calendar month, but consider a month of 31 days, that starts on a Sunday. In such a case, there would be 5 Sundays in that month, with the "5th" Sunday being the last
In a pre DTM scenario, the system administrator would have to tediously scan the calendar across the months, to locate the last Sunday of every month. But with the usage of DTM, it automatically recognizes the intrinsic purpose of such a recurrence pattern; picks the relevant dates & plans Downtime on the "4th" or the "5th" Sunday - whichever turns out to the last Sunday of that month.
Once Downtimes are created, DTM also allows the system administrators to edit them - which involve functions like "Extending a Downtime", "Reducing a Downtime", or "Deleting a Downtime". However extending or reducing a Downtime has to be done, before the Downtime in actually in progress.
In addition, to planning a regular Downtime, the other options available are
Unplanned Stop | This option is provided to schedule a critical Downtime, which had to be scheduled short-term without a complete planning process |
Crash | This option is provided to forcibly shut down a system that has behaved abnormally, which could be due to virus attack or extremely disruptive behavior |
Real Downtime | This option is to record in hindsight, the true length of the Downtime. This data can be used to check for time leaks and planning efficiency - in terms of over planning or under planning |
Critical Uptime | This option is provided in order to pre-book time slots on systems, during which Downtimes cannot be planned. This serves as a mechanism to ensure system availabilty during peak business hours |
Exception Handling in DTM:
To handle scenarios, wherein, from a family of planned Downtimes ,a certain event ID/ a Downtime , clashes with a Critical Uptime, DTM provides the option of moving that specific event out of the sequence.
The advantage of such an exception handling mechanism is that, it ensures that the rest of the sequence of Downtimes in that family remain unaffected and proceed as previously planned - and the sole exception that was moved out of the sequence, can be "deleted" or "edited" to happen at a later time slot on the same day, complying with the business rules.
Notifying in DTM:
System administrators have the option of notifying the owners and users of the target system through email, SMS or system messages.
- This provides 3 different text templates for each mode of notification, which are editable - (7)
- On selection of a target system for notification, the recipients can be automatically called from the pre populated list of system users. It is also possible to draw recipients from the business partners recorded on the Solution Manager system - (8)
- The default pattern of notification can be set for each system, which is automatically saved even for a later date. This pattern typically refers to frequency of notification such as SMS notification one hour before Downtime, Email notification one day before Downtime etc - (9)
- Specific changes in the notification patterns, for specific recipients can be triggered from this tab- (10)
Alert Suppression in DTM (during Planned Downtimes):
This feature gives you the option to suppress spurious CCMS alerts and save yourself cumbersome removal of alerts that you knew all along were not to be taken serious.
Full Monitoring | Provides all monitored data -for BI purposes, alerts and messages (available with Solution Manager Support Package 15) |
Suppress Alerts | Suppresses CCMS alerts but provides a view of the same in the Solution Manager's Alert Inbox |
Suppress Incidents | Suppresses creation of service desk messages (planned for Solution Manager Support Package 18) |
Monitoring Pause | Suspends all CCMS monitoring (available with Solution Manger Support Package 16) |
Managed systems require certain kernel levels for alert suppression to be supported. See SAP Note 1096782
Availability Reporting:
Prior to Solution Manager Support Package 17, planned Downtimes had to be separately recorded in the Service Level Reporting application in order to support proper calculation of provided service levels. As of Solution Manager Support Package 17, Service Level Reporting will consume the planned Downtimes from DTM thus preventing double maintenance. The native scheduler in Service Level Reporting did not offer all features of the NetWeaver Appointment Calendar Platform used in DTM, which is overcome through this feature .
In addition, data from DTM is used in BI reports for availability reporting. For more details check SAP Note 1129052.
Future Scope of Downtime Manager
While DTM is already a promising and convenient tool to plan and record Downtimes, many improvements and functional enhancements are yet to be delivered.
Repeated customer concerns include the need to seek approval from several stakeholders - both IT and business related, before releasing a Downtime on a system. Currently, DTM addresses this concern, only by the option of putting a Downtime into an "In Review" status, exporting the planned data on to an Excel file and assuming that the workflow between the parties is done independently. In future, planning and seeking approvals for Downtimes, through a workflow process between custom built roles of "Owner" and "Approver" will be sought. This workflow is planned to be eventually integrated with the Change Request Management of Solution Manager.
This eventually translates into a scenario, where not only will a Downtime be planned, reviewed, released, executed and so forth, but it will also be connected to what is actually meant to happened during the Downtime (for example, maintenance work).
Currently DTM does not support optional Automation i.e. optionally - enabling system stoppages at the beginning of a planned Downtime. Tentatively planned with Support Pack 17 or latest Support Pack 18, this situation will change. You will be provided the option to choose between "manual" and "automated" "Stop" and "Go" of a system. The manual option will provide you with a reminder, of an upcoming Downtime on a system, based on which the system has to be manually stopped. The automated option automatically executes the Downtime, by shutting down the system at the scheduled time.
I have tried to explain DTM through it basic functionality in this blog, but do keep visiting this page often to learn in detail on how DTM in principle operates with the CCMS world, which I will cover in the next edition.
Also keep an eye on Notes 1129052 and 1129385.
2 Comments
