DevOps primarily focuses on Delivery Speed and SRE focuses on Reliability in production but where does Production Support Engineers fit who also focuses on production monitoring, alerting, performance, user experience, incident management, RCA and work on code defects and understand business functionality?

  • In a SRE world, would production support engineers be more aligned to SRE or merged with SRE?
  • In a SRE world, would production support engineers be more aligned to SRE or merged with SRE? - PS engineers would merge with SRE.
    – KatariaA
    Commented Mar 26, 2019 at 2:26

3 Answers 3


The best answer to DevOps vs SRE is here What's the Difference Between DevOps and SRE ? From the above series, you will understand Class SRE implements DevOps and both are working on a similar ground and it's pretty align goal for both of them.

As a production support, you will be doing the task which you have mentioned in the question, apart, you need deep visibility, alert and notifications, latency, metrics, tracking, security, etc. lots of things to take care. And, it basically providing the service to the end users who is utilizing your application or system. Also, I see production support team have written the dockerfile and bash scripts to automate many tasks. So, whenever user faced any issue that first comes to Production Support team and it might went to other IT teams if it's not easily resolve. But, if you look at SRE, their sole purpose is to keep system in reliable state every time, maintain resiliency, etc. In some organization, the DevOps does this part too.

From my perspective, all the three terms are same as their goal align and just differ in functionality. These functionality differs from organization to organizations. But, DevOps are intended to bring culture and shift in paradigm so that everyone will work collaboratively. Hope this helps.


I don't want to nit pick, but I respectfully disagree with the idea that DevOps is about speed while SRE is about reliability. I understand this is an easy thing to think -- especially because SRE has "Reliability" in its name -- but it a'int so. :-)

SRE is all about velocity.

We think that over the long run you'll go much much faster if you recognize when the wheels are starting to go wobbly (SLOs and Error Budgets) and slow down in those cases to make things better. That, in our experience, is much faster than having to stop for a goodly long time because we let a bunch of reliability related technical debt pile up.

SRE can be thought of as a specific instantiation of DevOps with a more uniformly enforced set of constraints. (Hence the Class SRE implements DevOps formulation above.)


This is a good question and it is worth bearing in mind that that Ops can mean different things in different organizations. There is a) what you might call SysOps which is to do with the reliable running of the systems and which SRE effectively replaces in a DevOps context and b) what one might call Application Support which deals with manual intervention of a platform where there are gaps in the functionality or errors at the application level.

A Production Support role might cover either or both of these roles whether in a first or second line capacity. SRE is not really there to take on the Application Support function although they may (along with Development) be involved in engineering improvements to the platform to avoid the need for that manual intervention going forwards and through driving effective PIRs.

In your example the Production Support function seems to already cover much of what an SRE would also be responsible for. Depending on your Production Support Engineer skill set an SRE might approach the solution differently. In your case I would suggest you bring people with SRE skill set (monitoring, automation, DevOps working methods eg effective collaboration, PIR process as well as general SysOps skills) to work with the existing Product Support engineers. Whether you rebrand them as SREs or continue to have 2 roles would depend on their currrent skill set and potential but this could be a good career progression pipeline to recognise.

  • Noting (as per the google video linked above) that DevOps is not really a role but a general approach to technology. For this reason it is not useful to refer to it as a definition for a role as it will always cause confusion for someone.
    – rawcane
    Commented Sep 8, 2020 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.