DAY15 Azure Machine Learning 里的多人协作---谈 RBAC

铁人赛已经过了一半，相信大家都熟悉了 AML 大部份的操作了，现在开始我们要进入更加核心的主题：AML 在团队开发上的应用。

我们会要用 AML 来做 AI 专案的开发，很大的原因是这个平台很适合团队合作开发。以往在地端 GPU 设备开发 AI，往往只有一个人可以使用，多人使用时可能大家就要排时间错开始用，或是买更多台设备让大家都能用。

在 AML 上我们可以很多人同时使用，运算资源不够时就加开设备，但是如果每个成员都是想开资源、就开资源，那麽费用很快就会爆炸了。所以我们在实务上，会让某些人才有开资源的权限，而某些人只有编辑的权限。

但是在云的世界里，不是简单的赋予权限而已，我们就来介绍今天的主角 RBAC 吧！

RBAC 介绍

以角色为基础的存取控制（Role-based access control，RBAC），是在云的世界中，最为广泛应用的存取控制机制。和传统直接赋予使用者权限不一样，而是将权限赋予角色，角色再指派给使用者。

角色被定义为一个授权等级的工作职位或职称，一个使用者可以被给予多个角色。角色除了可以指派给使用者之外，也可以指派给群组、服务主体或受控识别等。

举例来说，KoKo这个使用者，被给予了资料科学家这个角色，可以在 AML 上面工作，但是不能去操作 Azure SQL 资料库的服务。
後来公司一直招不到 DBA，只好让 KoKo 也来兼任 DBA，这时候就可以再给予 KoKo 一个 DBA 的角色，这样子 KoKo 就有操作 DBA 和 AML 的权限了。
此时 KoKo 身上就被指派两个角色，有这两种角色的权限了。

角色赋予权限的原则，要符合 least privilege principle，一般翻成最小权限原则。是只给予当下最小且最必须的权限即可。
举例来说，小华这个使用者的工作，只是专门删掉不用的 VM 而已，这样子就可以领年薪一百五十万。我们就只要给小华删除 VM 的权限即可，不必给他删除 Storage Account 的权限，或是新增 VM 的权限。

Azure Machine Learning 内建的角色

AML 有四个预设可用的内建角色，说明如下：

1. AzureML Data Scientist：可以在 AML Workspace 内执行所有动作，但建立或删除计算资源和修改工作区本身除外。
2. Reader：只能做唯读的动作。可以列出和查看工作区中的资产，但是 Reader 无法删除或更新这些资产。
3. Contributor：可以查看、建立、编辑或删除工作区中的资源。举例来说，contributor 可以建立实验、建立或连结计算丛集、提交执行，以及部署 Web 服务。但是不能改变角色指派。
4. Owner：有 Workspace 中的所有权限，包含角色的指派。

除了内建的角色之外，我们也可以客制化自己的角色，以符合团队合作时的实际需求。

一个 AI 团队该有什麽样子的成员（Bouns 议题）

小弟多年来协助企业导入 AI 解决方案，看了很多成功与失败的案例，对於企业组建一个 AI 团队很有感。

这个部份和 AML 的学习无关，但是刚好今天的主题是团队协作，就顺便来跟大家分享。

私以为一个团队最重要的，不是什麽 Kaggle 高手，又或是 Microsoft AI MVP。而是一个有足够决策权的高层，而且他要有 AI sense。

看过很多企业，中坚干部很有热情，技术面也不错，想要协助公司导入 AI 专案，但是得不到高层的强力支持，最後失败收场。
很多时候向公司提出了 AI 专案，高层虽然会支持，但是支持的力道不够，一听到要花更多的钱，或是小小的卡关，就转向不支持了。

也有是高层虽然大力支持导入 AI，但是完全没有 AI 相关的先备知识，结果也往往是失败收场。最常见到的是高层以为 AI 是万灵丹，只要导入 AI 所有问题都可以解决，而且是立刻马上。不得不说这种高层还真的不少。

因此，私以为一个 AI 团队最重要的成员，就是一个有决策权又有 AI 知识的高层。

剩下的成员，就是常见的：
2. 资料科学家：从资料中找出问题，具分析和沟通的能力，了解整个 AI 专案和产业知识。
3. 资料工程师：收集整理资料，做前处理，资料库相关的技术。
4. 演算法工程师：了解各种演算的意义和能解决的问题，训练模型和优化。
5. 系统整合工程师：将 AI 模型与现有系统整合、部署等。

希望这一段内容，会对各位要组建 AI 团队的企业有所帮助。

今天没有丰富的图文教学，却也不知不觉破千字了，明天我们就开始来实战 RBAC 在 AML 的作法吧！