Fork me on GitHub
#bof-next-gen-ops
<
2020-06-24
>
Damon Edwards03:06:58

👆 @bryan.finster I think you nailed it, except it’s not the people, it’s the work. If the nature of the work is to use the tools/platform, it’s ops work. If the nature of the work is to build the tools/platform, it’s dev work. People can spend the majority of their time doing one or the other and get that label (as was the way with traditional functionally siloed teams for years). But now we are seeing the rise of your build it, you run it models where people’s work alternates and, in effect, neither people label really fits. Moral of the story: don’t confuse the labels we give people to tie them to an org model with the nature of the work. It’s much more fluid, like what happened to “QA”.

Damon Edwards03:06:58

👆 @bryan.finster I think you nailed it, except it’s not the people, it’s the work. If the nature of the work is to use the tools/platform, it’s ops work. If the nature of the work is to build the tools/platform, it’s dev work. People can spend the majority of their time doing one or the other and get that label (as was the way with traditional functionally siloed teams for years). But now we are seeing the rise of your build it, you run it models where people’s work alternates and, in effect, neither people label really fits. Moral of the story: don’t confuse the labels we give people to tie them to an org model with the nature of the work. It’s much more fluid, like what happened to “QA”.

Steve Thair (DevOpsGroup)08:06:42

I'd just like to say a huge thanks to everyone whose contributed to this debate so far - THESE are exactly the sort of debates I think the Ops community needs to have right now so we redefine what our roles mean in the modern world (regardless of what we call them). So keep the ideas and insights coming and if you haven't contributed yet, dive in, we don't bite!

Jamie Ballisat (Redgate)09:06:48

Hi all, today Kendra Little (MS MVP) is hosting a happy hour at 6pm BST. Join the https://slack-redir.net/link?url=https%3A%2F%2Fredgate.zoom.us%2Fj%2F91228088517 to chat about how to improve both speed and quality in database engineering, share your pain points, and get tips on identifying and conquering your biggest constraints no matter where you are starting. We'll have insights from industry leading research to share and since it's happy hour, it will be in a fun and  interactive format! https://redgate.zoom.us/j/91228088517 (edited)

Peter11:06:38

Hi all. I am curious to hear/see your views on a great DevOps Operating Model. Both a Target Operating Model, but also how a potential interim model for organizations with low DevOps maturity, hence, a pure DevOps TOM is a too big a step.

Peter11:06:38

Hi all. I am curious to hear/see your views on a great DevOps Operating Model. Both a Target Operating Model, but also how a potential interim model for organizations with low DevOps maturity, hence, a pure DevOps TOM is a too big a step.

Craig Cook - IBM11:06:27

Like @damon said, "Ops" is not a person, it's something a team does to run their own services. When IBM's Marketplace started ~5 yrs ago I extended the thought of "you build it, you run it" and added "you own it". Most of my time was spent teaching/coaching dev teams how to run their services. They got woken up when their service went down. Improves their focus and interest in operational practices and you get higher service quality. Handing your service to another team to run is not a good idea. I can't find any way to believe passing your "prod service" to a "SRE" team is going to be good.

Craig Cook - IBM11:06:27

Like @damon said, "Ops" is not a person, it's something a team does to run their own services. When IBM's Marketplace started ~5 yrs ago I extended the thought of "you build it, you run it" and added "you own it". Most of my time was spent teaching/coaching dev teams how to run their services. They got woken up when their service went down. Improves their focus and interest in operational practices and you get higher service quality. Handing your service to another team to run is not a good idea. I can't find any way to believe passing your "prod service" to a "SRE" team is going to be good.

Steve Thair (DevOpsGroup)12:06:19

────────── Stephen Thair is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://devopsgroup.zoom.us/j/96513873089?pwd=SXY0US85Z3hkcnlqSFRVRk83QVFrUT09 Meeting ID: 965 1387 3089 Password: i%iN19 One tap mobile <tel:+442034815237,,96513873089#,,,,0#,,815919#|+442034815237,,96513873089#,,,,0#,,815919#> United Kingdom <tel:+442034815240,,96513873089#,,,,0#,,815919#|+442034815240,,96513873089#,,,,0#,,815919#> United Kingdom Dial by your location         +44 203 481 5237 United Kingdom         +44 203 481 5240 United Kingdom         +44 208 080 6591 United Kingdom         +44 208 080 6592 United Kingdom         +44 330 088 5830 United Kingdom         +44 131 460 1196 United Kingdom         0 800 260 5801 United Kingdom Toll-free         0 800 031 5717 United Kingdom Toll-free         +1 346 248 7799 US (Houston)         +1 408 638 0968 US (San Jose)         +1 646 876 9923 US (New York)         +1 669 900 6833 US (San Jose)         +1 253 215 8782 US (Tacoma)         +1 301 715 8592 US (Germantown)         +1 312 626 6799 US (Chicago)         888 475 4499 US Toll-free         877 853 5257 US Toll-free Meeting ID: 965 1387 3089 Password: 815919 Find your local number: https://devopsgroup.zoom.us/u/ab85FeNG4n ──────────

Steve Thair (DevOpsGroup)12:06:47

call details for the Bof Session today are above! ☝️

Steve Thair (DevOpsGroup)12:06:15

If you have any questions or want to contribute to session notes/insights/observations you can on our Jamboard here - https://jamboard.google.com/d/10D9mwYtVfFFL_zC7sNH1v8wTKhRqot_M-JYzUJEAw5A/viewer?f=1 Note there are 3 screens to the Jamboard, the navigation is at the middle top.

Brian Martin13:06:14

I would define Ops as the practice of ensuring software is available for use by an end customer (internal or external).

Brian Martin13:06:40

In our model, we renamed the team I run as the Incident Response Team. We monitor the systems 24/7 and, to the extent that a service owner has implemented runbook actions to solve simple problems, we execute the runbook to restore service, but beyond that, it is a callout to a dev service owner.

Brian Martin13:06:13

My experience has been that if you haven't ever been on a call with an angry customer during an outage, you probably don't vicerally understand Ops and it's usually a bad idea to put a developer on a call with an angry customer.

Steve Thair (DevOpsGroup)15:06:14

Thanks to everyone on teh BoF call today - great contributions and conversation. Don't forget to add your thoughts, questions, ideas to the Jamboard - https://jamboard.google.com/d/10D9mwYtVfFFL_zC7sNH1v8wTKhRqot_M-JYzUJEAw5A/viewer?f=1

Tom Ayerst15:06:12

Funny how exchanges of anecdotes always end up with the “and then it blew up and s**t went everywhere” stories :rolling_on_the_floor_laughing: