@ gogogo:
2.1.1 – First bullet – Provide a link to UCAM’s standards, please.
Ok.
2.1.1 – Third bullet – This is a vague. What level of expertise is expected of ‘local IT support’? Can we expect that tickets opened at IT by departmental users will be tossed back to the departmental IT if central IT deems them to be too basic?
We expect that departments’ local IT can provide “reasonable” first triage. The idea behind having departments’ local IT providing initial triage support is to help with turn-around time as many problems are similar, repeated, and can be resolved much quicker locally. This is not meant to “punish” departments’ local IT. And no, UNM IT will not toss tickets back to local IT – we might forward them all to gogogo@unm.edu though.
2.1.1 – Fourth bullet – Back up and recovery should be part of the basic service.
I will bring this back for review and consideration.
2.1.1 – Include titles of policies, please (not just the numbers).
– Link to 2500 is broken
– The inclusion of Policy 7215 seems to indicate that payments can be managed on the department websites server. What, if anything, is IT doing to support that feature? Is accepting CC payments something that can be set up in CPanel? Or is that handled by a separate web server (or other software) tuned for that purpose?
– I think there was a reason why the titles were left out. I’ll double check. If there wasn’t a reason, I’ll make sure the titles are added in.
– Link will be fixed, thanks for finding this.
– Good point. I will bring this back for review.
2.1.2 – First bullet. I’m unclear about the purpose of this item. It doesn’t list things like Java applets, XML, JSON, REST services, SOAP services, AJAX services. It seems like things like that should be included in the list? Or is it a list of back-end technologies? But then why does it mention HTML, CSS and JavaScript? If I am serving XML, for example, does that mean that I’m in violation of the SLA?
– Your guess was right: limited by back-end technology. HTML, CSS, and JavaScript will be removed.
3.2 – 9th bullet (Bring to the Customers’ attention…)
This seems somewhat arbitrary to me. How is Customer fault determined, and how are IT fixes vetted by Customers? How do Customers report problems that arise due to IT activities (config changes, software (OS, php, database) updates)?
I propose to change this to: “Bring to the Customers’ attention any situation in which extra time is required of UNM IT staff to support this service. With Customers’ approval and request, UNM IT staff will engage in the agreed upon support activities. In these situations, UNM IT reserves the right to bill at the professional service rate outlined under Pricing and Billing for these activities.” Thoughts?
6.1 – Again, how is the determination that something was caused by a Customer made? What recourse does a Customer have to refute such claims? For example what if a site was extremely popular and began to utilize enough resources that it affected other sites? Would that be construed as being the Customer’s fault and the site would then be shut down? While I understand that P1 events need to be dealt with ASAP, there should be a way for Clients to arbitrate, especially if fault is going to be assigned by IT.
Good point on arbitration. I will bring this back for clarification.
9.2 – What’s the mechanism for gathering feedback and input from stakeholders?
This SLA is reviewed with departments annually via email when departments sign up for service subscription renewal.
Suggestions:
IT should probably offer specifics on what’s enabled (or disabled) in php.conf, mysql.conf (or equivalent), and httpd.conf. I don’t believe that there are security issues with revealing details like that, but such things could very well determine whether a Customer can actually utilize the service for some specific application. In addition, such details will make it easier to create local development environments that are similar to IT’s.
I will bring this back for review by Security. If approved, yup.
IT should provide a generalized outage page so that scheduled and unscheduled (if possible) maintenance doesn’t result in users getting no response at all. So, all traffic to the departmental web server(s) should be shunted to a page indicating that scheduled maintenance is occurring, if possible, while the service is down.
Oh, you mean a customized 404 or 503 page for maintenance/non-maintenance outages. Great idea. I will bring this back for review.
Edit: What about this page? http://mysos.unm.edu/
- This reply was modified 8 years, 5 months ago by tbui.