Answers: <p>AFAIK, there is no boundary for DevOps engineer. When it comes to questions you have put together, it is general misconception to consider DevOps engineer as administrators. </p>
  
  <p>DevOps is change in culture, change in mindset and change in approach. </p>
  
  <p>DevOps culture fills the gaps development and operations. </p>
  
  <p>DevOps mindset allows engineers to try out of the box combinations to explore tools, technology, services to fasten the process to test, build and deploy product.</p>
  
  <p>DevOps approach will allow engineers to come out of sticking to certain role and explore. </p>
  
Answers: CC BY-SA 4.0
Answers: 2020-01-28T21:46:00.477Z
Answers: 2020-01-28T21:46:00.477Z
Answers: sunil.kms123
Answers: <p>From the "how it should properly work"/"how it was meant" perspective there is no real "DevOps engineer" because DevOps is a methodology/culture which emphasizes also on technical practices which should stretch across as many roles as possible and feasible.</p>
  
  <p>How can we apply the CALMS (Culture, Automation, Lean, Measure, Share) mantra here? (Taking into approach that depending on factors like maturity, complexity and resources in the context, approaches need to be adapted to what helps to solve problems in an efficient and sustainable way)</p>
  
  <ul>
  <li>Requirements engineer: can I automatically qualify maturity of requirements and track their delivery?</li>
  <li>Software engineer: what is required to run my software in test either productive environment?</li>
  <li>Architect: can I have a big picture based on live metrics?</li>
  <li>Tester: can I create virtual temporary infrastructure to support execution of my code?</li>
  <li>System administrator: how can I better organize my help desk / 1st user support and leverage self-help / automation solutions?</li>
  </ul>
  
  <p>Somebody with a wish to focus on the methodology itself will be somewhere in-between all these guys and obviously become "jack of all trades, master of none". </p>
  
  <p>Given this, my consideration how I would approach your customers' inquiries could be:</p>
  
  <ol>
  <li>Please follow the instructions to setup VPN in this Wiki/code from this Git repo and if it's not working, document/show steps you have taken.</li>
  <li>Please share more details on the context (here is not clear who owns which parts).</li>
  <li>Let's allocate time to develop emergency plan for immediate action if required and also run scaling tests on a test system to model experiments, collect data and finally learn under which circumstances the performance problems appear. Then, we will know why it is happening. :-)</li>
  <li>Follow from 3.? What does mean schedule from your perspective and if you mean regular execution, how often? So please let's go back to previous item :-)</li>
  <li><p>Possibly, have you got more specs which infrastructure option (Cloud, on premises) should we use for that and what and what are you going to do? Here is a link to generic infrastructure planner, let's allocate time to discuss what is specific for Spark/Hadoop here and how will delivery to it look like.</p></li>
  <li><p>If identity management is not part of our architecture, let's assess what are you going to do. An outcome could be that you include creation of users to your database scripts. </p></li>
  </ol>
  
  <p>So the bottom line in DevOps culture regarding the role boundary is:</p>
  
  <ul>
  <li>professional communication first</li>
  <li>the boundary is to set boundaries inviting people to a professional conversation between adults, to get more conscious on both sides (!) about requirements, responsibilities and goals. Not just thinking in solutions and delegation but also make a plan and assess risks. </li>
  </ul>
  
  <p>Therefore seasoned and successful professionals who are today maybe 50+ yrs old say sometimes jokingly "we have been doing DevOps from the very beginning" and partly, they are right.</p>
  
  <p>To conclude and highlight and reflect on the real-world existence of such job-role, organizations who do not have a DevOps culture proceed to define DevOps roles as the following, for example:</p>
  
  <ul>
  <li>DevOps engineer is an advanced systems administrator who can code up the infrastructure and automate it completely.</li>
  <li>DevOps engineer is a tools administrator with coding skills to support the Dev team and ensure delivery towards production (CI/CD, deployment scripting but also Jira administration)</li>
  <li>DevOps engineer is a developer focusing on including infrastructure elements into development, like containers and cloud APIs.</li>
  </ul>
  
  <p>After all, many companies still look for the "full stack engineer" who should obviously become additionally the DevOps engineer (along with "AI/ML,  blockchain and foobar").</p>
  
  <p>Finally, the role boundary, possibly not only in the DevOps context, but in this special context indeed very likely:</p>
  
  <ul>
  <li>is also in your responsibility</li>
  <li>may change between projects and employers or just from time to time.</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2020-01-28T08:53:13.970Z
Answers: 2020-01-31T08:25:49.447Z
Answers: 2020-01-31T08:25:49.447Z
Answers: Ta Mu
Body: <p>I will not get into what is DevOps since everyone have their own meaning.</p>
  
  <p>But I would like to understand what is the boundary of DevOps engineer. Sometimes people ping me and ask to me that,</p>
  
  <blockquote>
    <ol>
    <li>can you please help me setting up VPN in my laptop?</li>
    </ol>
  </blockquote>
  
  <p>sometimes,</p>
  
  <blockquote>
    <ol start="2">
    <li>From the RDP machine, I am not able to open MySQL workbench, it hangs,
    can you fix it please?</li>
    </ol>
  </blockquote>
  
  <p>sometimes,</p>
  
  <blockquote>
    <ol start="3">
    <li>Production application is having performance issues, why is it
    happening?</li>
    </ol>
  </blockquote>
  
  <p>sometimes,</p>
  
  <blockquote>
    <ol start="4">
    <li>Can you please schedule the performance testing script?</li>
    </ol>
  </blockquote>
  
  <p>sometimes,</p>
  
  <blockquote>
    <ol start="5">
    <li>can you setup the spark and hadoop cluster?</li>
    </ol>
  </blockquote>
  
  <p>sometimes,</p>
  
  <blockquote>
    <ol start="6">
    <li>can you create users in MySQL?</li>
    </ol>
  </blockquote>
  
  <p>I think we need an industry wide boundary, otherwise, the role of DevOps engineer is going in every direction.</p>
  
Tags: <culture><project-management><job-role><team-role>
Title: What is the boundary of DevOps engineer job role?
UserDisplayName: karthikeayan
ThreadText: # What is the boundary of DevOps engineer job role?
  
  (Asked by: username_0 on 2020-01-28)
  
  I will not get into what is DevOps since everyone have their own meaning.
  
  But I would like to understand what is the boundary of DevOps engineer. Sometimes people ping me and ask to me that,
  
  > 1. can you please help me setting up VPN in my laptop?
  
  sometimes,
  
  > 2. From the RDP machine, I am not able to open MySQL workbench, it hangs,
  >    can you fix it please?
  
  sometimes,
  
  > 3. Production application is having performance issues, why is it
  >    happening?
  
  sometimes,
  
  > 4. Can you please schedule the performance testing script?
  
  sometimes,
  
  > 5. can you setup the spark and hadoop cluster?
  
  sometimes,
  
  > 6. can you create users in MySQL?
  
  I think we need an industry wide boundary, otherwise, the role of DevOps engineer is going in every direction.
  
  **Tags:** culture, project-management, job-role, team-role
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2020-01-28. Score: 11 | Accepted answer
  
  From the "how it should properly work"/"how it was meant" perspective there is no real "DevOps engineer" because DevOps is a methodology/culture which emphasizes also on technical practices which should stretch across as many roles as possible and feasible.
  
  How can we apply the CALMS (Culture, Automation, Lean, Measure, Share) mantra here? (Taking into approach that depending on factors like maturity, complexity and resources in the context, approaches need to be adapted to what helps to solve problems in an efficient and sustainable way)
  
  * Requirements engineer: can I automatically qualify maturity of requirements and track their delivery?
  * Software engineer: what is required to run my software in test either productive environment?
  * Architect: can I have a big picture based on live metrics?
  * Tester: can I create virtual temporary infrastructure to support execution of my code?
  * System administrator: how can I better organize my help desk / 1st user support and leverage self-help / automation solutions?
  
  Somebody with a wish to focus on the methodology itself will be somewhere in-between all these guys and obviously become "jack of all trades, master of none".
  
  Given this, my consideration how I would approach your customers' inquiries could be:
  
  1. Please follow the instructions to setup VPN in this Wiki/code from this Git repo and if it's not working, document/show steps you have taken.
  2. Please share more details on the context (here is not clear who owns which parts).
  3. Let's allocate time to develop emergency plan for immediate action if required and also run scaling tests on a test system to model experiments, collect data and finally learn under which circumstances the performance problems appear. Then, we will know why it is happening. :-)
  4. Follow from 3.? What does mean schedule from your perspective and if you mean regular execution, how often? So please let's go back to previous item :-)
  5. Possibly, have you got more specs which infrastructure option (Cloud, on premises) should we use for that and what and what are you going to do? Here is a link to generic infrastructure planner, let's allocate time to discuss what is specific for Spark/Hadoop here and how will delivery to it look like.
  6. If identity management is not part of our architecture, let's assess what are you going to do. An outcome could be that you include creation of users to your database scripts.
  
  So the bottom line in DevOps culture regarding the role boundary is:
  
  * professional communication first
  * the boundary is to set boundaries inviting people to a professional conversation between adults, to get more conscious on both sides (!) about requirements, responsibilities and goals. Not just thinking in solutions and delegation but also make a plan and assess risks.
  
  Therefore seasoned and successful professionals who are today maybe 50+ yrs old say sometimes jokingly "we have been doing DevOps from the very beginning" and partly, they are right.
  
  To conclude and highlight and reflect on the real-world existence of such job-role, organizations who do not have a DevOps culture proceed to define DevOps roles as the following, for example:
  
  * DevOps engineer is an advanced systems administrator who can code up the infrastructure and automate it completely.
  * DevOps engineer is a tools administrator with coding skills to support the Dev team and ensure delivery towards production (CI/CD, deployment scripting but also Jira administration)
  * DevOps engineer is a developer focusing on including infrastructure elements into development, like containers and cloud APIs.
  
  After all, many companies still look for the "full stack engineer" who should obviously become additionally the DevOps engineer (along with "AI/ML, blockchain and foobar").
  
  Finally, the role boundary, possibly not only in the DevOps context, but in this special context indeed very likely:
  
  * is also in your responsibility
  * may change between projects and employers or just from time to time.
  
  
  ---
  
  ### Answer by username_1 on 2020-01-28. Score: 2
  
  AFAIK, there is no boundary for DevOps engineer. When it comes to questions you have put together, it is general misconception to consider DevOps engineer as administrators.
  
  DevOps is change in culture, change in mindset and change in approach.
  
  DevOps culture fills the gaps development and operations.
  
  DevOps mindset allows engineers to try out of the box combinations to explore tools, technology, services to fasten the process to test, build and deploy product.
  
  DevOps approach will allow engineers to come out of sticking to certain role and explore.
  
  
  ---
  
  