Defective DevOps(blog.odoom.net)
blog.odoom.net
Defective DevOps
https://blog.odoom.net/defective-devops/
7 comments
I stopped reading at the point that an article trying to tell us how to effectively implement DevOps started talking about “DevOps Engineers”. I also got that little bit closer to getting “DevOps isn’t a job title” stickers made.
For large enough companies it can be a legitimate role; I know it exists inside Microsoft. There are multiple teams focused on build, test, release, and debugging infrastructure. I guess that's the type of thing you need once you reach hundreds to thousands of teams. Not to mention the rich data you can collect on process across the company; it likely makes cross-referencing issues easier for those central teams.
I think it might be useful to have a team of DevOps Engineers that rotate between teams every 3-6 months, implementing build+test+release+live site tools & infrastructure for their assigned team during each rotation, and then produce notes that get collected and merged across the DevOps Engineers (DOEs) across the company.
I think this could benefit a (large?) company in multiple ways:
- Because they rotate so frequently, they need to get off the ground quickly, they'll end up producing useful documentation (& keeping docs provided by the previous engineers up to date).
- Because they're exposed to so many different archiectures/stacks/failure modes, they'll gain a broader understanding of where the organization is. If you pool this knowledge across all DOEs you can find The Right Abstraction(TM) and build better tools. It'd also function as a health check across the organization: What teams need more assistance? What tools fail most often?
- Having to implement the same things for multiple teams will result in stronger automation and faster path for greenfield teams.
- If the DOEs have tight integration with build/test/release infrastructure teams, then they can work with those teams to improve tooling UX. What tools do we need? What tools does nobody use? The DOEs know from experience where the warts are.
As an extension, the infrastructure teams mentioned in the last point could also be formed out of a rotating roster of DOEs: they're not always out helping other teams directly, but sometimes "come home" to build new tools & services that address needs of other DOEs, needs that originated from work with other teams in the organization.
-- Separate idea --
I think the biggest concern people raise with DOE positions is that infrastructure work is finite: eventually it "just works" and no further work is necessary. I'd counter that the role of DOEs is to push customer-impacting incidents to 0 while maximizing productivity of other developers. It involves a mindset of "Every incident that happens in production can be avoided."
--
Sorry, didn't intend to write all of this. I'm open to opinions.
I think it might be useful to have a team of DevOps Engineers that rotate between teams every 3-6 months, implementing build+test+release+live site tools & infrastructure for their assigned team during each rotation, and then produce notes that get collected and merged across the DevOps Engineers (DOEs) across the company.
I think this could benefit a (large?) company in multiple ways:
- Because they rotate so frequently, they need to get off the ground quickly, they'll end up producing useful documentation (& keeping docs provided by the previous engineers up to date).
- Because they're exposed to so many different archiectures/stacks/failure modes, they'll gain a broader understanding of where the organization is. If you pool this knowledge across all DOEs you can find The Right Abstraction(TM) and build better tools. It'd also function as a health check across the organization: What teams need more assistance? What tools fail most often?
- Having to implement the same things for multiple teams will result in stronger automation and faster path for greenfield teams.
- If the DOEs have tight integration with build/test/release infrastructure teams, then they can work with those teams to improve tooling UX. What tools do we need? What tools does nobody use? The DOEs know from experience where the warts are.
As an extension, the infrastructure teams mentioned in the last point could also be formed out of a rotating roster of DOEs: they're not always out helping other teams directly, but sometimes "come home" to build new tools & services that address needs of other DOEs, needs that originated from work with other teams in the organization.
-- Separate idea --
I think the biggest concern people raise with DOE positions is that infrastructure work is finite: eventually it "just works" and no further work is necessary. I'd counter that the role of DOEs is to push customer-impacting incidents to 0 while maximizing productivity of other developers. It involves a mindset of "Every incident that happens in production can be avoided."
--
Sorry, didn't intend to write all of this. I'm open to opinions.
I 100% agree DevOPS shouldn't be a job title.. but it is hard to find operations people without the right social and technical skills without using it. So you can use the title since the market demands but the more important part is to avoid creating an ironic 'DevOPS silo'.
Once it told a Customer that I'm not a DevOp but a Cloud-Orchestrator...but in reality is see myself as a Systems-Administrator.
[deleted]
This is a zero content, generic fluff piece. It could be about any methodology! For example, replace devops with agile (or any other methodology) and devops-engineer with scrum-master. This is an insult to the reader.
Was this drivel written by GPT-3?
Was this drivel written by GPT-3?
Not a single real world engineering example and analysis. Concepts and culture stuff.