EGONetworks|团队重构大型内部工具的经验教训作者丨JunadeAli

译者丨足下
策划丨蔡芳芳
本文介绍了Cloudflare研发团队对内部工具Crossbow成功进行优化重构的过程，并分享了一些有益的经验。
Cloudflare公司的服务网络现在已经扩展到了90多个国家的200多个城市中。产品、技术支持和运维等项目组的工程师们经常需要诊断某地或某几台服务器的网络问题。
Crossbow就是用来解决这个问题的内部工具。有了它， Cloudflare的技术支持工程师们就可以运行各种命令（比如traceroute、CURL和DNS请求等）来分析问题，并用各种定制工具来定位产品的功能和性能问题。
Cloudflare的一位技术经理在去年9月提出，希望把Crossbow从产品工程团队转交给支撑运维团队。这个工具的受关注度很高，在此之前已经在多个工程团队之间转交过了，但并有开发出什么重要的新特性来。
Cloudflare的支撑运维团队一直与技术支持工程师们紧密合作，为提高效率，他们不断地开发各种诊断工具和自然语言处理技术等。因为有这样的基础，所以最终大家一致认为，接过维护Crossbow的重任，支撑运维团队是最适合的团队。
从Sisyphus身上学到的
在项目移交并征求改进意见的时候，一位系统可靠性工程团队的经理建议大家读一本书：《社区驱动软件的案例研究》。对于每一位在考虑开发内部工具，或者为类似工具做贡献的人来说，这本书都非常值得一读。书中解释了为完成相同的目的，为什么不同的自治团队会开发出多个不同的工具，以及这样的问题该如何避免。书中还讲到了要使用这样的工具所要面临的挑战和可采用的方法，尤其是使用这样工具的工程师们可能要改变习惯时。
我们从书中学到了许多很好的方法来帮助我们接管Crossbow ，并对这个大型内部工具开始进行重构和翻新。这篇博文可以做为类似指导书的补充篇，并提供了一些更切合实际的建议。
关于Cloudflare支撑运维团队的工作，在SRECon大会上的演讲“支撑运维工程：把开发者的成果部署到成千上万的服务器上”已经谈了很多，因此在这篇博文中就不过多涉及了。 Cloudflare支撑运维团队所采用的软件开发方法与极限编程的方式非常接近。
瘦身
Crossbow有两种使用方式：命令行和仅供内部使用的图形化界面，后者主要是Cloudflare的技术支持工程师们在使用。很明显，同时维护两种操作接口会给我们的改进工作带来巨大负担，所以我们决定废弃一个。这样我们就可以将所有力量集中于一个平台，从技术、可用性、功能等各方面做出重大改进。
我们向工程、运维、解决方案和技术支持等团队发起了一次调查，请大家反馈是怎样使用这个工具的。调查让我们可以了解到各个不同团队使用这个工具的方法，这样的信息至关重要。同时在我们废弃某个接口之前，大家都会知道我们已经充分考虑了他们的想法。我们不仅调查大家喜欢哪种方式，还会问他们觉得哪种方式对于他们来说是非常必要的，同时要提供理由。
喜欢通过网页使用工具的人给出的理由是工具维护团队没能提供足够的文档和培训。而喜欢命令行方式的人则觉得命令行方式对于他们的工作来说至关重要。产品工程团队的工程师们在工作中不会经常用到Crossbow ，但有些人觉得Crossbow对他们的工作来说非常重要，他们希望可以来把一串串的命令写到shell脚本里，从而让自己的工作自动化起来。
从技术上来说，图形化用户界面是用Java写的，还需要有个API网关服务，它要把HTTP请求转换成带配置参数的gRPC请求，再完成进一步的调用。命令行方式则直接与gRPCAPI打交道，因此这个系统更简单。 Cloudflare支撑运维团队的主要工作内容是系统工程项目，使用图形用户界面并不方便，因此废弃它也主要是考虑了要让我们的工作更方便。