Welcome!

@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Zakia Bouachraoui, Yeshim Deniz, Gopala Krishna Behara

Related Topics: @DevOpsSummit, Linux Containers

@DevOpsSummit: Blog Feed Post

Advice for the New On-Call Engineer By @VictorOps | @DevOpsSummit [#DevOps]

There is more to being on-call than just knowing how to type in the latest ChatOps commands

Advice for the New On-call Engineer

By Dan Hopkins

There is more to being on-call than just knowing how to type in the latest ChatOps commands, reboot AMIs and print out java stack traces. There are life skills that come from being on-call for a while and fortunately, those are lessons that can be taught.

Here at VictorOps we’re currently adding six new engineers to our on-call roster, so I’ve been thinking about the experience of being on-call and how to make the best of it.

The first day you go on-call can be frightening. The most important thing to remember is that you’ve already passed the first test. You have the trust and respect of your teammates and are providing them with a valuable commodity: peace of mind. No one wants to be on-call, so stepping up to the plate and taking shifts helps to improve the lives of everyone on your team.

https://www.flickr.com/photos/zakh/

1.) Make sure you understand and have the tools you need to do your job. If you don’t know how to use them while you’re at work, there is no way you’ll remember at 2am. Here’s a list, obviously your particular job might vary…

* VPN
* SSH credentials
* sudo privileges
* RSA key fob
* Credentials to your support portal
* Phone numbers and escalation policies for components of the system that you’re responsible for
* Links to the runbooks or chatops commands

2.) Understand the expectations for being on-call, both implicit and explicit. Hopefully your company has taken time to document the expectation for how you’re supposed to behave when you’re on-call. It’s always best to have things explicit, but looking through your chat rooms or timeline might give you indication if there are implicit rules that different team members follow. Some examples of both implicit and explicit rules are:

* “How fast should you be responding to pages?”
* “When should you escalate incidents to more senior team members, other teams or customer support?”
* “How should you handle short periods of time where you need to be away from your computer, such as going out to dinner or a movie?”

at_mentions

3.) Remember to communicate. This is often a tricky one for people in our field but communicating between teams (both engineering and non-engineering) is one of the key skills to being an on-call engineer. In addition to being expected to fix or diagnose issues, you’re there to send out communications with the rest of your team(s). There is definitely finesse in understanding when an issue needs to be run up the flagpole so take care to learn from how others on your team communicate.

4.) Manage your life. If you’re not a full time on-call engineer, you’re going to spend a lot of time balancing your “real duties” with being on-call and most importantly, with having a life. This is a tricky balance to get good at. If you’re on-call for extended periods (longer than a few days) you’re going to notice a precipitous drop off in “vigilance.” There are behaviors and a level of focus that you can only sustain for so long while being on-call.

2984249685_7fc90e5b13_o

5.) What about sleeping? When you’re on-call on a night shift, and you’ll be sleeping during it, there is a quick “pre-sleep” checklist that you should learn:

* Your “pager” should be set to “make lots of noise”
* Check your timeline for any warnings that will become incidents overnight (better to catch it early)
* You might save yourself a headache by having your computer at hand (close to your bed) so you don’t have to run through the house in your skivvys

6.) You’re not actually on house arrest. If you still want to have a life while on-call you might, on occasion, leave the house. Consider doing a few of the following:

* take your laptop and a phone that can tether
* let your teammates know
* trade on-call for a couple hours

Hopefully your first night on-call won’t be the shitstorm you fear and you’ll move on to be an integral part of the on-call team. If you’re looking for other helpful tips, check out our On-Call Firefight Survival Guide. Here’s to making on-call suck less!

The post Advice for the New On-call Engineer appeared first on VictorOps.

Read the original blog entry...

More Stories By VictorOps Blog

VictorOps is making on-call suck less with the only collaborative alert management platform on the market.

With easy on-call scheduling management, a real-time incident timeline that gives you contextual relevance around your alerts and powerful reporting features that make post-mortems more effective, VictorOps helps your IT/DevOps team solve problems faster.

@DevOpsSummit Stories
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?
Wooed by the promise of faster innovation, lower TCO, and greater agility, businesses of every shape and size have embraced the cloud at every layer of the IT stack – from apps to file sharing to infrastructure. The typical organization currently uses more than a dozen sanctioned cloud apps and will shift more than half of all workloads to the cloud by 2018. Such cloud investments have delivered measurable benefits. But they’ve also resulted in some unintended side-effects: complexity and risk. End users now struggle to navigate multiple environments with varying degrees of performance. Companies are unclear on the security of their data and network access. And IT squads are overwhelmed trying to monitor and manage it all.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogger and is a frequent speaker on the use of Big Data and data science to power the organization's key business initiatives. He is a University of San Francisco School of Management (SOM) Executive Fellow where he teaches the "Big Data MBA" course. Bill was ranked as #15 Big Data Influencer by Onalytica. Bill has over three decades of experience in data warehousing, BI and analytics. He authored E...
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.