2.1.1 – First bullet – Provide a link to UCAM’s standards, please.
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?
2.1.1 – Fourth bullet – Back up and recovery should be part of the basic service.
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?
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?
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)?
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.
9.2 – What’s the mechanism for gathering feedback and input from stakeholders?
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.
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.
Thanks!
Greg