在Uber，客户平台工程(CPE)团队负责构建我们的IT基础设施，并改进我们对管理工作场所生产率端点的思考方式。我们在全球拥有超过20,000名员工、数百个办公室和不断增长的设备类型，我们需要建立灵活的管道，使我们能够轻松地注入新的管理工作流程，而不会减慢我们的速度或导致技术债务。
在过去的几年里，优步的CPE团队部署了厨师这是一个单一的系统，可以扩展到多个操作系统，同时还需要对所有部署的更改进行代码审查，作为主要的端点管理平台。与传统的基于gui的管理平台不同，Chef允许团队根据Uber的独特需求创建确定的工作流。
虽然Chef仍然是优步的主要管理工具，但苹果实施了新的安全功能，例如设备注册，安全内核扩展,隐私偏好策略控制，限制了移动设备管理(MDM)后面的一些管理部分。
在本文中，我们将讨论CPE团队如何通过用户注册和版本控制的标准化，以及利用api驱动的Chef烹饪书为整个公司的用户编排和配置服务，在macOS上扩展MDM。
Uber的移动设备管理(MDM)
虽然我们使用Chef作为我们的主要管理工具，在过去的几年中- - - - - -特别是在macOS方面- - - - - -我们需要采用MDM系统来补充我们的工作流程。
在研究了许多开源和第三方MDM解决方案后，我们决定扩展与第三方供应商的合作关系，并将macOS端点添加到其数字工作空间平台中。
我们做出这一决定的原因如下:
- 数量上的优势:我们可以在实施和设计阶段利用我们的移动工程师，因为这种数字工作空间解决方案已经用于iOS和Android操作系统的设备。
- 强大的api:我们可以利用InstallApplication和InstallEnterpriseApplication api来安装我们的自定义工具．将我们的自定义工具移到MDM之后意味着员工必须注册到MDM以获得对其他工具的访问权。
- 用户级配置文件:因为这个数字工作空间解决方案与注册用户紧密耦合，所以我们可以实现基于设备的MDM概要和基于用户的MDM概要。开源工具，如Chef，munki， Puppet目前只支持基于设备的本地配置文件。用户级概要文件允许我们改进证书安装管道，以访问内部工具。
- 安全特性:有用的安全功能让我们可以立即锁定使用苹果推送通知服务(Apple Push Notification Service, APNS)的机器。
尽管如今MDM比以往任何时候都更加成熟，Chef仍然是我们的主要管理工具，用于确保我们的机器处于已知状态，并对车队所做的所有更改拥有清晰的审计跟踪。
标准化macOS MDM注册
虽然苹果提供了设备注册计划(DEP)来将设备注册到MDM中，但大公司可能会发现自己处于一个独特的位置，分叉的注册过程是唯一可能的结果。
采购dep设备的一些问题包括:
- 世界范围内的可用性:您的公司可能有办公室或员工没有DEP。在一些国家，你唯一的可能就是购买标有“消费级”的苹果产品。消费者设备目前不能移动到DEP工作流中。
- 临时DEP:临时DEP是将消费者设备转换为企业设备的过程。不幸的是，这只提供给iOS设备(即，ipad, iphone和ipod)。
- 苹果授权经销商:虽然许多国家都授权了苹果经销商，但他们的条款可能与您的公司不一致，或者他们可能不是您推荐的合作伙伴。如果一个国家只有一家授权的苹果经销商，你就不得不购买消费类设备。
除了这些摩擦之外，Uber的全球规模还导致了MDM用户体验方面的其他问题。在我们的尺度上，我们知道得到每一个macOS用户在我们的内部系统中阅读电子邮件或消息几乎是不可能的。更糟糕的是，由于我们的全球采购流程(DEP并非全球可用)，一些用户需要遵循DEP MDM工作流，而另一些用户需要遵循标准的MDM注册过程。此外，在我们MDM系统的内部测试过程中，一些使用谷歌Music等Chrome扩展的用户会被标记为拥有一个标记为“远程配置”的工具，从而触发一个新的苹果系统User-Approved MDM．这意味着即使用户遵循了说明，他们也需要额外的说明来实现完全遵守。
经过多次讨论，CPE团队得出结论，我们需要编写一个围绕MDM注册的自定义包装器。经过一些漫长而乏味的编码会议后，我们决定利用UMAD，或通用MDM审批对话框，通过Chef部署。
UMAD包装器提供以下特性:
- macOS 10.9.5及更高版本支持动态DEP注册。
- 如果DEP在支持DEP的设备上触发失败，将回退MDM注册。
- 非DEP设备的MDM注册。
- 用户批准的MDM检测和失败消息传递。
- 一个截止日期，随着截止日期的临近，UI提示会越来越咄咄逼人。
对UMAD进行测试后，我们逐渐将其部署到我们的设备上cpe_umad食谱。
我们注意到这对Uber MDM的速度和效率产生了直接影响。在一周内，UMAD帮助7000名员工注册MDM，在六周内，UMAD帮助16,000名员工注册MDM。在这16,000个用户中，大约有4,000个在他们的机器上有某种错误配置，通过使用UMAD注册MDM很快得到了纠正。在10周内，UMAD帮助92%的优步员工将他们的设备注册到MDM中。
macOS版本标准化
尽管我们经常更新和增强我们的Chef平台，并在整个公司部署UMAD，但我们面临的最大挑战之一是处理跨员工设备处理多个版本macOS的复杂性。
2018年，我们支持的macOS版本数量非常庞大。与我们使用UMAD对macOS MDM注册进行标准化类似，我们需要一个类似的系统来进行系统更新和升级。这对于确保优步数据的安全以及为公司提供一个一致的发展平台至关重要。
当我们使用munki对于自助应用程序和苹果软件更新，我们的一些团队成员发现了操作系统更新的各种问题:
- FileVault：具有FileVault的设备可能没有经过身份验证的重新引导。用户将开始升级并去吃午饭，但在等待用户进行身份验证时，升级会超时或失败。
- T1设备：T1 macOS设备在安装时需要internet访问，而munki可能无法在LoginWindow连接到internet，从而导致潜在的故障问题。
- T2设备：T2 macOS设备在T1需求之上包含了额外的安全性。macOS更新和升级现在需要机器停止(关闭)，而不是重新启动。当时，munki无法处理停止的T2设备，导致潜在的安装失败。
- 用户体验的差异:macOS的用户体验在不同的操作系统中有所不同:10.5到10.8的设备有一个软件更新首选项窗格，10.9到10.13的设备有一个统一的Mac应用商店和更新选项卡，10.14的设备取消了统一并重新引入了软件更新首选项窗格，但对其进行了现代化，使其看起来类似于iOS。
- 在苹果设备上测试时的差异:munki中的用户体验与Mac应用商店或软件更新首选项窗格中的用户体验不同，可能会导致意想不到的行为。
在我们的规模上，即使是1%的设备更新/升级失败也可能导致数百设备受到影响，所以我们决定利用，推动，一个处理更新的独立开源工具。与我们部署UMAD的方式类似，Nudge也可以通过Chef进行配置和部署。
Nudge是一个开源的统一包装器，围绕macOS主要升级(10.13到10.14)、macOS小型增量更新(10.14.0到10.14.1)和macOS小型组合更新(10.14.0到10.14.2)。管理员只需要确保设备上有macOS安装程序，并将Nudge配置为设备应该运行的最低操作系统。
Nudge允许我们将升级和更新体验统一到一个窗口或消息中，然后系统地将我们的界面与苹果使用的各种界面和工具联系起来。通过直接链接到苹果自己的二进制文件，我们不再需要担心意外的行为，并可以确保用户体验直接反映非企业苹果客户所看到的。
简单来说，除非苹果自己的安装程序或安装过程有问题，否则Nudge不会引入任何新的复杂性或未经测试的过程，苹果可能无法妥善处理。
大约在2018年底，我们对我们的工具链有足够的信心，我们可以在macOS 10.14.1上标准化。当时，Nudge只支持macOS升级，所以我们没有针对运行10.14.0的机器，我们当时最常用的操作系统是High Sierra 10.13.6，有近9000台设备运行该软件。到2018年11月初部署Nudge的第五天，10.14.1已经领先，拥有7000多台设备。2018年底，在Airbnb的帮助下， Nudge获得了小更新支持。现在我们已经超过了Nudge部署的第90天，10.14.3(2019年3月macOS的最新版本)是我们使用最多的操作系统，超过87%的Uber系统正在使用某种版本的Mojave。
最重要的是，我们的服务台还没有发行任何我们团队关于助推升级失败的罚单。
在Uber，我们用自己的烹饪书管理Nudgecpe_nudge，你也可以在我们的GitHub上找到。
厨师即服务
我们在Chef中遵循的主要设计原则是API烹饪书的概念。这一想法得到了两家公司的支持Facebook生产工程和Facebook客户端平台工程团队．
API烹饪书的一些好处包括:
- 而不是硬编码的默认值，值是“nil”或“false”。通过抽象这些值，如果正在操作的内容发生变化，您不必继续编写新的核心代码—您只需更新键/值对。
- 键/值对可以有条件地重写。这允许您利用一个可以跨多个操作系统工作的烹饪书。
- 由于每个值都可以被覆盖，所以您可以将这些api扩展到最终用户，允许他们为特性编写自己的值。例如,cpe_user_customizations是我们用来允许我们的终端用户自定义操作，如他们的默认软件安装和屏保。这些持续存在所有由单个终端用户使用的计算机。
- api允许您将代码抽象给其他可能不完全了解如何使用Chef但可以理解键/值对的团队。这大大降低了工程维护成本。
考虑到开源烹饪书对我们团队的好处，Uber在编写API烹饪书时就考虑到了开源;事实上，仅仅通过将烹饪书包含在运行列表中就可以应用的默认设置为零。默认情况下，每个API烹饪书都是禁用的，在管理任何状态之前，必须启用并传递配置。
下面，我们概述了Uber利用这种方法开发食谱的主要原因:
- 成为一名优秀的开源社区成员(贡献代码，而不仅仅是消费代码)可以提高代码质量，并创建健壮的功能集。
- 编写一般化的烹饪书强制进行抽象，这减少了特定的逻辑和潜在的技术债务，同时也减少了意外泄露专有信息的可能性。
下面的代码片段是端点工程师可能用于部署的一个示例萨尔(一种面向端点的模块化、开源报告工具)。cpe_sal会先跑，然后是cpe_profiles而且cpe_launchd这两本食谱都是必不可少的cpe_sal消费。
端点工程师可能会假设有三本烹饪书正在运行，虽然这在技术上是正确的，但如果我们深入到烹饪书中，我们会看到一个模式:cpe_sal有一个属性文件，主属性为false或nil。
在实际中cpe_sal资源文件(的主要代码cpe_sal)，每个动作周围都有“返回”守卫。如果值为false，则该特定函数不执行任何操作。这允许我们放置cpe_sal在我们的全球run_list，而不用担心它会将Settings应用到设备上。你必须显式地把它们标记为真实。
由于Chef允许您创建任何烹饪书，因此您只需创建一个应用开源烹饪书需要使用的属性的烹饪书。在下面的例子中，我们创建了一个cpe_base有一些属性的烹饪书cpe_sal需要实际运行一个配置。这种类型的烹饪书将根据您使用的开源烹饪书而有所不同，因此在这里创建您想要的任何类型的烹饪书，并将其添加到您的运行列表中。
的食谱cpe_base现在被添加到原来的运行列表中，需要放在前面cpe_sal，所以cpe_sal可以使用已修改的属性。
通过使用这种方法，我们能够开源cpe_sal不需要暴露我们已经实现的任何定制代码。这些代码片段只是一个小例子，说明了当正确利用api驱动的烹饪书时是多么强大。
前进
在Uber这样的高速增长公司，扩大移动设备管理有助于形成一种创造性思维，这种思维严重依赖于现有的MDM工具(如Chef)。我们大规模开发MDM系统的经验使我们接触到了开源解决方案，这是我们以前可能没有考虑过的生产环境。本着这种精神，我们鼓励您去看看推动和我们的CPE厨师烹饪书并开始为您的工作场所构建更有效的MDM系统。
如果你对处理大规模IT工程问题感兴趣，考虑申请我们团队的职位！
订阅我们的通讯以跟上优步工程公司的最新创新。
