本篇內容來自於論文：Migrating to BeyondCorp: "Maintaining Productivity while Improving Security"

擴大技術支持範圍，最小化員工影響

使用前面討論的工具和流程，我們能夠自動識別、聯繫和遷移整個用戶群。但是，我們還需要在轉型之前和出現問題時為用戶提供協助，並與用戶溝通。在工作流程轉型的過程中，爲技術支持提供專業訓練以及擴展用戶溝通和互動規模是至關重要的。

增強技術支持團隊的能力

我們在技術支持團隊裡精選出一組技術人員進行培訓，使他們成爲 BeyondCorp 架構模型中的倡導者和用戶遇到問題時的主要聯繫對象。在早期的推出階段，這些技術人員協助受影響的用戶迅速恢復工作，同時不影響遷移進度，並且將問題及時地反應給 BeyondCorp 專家。

最初，這些經過專業訓練的技術人員比其他技術人員獲得了更高級的系統訪問權限。作為 BeyondCorp 推出的第一批觀察者，他們可以預測技術支持部門的其他人員需要哪些訪問權限、工具和流程。此外，他們還通過全球技術講座、討論列表、午餐聚會等方式，對技術支持組織的其他成員進行培訓。隨著知識的傳播，我們擴大了所有支持人員的系統訪問權限。

在各地建立領域專家 (Subject Matter Expert, SME) 讓我們能夠直接地和有遷移障礙的團隊接觸。透過與熟悉情況的聯繫點合作，BeyondCorp 團隊可以直接與有遷移障礙的項目團隊溝通，並協同找到解決方案。與此同時，技術人員被授權並鼓勵在識別問題後盡快地將新的臨時解決方案或修覆方法添加到內部文檔中。將解決問題的權力分配給盡可能廣泛的網絡使我們能夠高效地共享知識和擴大支持範圍。

自助式幫助

爲了避免接收到大量的用戶詢問和疑慮，我們需要一種方法來最小化混淆，並在不需要技術支持人員單點干預的情況下回答常見問題。當一名用戶被篩選出要進行遷移至 BeyondCorp 架構時，我們會自動地傳送一封郵件，內容包含清晰的遷移時間表、遷移會如何影響他們工作的概念，以及項目資訊、常見問題與解答等連結。

我們還提供了一個自助服務門戶網站，允許受業務關鍵時間限制的用戶申請推遲遷移。為了回答問題並進一步大規模傳播知識，我們創建了一個內部討論列表，讓人們可以在其中共同尋找答案。通過分析常見問題，我們能夠快速迭代最初的電子郵件和項目文檔。

在整個推出的過程中，我們針對 error messaging 設計了一個專門的網頁應用並進行反覆的叠代和改進。該網頁應用清晰地指出常見問題（例如，介紹了用戶被拒絕訪問某些資源的原因）、提供解決步驟，並提供知識庫文章的連結。用戶可以自己解決常見問題，例如群組資格和 certificate 問題，這樣進一步地減少了技術支持幹預的情況。該網絡應用程序還可以將來自許多不同層和系統的信息整合為一系列單一的操作，從而幫助技術人員解決錯誤。

內部宣傳活動

為了提高 BeyondCorp 的知名度，我們開展了一項內部宣傳活動，提供了筆記本電腦貼紙、常見的徽標和措辭，並在辦公室各處張貼了可見的文章。這些材料指向了自助幫助和面向任何有問題的人開放的辦公時間。通過專注於提供信息、教育和幫助，我們直接建立了與用戶的信任、友好和支持。在整個過程中，企業溝通和技術寫作的參與至關重要，特別是在早期階段，當我們需要提供該計劃的意圖和影響的清晰圖像時。
（貼紙 😂😍）

階段性推出

BeyondCorp 項目最初作為規模較小的試點項目，地理位置靠近項目團隊。隨著時間的推移，我們逐漸擴大了推出範圍，逐步選定具有本地技術專家的地點，最終擴展到了風險逐漸增加且距項目團隊較遠的工作流程和站點。在取得成功歷史記錄、用戶的強烈支持以及對策略充滿信心之前，我們不會冒然遷移關鍵的業務工作流程。在這個過程中，推出規模和受影響的工作流程增加，而技術支持的負擔減少。分階段實施是成功的關鍵因素之一。

最終結果

通過不斷分析和改進上述所有方法，我們建立了一個系統，確保了 BeyondCorp 的推出可以在全球範圍內擴展，而不會對業務、支持或用戶體驗產生負面影響。我們並不是簡單地“增加更多人手來解決問題”，而是通過建立系統和流程來高效處理問題、升級和培訓，從而擴大了我們的努力。 此外，我們還能夠信任用戶，讓他們依靠信息、開放和對共同目標的認同來幫助我們實現變革。我們謹慎地追蹤與 BeyondCorp 遷移相關的技術支持事件。隨著公司越來越多地采用這一模型，近幾個月來（本篇論文著於 2017 年夏天），BeyondCorp 只占我們技術支持事件的 0.3%。從最初的 0.8% 開始，通過改進文檔、培訓、信息傳遞和推出方法，需要技術支持的情況逐漸減少。與 Google 內部其他類似的大規模內部 IT 變更相比，BeyondCorp 引發的技術支持事件相對少了 30%。

結論

There is always tension between the urgency to improve security and resistance to changing the habits of end users. When infrastructure and workflow changes threaten to impact productivity, this tension only escalates. Achieving a balance between progress and stability is more art than science. BeyondCorp’s keys to success and acceptance were analysis, adaptive planning, and proactive communications.

"Achieving a balance between progress and stability is more art than science. "

BeyondCorp 的成功關鍵是分析、適應性規劃和積極主動的溝通。

通過將 BeyondCorp 架構解藕，我們可以並行各組件的落實，而且每個階段對用戶的影響都很小。雖然部署 BeyondCorp 需要數年時間，但每一個里程碑都帶來了好處。通過累積，我們大大簡化了遠程訪問，提高了速度，簡化了網絡管理，並加強了我們的安全。

在 Google，我們能夠將在 BeyondCorp 項目中學到的知識應用到其他項目和服務中，尤其是最近（本文著於 2017 年）添加到 Google Cloud 的新服務（Identity-Aware Proxy）。BeyondCorp 最大的收獲之一是，我們認識到分階段實施項目的重要性，並在遇到額外特殊用例時繼續完善和發展我們的戰略。

雖然本文側重於 Google 的具體經驗，但它所分享的經驗可以被任何組織采用，無論規模大小，只要該努力得到了利益相關者的堅實支持。(“While this article focuses on Google’s specific experience, the lessons it shares can be adopted at any organization, regardless of size, so long as the effort has solid backing from relevant stakeholders.”)

好啦~這就是今天的內容。讀到這裡覺得好感動。

我老闆年初時給我推薦的一本書 "The Software Architect Elevator" 裡面有寫到，「轉型 Transform 的拉丁文原意是改變形狀或結構。因此，當我們提及 IT 轉型時，說的不是增量式的進化，而是對技術全景圖、組織機構設置和企業文化進行根本性的重建。這種改變基本上是翻天覆地的，你得把房子切成小塊，然後再把這些小塊重新組合成一個新的形狀。」

「企業資深架構師的工作分爲三個層面：(1)定義 IT 戰略、(2)落實管控、(3)關注實際情況，獲得有關決策的反饋。」

「在每次 “構建——衡量——學習” 循環期間，組織不僅能了解到哪些特性對用戶最有用，而且項目團隊也能學習到如何構建誘人的用戶體驗、如何加速開發周期或者如何擴展系統。這個學習循環對組織的數字化轉型至關重要，因為它支持內部創新和快速叠代。」

「企業IT部門必須變得以客戶為中心，並在 “構建——衡量——學習” 的無限循環中學習客戶實際使用產品的情況。如果所提供的服務不是客戶所需要的，那麽即使可以更快地提供也毫無意義。」

...

閱讀 Google 內部轉型過程的文獻真是今年下半年做的最正確的決定了。讓我看到一個規模巨大的轉型是如何真實、成功、相對快速地實現的。我想精髓就是 lean, and think in system!!

這篇文獻是 2017 年夏天寫的，全文關注轉型過程中的技術層面。明天我們開始讀下一篇文獻，著於 2017 秋天，關注轉型過程中的用戶體驗。

明天見！