3 ms·
I think that was not mentality. Maybe after years of working that way it turned out into mentality. That was employee utilization approach where you hire 1 DBA
by ozim 4y ago
I think that was not mentality. Maybe after years of working that way it turned out into mentality.
That was employee utilization approach where you hire 1 DBA and he runs all DB stuff because hiring DBA for each team does not make financially sense as there is not enough day to day work for DBA specialist on a project/product.
Other stuff is that DBA/SysAdmins have to have access to customer - company data so you still need separation of duties (no devs access on prod systems) and it is easier to make guy part of "OpsTeam" and give him access across all systems than get "Ops" person configured per project\product.
So why "DevOps" if you get operational overhead and you cannot "utilize employee 100%"? Because in most companies delivering new features is more important than making Joe Dbaer closing tickets like in factory because we learned it actually is not efficient when "important feature X" is delayed because Joe was doing his job fine but feature X was in queue.
- taylodl 4y agoGood things happen when developers are involved in Ops. Most developers would prefer to develop and not focus so much on Ops, and so they take the steps to automate the Ops as much as possible and essentially make the problem go away. Dedicated Ops staff won't do that because that would put them out of work.
- kazen44 4y agoin my opinion, the ops folk who are good at their jobs do automate the boring stuff. (because doing grunt work is uninteresting) I highly doubt ops will ever go away considering someone has to think about maintaining stability in a production environment. This is usually a different way of thinking a lot of developers are simply not aligned to do.