chapter twelve

12 Lean operations and production

 

This chapter covers

  • Why the operations mindset differs from development and how to shift
  • Going to gemba in production: observing the actual running system
  • Building andon systems that signal causes and pull the cord
  • Adopting SLEs as internal standards that make hesitation visible
  • Defining operational standard work as executable code, not prose
  • Identifying mura, muri, and muda in live production traffic
  • Applying production kaizen to connect every tool into one cycle

Your deployment finishes at 2:47 p.m. on a Thursday. CI is green. Dashboards show normal CPU, memory, and error rates. Three hours later, support tickets start arriving: search results take nine seconds to load. By the time the on-call engineer checks, p99 latency has climbed from 120 ms to 9.4 seconds, but the dashboard is still green. The alert threshold watches error rate, not latency. CPU is normal because the new code path replaced an in-memory cache lookup with a database query that blocks on I/O. No errors fire because the queries succeed; they just succeed slowly. You shipped working code into a production system you never actually looked at. That gap between "deployed successfully" and "running well" is where Lean operations live.

12.1 Shifting from development to operations mindset

12.1.1 Development velocity versus operational stability

12.2 Gemba in production

12.2.1 The silent degradation pattern

12.3 Andon for production systems

12.3.1 The cost of not stopping

12.3.2 Pulling the cord

12.3.3 Three levels of andon

12.4 Standard work for operations and incident response

12.5 Mura, Muri, Muda

12.5.1 Mura: The unevenness that causes outages

12.5.2 Muri: The overburden that breaks things

12.5.3 Muda: Capturing operational waste

12.6 Production Kaizen

12.6.1 Post-incident reviews as kaizen triggers

12.7 Exercise: Audit your production system through the Lean operations lens

12.8 Summary