“不只是为了省钱，或只是减少丢脸时刻，避免影响顾客，更重要的价值是，SRE是确保ML创新速度的关键。”Google ML SRE团队负责人Todd Underwood在去年10月全球SRE年会演讲时，他特别强调，这才是Google早在13年前开始将SRE经验和知识运用到ML系统的关键理由。
Google在2003年首创了第一个SRE（Site Reliability Engineering，服务可靠性工程）团队，通过系统架构设计、运维流程改善等各种做法，来确保系统运行的更可靠。2014年，Google公开了这套SRE方法论和经验，后来也成了许多企业运维自家网站和线上服务可靠性的重要参考。
不只是用来确保网站和线上服务的可靠性，13年前，Google已经将SRE成功运用到搜索服务，存储系统、广告资料存储系统的可靠性运维上，当时开始思考，是不是能将SRE运用到ML系统上，决定先从匹兹堡办公室的Google Ads品质团队开始，运用到依赖大量机器学习算法的Google的广告推荐机制上。
因为Google关键字广告采点击计费，点击才会计价，靠ML模型来推荐的广告越符合搜索需求，就会能成功吸引浏览者来点击。
Todd Underwood指出，广告系统越稳定可靠，营收就能越稳定，因此决定开始从这套系统开始导入SRE做法，称为“ML SRE”。Todd Underwood就是13年前发起了Ads ML SRE团队的关键人物之一，
Todd Underwood表示，AI跟ML其实很不一样，AI是从人、应用需求角度来看，但ML则是要让计算机系统可以运用机器学习技术来解决问题，是一种利用资料来训练模型的做法，ML是AI的一个子集。
Todd Underwood也公开了Google内部所用ML系统概略架构，跟大多数企业常见的ML训练流程差异不大。这个ML系统架构包括了5个流程，从资料搜集、资料准备、模型训练、品质管控到提供推论服务，Google打造了一套模型管理工具和流程调度系统，用来关注模型、特征和资料的元数据。Google也特别重视资料读取、资料检查、特征资料的分布和变动等资料品质的管控。
Google SRE工程师Mary McGlohon正是过去4年来负责运维和开发这套超大规模ML系统的工程师之一。
Mary McGlohon指出，机器学习系统过于复杂和庞大，必需要打造工具来分析，才能探索问题，对ML SRE来说，就不用知道每一件事的业务逻辑，也可以做事。
因此，Google也自行发展了不少ML SRE工具，从更大的尺度来观察系统，找出各种可能出错的状态，并依据过去的错误设计更好的实例方式。
虽然，Google没有公开这些ML SRE工具，但Mary McGlohon归纳出四个Google用来提高ML可靠性的SRE战略，这正是他们过去十多年确保ML系统可靠性的关键秘诀。
这四个策略，包括了，第一，要让失效问题看得见，才能知道为何出错。其次，也需要尽可能验证各种异动，才能避免异动带来的错误，并且要厘清对资料完整性的要求，最后则是得妥善管理工作流程的等待任务。
Mary McGlohon指出，若误以为ML是魔术，这是一个偏见，对在乎系统稳定的工程师来说，今天的偷懒，可能会带来明天的技术债，先分析ML系统的特征，才能知道系统出错时会有哪些风险，让我们知道可以如何管理风险。
ML系统的特别之处，第一是大量资料的依赖性。因为机器学习算法非常强大，可以有效识别信号和噪声，这就导致不需要筛选或过滤资料，也能提升预测能力。
甚至，不需要知道哪些数据源更有价值直接全部导入，这会带来一个后果，累计越久，就会有越多资料依赖性（data dependencies）问题，这也是Google ML系统的一大特质。其次，ML系统其实是一套庞大交互作用的流程系统，必须知道如何安排这些流程，才能管理风险。
最后一点，ML是一种超大规模的非典型工作负载，不同的ML批次运算，会有不一样的运算和资料I/O需求，这对资源调度工作带来很大的挑战。
Google也曾从分析了过去15年ML系统上百起宕机事件的检讨报告后归纳，出19种ML系统宕机问题，Mary McGlohon指出，其中只有30%的问题，是来自ML系统内部的问题，像是标记错误，模型配置设置错误，但高达40%的问题是来自分布式系统的内部问题，例如负载均衡出错，数据结构没有优化，工作调度安排错误等。
“从这个结果告诉我们，ML系统的运维可以借鉴其他分布式系统的运维和最佳实务做法。”Mary McGlohon指出，Google的ML系统是一种分布式系统，资料密集，流程化的系统，我们挑选了分布式系统最佳实务，资料完整性最佳实务，和工作流程优化实务来缓解风险。
ML SRE关键策略1：让失效问题看得见
“要知道如何解决故障之前，得先知道何时会故障，看得见故障是一件重要的事。”Mary McGlohon表示。
Google内部有一套协调调度平台，可以用来设计模型开发流程，可以设置模型配置，并提供仪表板来检查模型性能，可以用来观察模型如何运行。
不过，Mary McGlohony则是建议，SRE团队最好可以创建一些模型品质预警通知，通知模型开发者以及系统运维人员，一旦模型品质开始下滑，可以在更多用户发现之前，让模型开发者可以展开行动，退回前一版，或赶快开始调查原因。
“仪表板是一种降低事故风险的好方法，发生事故时，要确保开发这个模型的核心人员也能观察到系统的信息，他们可以成为解决问题的帮手。”Mary McGlohon说。
ML SRE关键策略2：尽可能验证各种异动
但只靠预警机制还不够，更主动的SRE方法是进一步验证各种系统上线的变动，可以从二进制档和资料的变动来关注。
如何最有效关注系统的变动，Mary McGlohon建议，任何系统都会有带有业务逻辑的二进制文件，不管是，特征处理，模型训练，或推论服务等，都会用到二进制档，因此，可以验证这些二进制档来确保是否顺利运行，另一个可以关注变动的地方是系统配置档的变动。例如像是资料Schema配置，不同阶段的各种配置。
关注二进制档和配置档的变动，最好的做法就是创建一个上线前的Staging（准备）阶段和环境，在这个环境中，复制一份正式系统，进行测试，验证性能，来确保异动的影响符合预期，确定没有问题才正式上线。
在Staging阶段较容易发现可能导致宕机的错误，但不容易发现性能问题的影响，例如I/O用量，CPU用量，一条工作流程跟大量工作流程同时执行的影响不一样，后者可能导致很多等待的任务，而影响了系统运行。
Google还会关注另外一种变动，就是资料变动，可以从原始资料变动，特征资料更新的脧中，模型表征的变动，推论资料的产生等。 “侦测资料本身的异动，是一种防止事故的做法。”Mary McGlohon表示。
如何最有效关注系统的变动，Google建议，任何系统都会有带有业务逻辑的二进制文件，不管是，特征处理，模型训练，或推论服务等，都会用到二进制档，因此，可以验证这些二进制档来确保是否顺利运行，另一个可以关注变动的地方是系统配置档的变动。例如像是资料Schema配置，不同阶段的各种配置。Google还会关注另外一种变动，就是资料变动，从原始资料变动，特征资料更新的脧中，模型表征的变动，推论资料的产生等。图片来源／Google
ML SRE关键策略3：更清楚掌握对资料完整性的要求
另外，创建模型后，在正式上线之前，Google会先用测试资料来了解模型的性能，或是在准备好特征资料后，先筛选出异常资料，避免对模型训练产生影响。Mary McGlohon表示，对特征资料越熟悉，就越能这样事先过滤，而且不能单靠资料异常检查，还是需要搭配对配置档和二进制档异动检查，来确保ML环境准备正常，也才能避免坏资料产生问题。
如何分辨哪些资料是异常资料，就得对资料完整性的要求，清楚了解送入ML系统的资料是否符合训练所需，而且能准时送达。
尤其，很多外部问题会影响资料品质，例如标记出错，数据源在不同时来自不同地方，资料处理流程在第三方，甚至可能无法监控资料来发生了什么事。Google SRE会要求，组织内部资料负责窗口，有任何资料需求的调整，也得通知SRE。
另一个做法是简化ML，避免坏资料带来长期的影响，也可以创建系统回复机制。例如遇到资料错误，或不完整的资料，训练出了有问题的模型，若有回复机制，就可以回到一个安全不容易出错的模型快照版本
ML SRE关键策略4：妥善管理工作流程的等待任务
Google ML SRE最后一项关键策略是ML工作流程优化，因为经常有大量工作流程同时进行，重载会是常见问题，一旦流程宕机，或者资料晚到，就得有弹性来应对，因此，Mary McGlohon表示，需要创建流程退回机制，另外要有工作量优先级机制，才知道哪一项任务可以延后，最后要让调度机制更聪明，例如可以针对系统备援来进行资源调度，一旦遇到宕机时就可以采用。
Google ML SRE最后一项关键策略是ML工作流程优化，因为经常有大量工作流程同时进行，重载会是常见问题，一旦流程宕机，或者资料晚到，就倒有弹性来应对，因此，Google建议，需要创建流程退回机制，另外要有工作量优先级机制，才知道哪一项任务可以延后，最后要让调度机制更聪明，例如针对系统备援来进行资源调度，一旦遇到宕机时就可以采用。图片来源／Google
ML SRE和SRE有两大挑战不一样
Todd Underwood指出，ML SRE特别跟其他SRE做法，有两件事不一样。第一是，新模型和新团队需要很大的弹性，可能有各种技术考量，业务需求，或资料限制，必须调整模型。
因为需要可以定制化的模型架构，容易增加新功能，超快速部署，负责团队能快速修改问题直接执行模型来更新，也就是说，Todd Underwood表示，ML系统，希望能够尽快正式上线，这意味着，机器学习训练要高可用，容量分派自动化，调度自动化，SRE自动支持等。但是，要具备高度弹性，也代表了不容易标准化，这是第一个挑战。
第二个不一样之处是，ML SRE的另一个挑战是“模型品质”，Todd Underwood指出，尤其要思考该如何对模型品质负责。Google常见做法是由模型开发者来确保模型品质，但在ML模型上线之后，很多问题是来自系统性问题，而非模型的问题，只靠模型开发者解决不了问题。
“如何对模型品质负责，这是一个还没有答案的ML SRE大问题，这真的是一个非常难解的问题。”Todd Underwood强调。
为了解决这个模型品质问题，Google正在思考的做法是，创建升级检查清单，也就是可以检查一个ML模型是否能从实验状态，进入到正式上线状态的检查清单。这个挑战也就是要定义一个模型的服务水准目标（SLO），关键是“如何判断，一个模型可以正常运行。”Todd Underwood说。
目前，Google有几项定义“模型正常运行”的角度，例如资料是否不完整，过大，过小，或者会出现不同版本。训练速度太慢，或容易卡住。或是训练过程太消耗资源、模型品质突然改变（准确度下滑）、服务无法加载模型、模型加载服务后变慢等。
Todd Underwood说：“这些就是我们会设立指标的地方，来测量数据和性能，来判断什么样的模型品质够好，可以升级到正式环境。还会搭配其他指标如Model元数据是否完整，和其他模型的依赖性检查等。
下一步，Google ML SRE想要做到5件事，Todd Underwood分享，一方面说服组织使用稍旧的ML技术但搭配可以自动化建模的做法，够用就好的ML，不是用最新技术。
其次，要打造一个兼顾各种功能和稳定性的端到端平台，但要把这些功能尽量背景化，希望做到，一个按钮就可以完成。
Todd Underwood也希望大幅降低训练成本，并且把各种ML服务变成API，可以稳定且方便集成到各种应用中，让ML无所不在，最后则是要创建ML品质评量机制，适用各处而且值得信任。