「不只是为了省钱，或只是减少丢脸时刻，避免影响顾客，更重要的价值是，SRE是确保ML创新速度的关键。」GoogleMLSRE团队负责人ToddUnderwood在去年10月全球SRE年会演讲时，他特别强调，这才是Google早在13年前开始将SRE经验和知识运用到ML系统的关键理由。

Google在年首创了第一个SRE（SiteReliabilityEngineering，服务可靠性工程）团队，通过系统架构设计、运维流程改善等各种方法，来确保系统运行的更可靠。年，Google公开了这套SRE方法论和经验，后来也成了许多企业运维网站和线上服务可靠性的重要参考。

不只是用来确保网站和线上服务的可靠性，13年前，Google已经将SRE成功运用到搜寻服务，储存系统、广告数据储存系统的可靠性运维上，当时开始思考，是不是能将SRE运用到ML系统上，决定先从GoogleAds品质团队开始，运用到仰赖大量机器学习演算法的Google的广告推荐机制上。

因为Google关键字广告采点击计费，点击才会计价，靠ML模型来推荐的广告越符合搜寻需求，就会能成功吸引浏览者来点击。

ToddUnderwood指出，广告系统越稳定可靠，营收就能越稳定，因此决定开始从这套系统开始导入SRE做法，称为「MLSRE」。ToddUnderwood就是13年前发起了AdsMLSRE团队的关键人物之一,ToddUnderwood表示，AI跟ML其实很不一样，AI是从人、应用需求角度来看，但ML则是要让电脑系统可以运用机器学习技术来解决问题，是一种利用数据来训练模型的做法，ML是AI的一个子集。

ToddUnderwood也公开了Google内部所用ML系统架构，跟大多数企业常见的ML训练流程差异不大。这个ML系统架构包括了5个流程，从数据搜集、数据准备、模型训练、品质管控到提供推论服务，Google打造了一套模型管理工具和流程调度系统，用来追踪模型、特征和数据的后台资料。Google也特别重视数据读取、数据检查、特征数据的分布和变动数据品质的控管。

GoogleSRE工程师MaryMcGlohon正是过去4年来负责运维和开发这套超大规模ML系统的工程师之一。

MaryMcGlohon指出，机器学习系统过于复杂和庞大，必须要打造工具来分析，才能探索问题，对MLSRE来说，就不用知道每一件事的业务逻辑，也可以做事。

因此，Google也自行发展了不少MLSRE工具，从更大的尺度来观察系统，找出各种可能出错的状态，并依据过去的错误设计更好的实施方式。

虽然，Google没有公开这些MLSRE工具，但MaryMcGlohon归纳出四个Google用来提高ML可靠性的SRE战略，这正是他们过去十多年确保ML系统可靠性的关键秘诀。

这四个策略，包括了，第一，要让失效问题看得见，才能知道为何出错。其次，也需要尽可能验证各种异动，才能避免异动带来的错误，并且要厘清对数据完整性的要求，最后则是得妥善管理工作流程的等待任务。

MaryMcGlohon指出，若误以为ML是魔术，这是一个迷思，对在乎系统稳定的工程师来说，今天的偷懒，可能会带来明天的技术债，先分析ML系统的特征，才能知道系统出错时会有哪些风险，让我们知道可以如何管理风险。

ML系统的特别之处，第一是大量数据的相依性。因为机器学习演算法非常强大，可以有效辨识信号和杂信，这就导致不需要筛选或过滤数据，也能提升预测能力。

甚至，不需要知道哪些数据来源更有价值直接全部汇入，这会带来一个后果，累积越久，就会有越多数据相依性（datadependencies）问题，这也是GoogleML系统的一大特质。其次，ML系统其实是一套庞大交互作用的流程系统，必须知道如何安排这些流程，才能管理风险。

最后一点，ML是一种超大规模的非典型工作负载，不同的ML批次运算，会有不一样的运算和数据I/O需求，这对数据调度工作带来很大的挑战。

Google也曾从分析了过去15年ML系统上百起宕机事件的检讨报告后归纳，出19种ML系统宕机问题，MaryMcGlohon指出，其中只有30%的问题，是来自ML系统内部的问题，例如标记错误，模型配置设定错误，但高达40%的问题是来自分布式系统的内部问题，例如负载均衡出错，数据结构没有最佳化，工作排程安排错误等。

「从这个结果告诉我们，ML系统的运维可以借鉴其分布式系统的运维和最佳实践做法。」MaryMcGlohon指出，Google的ML系统是一种分布式系统，数据密集，流程化的系统，我们挑选了分布式系统最佳实践，数据完整性最佳实践，和工作流程最佳化实际来缓解风险。

MLSRE关键策略1：

让失效问题看得见

「要知道如何解决故障之前，得先知道何时会故障，看得见故障是一件重要的事。」MaryMcGlohon表示。

Google内部有一套协调调度平台，可以用来设计模型开发流程，可以设定模型配置，并提供仪表板来检查模型效能，可以用来观察模型如何运行。

不过，MaryMcGlohony则是建议，SRE团队最好可以建立一些模型品质预警通知，通知模型开发者以及系统运维人员，一但模型品质开始下滑，可以在更多使用者发现之前，让模型开发者可以展开行动，退回前一版，或赶快开始调查原因。

「仪表板是一种降低事故风险的好方法，发生事故时，要确保开发这个模型的核心人员也能观察到系统的信息，他们可以成为解决问题的帮手。」MaryMcGlohon说。

MLSRE关键策略2：

尽可能验证各种异动

但只靠预警机制还不够，更主动的SRE方法是进一步验证各种系统上线的变动，可以从二进位和数据的变动来追踪。

如何最有效追踪系统的变动，MaryMcGlohon建议，任何系统都会带有业务逻辑的二进制文件，不管是，特征处理，模型训练，或推论服务等，都会用到二进制文件，因此，可以验证这些二进制文件来确保是否顺利运行，另一个可以追踪变动的地方是系统配置文件的变动。例如数据Schema配置，不同阶段的各种配置。

追踪二进制文件和配置文件的变动，最好的做法就是建立一个上线前的Staging（准备）阶段和环境，在这个环境中，复制一份正式系统，进行测试，验证效能，来确保异动的影响符合预期，确定没有问题才正式上线。

在Staging阶段较容易发现可能导致当机的错误，但不容易发现效率问题的影响，例如I/O用量，CPU用量，一条工作流程跟大量工作流程同时执行的影响不一样，后者可能导致很多等待的任务，而影响了系统运行。

Google还会追踪另外一种变动，就是数据变动，可以从原始数据变动，特征数据更新的变动中，模型表征的变动，推论数据的产生等。「检测数据本身的异动，是一种防止事故的做法。」MaryMcGlohon表示。

如何最有效追踪系统的变动，Google建议，任何系统都会有带有业务逻辑的二进制文件，不管是，特征处理，模型训练，或推论服务等，都会用到二进制文件，因此，可以验证这些二进制文件来确保是否顺利运行，另一个可以追踪变动的地方是系统配置文件的变动。例如像是数据Schema配置，不同阶段的各种配置。Google还会追踪另外一种变动，就是数据变动，从原始数据变动，特征数据更新的脧中，模型表征的变动，推论数据的产生等。图片来源／GoogleMLSRE关键策略3：更清楚掌握对资料完整性的要求另外，建立模型后，在正式上线之前，Google会先用测试数据来了解模型的效能，或是在准备好数据后，先筛选出异常数据，避免对模型训练产生影响。MaryMcGlohon表示，对特征数据越熟悉，就越能这样事先过滤，而且不能单靠数据异常检查，还是需要搭配对配置文件和二进制文件异动检查，来确保ML环境准备正常，也才能避免坏数据产生问题。如何分辨哪些数据是异常数据，就得对数据完整性的要求，清楚了解送入ML系统的数据是否符合训练所需，而且能准时送达。“

转载请注明:http://www.aideyishus.com/lkjg/417.html