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 的作法吧！