A system administrator assigned to help manage your application/service. Their focus is to manage the installation and updates of the application as well as prerequisite applications and services required by the application. They work closely with the customer who will be the application expert and will manage the day to day needs of the application.
There may be restrictions for which Data Classification Levels are permitted for each service offering. For more information about the Data Classification Levels, visit https://itsecurity.uiowa.edu/awareness/data-types-and-regulations/data-handling-guidelines. For data classifications of Restricted and Critical, approval from ISPO may be required as part of the request process for service. Please contact the email listed at the bottom of the service matrix for additional detail.
Monitoring is a general term for the variety of tools used to help ensure that the application and service you are using from EI is running at an acceptable performance level. At a system level, it includes continual checks for network connectivity, CPU and memory utilization, disk space, and tests for availability of critical processes such as ssh, ntp, and other OS support processes. At an application level, capabilities exist to check for http and other port specific responses or process specific items but are only at a high level and not fully deterministic of desired service response. See matrix for available options.
Alerting is the process of taking a monitored anomaly and making it actionable. Thresholds are set for performance which are monitored for compliance. If an error threshold is met, an alert will be escalated to an on-call administrator so that action can be taken to remedy the error. An example might be a network ping failure, or potentially a 404 error for a web application. Alerting hours may apply depending on chosen service level. See matrix for available options.
Automated alerting hours detail the hours during which error conditions for a service will be escalated to on-call personnel and/or service owners. These error conditions will be automatically monitored (system generated). Error conditions that occur outside of the designated hours will not be escalated or acted upon until the next available alert window. The hours listed are the maximum limits for each service offering and not the default setting. Please contact the appropriate EI Director if there are questions on alerting hours. See matrix for additional details.
Hours in which support staff are available to address issues with your service. Business day is defined as any weekday the University of Iowa is open.
Administrator support is available 24x7 but may require a customer to initiate the support request instead of an automated (system generated) alert. Customer initiated (via a call to ITS HelpDesk) is the after-support hours service offered for Specialized Application Service (SAS). For SAS services, a $125/hour support charge (1 hour minimum) will be incurred to the departmental MFK on file. Billable time will be rounded up to the half hour. See matrix for additional detail.
In the unlikely event of a critical incident with your service, the alert response goal is the expected upper limit of time needed for first response to your issue. This is not a guarantee of problem resolution time, but rather an expectation for initial contact to address the issue. See matrix for additional detail.
Normally, backups for VMs (virtual machine) are provided in a way that archives a point in time image of the entire VM. Restoration of this image is an “all-or-nothing" situation, where the entire VM is restored to the point and time of the image creation. However, in some cases, customers have a need for additional backups at a file level, such that they can restore a single file or directory if needed or for applications with open files (databases). In this case, file level backups are available upon request for physical and virtual systems, with corresponding costs for recovery operations.
A duplicate system used to test OS and application updates prior to deploying to a production server. If an application is Core, then we require a fully functional test setup to validate installations and updates. The test system must be functional enough for the customer and/or users to confirm required functionality prior to system updates. Details of the test configuration, or exception from having a full test system, will be defined in the business case document presented to the OneIT Governance board for CAS approval.
An additional environment used for more active testing of application updates. Might be used to verify/confirm new versions of an application or OS instead of applying to the test server so that the test server remains in lock step with production.
OS Security updates are security and maintenance updates for the operating system itself, typically supplied by the OS vendor. This service does NOT include any updates to applications. Customers can choose from various pre-defined maintenance windows.
Application updates are specific updates provided for the application, typically from the vendor, that will be installed by support staff within various pre-defined maintenance windows.
Troubleshooting and helping a customer and/or vendor to determine the cause of issues. Examples include reviewing application logs and working to solve issues within the application and associated components.
Request TLS/SSL certificates for the application, replace certificates prior to expiration, and revoke as needed when service is decommissioned. Certificate management is part of the monitoring solution within EI to prevent needed certificates from expiring. See matrix for available options.
This feature enables DNS, Layer-4, or Layer-7 redundancy capabilities controlled by an external Network Load Balancer, currently implemented using F5 GTM/LTM technologies. Customer support for this service will be provided by SAS or CAS teams, even for co-managed systems.
Host level firewall rules are local firewall rules that are configured and run on the system itself. In Linux, this is typically done using iptables, and in Windows, this is typically done using the Windows Firewall. These rules impact network traffic in relation to the application or system itself.
ISPO firewall rules are firewall rules that are configured and run on a dedicated firewall cluster maintained and operated by ISPO. These rules impact network traffic in relation to the campus network and the Internet at large. ISPO firewall rules must be requested via a form provided by ISPO at https://workflow.uiowa.edu/form/firewall-request.
VM Snapshots allow a “point-in-time" (limited duration) snapshot for a running virtual machine. This snapshot can later be restored if necessary. Typical use cases would be to set a rollback point prior to an application upgrade, for example. There is no charge for this service. Snapshots should be requested with a minimum of 4 business hours advanced notice. Snapshots are typically removed within 2 weeks of creation.
VM Recovery from snapshot is the process of restoring a VM to a state from a previous point in time, based on a snapshot that was taken at that time. This would typically be done by recovering to a previously created hypervisor snapshot. However, in the event of a catastrophic event, this option may involve a full restoration of the VM image from backup archives. Charges may apply if application troubleshooting is required.
Consultations are available for all customers to help us assess your needs and ensure you are receiving the service that fits your use case. Examples may include: Participate in pre-install or application update calls or meetings with the software vendor to represent the systems administrator for the server. Provide knowledge of the specific requirements of the U of I network and datacenter design as it pertains to successful application installation. May also be included in support calls to troubleshoot application issues in production or test environments.
Consultation services for intake and scoping of projects is a free service.
To be included as a Core Application, a business case must be submitted and approved by OneIT governance committee. The goal is to properly define the service and verify that it meets the guidelines for a core application. Example documents will be available in the near future.
See matrix for rate details. Time will be tracked and billed monthly.