多年前，Google开始在ML运维中导入SRE的做法，确保系统的服务可靠性，在2年前一场OpML ’20技术大会上，Google ML SRE运维负责人Todd Underwood与另一位团队资深成员Daniel Papasian实际以Google搜索服务运维为例，公开分享他们从搜索服务ML宕机经验中，发展出一套应对对策，除了希望改善大型ML系统宕机的问题，还要帮助Google创建更有韧性的ML运维策略，甚至还发现到，许多ML宕机事故并非真的ML服务出错，而是系统管理的问题。他们更依据超过10年Google ML运维归纳出19种ML出错场景的分类，来提供企业借鉴参考。
从老旧ML系统宕机经验中找解决方案，成了Google ML运维团队研究新课题
搜索引擎可说是Google最重要核心服务之一，如今近半数全球人口都在用，平均每秒就要处理高达7万次用户搜索查询的请求，从回答各种生活大小事，到天气、交通信息都难不倒它。
早在多年以前，Google就已经在搜索引擎中加入各种ML算法，提供更精准的搜索结果，像是分析搜索字词、搜索比对、网页实用性排名的算法等，只要依据用户查询字词、网页的关联性和实用性、信息来源的专业度分析等综合不同考量，就能从搜索索引中的上万亿个网页排序里，决定查询的搜索结果，来贴近用户搜索查询。
Google搜索引擎算法核心有个大型排名及推荐系统，这套系统经过多年发展，其中有套用了超过15年的老旧ML系统，也是Google使用最久且规模最大一套重要ML系统，但多年下来，这套系统屡屡发生宕机的事故，无法用ML模型进行推论，来优化排名及推荐内容，导致服务品质不稳定。这也成了Google所要面对的ML运维大考验。直到两年多前，Google ML运维团队终于找出了对策。
Google最老旧一套大型ML系统，建有上千个模型优化排名及推荐服务
以系统规模来看，这套大型ML系统中，每天同时要执行上千个ML模型，来优化排名及推荐服务，而且不只ML模型数量众多，模型训练更是个大问题，只要新资料进来，就必须不断更新生产环境中的ML模型，光是上千个模型同时训练，需访问和运算用的模型参数累计就高达1,000亿个，才能用于全部模型训练，加上这套系统历经多次翻新，系统越来越复杂，就在这样一个庞大且复杂大型系统架构下，有时只要ML工作流程或环节稍有差错，就可能造成ML系统宕机。
为了探究长期以来造成ML系统宕机的原因，Google ML运维团队两年前尝试进行研究，希望能找出适当的解法，避免相似问题再发生。他们分析以往所有ML系统宕机事件，要从这些历史事件中找到问题的根本原因，作为改善ML系统可靠性的参考依据，正好这套ML系统过去10年宕机过程的详细记录都有完整保留在数据库中，提供包含元数据（metadata）在内的完整事后的调查分析，可供团队研究使用。
这段期间，Google ML运维团队一共分析近百起ML宕机事故，从这些实际发生的事件中，自行分析归纳出19种ML出错场景要注意。其中，最常见的一种就包办了15起宕机事故。
具体来说，这19种ML出错场景的分类，有流程调度问题、后端系统重载、预期性资料导入临时出错、CPU硬件出错、缓存失效问题、模型推论参考的抽样分配出现改变、组态配置改变导致的混乱、数据结构没有优化、跨集群分派工作的挑战、训练策略执行没有按照预期顺序、过于频繁调整ML模型超参数、组态变动而没有妥善试验或验证、用户端对模型的推论做出错误推测、模型推论时间过长、在程序代码中使用不正确assert宏、误用标注错误的数据来训练模型、embedding矢量空间维度不匹配、测试任务与正式环境的沟通不正确，以及无法调度必要的带宽、内存、CPU资源。
基本上，从系统宕机归纳出的原因中，可以看见有些出错原因较单纯，像是缓存失效问题，还有一些是不易发现的错误，如跨集群分派工作的问题。另外有些错误则是与ML相关，例如embedding矢量空间维度不匹配就是属于这一类，甚至在复杂大型分布式系统环境下，也有可能因为使用的CPU芯片出错，导致ML系统宕机的情况出现。
当完成近百起ML宕机事故调查，归类成19种ML出错场景后，还进一步以分组方式加以划分，并分成两个组别来进行比较，一组是纯ML与非纯ML工作流程两者的比较，另一组则是单一系统或分布式系统间的比较。例如系统调度出错造成宕机，就是属于分布式系统管理的问题。
运维团队经过比较后发现，许多ML系统宕机事故和其出错原因，并非归因于ML本身的问题，大多是系统管理所造的错误，才有后面宕机的结果。从系统架构角度来看，他们则发现，若是ML系统有采取分布式架构设计，发生宕机事故比例会比单一系统时更高，甚至多达6成出错都跟分布式ML系统处理有关，这也可以用来说明，ML宕机和其系统采用单一或分布式架构，彼此之间有一定的关联性。
要运维一套大型ML系统，不能只懂ML，分布式系统管理更重要
从这些研究结果，Google ML运维团队也找到一些方法，来改善ML系统可靠性，像是要求对ML工作流程进行全面监控及关注，包含监测资料吞吐量、ML系统执行率，以及结合各种诊断测试等。对于不同源头的训练数据、ML模型及文件，也要创建系统化版本管控机制，以便发生宕机事故时，团队马上能修正。重新训练的ML模型部署前，也要确保能正常执行没问题才能放行，避免影响到整体系统性能与利用率。
正因为许多宕机事件都与分布式ML系统密切关联，也让Google ML运维团队更加意识到，一套大型系统中，从构建到运维管理，除了必须有专门团队来负责，对于运维团队组成，不能只有ML工程师，还必需要有分布式系统的工程师加入，甚至人数比例要比ML工程师都还高，来负责大型系统测试和诊断，通过这样的系统管理方式，才能提升系统的可靠性，甚至帮助Google创建起更有韧性的ML运维行法。
尽管，Google ML运维经验不一定适用每一家企业，但从这家公司多年ML运维和思考策略，也能提供企业借鉴来参考。Todd Underwood就建议，企业可以根据历史ML宕机事件，按影响程度、对公司冲击、事故持续时间和原因来进行分类，创建自己一套ML运维行法，除了经由分析找出根本原因，每年可以定期重新审视，持续改进内部ML工作流程。
Google ML运维经验：19种ML出错场景
1. 流程调度问题
2. 后端系统重载
3. 预期性资料导入临时出错
4. CPU硬件出错
5. 缓存失效问题
6. 模型推论参考的抽样分配出现改变
7. 组态配置改变导致的混乱
8. 数据结构没有优化
9. 跨集群分派工作的挑战
10. 训练策略执行没有按照预期顺序
11. 过于频繁调整ML模型超参数
12. 组态变动而没有妥善试验或验证
13. 用户端对模型的推论做出错误推测
14. 模型推论时间过长
15. 在程序代码中使用不正确assert宏
16. 误用标注错误的数据来训练模型
17. 矢量空间维度不匹配
18. 测试任务与正式环境的沟通不正确
19. 无法调度必要的带宽、内存、CPU资源
数据源：Google，iThome整理，2022年3月