When a SysAdmin implements a DevOps approach to their environment, there are many things that need to be considered. Not the least of which is to develop a strong line of communication between the developer and the SysAdmin. Occasionally, and more frequently as time goes on, I’m finding that these people are often one and the same individual, as coders or scripters are spreading their talents into the administrator’s roles. But, these are discreet skills, and the value of the scripter will augment the skills and value of the system administrator.

Process is a huge component of the job of a sys-admin. The ordering process, the billing process, the build process, the delivery process. How many of those tasks could be automated? How easily could these functions be translated to the tasks that other organizations face in many mundane functions that are conscripted and therefore could be scripted?

The wonderful book, The Phoenix Project outlines how an IT manager leveraged the powers of organization, and the development of process aided (perhaps facilitated completely) the recovery of a financially strapped, at one point industry leader.

Initially, the obvious communications issues, which had bred the perception that IT was falling behind in its requisite tasks. Systems, trouble tickets, and other tasks were not being delivered to the requestor in any sort of accurate time frame. As this man analyzed both perceptions and realities of these things falling short, he began questioning various stakeholders in the company. Both people directly affected, and those outside his realm were solicited for advice. He also evaluated process within the various groups of the organization, found out what worked, and why, then took the lessons learned, questions he had learned to ask, and successes and failures to help him to establish his points of failure, and those assets worth leveraging. In some cases, these assets were skills, individuals, and personalities that helped him to reallocate these assets, or to assist them in streamlining his functions within the organization to gradually or regularly gain leverage against the problems that arose, or fix those that had long been established.

A number of key takeaways from his experiences in this series of actions and interactions illustrate just what I was trying to outline. For example, the willingness to question both oneself and one’s both ally’s and adversaries in a given situation, with the goal of making things better is so very valuable. The willingness to take a critical eye into the workplace, both critically against yourself, but your successes and failures, so that the fixing of these issues becomes a clearer task may be the only way to achieve success.

These stories really don’t relate directly to the tasks of a sysadmin, but they translate to those quite palpably. What does your process look like? For any given set of tasks. How logical are they? Can they be eased, smoothed, or facilitated any more swiftly? Simple questions like, for example, how many hours does it take to do this thing can be critically evaluated, and thus, processes can be potentially revised such that those metrics can be improved.

Often, as I see it, the scriptability of some of these tasks, such that we leverage the systems themselves to aid us in these tasks, and allow us to shave off precious hours, improve customer perception, and gain credibility again, in front of our customers are the IT version of DevOps. But, the willingness to embrace this new paradigm can provide benefits in so many ways.

It all begins with communications. Don’t be afraid to allow yourself to be seen as not knowing the answer, but always be willing to seek one. We can learn from anyone, and by including others in our evaluation, we can also be perceived as humble, collaborative, and productive.