《中國企業協同解決方案》節選《 Bamboo 系統管理員》

上帝視角

Bamboo 的系統管理員具有上帝視角，而且對於組織內的資源，擁有相當高的訪問許可權，即使一些資源無法直接控制，也有資格對其進行許可權申請。因此，該角色由 IT 部門擔任是比較明智的選擇。

但同時，其弊端也顯而易見。IT 部門通常負責企業內部的軟硬體基礎服務，對於企業產品的業務知識並不擅長。雖然理論上來說，產品業務的知識匱乏，並不會成為短期內 IT 服務的瓶頸。但現實中，由於產品架構的設計以及部門需求不同，IT 部門是無法獨立提供支援的，而是需要跟產品部門的交付運維聯合辦公。

事實上，現在很多創業中的網際網路企業已經逐漸把權利下放，由各個部門自己負責 IT 事務，他們都會從成本考慮，從而由交付運維工程師擔任了組織內部的 IT 職責。

這種模式帶來了很大的便利性，但同時也帶來了更大的風險，使得“刪庫跑路”更容易。而上雲則讓這個風險變得更可控一些，這方面的內容，我們在其他章節中有提到。

作為 Bamboo 的系統管理員，除了需要對機器資源有所規劃以外，還需要清楚組織內所涉及的技術棧和業務特性，這會有利於設計出更高效更友好的自動化任務執行方式。在很多時候，我們會發現 Bamboo 搭建完成之後，出現各種水土不服，最主要的原因在於，搭建的時候並沒有考慮到組織的實際業務需求，僅以官方文件其中的一種方式按部就班操作，結果在配置流水線的時候不能很便利的落地，有一些必備外掛也由於未能提前裝好啟用，使得 Bamboo 完全不能勝任真實的使用場景。

部署方式的選擇

容器化部署未必最好

參照 Bamboo 的官方文件，我們很容易就可以在一臺主機上搭建出一套 Bamboo。而採用 Java 開發的 Bamboo，也很容易在各類系統上執行。

值得注意的是，如果系統管理員對 Bamboo 還不足夠了解，建議按照預設的路徑去搭建，否則在執行除錯之後再去調整，最後很有可能是需要推倒重來的。

我知道，近些年“雲原生”是個非常火熱的話題，並且容器上雲也是未來的趨勢，但我們可能未必需要一味的去追求容器化部署這件事情。

首先，我們不得不考慮到使用該方式的成本。的確，在不考慮用人成本的情況下，雲環境會讓維護成本降低很多，但是我們大多數的企業並不具備這類的人才儲備。

其次，即使有不少企業正在做雲原生轉型，但事實上，自身尚不具備雲原生的實力，此時，若把公司內所有業務都強行容器化，對於任何部門都是一個不小的壓力，更何況是一些還需要各個部門協作使用的服務。

最後，CI/CD 平臺維護不可能一帆風順，雖然 Bamboo 本身不會帶來部署的問題，但其在執行自動化任務的時候，會依賴於執行環境中的很多配置，處理這些問題，大多數管理員並不能分得清是主機問題，還是容器內部問題。

所以，如果貴公司是一家熟練掌握雲原生技術的企業，那毫無疑問，工具人學堂的顧問會強烈建議採用容器化部署，這使得資源能夠更好的被利用，維護也會更方便。

本地代理與遠端代理

如果說 Bamboo 服務本身是大腦，那麼 Bamboo 代理就是代表執行力的四肢。

不光 Bamboo，其他很多自動化流水線工具都採用類似的設計，即一個主節點配多個代理執行節點。這樣設計的好處在於，耗費資源的執行類任務將不會影響主節點的穩定執行，當資源不足，需要擴容時，增加執行節點即可，而不需要去改動作為排程使用的主節點。

通常，在企業的生產環境中，不太會採用本地代理的方式，雖然這種方式會更便捷也更便宜（本地代理免費）。但所有服務都在一臺伺服器上的部署方式，無疑是一座不知何時會噴發的火山，稍有不慎，就可能造成全面癱瘓。Atlassian 深知穩定性對於企業運轉的重要性，因此，Bamboo 按遠端代理節點的數量收費。

引入代理節點的設計，使得主節點從繁重的自動化任務中解脫出來，只負責編排和排程。這樣一來，也就無需對其進行各種任務執行時依賴環境的配置，而是均交給了代理節點。即使代理節點異常，也不會影響系統，若節點不可修復，換個節點取而代之。

如果遠端代理節點也是採用容器化部署，那麼就需要系統管理員清楚的認識到，自動化任務的執行環境是在哪個容器裡。工具人學堂的交付團隊在實施 Bamboo 專案的時候，通常需要花費不小的精力培訓客戶如何利用容器環境。

許可權需要控制嗎

許可權與安全

一個注重資源安全的公司，一定會諮詢關於許可權方面的配置。Bamboo 無論是使用 Jira 使用者目錄或者 Crowd ，甚至是直接對接第三方使用者目錄，都不是一個麻煩的事情。但對於不同專案的許可權，依舊需要在 Bamboo 上做一些額外配置。

也許未來有一天，Atlassian 會對各應用使用者許可權進行統一管理，從而減少各應用的獨立配置，但這並不是一項簡單的工作，至少現階段增加這一功能，一定是一件回報率為負的投資。

當我們按照組織架構，為對應的組織按照專案需求新增各自許可權的時候，可以有效的做到資產隔離。一些敏感的資訊，比如生產環境，可以讓無關的使用者不僅不能編輯，甚至不具有訪問資格。

其實，除了許可權上的隔離，Bamboo 在變數的保密性上也做了一些努力。如果我們在變數名後面加上特定的字尾（如 password， sshKey， secret， passphrase），那麼該變數在頁面上顯示時會以 * 代替。

雖然這只是前端頁面的一個掩耳盜鈴式做法，但至少這在終端使用者操作介面的時候可以有效避免敏感資訊直接暴露的風險。

許可權與效率

許可權上的需求通常看起來都很美好，但其與效率幾乎總是成反比。

在理想狀態下，人數越多，組織架構越複雜，許可權管理就越能發揮它的作用，但同時，效率也往往越低下。

實際的組織架構中，很少能夠做到一個人只在一個角色中。即使能保證使其只分配在一個專案中，也極有可能會身兼數職。更何況，現在越來越多的企業都想落地敏捷，而敏捷提到的“高效”往往讓人產生無需控制權限的錯覺，這種錯覺帶來的影響很深遠，以至於工具人學堂的顧問在專案實施中不得不非常重視客戶對許可權與便捷的接受度。

所以，許可權管控程度和效率的預期，是一個取捨問題。

我是工具人學堂的威爾（石巍/Will），Atlassian Solution Partner 高階顧問