Forum Replies Created
-
AuthorPosts
-
gogogoParticipant
Howdy:
This is echoing Elisha’s comment: what’s the purpose of this SLA? Is it to:
1. Define a Service that IT is offering and is optional for units to use?
2. Define a Service that IT is offering and is required for units to use?This leads to some questions:
If the IT service is optional, and units choose to use their own internal resources to provide the service for their own use, are they also required to abide by the SLA?
If a unit chooses to partner with another unit to provide these services, will both units be required to implement and abide by the IT SLA?
Thanks!
GreggogogoParticipantTuan:
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.
Thanks,
GreggogogoParticipantOops, one more thing. I hope it’s not too late!
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.
For completeness’ sake I would suggest something like this (using semi-fictitious versions):
- /path/to/zend/1/
- 1.12.13/
- 1.12.14/
- 1.12.15/
- etc.
- /path/to/zend/2/
- 2.4.7
- 2.4.8
- 2.4.9
- etc.
In other words, keeping past versions as well as the latest versions.
These don’t have to be full packages, but just the basic deployment code.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
Because both versions are fairly stable, developers don’t have to worry (much) if they use latest, and rely on IT to update the framework as needed. Having the ability to point to any version provides maximum flexibility, if needed.
Please let me know if any of this is unclear.
Thanks!
Greg
gogogoParticipantHi, Tuan:
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.
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.
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.
I think I got everything; the rest seems fine.
Thanks so much!
Greg
gogogoParticipant2.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 - /path/to/zend/1/
-
AuthorPosts