Answers: <p>Below comments will work for you: </p>
  
  <blockquote>
    <p>Monitor 5 different servers' performance.</p>
    
    <p>Monitor 2 of those servers Active Batch execution agents</p>
  </blockquote>
  
  <ul>
  <li>understand and priorities tasks/faults as per solution and business impact  </li>
  <li>build jobs to alert you &amp; your team (may be scripts already there)</li>
  <li>build rollbacks/optimizer  according  alerts (some rollback scripts may be already there)  </li>
  </ul>
  
  <blockquote>
    <p>Handle requests as they are created.<br>
    Handle project tasks as they are
    created.</p>
  </blockquote>
  
  <ul>
  <li>make sync closely with developer/testing teams and follow up / understand there approach, scripts and solutions what they have developed  </li>
  </ul>
  
  <p>Monitor Email/Skype/Phone</p>
  
  <blockquote>
    <p>Build whatever is requested that isn't directly assigned thru the
    ticketing system.</p>
  </blockquote>
  
  <p>follow up manually tasks/ solution designs that to be build and understand the requirement. To build jobs, you should educate your self at least with below technologies:</p>
  
  <ul>
  <li>data format json, xml, yml</li>
  <li>python , python/ linux scripting</li>
  <li>Python framework like Robot, Ansible</li>
  <li>Rest API</li>
  <li>CI/CD Jankins, Git</li>
  <li>CI/CD suite xtesting</li>
  <li>Linux</li>
  <li>solution specific dependencies</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2019-09-06T04:17:19.017Z
Answers: 2019-09-06T04:17:19.017Z
Answers: Jatinder Singh Brar
Answers: <p>I agree with those who have commented that the role you describe doesn't really match a typical DevOps role. However, there are certain things you won't be able to change in your organization. Instead, focus on the things you can do.</p>
  <h2>Understand the Objectives</h2>
  <p>The best place to start is with a clear understanding of Service Level Objectives. What kinds of things do external customers actually care about? If they don't care about uptime, don't make uptime measurements a high priority. Perhaps latency, software updates, content accuracy, or some other measure is more important. Also be aware of your internal customers' needs (your boss, coworkers, etc). What things do they care about?</p>
  <p>Once you understand what is most important to your customers, <strong>measure, measure, measure!</strong> Get as much data as you can about those items that matter. How long does it take to deploy code? When you close a ticket, what percentage of the time does it come back unresolved? And so on. Use those measurements to improve over time.</p>
  <p>Here are some areas you can focus your efforts (varies, depending on the company you work for):</p>
  <h3>Configuration</h3>
  <p>If someone logged into a server and broke the configuration, how hard would it be to correct the error?</p>
  <ul>
  <li>You should be able to consistently build and replace resources with minimal effort.</li>
  <li>Configuration management should be complete so that all meaningful changes are tracked.</li>
  <li>Ideally, build up processes or tooling as needed so that developers can modify configuration themselves in a controlled and collaborative way (:D DevOps!).</li>
  </ul>
  <h3>CI/CD</h3>
  <p>When new code is released, how does it get delivered?</p>
  <ul>
  <li>When code is pushed to source control, it should trigger automated testing and deployment. If possible, this should happen in a pipeline that deploys multiple environments in sequence as tests pass (dev -&gt; qa -&gt; uat -&gt; prod).</li>
  <li>Improve visibility so that you can easily see where different versions of the code are running, what errors are occurring, and how performance is changing.</li>
  <li>Enable your software developers to deliver code themselves (:D DevOps!).</li>
  <li>Collaborate with developers to improve this process (:D DevOps!)</li>
  </ul>
  <h3>Logging/Metrics</h3>
  <p>When something goes wrong, how quickly can you find out what the problem was? If something went wrong 2 months ago, can you still find out what the problem was?</p>
  <ul>
  <li>Collect logs in a central place with tools that help you search and visualize.</li>
  <li>Aggregate metrics with tools that help visualize.</li>
  <li>Reduce noise! If it's not meaningful, don't keep it (but be a little conservative, sometimes things turn out to be meaningful later).</li>
  <li>Work with developers to understand how logging and metrics would help them deliver better software (:D DevOps!).</li>
  </ul>
  <h3>Alerting/Incident Response</h3>
  <p>Ideally, you should not ever need to look at a graph, dashboard, or log message, unless there's an actual problem to solve. Sitting and watching a dashboard is not a good task for humans.</p>
  <ul>
  <li>Set up alerting so that you get notified when problems arise.</li>
  <li>Alerts should go to <strong>ONE</strong> person, who is the RIGHT person.</li>
  <li>Alerts should be <em>urgent</em> (needs to be addressed immediately), and <em>actionable</em> (the person getting the alert <em>can</em> fix it).</li>
  <li>In the spirit of paging the right person, you may be able to work with developers on getting them into some kind of on-call rotation (even just M-F 8-5 for a subset of code issues). (DevOps?)</li>
  </ul>
  <h3>Disaster Recovery</h3>
  <p>If your servers were destroyed today, how long would it take to be up and running again?</p>
  <ul>
  <li>Take backups of data and set up backup infrastructure.</li>
  <li>Test backup recovery regularly.</li>
  <li>Test failover to secondary infrastructure regularly.</li>
  <li>Work with developers to better understand how code will operate in a failover scenario and improve as needed (:D DevOps!).</li>
  </ul>
  <h3>Documentation</h3>
  <p>Heaven forbid something happen to you, but if it does, how well can someone else replace you. Document what you've built and improved so clearly that another person <em>can</em> replace you. Don't worry, this makes you <em>less</em> likely to be fired.</p>
  <h3>Education</h3>
  <p>Always, educate yourself. Take online courses, read books, work on certifications. I don't know what the path looks like for you. I believe that spending a few hours every week specifically dedicated to improving your own skills is a valuable use of your time (even for your employer!).</p>
  <p>A book like Site Reliability Engineering (Beyer, Jones, Petoff &amp; Murphy) or The Phoenix Project (Kim, Behr &amp; Spafford) might be good to read on this topic.</p>
  <hr />
  <p>Totally possible I've entirely missed the point of your question. If so, I apologize. However, I think this ought to give you some ideas of how you can spend your time in ways that is worthwhile to both your employer and yourself.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-09-05T20:57:49.633Z
Answers: 2019-09-05T20:57:49.633Z
Answers: 2020-06-18T08:28:10.803Z
Answers: vastlysuperiorman
Body: <p>At my current job, I started as a Software Developer, and I've worked myself into a DEVOPS position. I am worried about getting fired, not because I'm doing something wrong, but because I'm used to proactively doing things(writing code), whereas most of my time now is sitting around waiting for things to happen....</p>
  <p>My daily duties(and I asked my manager in a detailed email listing these same ones) are,</p>
  <blockquote>
  <p>Monitor 5 different servers' performance.</p>
  <p>Monitor 2 of those servers Active Batch execution agents</p>
  <p>Handle requests as they are created.</p>
  <p>Handle project tasks as they are created.</p>
  <p>Monitor Email/Skype/Phone</p>
  <p>Build whatever is requested that isn't directly assigned thru the ticketing system.</p>
  </blockquote>
  <p>It seems like a lot at first glance, but what is actually involved is little more than watching 1 monitor for new errors, and another monitor for messages. I can usually complete tickets in minutes-1 hour. Is this normal for Dev Ops-just sitting around waiting? If so, what can I do to be more useful? If not, am I in danger of getting fired?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-09-04T21:34:04.800Z
Comments: What you describe is not a DevOps position, in any sense of the term. It’s either just “ops” or what’s sometimes called “triage”. Perhaps using your existing development skills you might be able to automate some of that reactive monitoring, which would be a productive path forward out of what seems like a position with limited growth potential.
Comments: Dan1701
Tags: <operations>
Title: How to handle a new Dev Ops position?
UserDisplayName: King of NES
ThreadText: # How to handle a new Dev Ops position?
  
  (Asked by: username_0 on 2019-09-04)
  
  At my current job, I started as a Software Developer, and I've worked myself into a DEVOPS position. I am worried about getting fired, not because I'm doing something wrong, but because I'm used to proactively doing things(writing code), whereas most of my time now is sitting around waiting for things to happen....
  
  My daily duties(and I asked my manager in a detailed email listing these same ones) are,
  
  > Monitor 5 different servers' performance.
  >
  > Monitor 2 of those servers Active Batch execution agents
  >
  > Handle requests as they are created.
  >
  > Handle project tasks as they are created.
  >
  > Monitor Email/Skype/Phone
  >
  > Build whatever is requested that isn't directly assigned thru the ticketing system.
  
  It seems like a lot at first glance, but what is actually involved is little more than watching 1 monitor for new errors, and another monitor for messages. I can usually complete tickets in minutes-1 hour. Is this normal for Dev Ops-just sitting around waiting? If so, what can I do to be more useful? If not, am I in danger of getting fired?
  
  **Tags:** operations
  
  > **Comments:**
  > **username_1**: What you describe is not a DevOps position, in any sense of the term. It’s either just “ops” or what’s sometimes called “triage”. Perhaps using your existing development skills you might be able to automate some of that reactive monitoring, which would be a productive path forward out of what seems like a position with limited growth potential.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2019-09-05. Score: 1
  
  I agree with those who have commented that the role you describe doesn't really match a typical DevOps role. However, there are certain things you won't be able to change in your organization. Instead, focus on the things you can do.
  
  ## Understand the Objectives
  
  The best place to start is with a clear understanding of Service Level Objectives. What kinds of things do external customers actually care about? If they don't care about uptime, don't make uptime measurements a high priority. Perhaps latency, software updates, content accuracy, or some other measure is more important. Also be aware of your internal customers' needs (your boss, coworkers, etc). What things do they care about?
  
  Once you understand what is most important to your customers, **measure, measure, measure!** Get as much data as you can about those items that matter. How long does it take to deploy code? When you close a ticket, what percentage of the time does it come back unresolved? And so on. Use those measurements to improve over time.
  
  Here are some areas you can focus your efforts (varies, depending on the company you work for):
  
  ### Configuration
  
  If someone logged into a server and broke the configuration, how hard would it be to correct the error?
  
  * You should be able to consistently build and replace resources with minimal effort.
  * Configuration management should be complete so that all meaningful changes are tracked.
  * Ideally, build up processes or tooling as needed so that developers can modify configuration themselves in a controlled and collaborative way (:D DevOps!).
  
  ### CI/CD
  
  When new code is released, how does it get delivered?
  
  * When code is pushed to source control, it should trigger automated testing and deployment. If possible, this should happen in a pipeline that deploys multiple environments in sequence as tests pass (dev -> qa -> uat -> prod).
  * Improve visibility so that you can easily see where different versions of the code are running, what errors are occurring, and how performance is changing.
  * Enable your software developers to deliver code themselves (:D DevOps!).
  * Collaborate with developers to improve this process (:D DevOps!)
  
  ### Logging/Metrics
  
  When something goes wrong, how quickly can you find out what the problem was? If something went wrong 2 months ago, can you still find out what the problem was?
  
  * Collect logs in a central place with tools that help you search and visualize.
  * Aggregate metrics with tools that help visualize.
  * Reduce noise! If it's not meaningful, don't keep it (but be a little conservative, sometimes things turn out to be meaningful later).
  * Work with developers to understand how logging and metrics would help them deliver better software (:D DevOps!).
  
  ### Alerting/Incident Response
  
  Ideally, you should not ever need to look at a graph, dashboard, or log message, unless there's an actual problem to solve. Sitting and watching a dashboard is not a good task for humans.
  
  * Set up alerting so that you get notified when problems arise.
  * Alerts should go to **ONE** person, who is the RIGHT person.
  * Alerts should be *urgent* (needs to be addressed immediately), and *actionable* (the person getting the alert *can* fix it).
  * In the spirit of paging the right person, you may be able to work with developers on getting them into some kind of on-call rotation (even just M-F 8-5 for a subset of code issues). (DevOps?)
  
  ### Disaster Recovery
  
  If your servers were destroyed today, how long would it take to be up and running again?
  
  * Take backups of data and set up backup infrastructure.
  * Test backup recovery regularly.
  * Test failover to secondary infrastructure regularly.
  * Work with developers to better understand how code will operate in a failover scenario and improve as needed (:D DevOps!).
  
  ### Documentation
  
  Heaven forbid something happen to you, but if it does, how well can someone else replace you. Document what you've built and improved so clearly that another person *can* replace you. Don't worry, this makes you *less* likely to be fired.
  
  ### Education
  
  Always, educate yourself. Take online courses, read books, work on certifications. I don't know what the path looks like for you. I believe that spending a few hours every week specifically dedicated to improving your own skills is a valuable use of your time (even for your employer!).
  
  A book like Site Reliability Engineering (Beyer, Jones, Petoff & Murphy) or The Phoenix Project (Kim, Behr & Spafford) might be good to read on this topic.
  
  ---
  
  Totally possible I've entirely missed the point of your question. If so, I apologize. However, I think this ought to give you some ideas of how you can spend your time in ways that is worthwhile to both your employer and yourself.
  
  
  ---
  
  ### Answer by username_2 on 2019-09-06. Score: 0
  
  Below comments will work for you:
  
  > Monitor 5 different servers' performance.
  >
  > Monitor 2 of those servers Active Batch execution agents
  
  * understand and priorities tasks/faults as per solution and business impact
  * build jobs to alert you & your team (may be scripts already there)
  * build rollbacks/optimizer according alerts (some rollback scripts may be already there)
  
  > Handle requests as they are created.  
  > Handle project tasks as they are
  > created.
  
  * make sync closely with developer/testing teams and follow up / understand there approach, scripts and solutions what they have developed
  
  Monitor Email/Skype/Phone
  
  > Build whatever is requested that isn't directly assigned thru the
  > ticketing system.
  
  follow up manually tasks/ solution designs that to be build and understand the requirement. To build jobs, you should educate your self at least with below technologies:
  
  * data format json, xml, yml
  * python , python/ linux scripting
  * Python framework like Robot, Ansible
  * Rest API
  * CI/CD Jankins, Git
  * CI/CD suite xtesting
  * Linux
  * solution specific dependencies
  
  
  ---
  
  