Much of what is written about DevOps—a set of principles that helps development and operations teams work more effectively together—is delivered from the perspective of developers. In my opinion, DevOps needs to also take an operations point of view in order to be effective and practical. This article is all about putting the “ops” back into DevOps, so to speak.
Operations professionals are responsible for ensuring that IT services are available without interruption or even degradation in services. IT operations is a tough job and I have worked with many technology professionals who were truly gifted in IT operations with all of its functions and competencies. Many IT operations staff perform essential, albeit repetitive, day-to-day operations tasks that are essential to keep critical systems online and operational. In some organizations, mainframe operators are not as highly skilled as their development counterparts. When developers observe that operations technicians are not highly skilled they often stop providing technical information because the developers conclude that the operations technicians can’t understand the technical details. This dynamic can result in disastrous consequences for the company.
I have also worked with top-notch Unix/Linux gurus in operations who focused on keeping complex systems up and running on a continuous basis. IT operations professionals often embrace the IT Service Management Forum (itSMF) ITIL v3 framework to ensure they are implementing industry best practices for reliable IT services. If you are not already aware of ITIL v3, you probably should be.
The ITIL v3 framework describes a robust set of industry best practices designed to ensure the continuous operation of IT services. The ISACA Cobit and the SEI CMMI are also frameworks that are used by many organizations to improve their process along with both quality and productivity. CM professionals should particularly focus on the guidance in the transition section of the ITIL pocket guide, which describes change management, build and release, and configuration management systems (including the configuration management database, or CMDB). With all of this guidance, do not forget to begin with an understanding of the application and systems architecture.
The first thing that I always require is a clear description of the application and systems architecture. This information is not just for my entertainment. For build and release engineers, understanding the architecture is fundamental because all of my build, release, and deployment scripts must be created with an understanding of the architecture involved. In fact, development needs to build applications that are designed for IT operations.
Many developers perform on test-driven development (TDD) where code is designed and written to be testable, often beginning with writing the unit test classes even before the application code itself is written. I have run several large-scale automated testing projects in my career and I have always tried to work with the developers to design the systems to be more easily testable. In some cases this actually included hooks to ensure that the test tools could work without finding too many cosmetic superficial issues, which we usually call false positives. Test-driven development is very effective and it is my view that applications also need to be designed and written with operations in mind. One reason to design applications with IT operations in mind is to implement IT process automation.