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

我们新创建了一个内部的Crossbow用户讨论组，组织了一些培训，编写了新的文档，提前发出了废弃图形化界面的通知，并废弃了相关服务的源码。我们同时改写了命令行方式的帮助信息，简化了使用方式。这个小改动工作量不大，却极大地提升了用户体验。
用CloudflareAccess改进收发方式的架构
Crossbow的架构是许多年前设计的了，这是我们遇到的首要困难。 gRPCAPI可以在Cloudflare的边缘网络运行命令，但它要用到一个配置管理工具，而后者是系统可靠性团队想废弃的东西。事实上Crossbow也是它的最后一个使用者了。
为此我们特意去了一趟新加坡，拜访了当地的系统可靠性团队。团队成员们对Crossbow表现出了极大兴趣，希望能理解它是怎样工作的，以及他们可以怎样为这个工具添砖加瓦。我们在会议上介绍了当前的架构。当地同事则非常积极地就如何处理广域网络的稳定性、如何从旧方式中脱离出来等问题给出了许多建议。会谈给了我们许多宝贵的启示，让我们知道了常用的技术方案可能会在怎样的场景下出问题，从而可能会需要技术支持工程师们求助于系统可靠性团队。
【EGONetworks|团队重构大型内部工具的经验教训】我们决定采用一种比较简单的收发管道。边缘网络团队会提供一个gRPC守护程序，它负责接收新任务并执行，然后把执行结果发回给另一个API服务，后者会转发给任务的调用者。
对于API服务与客户端或边缘网络之间的安全认证问题，我们实现了一个JWT认证方案。对于命令行方式的使用者来说，认证是通过访问CloudflareAccess后面的一个HTTP端点来完成的，它会给客户端提供一个向gRPC认证的JWT 。具体的方案类似下面这样：CLI通过cloudflared向认证服务器发出请求；认证服务器返回签名后的JWT令牌；CLI带上JWT认证令牌向API服务发起gRPC请求；API服务用公钥对令牌进行验证；
gRPCAPI端点是放在Cloudflare内网的，因为用户已经用CloudflareAccess认证过了，所以我们不必再要求用户一定要先连公司的VPN ，然后才能使用这个工具。新的认证方式，以及单一的用户接口，让我们可以对工具的指标和使用情况进行收集，从而进一步做出改进。
风险管理
风险是工程专业人员所从事的活动所固有的，这意味着专业人士将会在管理和限制风险等方面发挥重要作用。 ——风险指引，工程委员会
管理风险对于任何工程项目来说都是至关重要的。但对于不同的工程项目，要管理的风险也不一样。可用性对我们来说并不是最重要的方面，因为工具不可用时技术支持工程师们可以求助于SRE团队。 Crossbow最大的风险在于Cloudflare网络的安全性，不能让它影响其它服务的可用性。因此我们有计划有步骤地改进了它的隔离性，很早就请信息安全团队参与进来，帮我们制订规范，并对新的收发管道进行代码审查。对于由此而引入的可用性问题，我们主动与支撑团队和内部的Crossbow用户组进行了沟通，向他们解释了存在的风险和这样做的初衷。
反馈、构建、重构、度量
Cloudflare的支撑运维团队采用极限编程的方式工作。极限编程的一个关键特征就是测试驱动开发，这也被称为“红-绿-绿”模式或“红-绿重构” 。工程师先用测试案例表述需求，然后写代码通过测试案例，再在交付软件之前对代码重构，来提高代码质量。
在刚接手这个项目时， Cloudflare的支撑和SRE团队都在忙Baton项目，它的目标是让技术支持工程师们尽可能多地解决用户问题，避免事事上交给SRE团队处理。
努力初见成效，他们整理出了非常宝贵的素材，正好可以做为Crossbow项目的功能需求列表。我们在JIRA上关联了所有需求，并提高了优先级，用测试驱动开发的方式实现这些需求，还引入了持续集成的方法。而且在功能发布之后，我们会用非常严格的方式对它们进行评估。我们增加了许多简单的功能，比如支持MTR（一个Linux网络诊断工具）、提供对不同CURL标志位的支持等，这些都提高了易用性。