SOLUTION

Consolidated system of IT-processes automation

Introduction

In nowaday company achieved sufficient level of IT-development scripts cover all infrastructure. They are used for management, monitoring and other automation tasks and are applied in a lot of systems. Scripts are a perfect tool for solving specified or temporary tasks locally appearing in the company, which have not ready-to-use appropriate solutions. Nevertheless there development is much easier than creating full-featured applications that allows getting problem solution quickly and by available means. However this solution has reverse side.

While organizations are tending to increase management and automation level of their IT-infrastructure, amount of various processes automation scripts increases. However these scripts themselves are not always organized properly enough and it often bears a risk in case of administrator who has created the script leaves (for his vacations or even for another company). Necessity to change or expand script quickly can result in long idle time of organization’s infrastructure while new employee is studying running processes (in case it is even possible).

The offered solution allows creating consolidated storage of scripts being applied in the company, monitoring their running status and failures, carrying out changes audit and transforming them from notepad quick notes to the level of serious and flexible organization.

Problem

Usually a lot of companies while automating their systems find themselves covered with a bulk of scripts written by different administrators (including ones retired long ago), located in different places (from administrator’s work notebook to enterprise servers), controlled by nobody (log-files are written to location, about which nobody knows), written in different languages, in different styles, using different libraries, non-updatable and undocumented.

Let’s consider these disadvantages in details:

• No documentation or incomplete/fragmented documentation.
• Scripts are created for specific problem and are directly launched into execution. Since the problem is solved, documentation is forgotten. The reason of this also may be the idea that the script is required only for a couple of times but, as the experience shows, there is nothing as permanent as temporary. Often scripts written for one or two times have been working for years.
• Only script’s author has competency in it. However even the author of the script written 5 years ago can face problems while trying to figure it out or edit it.
• Due to absence of documenting standards organization can face significant problems when its administrator leaves for vacations, retires or is promoted. Process of experience sharing is complicated (often an administrator cannot even remember all used scripts written and implemented by himself).
• Scripts location. The script on which critical business process of the organization depends can permanently run on administrator’s personal notebook. Then this notebook crashes or the administrator leaves for vacations having taken it with him and having forgotten about the script (which is maybe known by nobody except the administrator).
• Unification of scripts development.
• When there is no unified standard of scripts development, chaos can come to the scripts. So, for Windows systems the scripts written in Windows PowerShell can be found side by side with scripts written in VBScript, CMD, Python or even in sh executed via cygwin. Everybody wishes to write in the language he likes, and in such latitude at first there are no problems, until a person having no notion about this language need to figure the script out or edit it.
• Even when scripts are written in one language, there is a problem of scripts writing style. This is not nearly only aesthetic factor but also such items as errors processing and logging. The code of scripts written by one person and edited by another one is really terrible and hard to understand.
• Cooperative development or even maintenance is rather complicated. It is very difficult to ascertain accurately who has edited the script in such a way that critical data are deleted every forth full moon.
• Scripts may depend on both additional components installed locally on the server (undocumented, of course) and personal author’s parameters, e.g. aliases. It still complicates their using.
• Logging. Functionality of execution and errors logging is included during development to only a few scripts. Generally an author supposes that he will add this feature in case problems appear, but such approach does not help when history information about script execution is required or in causation of single non-reproducible failure.
• Audit. In common case it is impossible to track what changes were made and who made them in the script. Even when audit is enabled, changes in one parameter cannot be distinguished from adding new feature or from complete script rewriting.
• And the last but not the least problem of scripts development is consideration of its viability. Although mostly automation scenarios indeed help to save time, sometimes time spent for their development may be sunk time expenditures in principle.

Solution

We offer solution of all problems listed above using leading specialists’ experience in professional scripts development in two ways:

The first way is creating procedural regulations for scripts development, documenting and exploitation. These regulations will help you to create formal basis for order bringing and maintaining. Regulations will define standards and recommendations, the same for the whole organization, such as the following ones:

• Decision-making procedure for decisions on necessity of developing script for operation automation.
• Preferred script languages and methods of integration with systems.
• Feasibility of using third party additional components.
• Approaches to scripts location and execution.
• Styles and recommendations for code organizing.
• Arranging collaboration.
• Logging workflow.

The second way is a system for automation and coordination of automated processes, “orchestrator”, such as Microsoft System center Orchestrator or VMware vCenter Orchestrator. Orchestrator has capability of developing complicated automation scripts in graphical interface, called “procedures” (RunBook). Graphical expose significantly facilitates reading and understanding logic of procedures for administrators regardless which programming language they prefer. Moreover, Orchestrator allows executing common scripts written in any language, remotely as well, in Windows and *nix systems that provides saving existing resources and processes without having to completely rewriting.

Orchestrator also allows getting following advantages:

• Consolidating all procedures within one database that allows avoiding their loss. The database safety and availability can be provided by common means of backup and duplicating.
• Several execution servers. For executing procedures several servers can be dedicated. They can be used for load balancing as well as for procedure restarting on the other server in case of failure of the main server.
• Capabilities facilitating collaborating with procedures. Procedure can be checked out for editing and then checked in. All changes are saved in audit log and can be used for searching causes of problems resulted from, for instance, recent changes.
• Automated logging all activities included into procedure allows facilitating debugging and analyzing previous executions.

One of the main stages of such solution is analyzing available infrastructure of scripts and existing processes in the organization. Only then this stage is followed by development of regulations and approaches being appropriate for the organization and allowing improving situation with sufficient flexibility but without doing harm for the organization by complicating the process needlessly.

As a result of solution implementation your organization will be able to use automation scripts in a good cause without putting the company to additional risks but with increasing efficiency by reducing administrators’ workload and freeing them from routine work in favor of other tasks providing benefit to business.

To know more about regulations, recommendations and approaches to solving your problems you can use special form.