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），那麼該變量在頁面上顯示時會以* 代替。

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

權限與效率

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

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

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

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