Over a million developers have joined DZone.

An Agile Introduction to DevOps, Part V: Afterlife

DZone 's Guide to

An Agile Introduction to DevOps, Part V: Afterlife

Gil Zilberfeld continues his series on Agile and DevOps with a discussion about the always-unfinished nature of DevOps work.

· DevOps Zone ·
Free Resource

This is the fifth part of a series on Agile and DevOps. Part IPart IIPart III, and Part IV should be read first!

1ew9hxSo we’ve shipped our software. It's alive!

However, DevOps work is never done. In fact, the old Ops part started here, and if there’s any point of having live software in the hands of the customer, this is where we need help.

For example, we need to think of are the first seconds, minutes, hours, or days, the software is alive. What happens if something goes wrong?

What Will Happen Next?

Yes, these are risk-tainted glasses again. Depending on the risk involved, we might need to do some heavy mitigation.

Now, imagine going back twenty years ago, even more, when there was a horrendous bug we discovered after release. Imagine how many floppy disks or CD-ROMs we’d need to ship with the fixes. They didn’t call them service “packs” for nothing.

Yup, that was totally Ops. It’s easier today since we don’t need to reprint CDs, but that doesn’t mean it’s gotten simpler. The ability to push software in live mode also means it’s simple to push crap out. Mitigation is done DevOps style.

The first thing on our plate is to identify if something has gone wrong. We need proper identification and reporting and have it done early. There are those early feedback cycles again.

Monitoring mechanisms are part of the DevOps bag of tricks. Some of it relies on things the software produces and needs to be coded in. Some of it is environmental stuff that can be put on top of the product. All this combined can create lots of monitoring data.

Ain’t Nobody Got Time for Dat

The data then needs to be sifted through. Monitoring combines flagging issues with the appropriate information for reproduction back at the lab. Ops alone doesn’t cut it here; this is where we need the dev team collaboration.

We need to define what is important, what to track, at what frequency to track, how to get the information and how much it all costs. This is not just DevOps. It’s the responsibility of product, Dev, test, Ops, support – anyone in the product organization.

And that data collection is not static. The needs change all the time, because the product, environment, users, and usage change all the time. Monitoring data is the feedback mechanism we need to make our product better, and as with the product functionality, it changes too.

We don’t just limit our tracking to availability or load. It’s not just limited to the functionality. In fact, all this data can be aggregated and point us toward business KPIs.

(This would be a good time to talk about the I in Key Performance Indicators, since we keep forgetting that these indicators should be leading ones, as in, before something bad happens.)

So, DevOps combines the mental energy of everyone in the organization to forecast issues, flag them as quickly as possible, visualize trends, and cover all we can think of to see how to maintain an ever changing product.

Yes, shipping is just the beginning.

One more post to go. It will be about getting more feedback into the product.

devops ,agile ,software deveoplment ,devops adoption

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}