3 ms·

We started a Devops team at work. After a year there have been 0 Ops hires, it's all Devs. I think/hope we might see this change soon. Currently there's no rea

We started a Devops team at work. After a year there have been 0 Ops hires, it's all Devs. I think/hope we might see this change soon. Currently there's no real penalty for poor ops. If your customer data gets hacked, there are very few actual penalties, most of the pain is in reputation. I feel like there's been a lot of pressure to have government penalties for poor security practices, especially when so many companies "need" all the user data they can get their hands on.

jedberg 10y ago
> After a year there have been 0 Ops hires, it's all Devs. You say that like it's a bad thing. If you want DevOps to be successful, you don't hire a "DevOps team". You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops. The idea is that doing "good ops" is so easy that everyone in the company does it.
- bigiain 10y ago
  You do need at least someone who really knows what "ops tools" need to do, someone with sufficient experience to know the difference between "good ops" and "the first idea some non-ops experience developer had that looked like it solved the problem on his local machine"...
  - jedberg 10y ago
    Sure. But you can usually find a Dev who used to do ops that can fill that role.
    - bigiain 10y ago
      From my (admittedly somewhat limited) experience, an old-school sysadmin (who's likely moved into dev for the better paycheque) is often _way_ better at filling that role thad a more dev oriented person who's done some devops in the past. In my experience, "good ops" people are the ones with lots of war stories to tell of disasters or narrowly averted disasters either of their own of of friend/colleagues they hang out with. It's a profession who's lessons seem to be best-taught by spectacular failures and heroic recovery efforts, rather than college courses, vendor/consultant training, or "industry best practices" documents...
      - vacri 10y ago
        As I journey through my nascent (6? year) career in a sysadmin role (support previous to that), it strikes me more and more that ops is a craft, like blue-collar trades. You can't become a hot-shot ops staffer by being smart and attending a month of intensives; so much of it is learned through experience (and discussion). I think of myself more as a 'journeyman sysadmin' than a 'midlevel sysadmin'...
        jedberg 10y ago
        Absolutely! I always suggest to young folks who ask how to get into operations that they should set up a linux box and use it as their primary system. There is no better way to rack up your own war stories than trying to use a linux box on a day to day basis.
      - jedberg 10y ago
        I agree. My point was that OPs complaint was about not having any ops hires, and I was saying that he shouldn't need any. He can find a crusty old sysadmin who figured out that making their job easier by coding is a good thing. :)
- flukus 10y ago
  > You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops. We used to have people to make those ops tools, we called them ops. The whole devops things seems to be based on the false notion that ops didn't automate their work.
- CrLf 10y ago
  Equating "ops" with "tools" is just another symptom of the problems I was referring to. Tools are not the solution. Tools do not replace process, practice and goals. Tools are just tools.

jedberg 10y ago

> After a year there have been 0 Ops hires, it's all Devs. You say that like it's a bad thing. If you want DevOps to be successful, you don't hire a "DevOps team". You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops. The idea is that doing "good ops" is so easy that everyone in the company does it.

bigiain 10y ago
You do need at least someone who really knows what "ops tools" need to do, someone with sufficient experience to know the difference between "good ops" and "the first idea some non-ops experience developer had that looked like it solved the problem on his local machine"...
- jedberg 10y ago
  Sure. But you can usually find a Dev who used to do ops that can fill that role.
  - bigiain 10y ago
    From my (admittedly somewhat limited) experience, an old-school sysadmin (who's likely moved into dev for the better paycheque) is often _way_ better at filling that role thad a more dev oriented person who's done some devops in the past. In my experience, "good ops" people are the ones with lots of war stories to tell of disasters or narrowly averted disasters either of their own of of friend/colleagues they hang out with. It's a profession who's lessons seem to be best-taught by spectacular failures and heroic recovery efforts, rather than college courses, vendor/consultant training, or "industry best practices" documents...
    - vacri 10y ago
      As I journey through my nascent (6? year) career in a sysadmin role (support previous to that), it strikes me more and more that ops is a craft, like blue-collar trades. You can't become a hot-shot ops staffer by being smart and attending a month of intensives; so much of it is learned through experience (and discussion). I think of myself more as a 'journeyman sysadmin' than a 'midlevel sysadmin'...
      - jedberg 10y ago
        Absolutely! I always suggest to young folks who ask how to get into operations that they should set up a linux box and use it as their primary system. There is no better way to rack up your own war stories than trying to use a linux box on a day to day basis.
    - jedberg 10y ago
      I agree. My point was that OPs complaint was about not having any ops hires, and I was saying that he shouldn't need any. He can find a crusty old sysadmin who figured out that making their job easier by coding is a good thing. :)
flukus 10y ago
> You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops. We used to have people to make those ops tools, we called them ops. The whole devops things seems to be based on the false notion that ops didn't automate their work.
CrLf 10y ago
Equating "ops" with "tools" is just another symptom of the problems I was referring to. Tools are not the solution. Tools do not replace process, practice and goals. Tools are just tools.