IT administrators love to write scripts – at least, the most talented ones do. Scripting provides a powerful platform to automate simple and repeatable tasks. However, like with most powerful tools, there is an overwhelming temptation for scripting to be overused. When faced with a project deadline, a high-pressure failure event, or even just the need to simplify day-to-day events, administrators can unintentionally create scripts that are so complex they actually put the business at risk. I must confess that during my 2 decades-long tenure as an IT administrator and engineer, I’ve written a lot of scripts…a LOT of scripts…and learned a lot of important lessons. Scripting was never intended to replace application programming. Its purpose is to provide a quick and easy resource for performing simple and repeatable tasks. It is not uncommon, however, for scripts to start simple but balloon over time into complex code that is virtually unintelligible even to its author.
Managers and executives are often horrified to discover how many scripts are relied on for the successful operation of their IT infrastructures. But they usually don’t discover this danger until a business-impacting failure instigates an investigation and subsequent audit. In a typical business IT environment, scripts are everywhere. Unfortunately, it is often the overreliance on custom scripts that leads to systemically failing and out-of-control IT environments. Listed below (in no particular order) are the top five reasons an excessive reliance on custom scripts is hazardous to your business:
- Custom scripts are error prone – It should be no surprise that people make mistakes. However, there’s something about the scripting process that extenuates human errors. People do not think like computers, and our leaps of intuition sometimes make us miss critical steps or fail to create proper syntax in a logical chain. Computers, unfortunately, are very unforgiving of our logical flaws and make no allowance to adjust to our intent, but rather bow to the empirical lines in our code. The most glaring errors will likely be discovered quickly the first time the script is run, but less obvious errors may sit dormant for weeks, months, or years until conditions are right to execute that part of the code – and then, *BAM!*, the whole service unexpectedly crashes.
- Lack of support – When a script fails, there is no hotline to call, no support agreement to hide behind, and nobody else to blame except your IT administrators. Scripts rarely receive more than the most rudimentary of testing, certainly never enough to account for all the complex variables in a typical enterprise IT environment. If an improperly coded script inadvertently deletes data, crashes systems, or in any other way damages a production environment, the cost and responsibility for resolving the issue is entirely on business operations. This could potentially result in significant lost revenue, damaged reputation, and costly remediation.
- Loss of key knowledge – Custom scripts are typically created and maintained by a single administrator. Should that individual change roles or, worse, leave the company entirely, the script will be unmanaged until it breaks or needs to be revised. At that point, another administrator will need to decipher the script to make appropriate changes. In the best-case scenario, this is time consuming. However, more commonly scripts are extremely complex and not properly documented – a coding style often called “spaghetti-ware.” Untangling this coding mess can take weeks while services remain down and manual processes must be performed to maintain affected operations. After which, the environment is still at risk of the scripts new administrator’s eventual departure.
- Environment changes – Administrators write scripts to run on the environment existing at the time of their development. However, the reality is that IT environments are constantly changing, with files and applications frequently being moved, configuration settings periodically being altered, and software components continuously being patched and updated. Any of these environment changes could cause a number of scripts to fail in ways that may not be easy to identify or resolve. For instance, I shudder to think of all the PowerShell scripts that will need to be edited following the recent release of Windows 10.
- Script sprawl – As administrators become increasingly confident in their scripting abilities, they find it easier to resort to custom script to resolve a wide range of mundane and event-based problems. Over time this results in an overwhelming number of scripts – some active, some inactive, some in use, some no longer relevant, and some long forgotten. Script sprawl is a key indicator of an out-of-control IT environment and results in an inability to rapidly identify and resolve the root cause of critical problems. This problem is compounded when administrators reference scripts inside other scripts. Under those conditions, when a failure occurs, it isn’t even clear which script is causing the issue and all scripts in the chain will need to be reviewed to find the offending line of code.
It is ironic that even though scripts are initially adopted to simplify business process management and improve IT performance an overreliance on custom scripts can actually reduce IT effectiveness. To be clear, I’m not advocating that the use of scripts should be eliminated completely. Simple, well-documented, and easy to manage scripts can be an invaluable tool for automating processes not supported by any other available resource. However, all custom scripts supporting an enterprise environment should be cataloged and carefully maintained; their size and number should be limited; and their authors should be held accountable for any breaches in protocol.
To reduce the dependency on custom scripts while increasing the manageability of business IT services, organizations should adopt enterprise-class automation platforms such as those for process automation, job scheduling, and workload automation. These classes of solutions provide supported platforms that are fully tested and constantly updated to reliably support broad environment configuration. The most effective automation solutions are easy to use and fully customizable so they can be rapidly adapted to meet any business requirements. Automation platforms are the key to enabling the business IT agility, performance, and reliability envisioned by IT administrators but without all the challenges inherent with custom scripts.
For more information on automated solutions from HelpSystems that can eliminate a reliance on custom scripts, go to www.helpsystems.com/skybot