12.3 Policies

System administrators cannot operate with just the business objectives as guidelines. There is no setting on Linux or any other operating system where you can adjust a company's revenue or market share and business strategies. After all, market analysis is not the expected expertise of the system administrator.

System administrators need a set of guidelines that are derived from business goals and represent implementation of these goals in more technical terms. Management usually communicates such guidelines in the form of policies. To keep the focus on the key requirements, policies are most effective if they are few.

12.3.1 How to phrase a policy?

In practice, all system administrators follow policies, written or unwritten. The more extensive an installation is, the more obvious becomes the need to have formal, written, and agreed-to policies. Like laws in society, policies are needed as a guideline for potentially contentious issues within an organization. And like laws, policies can be phrased in very general terms and remain so, if they express a commonly agreed principle. Where there is less agreement, the policy is refined to a more specific statement.

For example, a common issue of contention is that of storage space usage. While available space, no matter how much there is, tends to get filled up as if by a law of nature, it is the job of the storage administrator to make sure that the company's key applications do not run out of storage. The goal of keeping storage available must be achieved within the limits of a budget. What could a policy look like that is to contain storage requirements?

A general policy could state that "All users must use space economically." This is flawed in two ways. For one, it implies that users are doing something wrong. Thus, it is likely to antagonize the very people who are being asked to cooperate not a good approach.^[20] Secondly, it does not account for application data or for the gray zone where users are consuming space through applications they use.

^[20] At the following URL, a white paper explores the psychology of policies and provides a detailed example for a storage policy and a matching SLA: http://www.ntpsoftware.com/WhitePapers/docs/DoYouNeedAStoragePolicy.pdf.

Assuming that we are in an environment where users access mainframe storage through the Linux images that they use and through the applications that run on these images, a more diplomatically phrased policy could state: "All Linux images are assigned to storage groups. At the end of each month, any group approaching 90% of its storage limit is reviewed to see if it is appropriate to raise the ceiling." This raises the awareness that there is a ceiling for what can be used at any time without pointing an accusing finger at anyone. Which image is allocated to which storage group is negotiable. For storage issues, this is probably still too general. z/VM could add a refinement of this policy, since it provides the possibility to balance the relative usage of space within a group and prevent a single image from seizing most of the available space.

A more specific policy could state that there are fixed quotas for the amount of space for each Linux image. ISPCompany provides Linux images to its clients and must be very specific with what a client is entitled to. Policies are normally intended to be long-lived, so the actual quotas are usually recorded elsewhere, for example, in a service level agreement (SLA). An SLA is an agreement between two parties, for example, the IT division and the sales division of a company or between a company and its clients. It states, in explicit terms, what one party commits to deliver to the other. In our example, this could include the space quotas for users.

To manage its space requirements, ISPCompany sets space quotas in the SLAs for the standard Linux images which it offers to clients. For example, under the terms of its standard contract, ISPCompany allows 100 megabytes of storage for a Web-hosting image that is intended for static content. Linux can be installed to include the function for assigning quotas to users and groups, and most distributions includes this function.

12.3.2 Why use policies with your Linux projects?

Why do we discuss policies in a book on Linux on the mainframe? Using Linux on the mainframe means change and might call for adaptations in your policies. Especially for companies that have been operating successfully with established procedures, change can be seen as a threat to the company's success. New policies are a means of enabling the required change and at the same time confining it to where it is necessary. Thus, those in charge of the Linux project have the freedom they need without everybody else feeling that all rules are being overturned.

We asserted that Linux could provide a platform for rapidly deploying new applications in mainframe shops. StoreCompany might well have policies in place that require lengthy test runs before a system can go into production. While this is perfectly appropriate for a z/OS system that processes financial transactions, it could defeat the purpose for having Linux as a fast deployment platform. Rather than scrapping the policy for z/OS systems, the policy can be altered. It could apply different rules, depending on what kind of system and application is to run. An acceptable solution to this simplified problem could be to continue with utmost care for transactions but to add a fast path for other applications, such as new Web interfaces, to be run on Linux.

ISPCompany has a business objective of being able to quickly respond to client requests for setting up one of three types of standard Linux images. To ensure that this goal can be attained, a ISPCompany policy states that there is a fixed set of services and an SLA for each of these types. No alterations or special provisions, no matter how simple, can be made to the three low-cost types. Otherwise, staff might get carried away with accommodating minor requests for customization and affect the speed of deployment as well as maintenance. After all, ISPCompany offers a separate category where both the fee and delivery time depend on the extent of the requested customization.

Let's assume that the SLA for one of the types also states the following: "Since we do the availability management for you, you are eligible for a rebate on your monthly bill if your server is unavailable for more than a one hour period." We will build on this example in the following sections on procedures and tools.