21–30 of 53 posts
> In short you can … > 1. Expect services to grow at a non-linear rate. Why would you expect this?
Earlier quoted context omitted.
It's a niche. It's how I earn my living. I work for small companies that don't have enough daily work to keep someone like me around, but they can pay me a retainer to be on call when Something Bad™ happens. It's actually pretty fun to have an ear in a wide variety of businesses, you wind up learning a lot outside of the technical world.
I suppose the natural question to ask here is if one thinks it is actually possible to be truly "on call" at multiple places simultaneously. Is the extent of your agreement service within a day or something shorter/longer?
I do have a couple of clients that pay quite a bit more for a call-and-fix any time guarantee, but I only offer that level of service to businesses where 1: there is at least one person on their regular staff who is technically competent enough I can walk through more advanced issues and they will understand how to follow instructions, and 2: I'm the one that built out their network, so I know the gritty details.
For the times when the shit hits the fan in two places at once, I have friends who do similar work, and there are a couple of guys I can call to cover if needed. Obviously they get most of the money from these instances, but the customer stays happy, and I get larger monthly residuals than I could otherwise take care of, so everybody wins.
This rings true.
Earlier quoted context omitted.
It's not just about that role, it's more about the interface between the people responsible for running the code and the people responsible for writing it, and to what degree each should be able to do the other's job. Just throwing shit over the wall isn't any good either.
If you need to do backend and front end ("full stack"), know devops, know cloud primitives, know database fundamentals, know document storage (Elasticsearch), what are you going to actually be good at? Not much. You can't have both depth and breadth of knowledge, unless you're doing unhuman levels of cocaine and never sleeping.
It's fun to watch people learn the systems administration trade, but it's a little disheartening to watch them conclude -- incorrectly -- that proper systems administration is some kind of software engineering job. Is this why Silicon Valley is allergic to the phrase 'systems administrator'? Ops, Devops, SRE... so many phrases to describe various jobs which all, when executed successfully, converge upon the same set…
A lot of people doing software have some sysadmin experience, and a small company probably doesn't have enough work for a full time sysadmin. And a part time sysadmin won't work because you need on-call.
One favorite situation I ran into: a database server with a RAID card set to do write caching without NVRAM on a server with a single power supply (so two bad things in one). An overloaded power strip blew a circuit breaker and when the server went down, the filesystem their database was running on was unrecoverable. Oh, and of course they weren't doing backups because they had RAID!
Earlier quoted context omitted.
Being a good sysadmin in 2016 requires a skill in programming. The ability to write apps and services that interact with your infrastructure's APIs is necessary to automate all the toil we've done since the beginning. (See google's SRE book) As I have more control over hiring decisions on my team, an inability to use any programming language effectively (bash, python, perl, /anything/) would disqualify someone from a…
Being a good sysadmin in 1996 and 2006 also required skills in programming. Sysadmins who don't code have always been limited in their career evolution. The same is true for developers who don't know anything about operations. The focus on automation, and it being called DevOps, is simply an evolution of the work of sysadmins. The same way devs evolved toward TDD and other modern programming techniques.
I believe you have this exactly backwards.
The problem is that we keep silo'ing everything and inventing new buzzwords and half-assed tech. We can split things into smaller pieces quicker than we could ever staff up.
Nothing has changed since the 80s. The only thing that's different now is that instead of programming in one little pond of a language, now everything you do is programmable. That doesn't mean you need 47 specialists. It means you need to get really good at managing and limiting complexity.
We don't want to split off and evolve roles into newer and even more specialized roles. This is the thing that made deployment and updating so whacked to begin with.
It's fun to watch people learn the systems administration trade, but it's a little disheartening to watch them conclude -- incorrectly -- that proper systems administration is some kind of software engineering job. Is this why Silicon Valley is allergic to the phrase 'systems administrator'? Ops, Devops, SRE... so many phrases to describe various jobs which all, when executed successfully, converge upon the same set…
There is no need for 'systems administrator' in the Silicon Valley.
The systems administrators are the guys who buy the desktop computers, setup windows, and kinda manage the active directory.
DevOps/SRE names exist because the tech scene had to stop the confusion between the hardcore linux admins who can code and the dude who can setup your desktop computer. The first is needed in dev companies mostly located in the tech hubs, the second is needed in most companies all around the world. The two have very little in common.
Earlier quoted context omitted.
It's a niche. It's how I earn my living. I work for small companies that don't have enough daily work to keep someone like me around, but they can pay me a retainer to be on call when Something Bad™ happens. It's actually pretty fun to have an ear in a wide variety of businesses, you wind up learning a lot outside of the technical world.
I suppose the natural question to ask here is if one thinks it is actually possible to be truly "on call" at multiple places simultaneously. Is the extent of your agreement service within a day or something shorter/longer?
Even with a Gold support plan with 2 hour guaranteed on-site response, it took nearly 2 days to get our servers replaced and running, but the bigger guys were back up within few hours of the outage. Sun simply didn't have the staff or immediate spares available to move any faster -- their response was still impressive - they brought in an 18 wheeler full of spares the next day.
They ended up giving us some months of free support or something like that to make up for the delayed response.
It's fun to watch people learn the systems administration trade, but it's a little disheartening to watch them conclude -- incorrectly -- that proper systems administration is some kind of software engineering job. Is this why Silicon Valley is allergic to the phrase 'systems administrator'? Ops, Devops, SRE... so many phrases to describe various jobs which all, when executed successfully, converge upon the same set…
> Is this why Silicon Valley is allergic to the phrase 'systems administrator' There is no need for 'systems administrator' in the Silicon Valley. The systems administrators are the guys who buy the desktop computers, setup windows, and kinda manage the active directory. DevOps/SRE names exist because the tech scene had to stop the confusion between the hardcore linux admins who can code and the dude who can setup yo…
It's fun to watch people learn the systems administration trade, but it's a little disheartening to watch them conclude -- incorrectly -- that proper systems administration is some kind of software engineering job. Is this why Silicon Valley is allergic to the phrase 'systems administrator'? Ops, Devops, SRE... so many phrases to describe various jobs which all, when executed successfully, converge upon the same set…
> Is this why Silicon Valley is allergic to the phrase 'systems administrator' There is no need for 'systems administrator' in the Silicon Valley. The systems administrators are the guys who buy the desktop computers, setup windows, and kinda manage the active directory. DevOps/SRE names exist because the tech scene had to stop the confusion between the hardcore linux admins who can code and the dude who can setup yo…