...
(https://itcrops.itap.purdue.edu/ioclog/)
Date
- Default is to the current day. If starting a log for Third Shift, Keep in mind that all entries should start no earlier than Midnight of the shift day the log is for.
- i.e. If it is 23:45 on October 30, and the shift is mostly on October 31, the entry should be moved up to 00:00 on October 31.
...
- NEVER EVER put phone numbers or email addresses in the "Description" field. That information is considered confidential, and if it is in the description field it will be in the log that gets emailed.
- If at all possible, please do not use names here. Sometimes a name needs to be entered, but use "Admin", Engineer", "Student", "Instructor", etc. whenever you can. This will limit our exposure to unnecessary mistakes.
- If at all possible, please do not reference gender when referring to the person.
- Please be short and to the point on your entries. Only pertinent information needs to be entered. Below is an example of an entry that is long that can be shortened:
- Long - "CSC reports FootPrints is unavailable. I advised the CSC I would contact someone on this issue".
- Short - "CSC reports FootPrints is unavailable".
- There is no need to write "I advised the CSC I would contact someone on this issue". Normal procedure dictates we would contact the admins for calls such as this so it should be assumed.
- Be consistent in the wording of log entries. There really is no right or wrong way when it comes to wording, but please be consistent throughout the log. Below are examples of 2 entries by the same Operator on the same log for different calls to the CSC for 2 different outages. The text should be the same with the exception of the specific outage.
- Entry 1 - "Called CSC to inform them of outage resolution for X"
- Entry 2 - "Notified CSC of outage resolution for Y"
- Example:"Notified on-call of Xymon deadpath alarm for lppbakbmo1.itap.purdue.edu. "
Entries regarding what app the issue is coming from should be refereed to in this section.
- Squared Up
- This is used when we have network alarms on Squared Up. Most production Xymon alarms appear in Squared Up so take care to report network alarms as appearing in Squared Up and NOT Xymon (which are reported separately).
- StruxureWare
- This is used when recording StruxureWare alarms.
- UC4
- This is used when reporting UC4 issues that do / did not require PCA intervention.
- Xymon
This is used when we have alarms in Xymon. Most production Xymon alarms will display in Squared Up, but it is important to know they are Xymon alarms, not Squared Up alarms and should be reported as such. EXAMPLE:
19:21 murra175 Data Center and Enterprise Storage Todd Turner 765-496-8214 / ITIDataCenterManagement@purdue.edu Outgoing call Ignore Alarm Metasys: Airstack alarm for module 9 with value of 4. Left VM. Email sent.
19:27 - Received email: Admin advises to ack alarm and ignore.
Combining Entries
- In an effort to streamline the log and make it more efficient please combine entries when applicable.
- Entries that can be combined are typically ones that involve the same issue or entries for machines that are down on TICMON that a TO investigates and resolves. Some examples:
- Combining Outage Entries:
- Non Combined
- 8:01 - CSC reports Blackboard is down.
- 8:03 - Notified Admin for reported BB issues.
- 8:10 - Admin reports BB is back up.
- 8:12 - Outage Resolution posted for BB.
- 8:15 - Notified CSC of outage resolution for BB
- 8:16 - Notified ITaP Comm of outage resolution for BB.
- Combined Entry
- 8:01 - CSC reports Blackboard is down. Admin notified.
- For "Group" and "Contact" use the group and name of the person you contacted to look into the issue.
- For "Status" use "Group Notified".
- 8:10 - Admin reports BB is back up. Service Alert Resolved. CSC and ITaP Comm notified.
- For "Group" and "Contact" use the group and the name of the person resolving the outage.
- For "Status" use "Service Alert Resolved"
- The above examples went from 6 to 2 entries. 1 for the reporting of the issue and 1 for the resolution of the issue. The entries were short and contained the pertinent information. The information about who we are contacting from the CSC as well as ITaP Comm is important, but the true meat of the issue is BB was down so the contact for the group/people responsible for fixing it is more important.
- 8:01 - CSC reports Blackboard is down. Admin notified.
EXAMPLE:
19:21 murra175 Data Center and Enterprise Storage Todd Turner 765-496-8214 / ITIDataCenterManagement@purdue.edu Outgoing call Ignore Alarm Metasys: Airstack alarm for module 9 with value of 4. Left VM. Email sent.
19:27 - Received email: Admin advises to ack alarm and ignore. - Non Combined
- Combining Outage Entries:
Ignore Alarms
There are times when an admin advises us to ignore an alarm/alert until further notice. If that happens the entry needs to remain on the log for three shift logs. After the entry has cycled through three logs, the entry needs to be moved to the shift log calendar and not made as a regular log entry. If at all possible please try to get the admin to commit to a time period or definition of what “until further notice” means. If the admin provides a timeframe use that for the duration on the calendar. If the admin can’t/won’t provide a period of time then put it on the calendar for the duration of a week. Once the duration has ended then the admin will need to be contacted to provide an update on the alarm/alert. Remember it is part of your daily duties to check the shift log calendar on a daily basis.