@mdcarter:
I think a definition of terms should appear at the top of the document that would define such phrases used throughout the SLA document. For example, “User” could be interpreted as the User of the service or the visitor to a website. It is sort of defined in the General Overview so that may not be the best example.
[IN PROGRESS] I could not agree more. In the “Mobile App Distribution SLA,” the definition for “End Users” was spelled out under the “End Users Responsibilities” section. I’m going to sneak the language in and bring this to Agreements next time for review.

Hi Greg,

Regarding Departmental IT Support, Central IT Support and triage, it might be a good idea to define (perhaps in a different SLA) what is expected of each? This seems like a good way to collaborate and to help establish bridges between IT and departments. For example, if a user called the help desk with a support request, they could ask if they had tried their local support options. If the answer is ‘yes’ then the technician who gets the ticket can assume that certain preliminaries have already been attempted, or at the very least, that the Departmental IT support can provide technical background about the problem.
[IN PROGRESS] One idea that was proposed in a different SLA discussion was to have an OLA for the local IT departmental units. As the introduction of this OLA is going to change the dynamic of how UNM IT has been working with departments. I am going to bring this back for feedback.

Regarding this:
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?

This sounds reasonable, as long as you’re not painting yourself into a corner. Two scenarios come to mind:
An active emergency requires that a site be shut down immediately; IT should have the option of doing that if the the emergency warrants it.

Cases where departmental contacts are non-responsive and IT must take action to prevent or stop problems.
In these cases like these, IT should be able to simply shut a site down quickly (and probably non-billable-ly), and sort things out later with the Customer.
As an update, the current template language that our Agreements Committed agreed to: “Upon notification, UNM IT reserves the right to bill, at our standard hourly rate or expedited service rate, for any avoidable situations in which extra time is being required of UNM IT staff.”

http://mysos.unm.edu/ seems like a good idea. As long as it’s not on dept2.unm.edu and dept2.unm.edu is down.
[IN PROGRESS] It’s going to be on a different server than the downed websites/apps. We use the F5 to to check and redirect.

Hey Andrew,

2.1.1 No line item for A-Z
IT’s services (this one included) are being revised/added for the Service Catalog.

2.1.2 The service desk has instructed many of our users that if they are using a browser besides Internet Explorer on a UNM Windows machine that it is unsupported. Is Internet Explorer no longer support for enterprise applications by UNM IT? What is the new enterprise browser that is compatible with all UNM IT supported enterprise applications?
New application development and implementation support prioritizes the following browsers: Edge, Firefox, Chrome, Safari, Android Browser – and IE 11 under specific circumstances (case-by-case approval – e.g., compatibility for core enterprise services that are critical and widely used).

2.2.1 “…can take multiple business days to complete” This needs to turn into a number.
This refers to the turnaround time for IT to assist departments with directory updates. As IT currently does not restrict the size of the requests that departments submit, a specific number cannot be produced. Also, there is currently no costs associated with having directory updates made by IT with submitted requests.

3.1 Is UNM IT able to provide reports on how many hits each A-Z entry is getting? Departments might be interested knowing how many people are clicking on their A-Z entries.
Yes, we have these metrics and can provide them on request.

5.1 Service desk hours are not listed on the support page, there is a link that leads to FastInfo on the support page
Yes…

Hi Eugene,

If Internet Explorer is not supported, specific versions of the browsers this does support need to be listed. Slippery slope excluding certain browsers.
[IN REVIEW] Added clarification regarding support for IE older than 11: “Directory listing editor is not supported on Microsoft Internet Explorer browser older than version 11.”

Updated to: “Directory listing is accessible by current vendor supported browsers delivered with the OS (operating system).”

2.1.1:
– What are the kinds of things departmental support can expect to be able to troubleshoot outside of the listed FAQ?
I assume that you are referring to the “question mark” FAQ on the menu bar. Outside of the how-to guide in the FAQ, departmental support can assist with standard user-support issues such as page not loading because of certain privacy settings (e.g., no javascript enabled) in the users’ browsers for example.

– Is it possible to list each department’s primary and secondary contacts on the department’s A-Z page so that requests to update the info can go directly to the responsible party? Should the department’s local IT support info be listed as a tertiary contact?
[IN REVIEW] Awesome idea. Noted as an enhancement request to application.

3.1:
– Item on poor implementation and planning does not apply?
Agreed. This is part of the SLA template’s language which is being reviewed and revised holistically outside of this SLA’s scope.

– Is there a specific format required for bulk updates that would make this more efficient for UNM IT and the department?
There will be. One of the enhancement requests in the queue is to add an “import” feature. Once this feature is implemented, the standardized format will be publicized to departments.

2.2.2 and 9.1: 
– If system performance and availability reporting are not available for this service then is it appropriate to list a specific uptime of 99.9%?
[IN REVIEW] Good point. Revised language for reporting to: “System availability reports for this service are available on request.”

Service-related questions:
If an employee separates or changes roles, is A-Z a directory that gets updated from Banner or is it a standalone system? If it is a standalone system, end-users need to be responsible for keeping this up to date. UNM HR separation checklist (http://hr.unm.edu/docs/employment/separation-checklist-for-staff-employees.docx) should be updated to reflect the supervisor having to submit directory listing changes that are not automated.
This is a standalone system. I agree with your line of thinking that end-users (designated contacts) need to keep the info updated. HR and IT have not had a conversation regarding the direction in which this application should take place yet. The next version of this application (no ETA) – in my mind – will more than likely pulls information directly from Banner as to avoid duplication of data across the various sources.

Is this directory using a different data source than what is available on directory.unm.edu and what a user can change via Directory Self Service (DSS)? How does DSS and what appears in A-Z differ? Not required of the SLA, but I think helps to better define the service and where users can expect updates to appear (or not).
This is a standalone system at this time. It uses a different data set in a different database than what directory.unm.edu (people) uses.

This service could be powerful if exposed in some fashion for folks to incorporate on other web sites. A single version of the directory that is accessible via web services that every department doesn’t have to duplicate in some fashion would make it an Enterprise service.
[IN REVIEW] Could not agree more. API is on the roadmap.

Eugene
Thanks for your feedback.

• This reply was modified 8 years, 9 months ago by tbui.

The phrasing of the second bullet in 3.2 seems misleading to me:
“Track websites’ and visitors’ activity and provide Users with access to this data;”

I assume what you are saying here is the IT will maintain web server access logs.  Tracking visitor’s activity could mean something much more “NSA” to some reading it.

Good point. The tool is tracking stats similar to Google Analytics. Perhaps a better wording would be: “Track visitors’ pageviews, sessions, and visits using system logs, and provide Users with this data.” The pageviews, etc. were examples as cPanel uses different terms than Google Analytics.

Policy 2570 should be referenced somehwere in the SLA.
Policy 2570: Official University Webpages –
https://policy.unm.edu/university-policies/2000/2570.html
Agreed. I think this should be included under Web Admins/Developers Responsibilities per policy’s:
“Staff, faculty, students, and contractors authorized to develop official webpages for any administrative or academic unit of the University, including webpages of the Health Sciences Center and branch campuses, should comply with the requirements of this policy.”

@ gogogo:

Currently, I believe that IT has Zend_Framework code stored in a centralized location so that users don’t have to consume quota for that. It would be great if that service was mentioned in the SLA.
I like this idea, and I would like to explore expanding the language to state “shared libraries” instead of limiting it to just Zend. I will bring this back for review.

In addition, it might be useful to have something like /path/to/zend/1/latest that’s a symlink that always points to the latest version, whatever that is. So, in for the examples I gave above:

/path/to/zend/1/latest -> /path/to/zend/1.2.15
/path/to/zend/2/latest -> /path/to/zend/2.4.9

In your experience, is it possible to link to Zend via http? I’m thinking architecture-wise, for websites sitting on different cPanel boxes, it is better to have Zend hosted on a central box that websites on all of the other cPanel boxes can refer to without resorting to shared drives. If Zend can only be included locally as your example stated, then each cPanel box would have to have Zend on there somewhere.

@ 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, 10 months ago by tbui.