Hot answers tagged

16

Great question! Most of us know investing in DevOps practices is a highly worthwhile pursuit for myriad reasons; we don't often justify DevOps on the impact to the bottom line alone, though. Note: this is something of an opinionated question, and my answer is likewise, opinionated. Tensibai wisely suggested we find the right metrics, and he used time-to-...


12

I don't think there are any "universal" DevOps KPIs. For example, velocity is great, unless it's not a key driver for your business. Amazon cares a lot about velocity because they have a massive retail operation. That's less important for a small app with 100 users. This begs the question: how do you select the best KPIs relevant to your business? That'...


12

The key metric for a DevOps pipeline is Cycle Time (also called Lead Time). This is the time it takes for a change (or a change request, tracking all the way to the inception of the idea). The best illustration of this concept I know of is from the book "The Goal", which talks about it in a manufacturing context. Deployment Frequency is useful as well. ...


11

The fire hose is a reference to an old Weird Al Yankovick movie, UHF (1989). In this movie, George Newman (portrayed by Yankovick) starts a local TV channel in the UHF band and is responsible for programming on the channel. After befriending the Station's Janitor, Stanley Spadowski, (portrayed by Michael Richards) George gives the Janitor a slot to run a ...


8

Captain obvious : by reducing time to market and defects on releases. To extend on this one liner, the usual pitfall is being an organization change without any reference. Engaging a culture or organization change implies some expense to train and introduce people to this new method, this have a cost in training but also imply a loss in productivity as ...


6

A technique we've used in the past in similar situations is to get "management commitment" that imposes these rules to every team member: Access to perform updates to the target deployment areas (i.e. production) is limited to selected automated systems, which have appropriate audit trails (= logging) of any kind of updates to the areas they manage. Manual ...


5

What they are talking about is Kaizen 5M (Man, Machine, Material, Method, Measurement). It is approach to continuous improvement at every station in the process and the Ms are possible points of improvement and to which there is a corresponding question (5Qs). Sometimes Environment is added for 6th, like in this process that explains how to construct the ...


5

The 2017 state of devops report says there's about a 31-45% "change failure rate." While that intuitively sounds about right, are they tracked as incidents? Nah. Because they get fixed pretty quickly, usually during validation. An issue that gets fixed quickly is still an issue. If you're not reporting these as such, that's a problem. So, it takes ...


3

The question hasn't had an answer in seven months so I will promote my upvoted comment to an answer: Finding the lifecycle of a specific message across services is known as "distributed tracing". Distributed tracing requires more than just capturing logs. OpenShift uses Kubernetes which is part of cncf.io/projects which governs opentracing.io and has one ...


3

A third party app metrics tools is great if it already covers all (or most of) the parameters you want to monitor and it presents the information in a convenient enough manner for your use case - you just need to (find it first and then) learn how to install/use/maintain it and then do that. Advantages: avoids the software development and maintenance costs,...


2

Yes, MTTR is/should always be tied to the business outcome: if things are not stable the very business is at risk. The fact that the expected code/feature/change is still stuck in process in scenario 1 is irelevant: the feature is not stable, so it doesn't bring new business, rolling back is the best you can do at that time from the business prospective. ...


2

DevOps does not have any KPI. It would be like asking what are the KPI of Love. But some of the things you mentioned (Problem and Incident Management, Capacity Management, Change and Release Management) do have good KPI, some of which are based on the theory behind DevOps. In general, for any business process, you can create a Value Chain Map describing how ...


2

You should do a comparison of commercial virtualization products on the same hardware resources, OR benchmarking commercial virtualization products individually, there are ways to do it, you can even script it. For example, VMmark is a free tool used to measure the performance and scalability of virtualization platforms VMmark Since your question is very ...


2

For Application specific calls you need to use a Prometheus client and create the metrics yourself. The Prometheus client will allow you to create a /metrics endpoint where you can output the current metric values which Prometheus will scrape. For metrics that are not unique to your application, you can use Prometheus exporters that will run on either the ...


1

As far as I'm aware, there is no universal standard amongst cloud providers. One reason for this is because most cloud providers like to abstract how their backend infrastructure, that their instances run on, is managed. How your instance is ran could change minute by minute depending on the cloud provider. The user doesn't care as long as they are getting ...


1

IMHO an absolute benchmark can be rather useless/misleading, I'd always consider the specific context of the application intended to be executed on the platforms being benchmarked and its performance requirements and use only benchmarks relevant to that application context. A few examples: if the application doesn't make a lot of use of the CPU and/or its ...


1

From code repository to any environment, as a running software would be "Time to Deploy" ( which is different from deployment time, btw ). From code repository all the way to production environment, the best aproximation is time to market (TTM), taking aside that time to market does involve the conceptual design of a product. But as you said you are ...


1

The mean time to recover has an implied subject - the mean time to recover what? Defining this is key to using the metric effectively. Are you recovering the general availability of your production website? Are you recovering the functionality of a particular feature that has a bug in it? Once you know what you're actually trying to measure, it's much ...


1

Late to the game here but thought I'd chime in. You can't manage what you don't measure, so for starters, here are the key metrics devops teams should be tracking for incident response: Uptime % : total % of time available = [total time - downtime] / [total time] MTTR : mean time to resolution = [downtime] / [# incidents] MTTA : mean time to acknowledge = [...


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