Earlier quoted context omitted.
I think the best model is to have your "devops/sre guy" embedded right on the team. I market myself in interviews as a software engineer (on the same team as the other SWEs) that just happens to focus on what actually getting this product into production and keeping it going looks like. I got my start in this by working at a startup where we were responsible for everything just by the nature of the limited staff. I t…
> I think the best model is to have your "devops/sre guy" embedded right on the team. And here lies the problem. We had "Ops" before. People would throw stuff over the wall from Dev to Ops, and now it became "Ops" problem. Operations would stonewall releases – because releases bring problems, and they want to keep things stable. Developers would push for releases, because that's what they are paid to do. To solve thi…
To be fair, most ops people i know worth their salt have been automating since forever. Doing operations at scale and still staying sane is impossible without automation.
The largests issue in ops is that reality in production is usually far more messy then development. Some minor issue which can be easily fixed in dev by something simple (take a reboot of a service for example) can be a major pain in production because of several factors. Usually related to interdependencies or customer impact.
Also, production (especially on the networking/hardware side) is usually hard because of things like hardware failure, physics itself or simply human error. These gems for instance[1][2].
[1] https://www.cisco.com/c/en/us/support/docs/field-notices/636...