Participate in the Crowdsourced #DevOpsAllStars Anthology

devops week form

Servers don’t serve themselves

We get it. Your job is incredibly hard, hours are long, challenges many… Oh, and BTW, your company’s brand and customer base are riding on your shoulders.

With rushed code releases, hotfixes in production, and revenue on the line, there’s never a good time to take a break or even pat yourself on the back. But through it all, you are an all-star, more specifically a #DevOpsAllStar. We’d love to share a story of your success with your peers (and the world) and acknowledge the work you do.

As a thank-you for your effort and completed contribution, we will send you your own DevOps All-Star team jersey! We will collate the submissions into a crowdsourced anthology to put DevOps in the spotlight where it belongs.

Nominate a peer! Recognize DevOps and share this with your team

Tell us how you:

  • Saved the day
  • Fixed a fire
  • Found a killer bug
  • Supported a release
  • Saved management’s bacon

If you have a favorite vendor or tool you want to give a shout out too or highlight, go for it!

Elton Stoneman, independent consultant, Microsoft MVP and Pluralsight author:

“A client of mine recently went live with a new product, backed by a fairly simple REST API. The development team had decided to sacrifice instrumentation to make a tight deadline. With a week before the press launch, we still had no instrumentation when we found a nasty issue that we couldn’t replicate on demand, but seemed to happen more frequently with more users accessing the API. We were able to get Loggly set up in 20 minutes and then sequentially added more logging until we found the root cause: In one path through the code objects were being added to a memory cache without being serialized. Typically I serialize anything going to a cache, so the cache just holds strings, because that means you can easily switch between memory and other cache types; but in this case one object had been missed. The code path went on to modify the object, which meant it got modified in the shared cache, so if the next request came in while the cache was still fresh, it got the modified object and that led to the 404. The cache was only short-lived so after 30 seconds the issue would go away, which made it even harder to debug – but the logs were still there to help track it down.”