![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
In a work chat, this gods-awful article about "What does a DevOps Engineer do?" came up.
( Read more... )
I thought I'd comment on a few of the howlers, but it grew a bit...
> As we all know the days of sysadmins who applies specialized skills to tune individual servers is over.
No, not at all.
> Work is all about Automation
All? No. It's a part, no more.
> explaining a daily routine
*The* daily routine
> become a DevOps Engineer.
DevOps Engineers.
> A System Administrator is supposed to build, manage, and troubleshoot servers on a regular basis.
And clients, and networking, and switches/firewalls/routers, etc. You missed out about 75% of the job.
> Become master in deploying virtualization
Become *a* master
> A DevOps Engineer must know the IT network and storage concepts.
A lot more than just knowing the concepts. They need to know the implementation and management, as well.
> Puppet, Chef, Jenkins, Salt, Ansible, Kubernetes, Docker, Prometheus, Cloud Computing and storage platform, and Infrastructure as a Code (Terraform).
This is a bizarre mixture of automation, deployment and testing tools, concepts, ideas and methods. These things do not belong together.
> But nothing to worry about here.
*There is* nothing to worry about.
Only I think that's wrong, too. There's plenty.
> For e.g. Python
"e.g." means "for example"; you don't need "for" as well, and it shouldn't have a capital mid-sentence.
> bridge between the development and operations teams.
What you're trying to describe is someone who _is_ the ops team, or part of it. Not a bridge; the role you are talking about _replaces_ ops. (Be that a good idea or not. Hint: it's not.)
> As we know in today’s time
"As we know today" -- only we do not. I don't think this is true.
> everything is automatized
*Automated
> including the server triggering
No "the".
> These days we hear a new term “DevSecOps” right!
No, we don't.
> A DevOps personnel
You can't have *a* personnel.
And knowledge and awareness of security is part of *everyone's* role now, not just in dev, ops, or devops.
> Now you will say why a DevOps person needs to know the testing?
"Now, you might say why should a DevOps person need to know about testing?"
> Nothing to worry here again You
Missing full stop.
> can always got to your Development and Testing teams to address the errors if any in their application.
This sounds like passing the buck -- if you don't know why continuous integration (or whatever) tooling is working, ask someone else to fix it.
It is very important to know your limits. To know what you know and what you don't know, to be able and unafraid to SAY "I don't know" or "I can't do that"...
This is a core life skill, not just a core DevOps skill. But it also has a necessary coda: when you say you don't know, you need to be able to say "... but I know how to find out." Knowing what you don't know, being able to say that you don't know it, and knowing who to ask or where to look, and being able to say that too.
This is so important, it needs to go at the top.
Big scary list of platforms, then being confident enough to say "I don't know."
This is how I know if someone is good or not: whether, when encountering something new, they say "I don't know".
Anyone who never ever says "I don't know" is no good at their job and should not have that job.
I do not hear you saying you don't know -- about anything.
> Infra setups (either over Cloud or Bare Metal or VM’s)
Never ever make a plural with an apostrophe, in any conditions. No exceptions.
> Version Control support (GIT, SVN ..)
An ellipsis is three dots, no more, no less. No exceptions. If it is ending a sentence or a list, no space before it.
> Checking Email
That's everyone with a job. Omit the irrelevant. Your readers' time is precious; don't waste it.
> Checking JIRA / Any ticketing tool for pending/scheduled tasks.
Any ticketing tool? (And why is it capitalised?) Don't you mean _your_ ticketing tool or tools?
Scheduled tasks? I thought you said it was all about automation now? If it can be scheduled, shouldn't it be automated?
> Clear Notifications of alerting system.
You uSe an awFul loT of RanDom Capital letters, do you Know that? Why?
> Ensure if any new server is created and monitoring has been set up on that.
Check for new servers every day? Really? This just happens without you, does it?
Just one? You use the singular, not plurals here, so you must mean just one of them.
> Verify if all the service running on that server are covered under the monitoring system.
All the service? Don't you mean all the services? Did you proofread this before you posted it?
Top tip to aspiring DevOps people: CHECK YOUR WORK. If you are not sure, for example, if you are not working in your native language or a language you know very well, get a native to check before pushing to prod.
> Check and automate if any server is running out of disk. Taking a backup of instance and restoring if required.
If any *servers* ARE. How will you automate adding disk space? Is that possible? Why are you picking out and highlighting this one task?
> Taking a backup of Prod DB and providing that DB to developers on Staging / Testing Environment for testing of any issue.
Any issue? You mean any *issues.* Attention to detail! Like you are not showing here.
Do you test on a copy of the production database? Really? Is that not a bit big?
> Automation setup for daily tasks like (DB/Instance/Logs/Config-Files) backup.
Don't use "like" when you mean "such as". They are not the same. Precision is important, too.
> In case of new project setting up new Jenkins Job. ( Freestyle / Pipeline).
Freestyle, like your punctuation?
> Making config changes on servers using (Ansible /chef/ puppet).
Don't put things in parentheses if you are being specific. Be consistent in capitalisation.
Actually, be consistent in general. You're not.
> Writing playbooks for automating daily tasks.
Playbooks? Is that not specific to one tool? Why not be general? Always be more general if it is applicable. DevOps is all about generalisation instead of specialisation. Is automation of repetitive tasks a daily task? I would think automation is about *eliminating* daily tasks.
> Deploying code on Development and Production servers.
Radically different tasks which you are combining. That sets off alarm bells for me.
> Ensuring that post-deployment sanity of code is done and proper sign-offs are given.
"Sanity" and "sanity checking" are not the same thing, you know.
> Providing assistance during Audits.
Audits? Every day? Remember these are daily tasks.
Being able to clearly distinguish between daily tasks and exceptional ones is a core skill, one you appear to lack.
> Ensuring that access on servers are given to required users only that’s too after proper approval
Clear separation of responsibilities and roles, you mean. Not lumping them together... for example, like you are lumping together three separate sentences here.
> Don’t be scared guys
Sexist language.
> as once you get hold of all these things your life will become easier and you will start loving it.
It is not necessary to love one's job.
> Another fact is this is one of THE MOST HIGHLY PAID SKILLSET
Highly paid *skillsets*. Remember to keep singulars and plurals separate. Separation of tasks, a key DevOps skill.
> out there in market.
The market. Or markets, as there is more than one.
Again, failure to pay attention to apparently small details, like capitaLisaTion, disqualifies anyone from working in admin or development or ops roles. Capitalisation is vital on Unix systems, for instance.
Always remember -- your purpose in life may be to serve as an example to others of what NOT to do.
2/10, would not hire.
( Read more... )
I thought I'd comment on a few of the howlers, but it grew a bit...
> As we all know the days of sysadmins who applies specialized skills to tune individual servers is over.
No, not at all.
> Work is all about Automation
All? No. It's a part, no more.
> explaining a daily routine
*The* daily routine
> become a DevOps Engineer.
DevOps Engineers.
> A System Administrator is supposed to build, manage, and troubleshoot servers on a regular basis.
And clients, and networking, and switches/firewalls/routers, etc. You missed out about 75% of the job.
> Become master in deploying virtualization
Become *a* master
> A DevOps Engineer must know the IT network and storage concepts.
A lot more than just knowing the concepts. They need to know the implementation and management, as well.
> Puppet, Chef, Jenkins, Salt, Ansible, Kubernetes, Docker, Prometheus, Cloud Computing and storage platform, and Infrastructure as a Code (Terraform).
This is a bizarre mixture of automation, deployment and testing tools, concepts, ideas and methods. These things do not belong together.
> But nothing to worry about here.
*There is* nothing to worry about.
Only I think that's wrong, too. There's plenty.
> For e.g. Python
"e.g." means "for example"; you don't need "for" as well, and it shouldn't have a capital mid-sentence.
> bridge between the development and operations teams.
What you're trying to describe is someone who _is_ the ops team, or part of it. Not a bridge; the role you are talking about _replaces_ ops. (Be that a good idea or not. Hint: it's not.)
> As we know in today’s time
"As we know today" -- only we do not. I don't think this is true.
> everything is automatized
*Automated
> including the server triggering
No "the".
> These days we hear a new term “DevSecOps” right!
No, we don't.
> A DevOps personnel
You can't have *a* personnel.
And knowledge and awareness of security is part of *everyone's* role now, not just in dev, ops, or devops.
> Now you will say why a DevOps person needs to know the testing?
"Now, you might say why should a DevOps person need to know about testing?"
> Nothing to worry here again You
Missing full stop.
> can always got to your Development and Testing teams to address the errors if any in their application.
This sounds like passing the buck -- if you don't know why continuous integration (or whatever) tooling is working, ask someone else to fix it.
It is very important to know your limits. To know what you know and what you don't know, to be able and unafraid to SAY "I don't know" or "I can't do that"...
This is a core life skill, not just a core DevOps skill. But it also has a necessary coda: when you say you don't know, you need to be able to say "... but I know how to find out." Knowing what you don't know, being able to say that you don't know it, and knowing who to ask or where to look, and being able to say that too.
This is so important, it needs to go at the top.
Big scary list of platforms, then being confident enough to say "I don't know."
This is how I know if someone is good or not: whether, when encountering something new, they say "I don't know".
Anyone who never ever says "I don't know" is no good at their job and should not have that job.
I do not hear you saying you don't know -- about anything.
> Infra setups (either over Cloud or Bare Metal or VM’s)
Never ever make a plural with an apostrophe, in any conditions. No exceptions.
> Version Control support (GIT, SVN ..)
An ellipsis is three dots, no more, no less. No exceptions. If it is ending a sentence or a list, no space before it.
> Checking Email
That's everyone with a job. Omit the irrelevant. Your readers' time is precious; don't waste it.
> Checking JIRA / Any ticketing tool for pending/scheduled tasks.
Any ticketing tool? (And why is it capitalised?) Don't you mean _your_ ticketing tool or tools?
Scheduled tasks? I thought you said it was all about automation now? If it can be scheduled, shouldn't it be automated?
> Clear Notifications of alerting system.
You uSe an awFul loT of RanDom Capital letters, do you Know that? Why?
> Ensure if any new server is created and monitoring has been set up on that.
Check for new servers every day? Really? This just happens without you, does it?
Just one? You use the singular, not plurals here, so you must mean just one of them.
> Verify if all the service running on that server are covered under the monitoring system.
All the service? Don't you mean all the services? Did you proofread this before you posted it?
Top tip to aspiring DevOps people: CHECK YOUR WORK. If you are not sure, for example, if you are not working in your native language or a language you know very well, get a native to check before pushing to prod.
> Check and automate if any server is running out of disk. Taking a backup of instance and restoring if required.
If any *servers* ARE. How will you automate adding disk space? Is that possible? Why are you picking out and highlighting this one task?
> Taking a backup of Prod DB and providing that DB to developers on Staging / Testing Environment for testing of any issue.
Any issue? You mean any *issues.* Attention to detail! Like you are not showing here.
Do you test on a copy of the production database? Really? Is that not a bit big?
> Automation setup for daily tasks like (DB/Instance/Logs/Config-Files) backup.
Don't use "like" when you mean "such as". They are not the same. Precision is important, too.
> In case of new project setting up new Jenkins Job. ( Freestyle / Pipeline).
Freestyle, like your punctuation?
> Making config changes on servers using (Ansible /chef/ puppet).
Don't put things in parentheses if you are being specific. Be consistent in capitalisation.
Actually, be consistent in general. You're not.
> Writing playbooks for automating daily tasks.
Playbooks? Is that not specific to one tool? Why not be general? Always be more general if it is applicable. DevOps is all about generalisation instead of specialisation. Is automation of repetitive tasks a daily task? I would think automation is about *eliminating* daily tasks.
> Deploying code on Development and Production servers.
Radically different tasks which you are combining. That sets off alarm bells for me.
> Ensuring that post-deployment sanity of code is done and proper sign-offs are given.
"Sanity" and "sanity checking" are not the same thing, you know.
> Providing assistance during Audits.
Audits? Every day? Remember these are daily tasks.
Being able to clearly distinguish between daily tasks and exceptional ones is a core skill, one you appear to lack.
> Ensuring that access on servers are given to required users only that’s too after proper approval
Clear separation of responsibilities and roles, you mean. Not lumping them together... for example, like you are lumping together three separate sentences here.
> Don’t be scared guys
Sexist language.
> as once you get hold of all these things your life will become easier and you will start loving it.
It is not necessary to love one's job.
> Another fact is this is one of THE MOST HIGHLY PAID SKILLSET
Highly paid *skillsets*. Remember to keep singulars and plurals separate. Separation of tasks, a key DevOps skill.
> out there in market.
The market. Or markets, as there is more than one.
Again, failure to pay attention to apparently small details, like capitaLisaTion, disqualifies anyone from working in admin or development or ops roles. Capitalisation is vital on Unix systems, for instance.
Always remember -- your purpose in life may be to serve as an example to others of what NOT to do.
2/10, would not hire.
