tbui

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • in reply to: Department Web Hosting SLA #561
    tbui
    Keymaster

    @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.

    in reply to: Department Web Hosting SLA #560
    tbui
    Keymaster

    @susier:
    Recommend replacing “Department” with the more general “academic unit” throughout.
    We do intend to provide this service to all departments and not just academic units.

    $75/hour charge should be a link to a separate schedule that will be updated periodically, rather than being hardwired into the SLA.
    [IN PROGRESS] Our Agreements made the same feedback – referencing the Service Catalog page. This will be changed.

    in reply to: Department Web Hosting SLA #559
    tbui
    Keymaster

    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.

    in reply to: Department Web Hosting SLA #558
    tbui
    Keymaster

    Hi Greg,

    Regarding other libraries: Indeed. I’m Zend-centric, but that’s by tradition. It might be worthwhile to consider PECL and PEAR, as well.

    Regarding using URLs for paths to the Zend library: this could be possible. php has the ability to read files from http URLs, but I don’t know if the autoloader code can deal with them. Zend_Framework (and all other php libraries that I know of) use a method of naming classes that will help an Autoloader to find and then include files. This emulates Java’s class loader but is much less formalized. So, for example, suppose that I evoke an object: $cool = new Zend_Cool_Class(). The Autoloader starts looking through the path variable for zend/cool/class.php, which must then contain a class Zend_Cool_Class(). Essentially, it’s replacing underscores with slashes with some rules to make it easier for developers.

    In addition, the framework allows users to create their own namespaces, for example ‘UNM_Extlearn_’, along with an optional path ‘users/el/Sites/application/modules/unm/extlearn/’. In that case if I evoke an object: $person = new UNM_Extlearn_Person(), then the framework’s Autoloader will know to look for the class code in ‘users/el/Sites/application/modules/unm/extlearn/Person.php’. The framework assumes a number of paths that are used by convention, and users are free to modify those (at their own risk) or add others. This functionality makes it easy to include other libraries, as well, and as you can see, since classes must be named correctly, namespacing is automatic.

    So, it’s a tangled web and elegant in its way. I would say the bottom line is that it’s probably best to use actual filesystem paths.

    I believe that this can be done, but it will be less elegant than what we had in the past. The Dept-Web environment uses NFS which allows our 6 web servers to share the same storage. The cPanel environment are siloed – i.e., websites are spread across multiple servers. As we are moving our systems to vCloud Air, shared storage is discouraged in new environments. One option that we can do to enable shared libraries across the websites is to have a local copy of the libraries on each cPanel server. There might be other more graceful solutions. I’ll bring the topic up for discussion at the next IA-meeting (March, 2016).

    in reply to: A to Z Department Listings #461
    tbui
    Keymaster

    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…

    in reply to: A to Z Department Listings #460
    tbui
    Keymaster

    Hi Elisha,

    2.1 Does this use the Cascade system, or something else? Should it use Cascade? Is there a webservice that could be queried?
    This does not use Cascade. This is a PHP application that uses a MySQL backend. Cascade – in its current state – does not allow for easy building of web applications.

    API is a future enhancement that we want to add to this application – along with pulling data directly from Banner.

    2.1.1 – Where should department IT go for triage scripts if they are going to support this service?
    For requesting access and making edits, there is a FastInfo available here: https://unm.custhelp.com/app/answers/detail/a_id/7445/kw/7445. This is available via the small question mark (Help) button on the menu.

    The video that Cameron Goble put together on that FastInfo also has other useful information – such as the structure and layout of the info.

    2.2.1 – Is there an upper bound on the number of days? How do things get escalated?
    Currently, there is no upper bound on the number of days as IT does not enforce a cap on the size of the requests that can be sent in for update assistance from departments.

    2.2.2 – I see 99.9% availability in most of these SLAs. Is this a default or service specific? Is this measured? What is the process for measurement? How are acceptable availability levels determined?
    The 99.9% availability is server-specific. As most of these services are hosted and run from servers, this number is being used in multiple places. The servers’ availability and performance are monitored and logged by a monitoring tool that our Platforms team uses. However, these metrics are not made available publicly today as there is no good control mechanism in place (yet) to allow IT to do so. These stats are available on request.

    3.1 – Are there billable services associated with this service? Which ones? What is the need for the billing portal in association with this?
    Template language. Template language is being reviewed, revised and approved holistically.

    3.2 This seems irrelevant to a directory service? “Maintain appropriate staff expertise in the maintenance and support of any customer supported equipment and/or applications;”
    Template language. Please see above.

    in reply to: A to Z Department Listings #459
    tbui
    Keymaster

    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, 2 months ago by tbui.
    in reply to: Department Web Hosting SLA #243
    tbui
    Keymaster

    My assumption based both on discussions and this SLA is that the goal is to move all sites currently hosted on IT’s departmental web servers to the cPanel servers.  My question is related to the 256mb space limit provided, somewhat mirroring Sharon’s comments above.

    1.  Has an audit been conducted looking at the size/quota of websites currently hosted on the Departmental web servers?  I know of and work with many departments that have quotas well over the 256 amount.  I would be curious to know the ranges and averages (mean , median and mode).
    We have not done an official audit, but we do collect that metric on websites.unm.edu (this website has restricted access) – big thanks to Farid Hamjavar at IT for maintaining it. It lists all 900+ websites on Dept2, and their quotas and usages. I can provide mean/median/etc. at a later date.

    2.  The idea of cPanel is great in terms of easily managing multiple sites under a single account.  For example, we currently host 30+ sites in a single NetID account.  That account has a significant quota.  I feel the limiting of disk space per account will encourage users to simply create a new NetID when space is an issue and they have multiple sites.  This creates more NetID and cPanels account that need to be managed on the IT side of things. However, I would prefer to manage everything in one account.
    (IN PROGRESS) Agreed to both points. Though, I do not have a good answer at this point due to the model in which cPanel is designed with. I will bring back to the implementation team for feedback.

    in reply to: Department Web Hosting SLA #242
    tbui
    Keymaster

    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.

    in reply to: Department Web Hosting SLA #241
    tbui
    Keymaster

    My thanks as well for taking the time to reply to all of these responses, in detail, and for being receptive to the suggestions made – Chad
    Chad, thanks for the kind words! All of us here at IT realized very quickly how amazing discuss.unm.edu was soon after it went live as it allowed us to received feedback like yours and others.

    With regard to your praise for “being receptive,” just wait until you see me put my foot down.

    in reply to: Department Web Hosting SLA #237
    tbui
    Keymaster

    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.”

    in reply to: Department Web Hosting SLA #232
    tbui
    Keymaster

    @ erooney:
    This draft of the SLA states that departmental/local IT will be the first line of support. Will there be any Operating Level Agreements (OLAs) between the centralized provider and local IT to support the customer? If a customer is going to rely on this agreement, then the central provider and the departmental IT group need to be in sync in terms of support. How will this agreement be structured for customers without departmental IT expertise for this service?
    (IN PROGRESS) Having OLAs in place between central IT support and departmental IT local support is a great idea. I’m not sure if we are there yet though. I will bring this question up at this Friday IT Agreements meeting for feedback.
    For departments without departmental IT expertise for this service, IT would provide support directly.

    • This reply was modified 8 years, 3 months ago by tbui.
    in reply to: Department Web Hosting SLA #231
    tbui
    Keymaster

    @ 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.

    in reply to: Department Web Hosting SLA #201
    tbui
    Keymaster

    @ steely:

    re: 2.11 bullet 4:
    You are way too clever for me by far, Tuan! That is not what I meant to suggest at all. But that’s what I said, isn’t it. Just reading this made my anxiety level shoot through the roof. I have had a couple instances of snapshot restoration that saved my skin and I was in panic mode already. Please do not add to my nervous state.

    [IN PROGRESS] The comment about the hostage situation was really a joke. =) I will look at options to do this effectively and make a proposal for internal approval. I will let you know.

    in reply to: Department Web Hosting SLA #120
    tbui
    Keymaster

    @ 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, 3 months ago by tbui.
Viewing 15 posts - 1 through 15 (of 23 total)