From DEVops to devOPS to DevOps
Don’t take me wrong, I have fully bought in to the DevOps philosophy and continue to actively preach it at Emirates Airlines. However after having actively explored the DevOps developments for the past two years, allow me to share some observations wearing my ‘OPS’ hat.
The marriage between Dev and Ops to me often comes across as the relationship between Archie Bunker (Dev) and his wife Edith (Ops) from the famous 70s-80s TV serie All in the Family. Dev-Archie was the loudmouth and Ops-Edith was the voice of reason in the relationship.
Likewise in the DevOps relationship Dev today seems to dominate the discussions. Maybe as a result of tools-vendors (typically starting with an ‘I’, ‘H’ or ‘C’) that jump into the new revenue-stream that Continuous Delivery related tools offers them, but also due to the Holy Grail of Continuous Delivery that is being spread by DevOps High-Priests like Jez Humble. Before you know your company starts a DevOPS transformation journey sponsored by the board!
Ops is still trying to find her/his own place in this young relationship. OK it is good to see that Dev and Ops no longer sleep apart but the gender-gap between the two of them needs some serious work.
I only have to refer to some of the recent headline incidents that impacted some airlines to remind us that stability of service is a precious thing and this can never be put at risk at the cost of big-mouth Dev.
Here my 10 tips for Ops to ensure this relationship has a long and happy life ahead!
1) QoS accountability
Let’s make sure that we all agree that the DevOps team has FULL accountability for the QoS of the service they support. There is no head of IT Service Management to hide behind and for sure not Ops to blame!
2) Support is a team sport!
Like anyone in the Toyota factory could stop the production line in case of an issue, the same is valid for Ops. Ops duties rotate among all team members and for sure is not the task for the most junior in the team. All hands on deck when the application is down!
3) Monitoring is no afterthought!
Ensure that the operational monitoring of the application and supporting infrastructure is an integral part of your user stories as you develop the service. Also, your application standards will define when and how the application alerts abnormal situations. Finally, your organisation has a Monitoring expert in house that drives you overall monitoring strategy.
I refer to James Turnbulls’s excellent book The Art of Monitoring.
4) Re-balance Testing vs Monitoring efforts
High quality delivery was tattooed in our ‘waterfall’ mindset. We have spent way too much of our development efforts on testing applications to death. Accept Dev has its flaws but ensure Ops had the capabilities to detect issues immediately after deployment and ensure you have feature switches to switch off defect features in a seamless way.
5) Flatten your support levels!
If DevOPS is all about removing handovers and potential bottle necks, why do we need L1, L2 and L3 support? Away with it!
Remember support is a teamsport! Only by giving the team 100% of the support load they will start to take all support cases serious! They will start to automate repetitive tasks to ensure they are not interrupted too often and ensure that events are fine tuned! It maybe painful in the beginning but is essential to the succes of your DevOps journey!
Please do read Jon Hall’s inspiring ‘ITSM, DevOps, and why three-tier support should be replaced with Swarming’.
6) Track application reliability & maintainability!
ISO25010 states the need to track reliability and maintainability. Maintainability is defined as the degree of effectiveness and efficiency you service has
- Modularity
- Reusability
- Analyzability
- Changeability
- Modification stability
- Testability
- Compliance
The Software Improvement Group (SIG) did some good work on to define how to measure maintainability.
7) For God Sake: Track your Technical Debt!
A good product owner always balances the investments for functional enhancements vs those that are needed to clean up your technical debt. Don’t let your Tech Debt pile up and track it!
8) Ensure your Ops Tools are Agile!
Needless to say that as you move to a more Agile development world, your Ops toolset needs to be equally agile. Do not depend on other teams to update your Ops tools but make that skill an essential part of the team and ensure it has its place in your backlog!
9) Automate the Hell out of Ops!
Where CD aims to automate the full SDLC cycle, make sure Ops runs most of its time on AutoPilot. Standard Ops tasks should get fully automated through user-stories in your development backlog, and human intervention should be limited as much as possible!
10) Always be ready for the unexpected!
How much you monitor and how much you automate, expect things will go wrong! Don’t wait for that to happen on a Friday night, but test your Ops readiness at unexpected intervals. Adopt tools like Chaos Money and be ready for the unexpected!
In Summary:
99% of the lifetime an application is just about it ticking along and is not subject to changes even in a perfect CD world. It just does what it is designed for. The minimum you can do is to ensure that for these 99% of the time you are there when it needs you!! Only if Dev and Ops are equal partners we are ‘All in the Family’.
