Re: ITCS status tool feedback

[gelle@xxxxxxxxx]

This is the feedback blackops worked on together.  To this I would add 
that the 24 hour limitation should be immediately rolled back, or a 
category for non-emergencies under 24 hours eg 'routine non user 
visible environment changes' should be added.

gabi

	From: 	  gelle@xxxxxxxxx
	Subject: 	outage/status tool feedback
	Date: 	June 2, 2005 3:25:40 PM EDT
	To: 	  blackops@xxxxxxxxx
	Cc: 	  akbrooks@xxxxxxxxx

We worked on these as a group.  Not sure who you want them sent to, or 
if we should next get input from other UMCE groups.

IN ORDER OF PRIORITY

1.  Staff only notes should be mailable.  Staff groups to receive 
outages with notes should be separately selectable from groups to 
receive the outage notice.  Groups should include 'blackops' 'gpcc' 
'swat.team' (web) 'wats' 'sites.tsg' etc.  There are probably others.  
Currently we have to send additional explanatory messages to our groups 
following reporting outages.  One of the features we were promised was 
one stop reporting, but currently there is no way to make a technical 
staff consumable report.
    The uniqname of the reporter should be included with the staff 
notes.  They are not currently in the mailed reports, which is fine for 
public consumption but nearly useless for staff.

Currently, the form has boxes roughly describable as:
report for users, report for managers, report for colleagues.
The report for colleagues part is crippled.

2. Routine maintenance should be reportable in one step!! (i.e. This 
change was just completed).  Currently routine maintenaince is not even 
a category. Also, outages that already happened should also be 
reportable in one pass.... forcing people to click twice isn't going to 
stop us fixing first and reporting later.  Directory crashes are a 
shining example of this.  We restart the daemon then report that it 
crashed and was restored.  It is not possible to determine if there is 
a more serious problem without first investigating.  In simple cases 
this is concurrent with a fix.  If there is an outage the oncall staff 
knows the solution to,  the first step is usually resolution - then 
reporting.

3.  Service checkboxes are needed for:  Email gateway or Mail Routing, 
UMOD/Directory!!!!!!!, Printing, DHCP, SpamBox, and possibly email 
virus blocking.
IMAP Email is a very general category, mail delivery to imap is 
different than imap access.  Webmail should be listed.  Other groups 
likely have other additions.

4.  Improved reporting and REPORT NAMING guidelines.
Currently, action in case of outages is clear.
Reporting criteria for scheduled maintenance w/o outage, routine 
maintenance and service degradations are less clear.

Cases:  nefu restarts (currently listed as scheduled maintenance--no 
outage)
        removing one machine from a redundant pool (currently listed as 
service degradation, but there is no actual service degradation at 
current load levels)
        simta partial rollouts
        slapd crashes (a simple restart, reported after a crash)

Production machines are changed regularly.  Sometimes by human 
intervention (clearing tripwires) and some are automated (imap 
updates).  Currently we are mandated to report human initiated changes 
but in some cases this is silly, particulary clearing tripwires and 
nefu restarts.

4 b. Report naming is currently being refined by 'freak out' reactions 
from managers.  Please give us sample headings for reports that we 
should model.  Ideally these would be automatically generated by the 
tool based on the features selected.
Naming guidelines for services.  What are the user consumable service 
names we should be using? Should email delivery be called mail gateway, 
mail routing, email gateway, mail relay, mail forwarding or mail 
delivery etc).  How should an IMAP outage (aka "email") be 
distinguished from a webmail outage?  Can we have a list of the 
official names of all our services so we know what they are called?

5.  Categories do not reflect all types of work, such as 'routine 
maintenance', we have been listing these as 'scheduled maintenence--no 
outage expected' but without allowing lead time for notification.  
Leading to aforementioned 'freak outs'
Should routine maintenance not be reported?  If so, a routine 
maintenance category should be created.


6. Field for server name(s).  The servers involved should be separately 
tracked so we can later search by machine.  (optional field)  Would be 
useful for staff
to later track problems.  E.g.  look up on frontend imap - could yield 
all the frontend imap maintenance,  or specific names would probably 
only yield the emergency outages/maintenance.


7. Automated reminders about open reports for dates past.  Human 
checking by outages group seems less useful.

We think we might have more later, but these are our immediate and 
pressing concerns.

Contact us if you have any questions at blackops@xxxxxxxxxx
Sincerely,
blackops


On Oct 10, 2005, at 2:54 PM, Willie Northway wrote:

> Please send me your thoughts on the current state of the ITCS status 
> reporting tool. What do you like, as well as what you think should be 
> changed - both technically and policy-wise. Only with this list in 
> hand, will we be able to present an effective case for change. I'll 
> bring this to a meeting, and I'd like to invite anyone who feels 
> strongly to accompany me, so please identify yourself if you're 
> interested.
>
> Thanks - Willie
>
> --
> Willie Northway                  University of Michigan Webmaster Team
> http://willienorthway.com/       http://www.umich.edu/~umweb/