51CTO编辑注：阅读本文之前，您可能对这篇文章也感兴趣：开发者与系统管理员的争执:不要碰我的生产环境!
Mitchell Hashimoto，Vagrant的共同创立者，Kiip公司的系统管理员，在Gothenburg的DevOps Days上的讲演中提出了一个基于经验的、将组织由传统的黑盒运维文化转型为（理想的）白盒文化的路线图，在白盒运维文化的环境中，开发人员可以自由的改变生产环境。
Mitchell的路线图目标在于保持应用程序（和环境）稳定，同时支持加快的反馈周期，和更加快速的部署周期。这份路线图由下述5个步骤组成：
- 度量和监控
- 高层次的文档
- 在开发环境中镜像生产环境
- DevOps办公时间
- 自动化的基础设施测试
获取操作环境的测量数据让开发人员更好的理解操作的性能和稳定性。虽然有很多可用的监控工具，但通常开发人员并不熟悉它们。通过获取数据和提供可视化的反馈，例如描述服务器负载或响应时间的图表，会逐渐影响开发人员开始关注运行中的系统的状况。
基础设施的文档，包括高层次的运行时架构图或其它有意义的制品（例如部署流程，失败解决方案，工具使用指南等等），可让团队深入了解生产环境内部情况，及变更对整个系统的质量，如可扩展性和性能，的影响。经常性的、有关技术的简短交谈也有助于提高已交付的、运行中的应用程序的可见性，同时也提供更多对特定技术或工具的深入解释。
在开发环境中镜像生产环境，可以让开发人员熟悉生产环境中的脚本，并开始尝试一些试验，而无需担心失败。通过重用脚本和工具来管理开发环境，和管理生产环境一样，可以节约很多工作量。更进一步来说，在实际应用于生产环境之前，部署过程经过了千百次的演练和测试。
进一步促使DevOps文化转变，包括开发和运维每周有共同的工作时间，借此解释和澄清双方需了解的各种主题，甚至开展一些代码审查，从而培养一种合作的学习氛围。***的技术变革包括自动化基础设施测试（无论是单元测试、集成测试或系统级测试），给开发人员提供了一张“安全网”，以便放心的对运维进行变更。在这一点上，开发人员对运维的变更可由运维人员轻松的控制和验证。
Mitchell强调，事实上，所有这些变化需要按照顺序慢慢实现，以便能够被消化。特别是交替推动技术变革与文化变革为接受这些改变提供了空间。
查看英文原文：Moving Ops from black to white box
译者 姚九强 是一名业务分析师，机器人爱好者，目前在ThoughtWorks。关注敏捷方法、运维和业务模型。
原文：http://www.infoq.com/cn/news/2011/10/ops-from-black-to-white-box
【编辑推荐】
