Quotes from Gene Kim

To have humans executing tests that should be automated is a waste of human potential.

telemetry is what enables us to assemble our best understanding of reality and detect when our understanding of reality is incorrect.

Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity.

However, for decades we have ended up with silos of information, where Development only creates logging events that are interesting to developers, and Operations only monitors whether the environments are up or down. As

We're putting in checklists everywhere, especially when we do handoffs within the team. It's really making a difference. Error rates are way down.

One of the problems of prevention is that you rarely know about the disasters you averted.

Step 2 is to exploit the constraint," he continues. "In other words, make sure that the constraint is not allowed to waste any time. Ever. It should never be waiting on any other resource for anything, and it should always be working on the highest priority commitment the IT Operations organization has made to the rest of the enterprise. Always.

Once we have centralized our logs, we can transform them into metrics by

In addition to collecting telemetry from our production services and environments, we must also collect telemetry from our deployment pipeline when important events occur, such as when our automated tests pass or fail and when we perform deployments to any environment. We

She looks around at the entire floor. Over a hundred developers are typing away, working on their little piece of the system on their laptops. Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else's.

We should also collect telemetry on how long it takes us to execute our builds and tests. By

The principles of Flow, which accelerate the delivery of work from Development to Operations to our customers The principles of Feedback, which enable us to create ever safer systems of work The principles of Continual Learning and Experimentation foster a high-trust culture and a scientific approach to organizational improvement risk-taking as part of our daily work

Solving any complex business problem requires teamwork, and teamwork requires trust.

Why Do DevOps? The competitive advantage this capability creates is enormous, enabling faster feature time to market, increased customer satisfaction, market share, employee productivity, and happiness, as well as allowing organizations to win in the marketplace. Why?

Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored.

Trust Wes to say what people are thinking but are too smart to actually say aloud.

we must ensure that the applications we build and operate are creating sufficient telemetry.

creating application and infrastructure telemetry to be one of the highest return investments we've made. In

In DevOps, we typically define our technology value stream as the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer.

We're going way too slowly, with too much wip and too many features in flight. We need to make our releases smaller and shorter and deliver cash back faster, so we can beat the internal hurdle rate.

When deciding whether a message should be ERROR or WARN, imagine being woken up at 4 a.m. Low printer toner is not an ERROR.

There were still so many uncertainties. But unlike before, our challenges feel within our ability to understand and conquer. Our goals finally seem achievable. I no longer feel like I am always on my heels, with more and more people piling on, trying to push me over.

our competition is not the FAANGs—it's the other horses in our industry and tiny little software startups that are encroaching on our market.

Dr. Eliyahu M. Goldratt, who created the Theory of Constraints, showed us how any improvements made anywhere besides the bottleneck are an illusion. Astonishing, but true! Any improvement made after the bottleneck is useless, because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck merely results in more inventory piling up at the bottleneck.