Liam_on_Linux (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
liam_on_linux) wrote2020-10-08 01:08 pm
liam_on_linux) wrote2020-10-08 01:08 pm
What a DevOps engineer -- or any engineer -- should and shouldn't do
In a work chat, this gods-awful article about "What does a DevOps Engineer do?" came up.
(Copying the text in here, as there's a good chance he will delete it.)
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.
(Copying the text in here, as there's a good chance he will delete it.)
As we all know the days of sysadmins who applies specialized skills to tune individual servers is over. Work is all about Automation and it requires to re-skill yourself and adapt to these new and disruptive tech changes.
So before we start explaining a daily routine of a DevOps engineer we must thank you all the System Administrators who acquired a lot of new skills to become a DevOps Engineer.
A DevOps Engineer should be proficient in following skills -
Should be an Excellent System Admin
A System Administrator is supposed to build, manage, and troubleshoot servers on a regular basis.
Become master in deploying virtualization
A DevOps professional should be well-versed with the entire process of virtualizing servers and other components.
Some of the important virtualization tools and technologies are VMWare, Clouds (AWS, GCP, Azure etc.), KVM, Vagrant, VirtualBox etc.
Networking and Storage knowledge
A DevOps Engineer must know the IT network and storage concepts. This comes in handy when there is a need to design solutions that can stand up to the test of scalability, performance, and high availability at all times.
Knowledge of Automation tools
There are a lot of automation tools and technologies that are being deployed in the DevOps process, and as a DevOps professional we need to be familiar with these sets of tools and be able to deploy them in the DevOps set-up.
Some of the important tools that are being widely deployed include Puppet, Chef, Jenkins, Salt, Ansible, Kubernetes, Docker, Prometheus, Cloud Computing and storage platform, and Infrastructure as a Code (Terraform).
Programming!
Now this is one part where most of the DevOps engineers with SysAdmin background lacks.
But nothing to worry about here. Having a basic knowledge of coding in any of the popular coding language (For e.g. Python) can go a long way. This way, the DevOps professional can be a better bridge between the development and operations teams. As we know in today’s time everything is automatized including the server triggering, application installation, configuration, and validation processes.
Remember one thing as a DevOps Engineer you will not be writing some thousands of lines of code. What is required is to have basic enough knowledge to write some small scripts and should be able to understand the code flow.
Security
These days we hear a new term “DevSecOps” right!
We hear it because Security is one of the prime focus of a DevOps professional. A DevOps personnel needs to know about various security measures that are to be taken care of to ensure that the system is safe and sound and running at all times.
Testing
Now you will say why a DevOps person needs to know the testing? I agree with that question.
But as you know there are a lot of automation tools that are deployed for the process of testing, so the DevOps personnel needs to have hands-on experience of working with these tools.
Nothing to worry here again You can always got to your Development and Testing teams to address the errors if any in their application.
What does a DevOps Engineer do ?
- Infra setups (either over Cloud or Bare Metal or VM’s)
- Software Installations
- Server Maintenance
- Application Support
- Version Control support (GIT, SVN ..)
- Build and Release process support (Jenkins, Team city ..)
- Automate Configuration Management (Ansible, Chef, Puppet ..)
- Support cross functional teams
- Research and Deploy new tools
- Vulnerability Assessment and Patching
- Server and Application level Monitoring (ELK, Prometheus, Grafana ..)
- Knowledge of Ticketing system (Jira, Bugzilla ..)
- Automated Backups
- Access management
- Documentation
- Continuous Improvement and Self Training
Basically a DevOps Engineer should be a LIFE LONG LEARNER!
A Daily “TO DO LIST” of A DevOps Engineer
- Checking Email
- Checking monitoring alerts
- Checking JIRA / Any ticketing tool for pending/scheduled tasks.
- Clear Notifications of alerting system.
- Ensure if any new server is created and monitoring has been set up on that.
- Verify if all the service running on that server are covered under the monitoring system.
- Check and automate if any server is running out of disk. Taking a backup of instance and restoring if required.
- Taking a backup of Prod DB and providing that DB to developers on Staging / Testing Environment for testing of any issue.
- Automation setup for daily tasks like (DB/Instance/Logs/Config-Files) backup.
- In case of new project setting up new Jenkins Job. ( Freestyle / Pipeline).
- Making config changes on servers using (Ansible /chef/ puppet).
- Writing playbooks for automating daily tasks.
- Deploying code on Development and Production servers.
- Ensuring that post-deployment sanity of code is done and proper sign-offs are given.
- Seeking for approvals from (Business/QA/UAT and Security Sign-offs).
- Providing assistance during Audits.
- Ensuring that access on servers are given to required users only that’s too after proper approvals.
That’s All!
Don’t be scared guys as once you get hold of all these things your life will become easier and you will start loving it. Another fact is this is one of THE MOST HIGHLY PAID SKILLSET out there in market.
So keep on doing CL (Continuous Learning).
Hope you like the article. Please let me know your feedback in the response section.
Thanks. Happy learning!
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.