
可观测性与软件供应链
|
139
接收
Web hook
测试结果的
API/ 前端
触发器生成 /
测试工作流
执行异步
作业
执行器 执行器
执行静态断言 /
容器构建
执行测试脚本,
上传结果
CI 操 作 API,
Slack Web 应
用程序和作业
队列应用程序
环境
图 14-1:一个端到端测试 Web 应用的工作流示例
14.1 为什么 Slack 需要可观测性
纵观
Slack
整个历史,其在客户数量和代码规模上都有了非常大的增长。虽然这些变化
令人兴奋,但这样的增长也伴随着一些问题,例如,复杂性增加、边界模糊和系统扩展
性不足。测试用例的执行次数数量级曾经达到每天几千次,现在增加到了几十万次。这些
测试所使用的资源在不同的代码仓库和团队中都是不断变化的,并且有着技术多样化的趋
势。在这种规模下,有必要通过自动扩容和超卖等策略来控制成本和计算资源的使用。
有关
Slack
的
CI
系统和成本控制策略的更多详细信息,请参阅
Slack
Engineering
的博客文章“
Infrastructure Observability for Changing the Spend
Curve
”(
https://slack.engineering/infrastructure-observability-for-changing-
the-spend-curve
)。
所以,我们在开发环境中测试和部署代码的工作流比某些生产服务还要复杂。基础设施
或者代码运行时版本的潜在依赖关系可能会被意外更改并引入意外的故障。例如,
Slack
依赖
Git
进行版本控制 ...