An Internal Support Agreement can keep developers and support staff from each other's throats

Of all the battles inside IT, none have been uglier than those between applications development and the infrastructure support organization. Creating an internal service level agreement can help prevent this rift.

By Harris Kern

Businesses have enough competition outside the business without having it inside as well. I propose creating an internal service level agreement called an internal support agreement to keep your infrastructure support group and your applications development staff away from becoming adversaries.

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.

Tips in your inbox
TechRepublic's free CIO Issues newsletter, delivered each Monday and Wednesday, covers C-level managerial advice, from HR best practices to infrastructure management tips.
Automatically sign up today!

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. When designing an Internal SLA (for supporting a development server) the first area to start with is defining security privileges.

SLA elements to define

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