阿迪达斯解决方案架构团队负责人 Thomas Gieling 和 SOASTA 的性能咨询师 Kristian Skoeld 在上一次阿迪斯特丹速率大会上联合呈现了大型鞋服类制造商的IT 如何驯服他们国际网站上第三方工具失控的扩散，避免影响性能。此外，这还导致业务和IT 之间互相指责的文化环境。专注于性能数据和用户体验验证的新的第三方管理过程是止血的关键。
最初缺乏治理（以及IT 团队能力的缺乏，近期网站数已经增长了20 倍，但团队能力却未跟上）意味着业务需求在分析、跟踪甚至（某些）功能已经由已被添加的其他第三方工具重复实现了，而未顾及他们的技术品质如何。于是，性能开始下降，而技术人员（把太多工具归咎于业务）和业务人员（把性能太差归咎于IT）之间也存在着分歧。
Skoeld 帮助想出了一个改善这一情况的策略，它需要总结正在使用的工具（超过 60% 的网站），针对每一个工具设立业务负责人，并定义它的目标、影响（它增加了网站的 akce，还是增强了用户体验，或者是一个数据分析工具？）和危险程度。无业务需求的第三方首先清除。
凭借业务与 IT 协作完成的每个工具的价值与性能比分析，减少第三方依赖的数据驱动流程实施到位了。性能影响不大的低危险程度工具可以暂留，而具有高性能影响成本的高危险程度工具就得去除了，或者必须要找一个替代者。
这个新的管理流程还考虑在用户体验方面的实际影响。A/B（版本 A 有第三方，版本 B 中没有）可以对比在用户转换甚至财务影响方面的净效应。减少技术债（主要是绩效术语中）是共同的目标，排出业务价值的优先级是弥合组织中这一分歧的关键。
举个例子，一款用于从网站用户那里收集反馈的第三方工具。这款工具带来了 20 个以上的请求，并把页面大小增加了 300kb。虽然一瞥之下觉得不太合理，但 A/B 测试的数据显示用户体验（也就是会话长度）并未受到影响，而且销售数据也是一样的（有没有这款工具的时候）。
Skoeld 还建议首先控制直接的第三方依赖。找出所有的间接依赖（比如使用 Request Map ）可能非常难以实现（Skoeld 发现用户两周内仅在 adidas.de 上就到过 2800 个第三方域）。分析直接依赖和它们的外部请求非常重要。随着时间的推移，组织应该目标与高危险性第三方工具供应商建立直接关系，以便设立性能预期以及确立建设性的反馈期待。总之，业务危险性第三方工具需要积极治理而不是被动消费。
查看英文原文： How 3rd Party Tools Nearly Killed Performance (and Culture) at Adidas
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论