Enterprise
EECS Computing Enterprise Organization
David E. Culler
Vice-Chair for Computing and Networking
March 3, 1999
This memo outlines the proposed organization of the EECS computing enterprise that we plan to have in place July 1, 1999 to provide a basis for continued growth and evolution of the enterprise for several years.� The overriding goal is to provide a uniformly higher quality of computing and networking capability across the department. More specifically, we seek to provide a common, coherent infrastructure for the various activities and groups within the department, allow rapid incorporation of evolving hardware, systems, and software technology, give our technical staff clear goals and responsibilities, have a transparent allocation of funds that reflects demand across the research-instruction boundary, simplify and enhance user support, clarify the management task and obtain greater human efficiency in the face of rapidly increasing array of computing devices. The department leadership and the technical staff have been working toward this goal for the past year and a half. To complete the process and allow the enterprise to be sustained, we propose here a gentle reorganization of existing and planned technical staff positions and a corresponding funding model. Although technical functions are outlined here, a separate document describes the technical system design of the enterprise in greater detail.
The key elements of this proposal are the following.� (1) The existing CSG, IESG, Titan, and unaffiliated department technical staff become reformulated as an Infrastructure Development and Support Group (IDSG), Computer User Support Group (CUSG), Instructional Support Group (ISG) and Electronics Support Group (ESG).� IDSG will be explicitly shared across the EECS/ERL boundary – it will have members from each and will support both. It will support networks, servers, services, and the technical staff in other groups, not individual users.� CUSG will be entirely ERL and focused on high quality user support – not just machine support.� ISG and ESG will be departmental focused on instruction, electronics, and devices, but able to rely on IDSG for infrastructure.� With the exception of IDSG, effort crosses the boundary by explicit recharge. Each of these groups has a lead supervisor with four to eight staff.� (2) A department wide Computer Resource Manager position will be created to provide top-level management, overall technical direction, budgetary oversight, and assistance to the Vice-Chair for Computing and Networking.� (3) The current charging structure of network access fees (NAF) and CSG contracts and charges will be reformulated as a per-user Computer Infrastructure Fee and a user support contract, so there is more complete financial transparency and accountability.
1. Background
The computing and communication resources within the department of EECS have undergone dramatic growth in recent years. Three years ago there were something less than a thousand machines in the department, now there are more than four thousand. Intel-based PCs have become a majority platform, NT has become widely established, and Linux has begun to displace vendor supplied Unix. New complete network infrastructures have been installed in both Cory Hall and Soda Hall, following trends though shared ethernet, ATM, switched ethernet, and gigabit ethernet. A wide array of servers has been established, with storage servers now providing multiple terabytes. The technology has advanced, the components have changed, the skills needed to support the environment have risen, the expectations have been radically altered, and demand has increased to adopt leading-edge technology to sustain our position as a world-leading department.
There has been a paradigm shift towards shared, infrastructure services behind a rich desktop environment. This marks a third phase for the department.� Historically, we had a phase of centralized computing from ?dumb terminals,? which was followed by a phase of independent workstations and PCs with many small server groups. The transition to shared services began in earnest with the Mammoth Institutional Infrastructure project and its introduction of the Auspex servers, that provided networked file service (NFS) on all CS subnets, common binaries (SWW), DNS, and NIS.� In 1990 the CS faculty voted to make migration to this common infrastructure a division-wide imperative, with elimination of the multitude of group servers a clearly stated goal. This approach transferred largely to instruction and, in somewhat lesser degree, to the EE research environment.� It resulted in a vast reduction of overall effort and an enhancement of capability.� We now take the availability of these services for granted and depend on them deeply. The infrastructure has been greatly consolidated and enhanced in the past two years on both CS and EE sides, with major industrial donations. Now, with the emergence of web-based computing, a second major technical computing platform (NT), and wider spectrum of standard networked services (e.g., directory services, server-based mail, scheduling), we need to place a more concerted effort behind the infrastructure, ensure that it bridges EE and CS, provides commonality across instruction and research, and incorporates Unix and NT as gracefully as possible.
Organizationally, we have had numerous technical organizational components reflecting the interests of specific communities, without very clear charters and division of responsibilities. A major organizational step was taken in 1997, when Technical Computing Services (TCS) was broken up into the Computer Services Group (CSG) and the Instruction and Electronics Services Group (IESG).� This reorganization primarily reflected a need to get financial clarity.� CSG is a an ERL organization primarily providing recharge services to research and departmental groups through contracts and time-and-materials arrangements. It also collects a per-person Network Access Fee (NAF). IESG is an EECS organization, primarily providing FTEs for instruction and departmental function, although the electronics subgroup also provides some recharge services.� The 1997 reorganization was a vast improvement, brought the debt under control, and provided better management, but it did not clearly define how function was to be divided across these groups, how new development of the enterprise would be carried out, how to benefit from opportunities to share resources, or how other groups would interact with these.� With the benefit of some experience in this structure and in trying to advance our computing enterprise with it, it is clear now that we need to take additional organizational steps. In doing so, we want to assimilate the Titan group, which picked up from the Mammoth group on the CS side, and departmental staff that have fallen outside the CSG/IESG structure. We want to develop clear tasking, responsibility, areas of innovation, and funding model for each group.� We want a clear interface between groups and between these and the individual research groups. The fundamental observation is that there are essentially no stand-alone components any longer. There is deep and valuable sharing across many aspects of the enterprise. Not only is the environment more deeply integrated, but system support groups are now required to work together as never before. This makes the need for coherent system design and understandable organizational structure paramount.
Faculty, staff, and students are generally confused about what resources are available to them, where they should go when problems arise, and what to expect. Most faculty members feel that the existing state of their computing environment is a significant impediment, either to their teaching or their research. We have multiple technical organizations doing vital, high quality work, often on their own initiative, but feeling frustrated, under-appreciated, and often short-changed. There is unease in how resources (either recharge moneys or FTE) are allocated. There is no clear sense of when an activity within a group has crossed the boundary and should be moved to another.� Most technical advances get mired in long-winded struggles over who is going to pay for what. Hardly the situation that we want to be in as we embark on securing our world leadership position in the field.
2. User View
The central theme is that we have become an enterprise of richly configured desktops supported by common, substantial infrastructure services. Hardware has become relatively cheap and turns over rapidly.� Time is very precious, and the major costs are system and software configuration, trouble diagnosis, and human frustration. Across the department, there are three modes of usage that need to be addressed.
1. The typical user wants to have a single point of contact where they go for help or service. This user support service is not just a matter of making a machine work, it is making the user?s environment work for the tasks they perform. Users may not have a complete understanding of the infrastructure that exists behind the scenes, but they need to have a simple way to work effectively within it. On the research side, this function is to be provided by the Computer User Support Group (CUSG) within ERL.� It will become staffed at a level of expertise and with a funding structure such that it can offer a complete support contract that allows members of the research community to have working up-to-date facilities without becoming experts in system administration.�
2. Instructional users, students and faculty in their teaching role, will have a similar point of contact in the Instructional Support Group (ISG) within the department.� It has a narrower scope of support, but staffs a very large facility efficiently.� From a faculty viewpoint, there is one place you go for everything concerning your desktop, laptop, or research computing facilities and one place for classroom and instruction lab facilities. The actual computing infrastructures have as much commonality and cross communication as possible to minimize effort, but there is a clear financial and staff support separation.
3. Many large research groups, as well as department administration, provide their own staff to support users, desktop machines, and lab equipment.� Today, all of these groups utilize the infrastructure services for much of their needs, but they maintain their own local support function.� A user in such a group goes to their staff support.
To allow these three modes of use to coexist effectively and to allow all of them to benefit from the continued growth of common services, there needs to be a group focused on providing the information technology infrastructure upon which the entire department depends.� It provides the common environment and services, tying multiple different operating environments together.� This is the main place where responsibilities are shared. It defines the common capabilities, environment, policies, and resources.� It has a substantial development role, as the capabilities of the infrastructure keep advancing. The infrastructure group supports the services and the staff that support the users.
3. Organization
3.1. Components and Relationships
The organizational components and basic workflow is shown in the following figure.� Five specific technical staff groups are identified, outside the individual research projects.
� The Infrastructure Development and Support Group (IDSG) is tasked with developing, maintaining, and supporting the core department-wide infrastructure in support of computing activities across the department. The specific components of work and funding model are discussed below.� An important point to understand here is that this group deals primarily with technical staff supporting specific functions within the department, rather than the end-users on an everyday basis.� Its concerns tend to be long term and wide scope. If functioning perfectly, it is invisible. Services are available.� Needs are anticipated. Of course, it provides a problem-tracking, trouble-shooting function, but this is intended to be used by technical staff who have performed the initial source problem diagnosis and isolation on behalf of the effected user or users. The IDSG is typically the one that must address campus issues and interaction with IS&T.
� The Computer User Support Group (CUSG) provides direct support for end users and their desktop, laptop, or laboratory computers. Specific emphasis is placed here on user support, not merely computer support. It is not enough to connect the user?s computer to the infrastructure and turn it on. The bulk of the work is expected to be supporting users themselves.� This means configuring software to that it meets their changing needs, training, answering questions, tracking, trouble shooting and diagnosis.� They allow researchers not to become experts in the details of their computing environment and infrastructure.� Typically, when a problem arises it will go to the CUSG help desk. Staff there will provide the initial problem analysis and localization. If the problem has to do with the local machine, its configuration, or its usage, they can address it.� If the problem is deeper, they can provide an informed problem report to IDSG on behalf of the user. Very often, a problem with the infrastructure will be revealed across several users.� Similarly, when a new user or new machine arrives, there is a fair amount of up front, end-system work, which typically yields a few simple infrastructure requests (create user account, allocate file storage, enable port).� On the other hand, a security problem may be detected within the infrastructure due to an attack, but need to be handed back to the CUSG administrator responsible for the machine for remedy or upgrade. CUSG is tasked with developing, innovating, and supporting tools for efficiently managing a large population of users, a rich and productive desktop computing environment, effective tracking of the configuration and usage requirements of defined groups of users, effective and predictable handling of service requests and trouble reports.
� The Instructional Support Group (ISG) manages the resources within the instructional labs and classrooms and supports instructional users in their instructional function. It has a very large user population and a higher user-to-staff ratio than the other groups, but it has a much more focused function. Typically, it provides a separate set of user accounts and separate resources, but utilizes the common infrastructure as much as possible, including snapshots of common binaries, common file storage, etc.� We need a clear financial separation between instruction and research, while providing as much commonality of environment and ease of access across the two.� ISG is tasked with developing and maintaining a state-of-the-art instructional environment that tracks the changing needs of courses and provides predictable responsiveness to requests and trouble reports.
� The Electronics Support Group (ESG) is responsible for instructional lab resources that have an electronics or instrumentation component.� It provides research user support services on a recharge basis for a range of instruments and electronics devices, including their software support, where they attach to computers, and a variety of non-conventional computer systems, such as those with numerous sensors and actuators.� It provides support for electronics involved in everyday department operations, such as copier keys.� While the major problems motivating this memo is the need to coherently address the accumulated growth in infrastructure capability and user support within a rich desktop, we anticipate that the major growth area in the next five years will be a small, diverse device.� Thus, as legacy ESG functions diminish with the shift to simulation and digital operation in the labs, the function of ESG will grow in the proliferation of AV capabilities and of small devices.
� An individual research group of significant size, such as the MicroLab, BSAC, or BMRC, may elect to perform some or all of its user and end-system support in-house. This means that they do user support, configuration, and problem isolation internally.� Designated staff interact directly with IDSG much as do CUSG staff.� Typically, these groups desire a certain amount of autonomy, and that will be supported within simple guidelines.� They may utilize CUSG on a fee basis for some of this support, and they may utilize ESG services. However, it needs to be emphasized that if a group elects to avoid the cost of CUSG support, they must indeed provide the analogous function – including user problem isolation, conformance to department policy, configuration, and training. They cannot simply utilize IDSG as an unpaid CUSG replacement.
� The Administrative Support Group (ASG) functions much like a self-managed research group, but serves the needs of department staff.� It has a different user base and a different application focus, but has the same relationship to the infrastructure.� In addition, this group maintains the department?s web presence down to the point where links cross over to pages of individual research projects and users.
Even if the IDSG and CUSG were managed by the same individual, it would be important that each have a well-defined interface, accounting structure, and charging model, since IDSG is logically shared and supports several other groups directly. End users work directly with the support staff associated with their local environment, either CUSG contact, ISG, or their group staff.� These staff members work closely with the IDSG.� ESG is very closely related to ISG and primarily addressing the instruction machine. Although it maintains shared facilities, they are narrowly shared among specific lab users, rather than transparently shared over a wide population.
3.2. Reporting Structure
A proposed organization chart is shown in Figure 2.� There is a moderate shuffling of personnel across Titan, CSG, and IESG to form the IDSG.� Each group has a supervisor and reasonable sized staff reporting.� The CRM position provides technical and personnel management at the top, reporting directly to the Vice-Chair. The CRM maintains budgetary oversight on CUSG and IDSG, to ensure an accurate and efficient usage of resources. ISG and ESG have a very tightly linked budget, with department business manager providing oversight.� They often work together in securing major resource donations and grants.�
One important element of this structure is that it should be possible to provide technical staff with technical staff as supervisors, who can provide professional guidance, perform meaningful performance evaluation, and represent staff needs to upper management.� There are cases where technical staff report directly to faculty or to administrative staff, but it is almost always problematic if they have no technical staff providing management, assessment, evaluation, training, etc. Supervisors in this structure provide management services, which may be called upon, and appropriately compensated, outside their specific group.� Thus, a research group with one System Administrator may have that person supervised by CUSG for a fee.� A large group of research staff, or perhaps department technical staff, might report to the CRM.� These reporting relationships cannot be forced to take place, but the value of them is so great as to make it wise to plan them in from the start.
4. Funding Model
On the research side, there is a two-part funding model. Each user pays a monthly Computing Infrastructure Services (CIS) fee.� This replaces the current Network Access Fee, and makes clear that it is not network that is being funded, but the entire array of services, resources, and staff. This fee will be pegged to the research fraction of a clear accounting of the IDSG costs. All of these services will be under a flat fee, with the exception of file storage and backup.� Research groups differ greatly in their storage demand, so this cost should be separated out. CIS monthly fee is of the form $U per user + $S per gigabyte, with a one time storage purchase fee.� Current estimate for CIS fee in July 1999 is
� CIS Fee = $35/per person per month� ($420/year) – includes 100 MB Unix, 100 MB NT, 100 MB IMAP storage.
� Storage purchase fee = $275/GB ��������������
� Crisis protection backup fee = $140/GB per year
� Port upgrade or hookup fee = $300����������� (or if faculty prefer, we can use a monthly fee)
In addition, user groups may contract with CUSG for computer and user support, hire such support on a time and materials basis, or support their own system staff.� CUSG will over a complete support contract as a function of the number of machines and the machine types. It will also offer hourly support for functions that can not reasonably be covered on contract, or to augment dedicated group staff.� This recharge will be administered through ERL. The proposed rates are:
� $730/year per client machine
� $1350/year per server machine
� $55/hour time and materials
Note that research groups that elect self-administration still pay the CIS fee, as they still consume infrastructure resources. As discussed below, the CIS fee is not a substitute for computer and user support.� IDSG is responsible for making sure that the network works, mail is not lost, addresses are translated, files are accessible, binaries are available, and so on.� They are not responsible for configuring your desktop machine so that it works.
The funding model on the instructional side is necessarily quite different.� There is no user fee for instructional users. Funding for instructional support continues to be through FTEs, state funds, donations and grants. Computer and User support for instructional labs, classrooms, students, and teachers in their instructional function is through ISG.� It provides its own, focused helpdesk capability, account management, file restoration, etc. However, these users and desktops also draw on the common infrastructure, and increasingly so, but no equivalent CIS fee is collected. This fraction of the load on IDSG is to be covered directly through departmental FTEs within that group.� Currently, instruction pays 230 NAF fees, one per machine.
A degree of insulation between research and instructional activities will be provided within the infrastructure, where it is cost effective and does not interfere with productivity. For example, it is easy to separate instructional storage demands, but it needs to be possible to access instructional files from research machines and mail traffic goes through the same relays.
CIS support for department administrators could in principle be handled either as a CIS fee or as and FTE contribution.� Indeed, just as a research group could change its selection between self-administration and CUSG administration, the department administration has this option. Given the current situation, it makes most sense for the department administration to contribute FTE and storage support to the IDSG, rather than have more funds flowing between EECS and ERL.
ESG serves department and research, but primarily department.� Thus, the current situation is retrained where staff are department employees and services are offered to research groups in a recharge basis.� A clear accounting of these breakdowns and the scheduling priorities needs to be provided.
4.1. IDSG Responsibilities
As the IDSG is essentially a new group, it is important to spell out its responsibilities in some detail. The IDSG is responsible for several layers of infrastructure function from the raw network up to shared user services, in support of each of the major user groups in the department.� It must do so in a manner that is highly available, responsive to problems, and responsive to changes in software and hardware technology. We are moving to an enterprise architecture supporting Unix and NT in a coherent fashion, with a single directory capability spanning the department, a uniform set of services offered to clients of either ilk, cross access of storage (moving toward a single store), a direct mapping of group structures across both domains, and a solid security framework.� Functions are listed here from the bottom-up, where each depends only on previous ones.
4.1.1. Department Networks
IDSG is responsible for operating the networks in Cory and Soda hall, except for the experimental networks specifically allocated to research projects. In many cases, these networks are managed by IS&T. In some cases, e.g., the ATM networks, they are managed locally.� Even with IS&T managed networks, the department needs to maintain a connection database.� Trouble-shooting reaches across, as well. This group will manage the design, installation and renovation of entire networks, as well as specific day-to-day operations.� Now that the major networking infrastructure is current across the department, we can move to a funding model that is fair without being idiosyncratic.� IDSG is responsible “out to the floor box”. The cable, network interface, and computer are the end-system responsibilities.
4.1.2. Infrastructure Machines
IDSG is responsible for maintaining the machines, disks, operating systems, and local software of the computers that comprise the infrastructure.
4.1.3. Infrastructure Backup
Several of the machines providing infrastructure services require local file storage for configurations, logs, spools, binaries, etc. These must be backed-up without depending on higher level services.� In addition, user file storage backup is provided as a service, see below.
4.1.4. Time Service
NTP servers receive TICs from redundant level 1 servers and provide it throughout the department.
4.1.5. Hostname Service
Hostname� service is provided for hosts in the CS and EECS domains.� Today this consists of� a primary DNS server and a collection of redundant secondary DNS servers, which have IP addresses on each of the production networks.�(Currently CS primary is maintained by IS&T).� Going forward, this service will integrate with broader directory services.� DHCP will be used more extensively.� In that model, end-system administration would be responsible for registering authorized equipment, IDSG would be responsible for the DHCP capability.
4.1.6. User/Group Name Service
NIS service for Unix domains and NT domain services are to be provided uniformly.� A key element of this is that the two worlds should inter-operate.� This is achieved by establishing a one-to-one mapping between entities in each world and developing a single point of entry. This is expected to integrate under a common directory service as well.
4.1.7. Directory Service
IDSG will provide department wide directory services in the near future.� Initially this will subsume much of the DNS, NIS, NT DS content, but will increasingly support the growing spectrum of centralized configuration information.� Much of the user and end-system content of the directories will be entered by end-system administrators.� IDSG will be responsible for providing scalable, available directory service to support the growing load.
4.1.8. Security
IDSG is responsible for building a department wide security so that reasonable policies can be instituted and monitoring security.� We want to eliminate clear text passwords.� This means a uniform kerberos, SSH, NT infrastructure.� A simple practice for certificates, as well.� CUSG and equivalent are responsible for ensuring that all clients conform to policy.� Break-in and breeches inevitably involve infrastructure and client staff to resolve.
4.1.9. Application and Utility Binary Service (SWW)
Provides complete Software Warehouse (SWW) for several client architecture/OS, including NT.
4.1.10. User/Group File Service and Backup
Stable, networked file service is provided to Unix and Windows clients.� IDSG is responsible for developing the scalable file storage infrastructure, cost-effective backup capability and the client support so that thousand of clients can gain access through NFS or NT FS.� Servers of either type will be accessible to authorized clients of any type.� A funding plan and design should allow research groups to purchase storage according to need and pay according to cost.� Costs involve initial storage purchase (burdened by its server support), on-going maintenance, and backup.� Restores for accidentally deleted files should be off-loaded to end-system administrators as much as possible.� IDSG is responsible for dealing with server failures and the like.
4.1.11. Mail/Messaging/News
Provides primary mail relay and limited spam filter for CS and EECS domains, user forwarding, mailing lists, and longer term spooling.� Supports defined spectrum of client protocols (with security) and browsers.� Moving toward IMAP and Exchange, administered through a single directory service.�� Web-based clients will be supported.
4.1.12. User/Calendar
Provides lookup/finger service, relaying finger access to user client machines.� Provides resources to support shared calendar service for resources and people.�Calendar entities will draw from Directory Service.
4.1.13. Web/FTP
Provides http and ftp access to well-defined content managed by users and groups.
4.1.14. Print
Print spool for several printers, network printers, and relay to several group print spools.
4.1.15. License
Provides license service for small collection of applications to large population of clients. Local storage provides license configuration info and binaries.
4.1.16. Login
Essentially all users have desktop workstations and PCs. Many remote servers exist in the organization. IDSG may need to provide a limited backstop login service, as exists today with ?huginn?.� CUSG will support the full function login, ala ?divine? today.
4.1.17. Management
Secure login access to infrastructure servers and runs network management software. It has limited access, with no DNS, NIS, etc.
4.1.18. Build Services
Several machines serve as build hosts for SWW for each of the supported client architectures. Currently this consists of HPUX 10, Solaris 2.5, Solaris 2.6, Solaris/X86 2.6, OSF 4.0, and Linux.
4.2. Computer User Support Group
The role of CUSG is to provide non-instructional computer and user support.� It should be evaluated on the satisfaction of the users, the ease at which technical operations are handled, the availability of the resources it operates, and the efficiency of that operation.� As a part of ERL, it offers its services on a contract and hourly fee basis to researchers and to the department. It should provide a clean interface to users who adopt to pay for its complete service package, including a clear process of handling, scheduling, and tracking work requests. It should be able to maintain a complete enough understanding of the customer environments to provide complete solutions on a proactive basis, rather than fixing only what the user knows to be of� issue. There should also be a clean interface for research or administrative groups that utilize the shared resources, but provide their own user support. It should be a vital, proactive group, constantly improving in quality. This means focusing its creative efforts toward better tools, higher quality of user support, cleaner billing and tracking, improved throughput and access to shared infrastructure.
The details of CUSG function are spelled out in its support contracts.� They will be based around the concept of user groups, collection of people that have some sharing of resources.� Many groups share printers and file space internally.� The individuals may switch around between machines.� The collection of users are aligned with a portfolio of research grants and may share a grant administrator.� Examples might be the theory group, systems group, robotics group, BSAC, controls, etc.� There should be good tracking of such relationships within CUSG, so that needs of a group can be met.� When a new machine is added to the group, it generally needs to look like the rest.� When a printer is added or moved, typically each of the clients should adjust.� When a visitor arrives and joins a group, there should be a straightforward (and quick) process to enable their operation.
IDSG is responsible for ensure that machines are available to support logins.� End-user support (CUSG plus research staff) is responsible for all user configuration, dot files, etc.
4.2.1. Complete System Contract Support
CUSG will provide computer and user support for groups of users.� This provides a single point of contact for assistance in procurement, complete installation in conformance with dept. standards, operating system and software configuration, configuration of client access to services and group resources, enabling of services to client, upgrades, and HELPDESK support.� It will provide tracking of problem reports, with escalated resolution.� It provides LDAP/account maintenance (verification, creation, updating, passwords), data restores, and resolution of issues related to user registration or billing. Service and performance metrics are spelled out below.
A System monitoring
����� Systems are actively monitored during business hours, and downtime notifications are automatically send to responsible personnel for immediate response.� All systems are tracked, and the uptime statistics are summarized and posted on the web as well as monthly reports.
B Access to HelpDesk for all user consultations and problem tracking
A contracted system with problem related to supported services will enjoy the highest “level 3” priority when dispatched from HELP.� This means a 90% problem resolution within 2 working days (8am-5pm) from the time it is dispatched from HELP (for a clear definition of the HELP priority levels, please refer to the HelpDesk?s publication).� If the request is determined to be of T&M nature, it will still be put on a “priority” status within CUSG?s T&M queue.� Priority T&M has a metric of 90% resolution within 1 working week.� All metrics are assumed to excluded from non-controllable factors, such as waiting for parts, vendor or software bug, etc.
C Mounting of the entire SWW (or NTSWW).
D System configurations, hardware peripherals, and software applications database management and tracking.�
E Network accessibility and management (DNS and IP)
F Installation of all “IDSG-sanctioned” system and security patches within 30 days of release.� All sanctioned patches will be officially released over the WEB, and status of installations will be reported via monthly report.
�� G Installation of all Lab sanctioned OS upgrades for standard configurations within 3 months.� This is also done at user/owner?s discretion.� Notifications will be sent one month in advance, and actual upgrades will be reported via monthly report.
�� H Minimum of 3 verifications per year per system.� This will include the system setups, user access, UCB tag number, serial number, hardware/software support, contact person, location, monthly fees, backups, and all recommended security checks published by the Lab?s CPPM.� Reports will be sent to owner/user of the system, as well as departmental inventory staff.
�� I General system security measures :
1. Standard tcp_wrapper templates as published by IDSG;
2. Central system logging and data analyzed;
3. No local root/Administrator access;
4. In case of security incidents, all required actions;
5. Quarterly local password checking, if applicable;
�� J System crash diagnostics and recovery
Contracted systems emergencies includes system crash, failures of peripherals defined in the “standard configuration”, etc.� The CUSG will try every means to get system backup on line, including the option of replacing hardware.� All standard services should be restored and system resume service two working days.
�� K 1 GB of disk backup
This service is included with contracted support; however, users can opt out of it and will get $25/month credit.�Note that opting out of this service will also void the service commitment associated with “J”, with the exception of a cloned situation where the master build is readily available.
�� L User account management and distributed printing setup
Basic NIS (CSD) domain services includes user passwords and accounts, automounter maps, netgroup privileges, etc.�Contract system management also includes setup and maintenance of distributed printing.� However, access to distributed printing is a recharge function and not included.
�� M Monthly system status report
This will include all the information associated with all services rendered on the system, but also, at the CUSG?s discretion, be used to announce future plans and services offerings.
N Root/Administrator access on the system managed is restricted to CUSG staff only.� Root/Administrator passwords are not to be shared or given to the customers, and access will be secured by the CUSG.
4.2.2. Self-Administered System Support
HELPDESK is available to authorized ?technical POC? for any groups selecting ?self-administered? package.� Users of those systems should contact their authorized administrators first for any kind of problem reporting or user support, and the authorized technical POC, after gathering all the facts, can access the HELPDESK.� The priority is based on the nature of the call and follows the same rules of the HELPDESK priorities.� System must conform to all published EECS computer security and administration policies.� Direct user support will be charged on an hourly basis, does not inherently provide group-level consistency, and is of lower priority than contracting users.
4.2.3. Additional Services
Several additional services will be provided on a time and materials basis, as described in the labor contract.
4.3. Instructional Support Group
�The Instructional Support Group supports the specific needs of instructional accounts, the focused software base associated with instruction, the computer laboratory resources, its dedicated resources, and its share of shared resources. The functionality should be a discrete, compatible subset of that supported by CUSG to minimize the overhead in transferring research efforts into the instructional program, to better utilize faculty and student time, and to maximize the benefit of technical staff efforts.
4.4. Electronics Support Group
The electronics support group is oriented around the departmental needs for development, support and maintenance of instruments, embedded controllers, electronic devices, audio-visual equipment, and laboratories containing such equipment. It utilizes the infrastructure where computers are involved in its work.� It is primarily responsible to the needs of the ISG and department, and provides its services on a recharge basis to research groups. A clear and transparent prioritization of work scheduling will need to be maintained, with instructional needs having priority, within reasonable limits.
4.5. Open Issues
This document has not address the specific needs of AV in classrooms and conference rooms.� A clear funding model and service discipline will need to be developed.� The work is performed primarily by ESG.
We are currently working through the specifics of the transition of capital equipment, debt, people, etc.
The current modem service is simply folded in without improvement.� It consists of 64 non-instructional and 48 instructional modem pools, each roughly half 28.8 and half 14.4.� The last estimate for replacing these was 250K$. We recognize that in the long term, it is unlikely to be cost effective for the department to provide this function in the presence of many ISPs.� Wherever possible, we are encouraging faculty to use the free campus faculty modem bank and others to use the SHIP service ($10/mo) provided by IS&T.� (IS&T also provides dedicated modems for $70/mo.) Many of our students have access through the residence halls or ISPs.� The connection of last resort remains the campus Warhol and 643-9600 services, and the EECS modems.�� We will work actively with IS&T and local ISPs to develop a viable alternative.
As we complete the gigabit connectivity between Cory and Soda, we will also place the department on the campus Tier 2 backbone.� Several technical details remained to be worked out, and these will interact with issues of what portion of the network IS&T supports.� As part of that, we will need to address the proposed per port IS&T fee.
The Campus ?Commission on Computing? last year recommended campus support for faculty computing.� Moneys are being distributed through the deans, and we will need to determine how the department will receive this support.