Skip to main content

4 lessons for sysadmins from The Unicorn Project

Lessons for sysadmins and DevOps from the novel "The Unicorn Project."
Image
Unicorn project with snowy tree
Image by Pixabay

Most people practicing DevOps are familiar with the work of Gene Kim. You might have been introduced to DevOps and "The Three Ways" through The Phoenix Project, or you might rely on The DevOps Handbook as a guide to change your team’s culture and increase their productivity. Kim is back with a new volume from the perspective of a lead developer and architect in The Unicorn Project.

The book is described as "a novel about developers, digital disruption, and thriving in the age of data." I was hooked on the storyline from the beginning when the lead character, Maxine, was exiled from a great engineering position in the fictional company Parts Unlimited because of a mistake that was made in production.

Maxine took on her new role in the "Phoenix Project" with a smile (and a fair bit of skepticism). Her first challenge was to get the developer build environment up and running on her laptop. This proved to be no easy task as she ran into issue after issue and kept creating tickets with the internal help desk requesting access to certain share folders or license keys. She was getting nowhere fast, but she was determined.

Maxine’s persistence got the attention of others. While instructed to "lay low" by management, that was not her style. She had quite the adventure throughout the rest of the story as she was invited to join "The Rebellion"—a group of the best and brightest engineers in the company training in secret to become a learning organization.

One of my favorite aspects of this book is the realistic scenarios that the teams are facing. It’s the journey they are on that many sysadmins are all too familiar with. The step-by-step task of growing from no build process to an automated one is a key journey with multiple learning opportunities and chances for missteps. There are numerous takeaways here from the perspective of a sysadmin. Let’s take a look at them.

Repeatability and consistency

Maxine was desperately trying to get a build environment, but no one in the entire company was able to replicate. Every developer was checking in code based only on their local environment. Not good.

Her documentation on creating a build environment, notably where the gaps and blockers were, helped members of The Rebellion reach a state of repeatability and standardization. More importantly, having a consistent build experience for each developer was critical to the success of the project. Sysadmins strive to create standardized, repeatable builds for their users to provide a consistent experience.

Creating a culture of learning

Eventually, the journey led the teams to deploy code to production. The Unicorn Project was so large, and with so many moving parts, that deploying code was not a pretty task. Imagine multiple conference rooms of people (war rooms) and lots of fingers being crossed during code deployment. Needless to say, there were failures, but they learned from them.

Monitoring, alerting, and lots of log files were involved in the first and future deployments. The team set up tools to help them understand what was happening during code deployments so they could learn faster and fix any problems that popped up. While highly stressful, the team was successful in getting code out. And ultimately, more predictable and more often.

Avoiding the lone wolf sysadmin

There was a character in the book, Brent, who was the sysadmin who knew it all. Network question, call Brent. Database issue, call Brent. The server just went down, call Brent. He was the type of employee who couldn’t take a vacation without getting paged. And it wasn’t that Brent was trying to be the lone wolf, it just kind of happened that way because of management.

Thankfully, the storyline improves for Brent, but it leaves a valuable lesson in this story: Lone wolves won’t last long in traditional organizations and the lack of documentation is not job security. Sharing knowledge and workload is critical for successful teams practicing DevOps.

Working harder not smarter with automation

No DevOps book would be complete unless we touched on the topic of automation. Maxine and her team were definitely interested in automating those mundane tasks. With the challenges of their build and deployment processes, there was definitely experimentation around what tasks could be automated. I like how the team took baby steps to their automation approach. They didn’t see automation as a way to replace their jobs, they instead saw automation as a way to let them work on more challenging issues.

Time to give DevOps a go

In conclusion, I think this is a great read for sysadmins with a desire to help create or be part of a learning culture. You’ll definitely come across a few scenarios in the book where you’ll say, been there, done that. If you’re ready to jump into DevOps practices, step away from the terminal window for a bit, get the download from Gene Kim, and pick up a copy of The Unicorn Project.

What to read next

Topics:   DevOps   Automation  
Author’s photo

Jason Hibbets

Jason Hibbets is a senior community architect at Red Hat which means he is a mash-up of a community manager and project manager. He works with the Enable Sysadmin community, but also dabbles with Opensource.com and the Open Organization community. More about me

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX