3 ms·

Are the developers-who-are-denied-access that you describe also on-call and watching monitoring alerts for when something goes awry? I've worked in companies w

Are the developers-who-are-denied-access that you describe also on-call and watching monitoring alerts for when something goes awry? I've worked in companies where "DevOps" was thought to mean: "Devs have a lot of access, even root/dba/etc. access, and while they're sleeping or if they get stuck on something, they should punt it over half-finished or half-broken to the infra eng / devops group" ^^ This is so incredibly common, especially in small/startup environments. It's a nightmare I actively aim to fix when I join / consult at companies. There's instability in the environment, inconsistencies, or just a mess, and you parachute in there to fix. Step 1, kick out all devs from any systems they have too much access (unless they're special, knowledgeable ones and know and understand what you're trying to do), Step 2, stabilize the system. Step 2 involves environment separation, real automation that more than one person can use, setting up monitoring, and much much more.

fogetti 8y ago
> while they're sleeping or if they get stuck on something, they should punt it over half-finished or half-broken to the infra eng By the description of it, the root cause of the problem is your setup. Dismantle the infra eng team and make the dev team to monitor their own apps. By reading of your explanation devs should have more access and responsibilities. You set up a half baked process and you are blaming the devs for it? Not cool.
- oblio 8y ago
  Ha ha. That's assuming the dev team wants to monitor apps. I've met many, many devs who have 0 desire to be woken up at night for crap they coded during the day. They just want to code. It's incredibly common. Not that I blame them, if you can work just 9-5, why wouldn't you?
- mancerayder 8y ago
  I've never seen anything like that, nor have my dev and DevOps buddies, ever seen anything like what you just suggested. Dismantle infra eng and make devs do everything? I support that, for one reason: a year from now I can charge consulting dollars when I come to fix these unstable, poorly documented, environments with minimal automation and HA.
  - fogetti 8y ago
    Well I did that in the startup I worked in previously. And no, they are not gonna call you for your shitty service. They are pretty stable. Guess what? We knew how to configure private clouds, loadbalancers, sharding and high availability. We pretty much know everything about Kubernetes/Amazon ECS et. al and related technologies and we didn't have any problems with monitoring or low level networking among others either. Anyone can learn this shit. There is nothing special about it. Don't hold your breath for seeing your consulting dollars, LOL. :D

fogetti 8y ago

> while they're sleeping or if they get stuck on something, they should punt it over half-finished or half-broken to the infra eng By the description of it, the root cause of the problem is your setup. Dismantle the infra eng team and make the dev team to monitor their own apps. By reading of your explanation devs should have more access and responsibilities. You set up a half baked process and you are blaming the devs for it? Not cool.

oblio 8y ago
Ha ha. That's assuming the dev team wants to monitor apps. I've met many, many devs who have 0 desire to be woken up at night for crap they coded during the day. They just want to code. It's incredibly common. Not that I blame them, if you can work just 9-5, why wouldn't you?
mancerayder 8y ago
I've never seen anything like that, nor have my dev and DevOps buddies, ever seen anything like what you just suggested. Dismantle infra eng and make devs do everything? I support that, for one reason: a year from now I can charge consulting dollars when I come to fix these unstable, poorly documented, environments with minimal automation and HA.
- fogetti 8y ago
  Well I did that in the startup I worked in previously. And no, they are not gonna call you for your shitty service. They are pretty stable. Guess what? We knew how to configure private clouds, loadbalancers, sharding and high availability. We pretty much know everything about Kubernetes/Amazon ECS et. al and related technologies and we didn't have any problems with monitoring or low level networking among others either. Anyone can learn this shit. There is nothing special about it. Don't hold your breath for seeing your consulting dollars, LOL. :D