| The agile DevOps series contains the following posts: | |
|---|---|
| What is DevOps | Working software |
| The environmentalists | Ship ahoy! |
| Afterlife | |
So we’ve shipped our software. IT’S ALIVE!
But 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. Today it’s easier, since we don’t need to re-print 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’s 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 are environmental stuff that can be put on top of the product. All those combined can create lots of monitoring data.
Ain’t nobody got time for dat
Which then needs to be sifted through. So 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, 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.
So we don’t just limit our tracking to availability or load. It’s not just limited for 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 the 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.