Hot answers tagged

49

DevOps is about maintaining code, is that correct? DevOps is not "just" about code, or systems, or any one thing. DevOps is a very general term that covers all things related to software delivery. Site Reliability Engineering is a term popularized by Google. From this article https://landing.google.com/sre/interview/ben-treynor.html we can distill their ...


20

Dave Swersky already posted an excellent response above with Ben Treynor's definition of SRE, which is as poignant today as it was in 2003. Fundamentally, it’s what happens when you ask a software engineer to design an operations function. So, in an attempt to further define "DevOps", here's an excerpt from the book Effective DevOps by Jennifer Davis &...


16

Site Reliability Engineering falls under more or less traditional operations, but heavily automated and version controlled, what is also called Infrastructure as Code. It is a well defined vertical role. In modern DevOps this is the vertical slice that relates to Operations. You can have a team of SRE. DevOps as such is a cultural change for an organization....


8

Your question doesn't seem to make any assumption about the platform/OS it is about. Which is why it may make sense to add an answer about how this is typically done/addressed in a mainframe environment, where the "engineers" (as in your question title) are actually groups of people were dozens (possibly hundreds) of people are involved. My answer is based ...


6

Thankfully, since Site Reliability Engineering developed internally at Google and only recently has started to make its way into the broader community, it is fairly well-defined. What isn't, though, is web operations (or "systems administration" - as an example of the lack of clarity, you use both in your question). It's difficult to discuss the ...


5

What is the future of DevOps in the age of serverless? Can you see less and less DevOps roles being available in the age of serverless? I personally dislike the DevOps Engineer role as DevOps is a culture! What you probably mean is whether Operations or System Engineers will be phased out. Like the other answers indicate, these activities will still be ...


5

Disclosure: I work as a devops coach at a global company with over a thousand developers. TL;DR It depends whether you think devops is a particular set of skills and tools, or whether you think devops is a culture and way of working. It you look at the “what is devops” questions and answers, in one interesting answer here, they give some insights as to ...


5

Also serverless needs some infrastructure and for that you also need software components to develop and rollout. Beyond yet another website or application server I'd also think of energing advanced ecosystems related to: Internet of things - embedded systems and edge servers Artificial intelligence and data engineering in distributed systems. Could be ...


5

Answer based on my knowledge of French "Internal controls" regulation, kind of equivalent to the SEC regulations you point to, I assume linking here to a French legal text would not be really useful and I know of no good translation of it. In an ideal 'You build it, you run it' model, everyone in the team will be accountable for the change. The risk ...


5

I think we need to view this in the larger context of Flow and Systems Thinking which is one of the core values of DevOps. Specifically, DevOps Values require an understanding that each individual is part of a larger system and work toward increasing the flow of value through that system to the customer. DevOps also focuses on helping the organization set a ...


4

@Abhay Pai why not posting this as 5 different questions? Google for "left shift" in DevOps context. Consider DevOps team patterns http://web.devopstopologies.com/ "While DevOps raise problems and dispatch them to Dev to solve, the SRE approach is to find problems and solve some of them themselves." https://devops.com/sre-vs-devops-false-distinction/ ...


4

DevOps roles will probably be around for some time. Most enterprises and start ups have different needs, server-less is more of an indication of “developers need less focus on the resources and infrastructure for applications” in the sense of applications healing themselves, developers would need to write functions, these functions would often need to change ...


4

I think there are two ways to go about this. You can either go deep in Systems Engineering or the reliability aspects of Software Engineering. I'm a Systems Engineer myself. I think I got the job because I knew quite a bit about Linux internals (read Linux Kernel Development by Robert Love and no you don't need to be a kernel developer) AND Non-Abstract ...


4

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 ...


3

We don't use Agile for the DevOps group ourselves, but we do integrate with the normal Scrum Teams. When something is needed by the team from DevOps, such as optimizing the build server, the related team puts a PBI in their backlog with a 'DevOps' label. Our lead has a custom dashboard in Jira with all issues labeled 'DevOps'. They work with the Scrum Master ...


3

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 ...


2

The types of numbers you're looking for might be hard to come across, because they're highly variable (even within one organization, it varies service-to-service and team-to-team, in my experience.) The SRE Workbook is now available for free, and includes two case studies (chapter 3) that might be helpful. Also, New Relic's SRE eBook does a really good job ...


2

I was wondering whether anyone in this forum had new arguments they have heard or tried in person to convince executives of the need to set service level objectives at a level below 100%, hence the original question. Here are some approaches I've seen or taken in the past to tackling this problem. The Site Reliability Workbook has a few suggestions here, ...


2

In an ideal world, the SLOs would be driven by business needs, and information about your customers. Remember: an SLO should be the level of reliability at which most users are happy with your service. To do this you can partition your service's behaviour into critical actions. A critical action is a discrete piece of functionality offered by your service,...


1

Consider a service using the alerting rule from the book: job:slo_errors_per_request:ratio_rate1h{job="myjob"} > 36 * 0.001 The burn rate is the rate at which we are exhausting our error budget. A burn rate of 1 means that we'll have exactly exhausted our error budget at the end of our reporting period. A burn rate of 2 means that we'll have exhausted ...


1

This is actually quite easy, if you know how much lost means the system being down. That is if you take eBay or Amazon they would have considerable loss even for one second of downtime in a year. So they strive to have a 99.9999... reliability/uptime. So this is not about 100% but how many nines does it make sense to invest for you to come close to 100%.


1

Why do you think 100% reliability is not a good idea? Can you support your beliefs with numbers, facts and logical explanations? Is the needed hardware too expensive? Development time too long? Maybe you can show that the probability of success of a chain of components is the multiplication of the individual parts, some of which are not under your control? ...


1

it sounds as though the concept of "burst limits" may apply here. If high reliability is needed during foreseen special events of a generally similar duration, it probably is also needed during emerging events too. I suggest broad timescale SLOs (e.g. 99.9% successful responses per month) plus sliding SLOs based on demand, or fixed-limit SLOs instead of ...


Only top voted, non community-wiki answers of a minimum length are eligible