下载掌阅APP，畅读海量书库
立即打开
现在，我们将第一次从客户那里直接获得输入！产品软件工程师、机器学习工程师和站点可靠性工程师都在这里一起工作，将我们最新版本的应用程序交付给最终用户。如果我们使用的是基于计算机或移动端的应用程序，这将涉及软件版本发布以及这些发布所需的所有质量测试。然而，在我们的案例中，我们发布了一个新版本的网站，其中将包含由机器学习模型驱动的推荐和结果。
发布机器学习管道与发布任何其他线上系统有共通的部分，但也有很多特定属于机器学习系统的问题。关于一般线上系统的发布建议，请参阅由Betsy Beyer等人编辑的 Site Reliability Engineering：How Google Runs Production Systems 一书（O'Reilly，2016）第32章（ https://oreil.ly/OsNL3 ）。包括基本的检查/观测、发布的控制以及回滚在内的这些措施是必需的，一个没有定义回滚计划的发布是十分危险的。如果你的基础设施实现回滚操作十分困难，或者根本不允许回滚，我们强烈建议你在发布之前先解决此问题。下面将详细介绍一些特定于机器学习的问题。
模型即代码
请记住，模型与训练系统二进制文件、服务路径和数据处理的代码一样，都是代码。部署一个新模型一定会使你的服务系统崩溃并破坏你的在线推荐模型。部署新模型甚至会影响某些系统中的训练（例如，使用迁移学习开始训练另一个模型）。以相同的方式对待代码和模型发布很重要：尽管一些组织在（比如）假期发布新模型，但模型完全有可能出错，而且从某种程度上说，如果发生这种情况，就需要在短时间内进行代码修复。在我们看来，它们具有同等的风险，应该采取相同的应对措施。
缓慢发布
在部署新版本的在线系统时，我们通常能够逐步进行部署，从所有服务器或用户的一小部分开始，只有当过一段时间我们对系统的正确运行和机器学习改进的质量有信心时才会逐步扩大规模。这里要明确的是，我们需要尽力限制损失并在两个维度上获得信心：用户和服务器。如果我们碰巧生产了一个糟糕的系统或模型，我们肯定不想让它影响到所有用户；相反，我们首先将它展示给一小部分终端用户，然后逐渐增长。类似地，对于我们的服务器群，如果碰巧构建了一个无法运行或运行不佳的系统，我们也不想它影响到所有的服务器群的计算空间。
其中最棘手的方面是确保新系统在部署过程中不会干扰旧系统。对机器学习系统来说，最常见的是通过中间存储工件来实现。具体来说， 格式 的变化和 语义 的变化会导致数据解释中的错误。第2章会介绍这些内容。
发布，而不是重构
“每一次改变尽可能少”这种常见的原则适用于许多系统，但在机器学习系统中尤为明显。整个系统的行为很容易发生变化（通过底层数据的变化等），因此在任何其他环境中都很微不足道的重构可能导致无法找到问题所在。
在数据层隔离部署
在进行渐进式上线时，请记住 必须在数据层 以及代码/请求/服务层进行隔离。具体来说，如果新模型或服务系统的日志输出被旧版本代码或模型使用，则对问题的诊断可能会十分漫长且棘手。
这不仅是一个机器学习问题，未能将新代码的数据路径与旧代码隔离开来，在过去几年中导致了一些惊人的运行事故。尽管机器学习系统中的故障往往更微妙且更难检测，但这可能发生在任何处理数据的系统上，这些数据由系统的不同部分产生。
故事时间：本书作者之一曾参与一个支付系统的开发，该系统在新功能部署期间出现错误。虽然这出乎意料，但在运行系统的环境中并非完全没有先例，因此只需回滚更新即可轻松修复。考虑到错误随着部署进度成比例地增加，这一点尤其正确。
团队也是这么想的！但不幸的是，随着回滚完成，错误率飙升至100%，团队陷入了恐慌。经过多次调试，发现更新实际上为达成新功能的预期而更改了一些数据格式，并且与旧系统期望的格式不兼容。就像在部署期间所发生的，当较新的组件写入的日志恰好被较旧的组件读取时，就会发生错误。回滚取消了正确处理已写入的新格式日志的功能。事实上，如果团队让部署完成（或一次性完成），错误就会消失。这里的主要教训是，需要全面考虑可能需要参与回滚的所有系统组件，尤其是数据层
。
在发布期间测量SLO
确保你至少有一个能够显示最新和最敏感指标的仪表盘，并在发布期间跟踪这些指标。当你找出最关心的指标以及最有可能表明某种发布失败的指标时，可以将这些编码到一个服务中，如果未来出现问题，该服务会停止发布。
回顾发布
无论是手动还是自动，确保在任何类型的发布过程中进行监控。较小的组织或较大的（或更不寻常的）发布应该由人监控。如前所述，当你对其有信心时，便可以开始依靠自动化系统来完成此操作，并且可以显著提高发布速度！