Home > Articles > Software Development & Management

Let's Play Together = Internal Support Agreement

  • Print
  • + Share This
Businesses have enough competition outside the business without having it inside as well. Harris Kern proposes creating an internal service level agreement--called an internal support agreement--to keep your infrastructure support group and your applications development staff away from each other's throats.
Placing special emphasis on a comprehensive approach combining organization, people, process, and technology, Harris Kern's Enterprise Computing Institute is recognized as one of the world's premier sources for CIOs and IT professionals concerned with managing information technology.
Like this article? We recommend

Like this article? We recommend

In many of the companies we visit, the applications development staff is located at the division or business-unit level. Unfortunately, the support groups reside in different buildings. How does a centralized IT infrastructure support group provide system administration services to scattered corporate developers? This and other issues should be clearly defined in an internal support agreement.

Of all the battles inside IT, none have been uglier than those between applications development and the infrastructure support organization. Even when development and support were centralized under one organization, there was always finger-pointing. The charter for applications development is to design, develop, and deploy systems into production as quickly as possible. The charter for infrastructure support is to ensure that proper standards, guidelines, and QA testing are adhered to, and that thorough documentation is provided. Most of the issues arose around implementation and support of mission-critical applications. Development would blame Operations for messing up a restart to a system error, or Operations would blame Development for lack of QA or support. There were many other issues of this nature.

As in the mainframe era, developers still want the centralized IT infrastructure staff to support development servers in a limited way for such mundane tasks as backup-and-restore. But today's development servers are a problem for both the development group and infrastructure support. Developers want top-level, "root" or full administrative access to their development machines. This is a problem because owners of root passwords can bypass normal safeguards and unwittingly destabilize a machine in seconds.

On the other hand, developers do need occasional unlimited access to a machine. Denying access makes their jobs more difficult than necessary—or even impossible. What to do?

To solve this problem, we devised joint root authority. The infrastructure support organization and the two most senior developers will own root access. If developers abuse root privileges, the infrastructure organization will no longer support development servers.

One of the most important pieces of this puzzle is an internal Service Level Agreement (SLA) between the infrastructure support staff and the applications development staff. In this document, expectations are clearly outlined for both groups. The following sections show some of the key categories and examples of an internal SLA.

NOTE

Every shop will have different requirements, of course—these are only examples.

When designing an internal SLA for supporting a development server, the first area to start with is defining security privileges.

Server Root Authority

Root access to support servers AD0001 and AD0002 in the following example is given to Mr. A and Ms. B. Mr. A and Ms. B are to support/back up each other in case of illness or vacation. If they're both unavailable, you would contact Technical Services.

All changes to a server's root will be audited to provide a trace of root user activity. The following activities are accomplished by Technical Services upon request:

  • Kernel changes

  • Disk reconfigurations

  • Modifications to the root user environment

  • Installation of binaries into the system directory structure

  • Modification to any network-related configuration files

  • Manipulation/modification of any system daemon run at the root level

  • Changes to the /etc/rc* files

The following is a partial list of activities that may be accomplished by the applications development root owners:

  • Change /etc/exports for mount directories

  • Change /etc/fstab

  • Add users/groups

Server Availability Hours

The following schedule determines server availability as established between the applications development and infrastructure support teams.

  • 00:00–23:59 M, T, W, Th, and Sun

  • 00:00–23:00 F

  • 03:01–23:59 Sat

  • 20:00–23:59 (once a month for system maintenance, upgrade, and testing, all will be posted through Change Control)

Backups

  • Full system backups start at 23:00 every Friday, with a total downtime of four hours.

  • Incremental backups start at 20:00 every Monday–Thursday

NOTE

In this example, if users are on the system while incremental backups are running, any open files would not be backed up. This is the sort of important point that should be specified in advance in your internal SLA.

Support Responsibility

Services

Group

Types of Services

Hours

System Software

Technical Services

Solaris, Sybase, installation, upgrade, maintenance

00:00-23:59

System Hardware

Desktop Support

Server, monitor, workstation, installation, maintenance

00:00-23:59

Application

Application Development

Set up applications and perform demonstrations, project file access

08:00-18:00


  • + Share This
  • 🔖 Save To Your Account