Devops: You build it; you run it… sort of
DevOps seems to be sweeping through IT departments these years and for most developers it seems to be sen as a way of getting those pesky gatekeepers from Operations away and ship code whenever any developers feels like it.
The problem is however, that in the eagerness to be a modern DevOps operation, the focus is often solely on the benefits of faster releases (on the short term) the “DevOps” provide over “Dev to Ops”, and many developers do seem to forget the virtues Operations (should) bring to the party.
From my observations here are the top three fails when adopting DevOps:
- Too must focus on features, less on foundation. Often Operations is making sure that operating system, libraries and other components utilized by the system is updated for security and end of life. As these tasks does seem to provide “obvious value” for the users of the system prioritizing them seems to be a challenge (unless the developers find new cool features in the new version of a framework they want to use, naturally).
- Lack of monitoring tools. Making sure you don’t run out of system resources - be that disk space, memory or CPU - is boring. The same goes for customer support tools, diagnostic tools and other tools which forecast operational issues. As those tool belong to Operations, sure they can’t be important in DevOps and are often skipped or haphazard at best.
- No plan for handling incidents. As developers tend to move forwards and rarely lack confidence and thus the plan for handling incidents and operational issues is usually made ad-hoc when the issues occur. During daytime, when everyone is available this may not be a significant issue, but during nights, weekends and holidays, finding the right developer who can help often causes the incident to last longer and in some cases even worse if eager developers make changes in a part of the code they aren’t familiar with.
I do firmly believe that DevOps is the right way to build and manage IT systems, but I also find, that too many teams forget the Ops part and doesn’t incorporate the skills brought to IT from Operations minded people, and the potential to build better systems through an DevOps setup is thus often not fully realized.
(This post originally appeared on Linked)