消防员的工作量

作为老板，你肯定希望员工的工作能饱和，不会闲着。

如果你要招聘的是消防员，你希望他的工作饱和吗？

如果按资源利用率的角度，假如有一天你发现这个消防员闲着没事干，你很有可能把他裁掉，等到一天每一个消防员都非常忙的时候，再招几个来应付一下。

天天出去救火的消防员，从资源运用的角度是充分利用了这份人力资源，但这并不是社会的目标。有些角色是要维持一定缓冲量的，你闲放着，是不希望需要用上，但万一有一天需要用上的时候，会是一个决定性的角色。

消防局的职责一般不仅仅是救火，还需要尝试控制【万一出现火灾】的机会率：通过条例，巡查，教育，推广等等手段来降低【万一出现】的机会。

运维团队，也是一个道理。

运维团队的大小，取决于：

• 系统变更的频率，系统变化越少，运维团队越小
• 系统出现问题的机会率，机会越低，团队可以越小
• 一旦出现问题，排查和修复手段的复杂度，修复手段越复杂，团队分工越精细，团队越大
• 标准化、自动化程度，越标准和越自动化，团队越小

所以要轻量化建设运维团队，首先要注意：

• 如何降低系统变更的频率
• 如何降低系统出现问题的机会率
• 如何降低修复问题的手段的复杂程度
• 如何把工作标准化和自动化

首三点主要是开发团队设计时候需要考虑的：比如，系统设计是否足够灵活，有没有冗余，有没有日志，日志提示请不清晰，系统依赖关系合不合理，重启系统需不需要一定顺序，有没有什么熔断或限流机制，有没有埋下足够排查问题的点等等。

标准化和自动化要靠运维人员的自身管理能力和编程能力（或使用自动化工具的能力），把相对重复的劳动化为程序，提升自己的工作效率

至于测试团队，除了功能测试以外，需要通过压力测试等手段去探索整体系统最脆弱的点，并给开发团队足够的信息去排查改善，或者运维团队一条红线，让运维人员设置相对的警报。

开发、测试和运维（dev-test-ops），对于整体系统稳定性有着不可分割的责任。

希望有一天大家都觉得，消防员闲着是一件好事情。（不包括有火不去救的这种闲着）