Using DevOps for continuous process improvement.

Article written by Ian Morrison: DevOps Consultant

I have been to countless conferences where the sport of the day was seemingly for speakers to take it in turns defining DevOps. As a recovering system administrator who revered the old Sun Microsystems slogan “The Network is the Computer”, my peers and I had pretty much always practiced what these corporate managers were trying to describe.  

Before it was called DevOps, the folks that were running large systems effectively had their stash of secret weapons; scripting, automated deployment, incident handling runbooks, monitoring, name-spacing, documentation, and collaborating over IRC. To us, it was just best practice. It has been very interesting to see that the wider world has adopted these ideas as their leadership teams start to insist on increasingly higher standards of reliability, flexibility, scale, and performance.  

These days the tools and platforms have changed, but the principles remain the same. 

It is very easy to get caught up with the technical details when talking about DevOps; as somebody that has been on both sides of the coin, built systems and trained people on how to use them, I have seen that the temptation can be to focus on learning specific tools. There are dozens of mature DevOps tools out there today, and a modern organisation will likely see benefits from making use of many of them. However, in my experience, it’s best to resist the glamour of these tools to begin with. Instead try to zoom out and view your challenges from a higher level. The question I ask myself and customers continually is, “what is the problem you are trying to solve?”. Once you have explored that a little, the right tools and techniques should naturally follow. 

By stepping back and analysing the specific challenge you are facing, taking into consideration the challenges you have faced before, and are likely to face again, we can start to arrange our efforts so that challenges get easier over time. Each time we iterate over a process it gets better, and confidence in the system grows in return. 

Think of a thing you do regularly at work… Do you have a documented process? Have you tested the documentation by getting a team member to follow the process? What is the information that you will need while working through the process? How does the process change each time you do it in slightly different circumstances? The key concept to streamlining these problems is consistency. By analysing the process, minimising variations and potential permutations, it becomes possible to take a documented process and automate it. Automation in turn provides many benefits, not just labour and cost savings, but to me at least, automated processes simplify the environment, and therefore the systems you are managing by enforcing consistency. 

The idea is to identify chaotic business processes. Every organisation and their departments within, have things they do regularly that would benefit from automation and consistency. Start by defining the problem clearly, from there you can start to document the existing process as best you can. Identify the parameters that change with circumstances. Make it repeatable. And finally, when you can run a process at will, optimise it. Make it easier to maintain, more robust, inter-operate with other components or processes. Look for areas where human intervention is required; what information do they need? What do they need it for? And how can it be represented in the system? Can you describe the situation with a simple true or false statement, or if more granularity required?  By identifying these operational information requirements, the whole ecosystem can be enhanced to make work life easier for everyone. 

As an example, you have automated the build and configuration of a typical company laptop. At the end of the process a simple alert which says if it has worked or not might be enough. But if your builds are complex, and take a long time to run, your analysis might reveal a need for a decent logging solution so that if things go wrong, you can search through the logs to understand and resolve the problem, streamlining the process. 

People will continually try and define DevOps. In my mind, it’s simply about developing a better operations practice. Work out what the problems you’re trying to solve are. Identify the things that make life more difficult, and design solutions that minimise or mitigate entirely. If you would like a hand with that, please feel free to get in touch with the Towers Associates team.