项目试运行期间，运维由测试团队担任，主要是系统更新部署，应用配置等工作，在开发的指导下，测试也能应付。上线一段时间后，工作深入到了数据库维护，服务器优化等，问题开始出现了，毕竟测试和运维的工作性质有很大的不同。测试人员如何来做好运维工作？成了我最近一直在思考的问题。

开始我认为是思维的问题，测试工作带有一定的破坏性，要求测试人员不拘泥于固定的套路。周鸿祎曾说过，当他坐在电脑前开始测试时，立马变成了一个电脑白痴。所以测试人员在某些时候要忘掉技术，变身小白用户，力求把系统搞崩溃。

运维工作则刚好相反，要求稳扎稳打，每一步操作都要考虑可能带来的后果，同时要给自己留下后路。高中的数学老师要求我们做题时应该“如临深渊、如履薄冰”，这8个字用来形容运维工作非常恰当。

所以测试人员如果按照固有的思维来做运维，会带来很大的风险。但思维模式仅仅是影响因素之一，如果从整体来考虑，因素还会更多，如技术栈，学习能力等等。这里借用系统思考的工具，通过一张图来说明。

这张图是流量-存量图和因果分析图的结合，因果分析图在上一篇《系统思考入门》中已有介绍。这里先简单介绍下流量，存量的概念。

存量：随时间积累的变量，它的值能够在任意一个时间点上被测量，在图中用方框表示。运维系统里，存量可以认为是思维、技能、工具的集合。思维，技能是无形的东西，虽然很难被测量，也可认为是存量。

流量：增加或减少存量的值，其本身的值只能在一段时间内统计得出。在图中用带阀门的箭头表示。能够增加运维存量的流量有学习成果和有经验成员加入；减少运维存量的流量有员工离职、新人加入以及知识的老化。

大多数的经营目标可以表示为对存量集合的优化，而管理者所能采取的措施，便是实现对流量的调整。

图中和学习成果流量相关的2个反馈环都是增强型回路，但并不会导致存量指数级的增长，运维效率、琐事占比这两个因素都有自己的瓶颈，到一定程度就会趋于平衡；自我提升意愿也是很主观的，受很多因素的影响，这里并没有全部列出，所以学习成果这个流量并不会持续增长，甚至可能会衰退。

其他的几个流量，虽然影响运维系统的存量，但其本身却更多的受到其他系统的影响，需要放到更大的系统中去讨论。

如果系统的存量得不到保障，就要去识别产生问题的系统结构，找到一个“杠杆点”。所谓的“杠杆点”，就是在系统的某处施加一个小的变化，就能导致系统行为发生显著的变化。运维系统的杠杆点在哪里？这张图可能不能给你答案，因为它只是个人对系统的理解，远非系统本身的原貌，甚至可能是错误的解读。真正的答案，还需要大家自己去探索。

最后，引用“系统之美”作者的话，和各位共勉：你必须努力思索，审慎地分析系统，并抛弃自己的范式，进入谦卑的“空”的境界。最后，看似无为，却可能是最为根本性的、战略性的、有效的杠杆点；看似疯狂，放下一切，却能优雅地与系统共舞。