DevOps On Mars

Last week I finished reading The Martian by Andy Weir. It was a great story, well researched and well written. Most of you know what it’s about, astronaut Mark Watney gets stranded on Mars. He has to survive with limited supplies for much longer than expected, with expertise in botany and engineering.

What struck me was the way so many organizations worked together in a DevOps approach for a common purpose:

• The astronaut on Mars
• The crew on his ship
• NASA
• JPL
• The Chinese Space Agency

Some of the constituents are strange bedfellows indeed, but they made it work.

The different groups are scattered in various locations, using different systems, with uneven priorities and incompatible levels of risk. But when the players realize the extreme stakes, they all step up. Some even bend the rules, and they work together to bring the astronaut home.

Watney opines at the end that most people do want to help others and try to avoid harm coming to others.

Watney uses rovers already on Mars.

I’m a bit of a science geek, so I loved all the research Weir did to make the book as realistic as he could.

I’m also a little jaded by working in technology for the last 15+ years, I guess. When I read the book, I kept comparing the constituents to various groups and organizations at a company: competitive against each other, but ultimately working toward a common goal.

A few truths of IT issue resolution are revealed:

• Location doesn’t matter with the proper use of technology and proactive communication
• Tooling is important because compound integrations are often required for complex issues
• Preparation is crucial for nonlinear processes under changing circumstances
• Quick thinking matters too, especially in isolation
• Be resourceful and use the tools and equipment available to you

Resourceful is a big deal in the book. Watney uses rovers and other equipment already on Mars, and uses his botany and engineering experience to make food last longer and himself more mobile.

A stranded astronaut counts as a major incident to me. Getting so many disparate groups of people together requires some exceptional communication, and the book hit on all of them, even though I don’t think Weir did it on purpose.

• Rapid engagement: Identifying and engaging the right person quickly is critical to rapid resolution, but so is delivering the most relevant information with minimal manual intervention.
• Intelligent responses: Customizable, actionable messages can be tailored to be specific to an event, expediting the engagement process.
• Multi-Modal support: As businesses move at a glacial pace from email to more nimble communication platforms, they must adopt support for a wide range of technologies.
• Integration with operations: Proactively reporting less urgent events earlier can often prevent them from becoming major incidents.
• Stakeholder alignment: Communication during major incidents involves more than just the resolution process. Failure to communicate to stakeholders can impact public perception, customer loyalty, and many other revenue-impacting metrics.

I don’t want to give the book away, but when they exhausted standard processes, they started breaking rules and trying new ways of accomplishing unfamiliar tasks. And they had to work together and share information, even when it was uncomfortable.

It’s good business. It’s common sense. It’s DevOps.

So let’s bring this back down to Earth.

Read the Major Incident Management Survival Guide

Remember the five essentials of service desk communication:

• Rapid engagement
• Intelligent responses
• Multi-modal support
• Integration with operations
• Stakeholder alignment

You many never find yourself abandoned on Mars, but these five essentials of major incident communication could still save your bacon one of these days. Learn more in our latest white paper, 5 Essentials of the Service Desk.

Request a demo