21–30 of 84 posts
Welcome to "Olds-land," Rachel. Sorry about that. It's almost impossible to be a developer/engineer/opsmonkey, with any varied experience, without running into this. People will always find something in your résumé, that makes them uncomfortable.
> they didn't have the usual lists of godawful clown software that most places rattle off that you'd be expected to work with.
That could be a summary of all that is amiss with the tech industry, these days.
People need operations staff, people don't like operations staff and keep trying to treat them like developers. But, operations staff do and have always developed software, just internal software for glue or orchestration, and they work differently to regular software developers in that their customers are usually themselves to meet an internal objective of reliability, stability or ease-of-use for developers. It's i…
>Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same operational solutions, just with better tools as the passage of time allowed better tools to exist. DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure). Maybe when it became a…
Not happening in any of the companies I worked for as a contractor or subcontractor. In those companies at best dev teams have nowadays some additional capability to deploy to dev/test instantly (so they do their own CI/CD pipelines and manage dev infra via Terraform or whatever) but production is always handled by a "DevOps" team which does not touch the application code at all. This is especially visible in companies that outsource their development to software houses / individual contractors (B2B stuff, most of the folks I interact with).
Honest question, what would you call a role that: * Is on call * Manages internal software (grafana, Prometheus, salt stack, etc) * is the first line of defense for issues in the field, works with support and the engineering team to handle problems * Manages a distributed fleet of servers (uses off the self and/or custom code to do so) * Builds internal tools/automations to improve the reliability of our platform and…
I think my current title has the word "cloud" in it or something and my boss rejects (with prejudice) "SRE" or "devops" explicitly to avoid being labeled as operations.
Honest question, what would you call a role that: * Is on call * Manages internal software (grafana, Prometheus, salt stack, etc) * is the first line of defense for issues in the field, works with support and the engineering team to handle problems * Manages a distributed fleet of servers (uses off the self and/or custom code to do so) * Builds internal tools/automations to improve the reliability of our platform and…
Overworked?
Honest question, what would you call a role that: * Is on call * Manages internal software (grafana, Prometheus, salt stack, etc) * is the first line of defense for issues in the field, works with support and the engineering team to handle problems * Manages a distributed fleet of servers (uses off the self and/or custom code to do so) * Builds internal tools/automations to improve the reliability of our platform and…
It still means mandatory, potentially grueling, on-call rotations.
If you can affect the quality of the on-call, then it's not so bad. If you can't, then that's your ammunition to remove the feature from being "blessed". This is the gift that the SRE book actually gave people. That, and error budgets. It loosened peoples idea of what ops was, before this it was 100% uptime of all services at all times, and ops people being responsible for things that they could not reasonably affect…
IDK, part of the reason I got into things like DevRel is that I am good at SRE style work, but I'm just not cut out to be pager bitch like other people are. I now have a 500% premium for any job that involves oncall work. Nobody's taken me up on it, surprisingly.
Honest question, what would you call a role that: * Is on call * Manages internal software (grafana, Prometheus, salt stack, etc) * is the first line of defense for issues in the field, works with support and the engineering team to handle problems * Manages a distributed fleet of servers (uses off the self and/or custom code to do so) * Builds internal tools/automations to improve the reliability of our platform and…
Honest question, what would you call a role that: * Is on call * Manages internal software (grafana, Prometheus, salt stack, etc) * is the first line of defense for issues in the field, works with support and the engineering team to handle problems * Manages a distributed fleet of servers (uses off the self and/or custom code to do so) * Builds internal tools/automations to improve the reliability of our platform and…
In general, most of the issues I've seen with these sorts of roles aren't the naming of them but rather the third bullet in your list. Having an ops role that's responsible for all the problems with software they didn't build and weren't allowed to have meaningful input to the design/implementation of isn't healthy. It sucks up their time and energy fighting fires they didn't create and likely aren't really empowered to fix. This is the problem with this role (as often implemented) that Rachel talks about in her first paragraph.
If you really care about having a good and reliable product you need people involved with the design and implementation that are deeply invested in making it reliable and maintainable in the long term - which means either making your dev roles shoulder some of the oncall burden or having people that straddle the ops and dev teams. Or both. If you're having difficulty filling this role, perhaps this is the real problem?
People need operations staff, people don't like operations staff and keep trying to treat them like developers. But, operations staff do and have always developed software, just internal software for glue or orchestration, and they work differently to regular software developers in that their customers are usually themselves to meet an internal objective of reliability, stability or ease-of-use for developers. It's i…
To expand a little: The job of any "operations" person is to keep the money flowing and avoid wasting money/looking stupid. All that technical circle jerking is just a temporary detail.
Fads come and go, getting functional products in front of customers is forever.