From Dev to DevOps with better monitoring
15 Jun 2018
DevOps has been the way to go for some time, but how do you get your development teams to start adding Ops to their daily routine? Many development teams are still completely focussed on delivering their product and start developing the next product right after they are done with the last one. Teams like this, focus on deliverance and not on the product itself. A DevOps team however should also monitor, maintain and fix the products they delivered. For many Dev teams (and their organisations) transforming into DevOps it is difficult to find or make time for monitoring and maintenance. Isn't it much cooler to build new features than to perform boring maintenance tasks of browse through monitoring results? To overcome this teams should get to know their application, know how it performs, when its behavior is erratic, how users interact with it, when it is slow and why. But how do you get teams in touch with their application? The right use of monitoring tooling can be help here.
Why monitoring
Most organisations have monitoring tools in place, and those who don't should get them right away. If you're lucky the operations department looks at the monitoring tool occasionally and calls you if something turns red in the tool. If your are really lucky, automatic alerts of your monitoring tool are used and your operations people get a notification if part of your applications goes down. But too often monitoring tools are only checked occasionally by af handful of developers. Monitoring should be used proactively, teams should be notified when their application behaves erratic, so fixes can be applied right away if necessary, preferably before any customer notices something is not working.
Bringing monitoring to teams
Just telling teams to use the monitoring tools doesn't work however. So your best bet is to bring monitoring to the teams. Some ways to do this are :
- Display the output of your monitoring tool on a clearly visible screen so all developers can see how their application performs
- Make viewing and discussing monitoring results an integral part of team meetings. You could for example review the performance of the application with the team during a team Retro session
- Send notifications for certain monitoring events (e.g. too many errors, too high response time) to all team members working on the application being monitored. You can use team chat applications like Slack or email
- Send weekly/daily mailings to all team members with monitoring statistics of the last week/day
- Show monitoring metrics (amount of errors, response times, etc.) in team Demo's to show team members and stakeholders what the quality and stability of their application is and make commitments to improve certain metrics
You have to know your teams to be able to determine which combination works best. After working this way for some time the teams should begin to look for possible issues in their applications without being asked. How long this takes depends mainly on the maturity of the teams. Once teams use the monitoring tools in a proactive way, they start to feel more responsible for their application. This should result in teams wanting to fix not only fatal site crashes but also performance issues, security issues, or sub-optimal implementations. Team focus will shift from just delivering an application to delivering and maintaining a high quality application.
Conclusion
Getting development focussed teams to start feeling responsible for how their applications actually behaves after they delivered it is a difficult process. Bringing metrics from monitoring tools to the teams in one of the ways mentioned here is an effective way for teams to start to get to know how there application really behaves in real live. This should in turn lead to teams feeling responsible for the behaviour of there application. The end goal should be teams fixing and improving their applications before customers start complaining about errors or low performance.