【第五篇】 ：用戶體驗
系列論文的前幾篇討論了在實踐過程中我們如何解決各個方面的技術挑戰[1-3]。在遷移過程中，除了技術因素，還要考慮人的因素：在整個遷移過程中，必須始終將用戶牢記于心，為最終用戶盡可能地提供無縫的體驗。當出現問題時，我們希望用戶知道如何解決，去哪里尋求幫助。本文將討論谷歌員工在模型中的工作體驗，從新員工入職、新設備配置，到遇到問題時如何處理。
創造無縫的新員工體驗
對于許多新員工來說，模型這個概念是相當陌生的：他們習慣了通過VPN、公司專屬WiFi、和其他特權環境來訪問他們日常工作所需的資源。上線之初，許多新員工繼續向我們的IT服務臺團隊（內部稱為技術站）請求VPN訪問。用戶過去習慣性地認為如果不在辦公室的時候需要工作，就要經過復雜的IT設置，需要VPN。架構師原本以為用戶不在辦公室，有遠程訪問需求時，會嘗試直接訪問內網資源，并發現可以成功訪問。這樣看上去非常完美：無需用戶申請訪問配置，無需技術站的支持負擔，簡直就是雙贏。然而事與愿違，（遠程訪問需要申請VPN權限的）用戶習慣根深蒂固。
●新員工入職培訓
顯然，在用戶開始谷歌的IT之旅時，就應該讓其盡早了解這種新的訪問模式，因此我們在新員工入職培訓時就開始介紹。在培訓中，我們有意避免去講解模型的技術細節，而是關注最終的用戶體驗。我們強調用戶不需要VPN，可以“自動”獲得遠程訪問權限；用戶無需改變他們的工作流就可以在辦公室、家里、飛機上，或咖啡館工作。通過培訓，我們向用戶展示了的谷歌瀏覽器（）擴展程序，作為訪問模型中最常見的面向用戶的方式（有關擴展的更多細節，請參見下面章節“擴展”）；我們還展示了在中代表連接“正確”的圖標（參見圖2）。只要有“正確”連接標識，用戶就可以通過任何網絡連接訪問他們需要的絕大多數工具和資源。
●新設備安裝配置
當用戶初次使用公司賬號密碼登錄其公司設備時，其訪問設置將被自動配置。為了實現這種無縫的入職體驗，清單進程和平臺管理工具在后臺工作，以配置新的租用設備并進行初始化。如“谷歌：從設計到部署”[1]中所述，我們根據大量的數據來判定設備的信任等級，包括觀察數據（最近安全掃描時間，補丁級別，安裝軟件等）和預設數據（分配的所有者，VLAN等）。為了解決這種判定的復雜性，我們的清單團隊遵循自動配置流程，以確保首次登錄時正確信任新租用設備。驗證必要的用戶賬密后，我們會自動將自定義擴展程序推送到用戶設備。從用戶的角度看，只要能夠看到擴展中的綠色圖標，他們就可以訪問企業資源。通過在新員工培訓中講解的擴展，基本消除了新員工困惑，并且可以支持新員工的遠程訪問請求。
減少VPN使用
盡管新員工在培訓中了解了，但畢竟他們在入職谷歌的頭幾天中可是接受了大量的信息沖擊，讓每個人都能回憶起培訓中的每個細節不太現實。于是我們修改了VPN申請流程和工具來強調在培訓中講解的概念。
默認情況新員工沒有訪問VPN網關的權限，他們必須通過在線申請門戶來申請VPN訪問權限。在此門戶上，我們明確提醒用戶是自動化配置的，他們在請求VPN訪問之前應嘗試直接訪問他們需要的資源。
如圖1中的流程圖所示，如果用戶跳過這個警告，我們還會對用戶通過VPN隧道訪問的服務進行自動分析。如果用戶在過去45天內沒有訪問過任何一個模式不支持的企業服務，我們就會向他們發送電子郵件，郵件中會解釋，由于他們訪問的所有公司資源都是通過支持的，因此他們的VPN訪問權限將在30天后到期，除非他們訪問不支持的服務。我們在VPN訪問權限失效前7天會再發送一個通知，然后在第7天結束后取消用戶對VPN網關的訪問許可。這種自動化流程使我們主動剔除對傳統訪問基礎架構的不必要使用，并最終完全拒用VPN基礎設施。
圖1：自動分析和取消員工的VPN使用
借用項目
實現自動配置還帶來了一個意外好處，為用戶改進了其他方面的技術體驗。其中一項最明顯的改進是我們的借用筆記本電腦項目。像許多現代公司一樣，我們員工的工作方式非常靈活，可以在辦公桌、會議室、休息室或家中自由工作。移動設備（特別是筆記本電腦）對其生產力至關重要。為了處理忘帶、遺失或被竊的情況，我們提供了一種自助式借用筆記本電腦程序，可以讓用戶盡快恢復正常工作。
使用遍布全球的自助式谷歌筆記本電腦借用站，任何用戶都可以將借用的筆記本電腦臨時注冊為自己的工作電腦，最長可達5天。從拿到筆記本到開啟工作狀態可能就幾分鐘時間，這樣簡單的流程讓用戶受益良多。借用設備開通足夠簡單，所需支持服務也隨之減少，技術站的資源就可以釋放出來處理其他問題。當用戶歸還設備或借用時間到期時，系統會自動撤銷其證書，并降低其信任等級，為下一個用戶重新借用做好準備。
的瀏覽器擴展程序
通過或多或少地消除對VPN客戶端的需求，我們可以通過擴展程序這個單一入口來封裝幾乎所有的訪問需求——無論是遠程訪問還是本地訪問。擴展程序會自動管理用戶的代理自動配置（Proxy Auto-，PAC）文件，明確將一些特定訪問場景路由到訪問代理[2]。當用戶連接到網絡時，該擴展程序會自動下載最新的PAC文件并顯示“正確”連接的綠色圖標。瀏覽器根據PAC文件中的規則自動將企業服務的訪問請求路由到訪問代理。這使得內部開發人員可以不用明確配置客戶端訪問入口參數的情況下部署企業內部Web服務：客戶端訪問入口配置要求開發人員在公網DNS中配置CNAME指向訪問代理，訪問代理就會自動處理用戶身份認證和授權。
由于擴展程序將所有流量路由到訪問代理，用戶將無法訪問那些訪問代理不可達的設備。另外，擴展必須下載正確的PAC文件，以便準確路由業務流量。這種設置可能在某些場景下可能會出現問題，比如有強制驗證門戶的網絡連接的場景，或用戶需要訪問本地網絡上與設備而不希望通過訪問代理進行路由。我們需要對用戶解釋這些問題并提供補救方法chrome瀏覽器翻譯失敗的解決方法，最好不要增加技術站的支持負擔。擴展程序的認證狀態圖標（如圖2所示）提示了進一步排除故障的方法信息。
圖2 擴展中表示身份認證狀態的圖標
當出現問題的時候
當出現故障或用戶遇到復雜的邊界情況時，會發生什么？通過假設用戶會遇到的問題，確定常見場景，制定計劃盡可能順利地解決這些問題。讓用戶能夠理解問題，并在可能的情況下自我修復，這是我們一貫的首要目標。
●可以自我修復的問題
因為我們是一家擁有許多差旅員工的全球性公司，當他們在機場、酒店和咖啡館辦公時經常會遇到強制驗證門戶。這些門戶網頁通常在私有網絡的默認網關上，當用戶連接到這樣的網絡時， 擴展程序會嘗試下載PAC文件，但是強制門戶網頁會阻攔PAC文件的下載。
要解決此問題，當擴展程序檢測到網絡狀態變化時，我們都會確定設備是否位于強制門戶之后：通過嘗試訪問，正常情況下應返回HTTP 204的空頁面。如果我們收到HTTP 204以外的任何內容（最可能出現的是HTTP 302），就認為該設備需要先通過強制驗證門戶的認證。這種情況下，擴展程序會直接使用內置的預定義PAC文件，并警示用戶。
當用戶碰到強制驗證門戶的場景，可以點擊擴展程序圖標，我們會告知他們在連接機場或酒店的網絡的時候碰到強制驗證門戶的這個問題很常見。的工作不會受到影響，只需要將的設置更改為“Off:”即可，當用戶完成強制門戶驗證后，瀏覽器擴展即可成功下載最新PAC文件。這個簡單的流程允許用戶在最短時間內完成自我修復，沒有增加技術站的負擔。
用戶還經常嘗試訪問私有網絡中的設備，比如許多谷歌員工就會使用公司筆記本電腦來執行配置連接家庭打印機或其他網絡設備等任務。但由于配置通過訪問代理來路由所有連接，所以啟用擴展后，連接就會失敗。與強制驗證門戶的情況類似，解決方案是將設置更改為“Off:”。但不同的是，我們無法輕松檢測到此故障狀態。因為通常情況下，這種場景下的用戶有一個激活的并且功能正常的互聯網連接，因此從擴展程序的角度來看，一切正常，用戶可以通過訪問所有的企業資源，沒有理由發出警報。
為了弄清楚在這種情況下如何有效地與用戶交互，我們進行了一次典型的用戶體驗測試：工程師把公司筆記本電腦帶回家，想用它來更改家里打印機的設置，兩臺設備通過IP地址連接。用戶連接到家庭網絡，擴展成功連接，下載最新的PAC文件，并配置瀏覽器代理。當用戶在新建的瀏覽器Tab標簽頁中輸入打印機的IP地址時，對私有網絡的訪問流量一起重定向到了訪問代理。網絡請求失敗，用戶得到錯誤提示。
我們將解決問題的關鍵點放到最終的錯誤頁面上，并提出了一個解決方案：通過訪問代理展示錯誤頁面。我們創建了一個自定義HTTP 502錯誤提示頁面，以便在某些場景下將警示信息插入到錯誤頁面中。具體來說，特別是針對用戶試圖訪問或約定的地址時，我們返回的HTTP 502錯誤提示頁面可以明確給出提示，用戶就會知道如果他們在訪問本地網絡設備如家用路由器或打印機時（兩個最常見情況），需要將擴展修改為“Off:”。通過這種方式，我們能夠基于現有的基礎設施和流程，讓用戶自行修復問題。
我們的海外員工有時需要配置一些自定義代理來測試廣告。如果用戶安裝了多個擴展，每個擴展都試圖配置代理，那么這些擴展就會相互沖突，這可能會使用戶感到困惑，并影響他們訪問企業資源。
我們用兩種解決方案來處理這種情況。首先，我們將海外的代理配置直接集成到擴展程序中。當用戶有業務需求要從特定位置對外訪問時，他們可以從支持國家的下拉菜單中選擇該位置。這為用戶提供了一個單獨擴展來滿足他們管理最常見的業務代理服務器的需求。
此外，當用戶有合理需求運行額外的代理管理擴展時，他們的圖標將從綠色變為紅色。然后我們給他們一個選項，將狀態更改為Off： 并告知他們何時應該使用此設置。同樣，這個過程允許用戶進行自我修復，提高他們的工作效率并減少對我們支持團隊的咨詢的工作量。
復雜問題解決：門戶
對于上述簡單問題，可以通過自定義錯誤頁面或擴展程序讓用戶可以快速地進行自我修復。然而對于一些看似正常的訪問失敗場景，用戶和支持團隊都會迫切需要知道被拒絕的原因。后端基礎設施中的ACL邏輯復雜、層級多，無論對用戶還是支持團隊而言，想要理解這特定決策背后的邏輯都有困難。即使是一個經驗豐富的SRE工程師，也可能需要花費很多時間查詢許多內部服務，來找出一個403錯誤頁面的原因。考慮到訪問代理每天可能產生的403錯誤頁面的數量級（僅HTTP/S就有約12M/天），人工參與故障排除是不可規模化的，也是不切實際的。
為了方便診斷和解決更復雜的訪問問題，我們設計了一個門戶網站來幫助用戶和支持團隊。我們不只是用一串通用錯誤代碼來告訴用戶他們的訪問被拒絕，而是解釋他們被拒絕的原因以及如何解決這個問題。門戶是獨立的，而不是直接集成到訪問代理服務器中，因為它使用的是更細粒度的ACL，取決于最終用戶當前信任級別。由于訪問代理默認是公開的，所以我們需要限制攻擊者從403錯誤頁面中獲得的信息量。
●架構
門戶大致分為前端和后端，兩者之間采用API進行通信。
●解釋引擎
除了查詢和表示ACL外，門戶還需要有效地向用戶展示這些信息。針對這些被拒請求的響應報文細節，我們構建了一個解釋引擎（ ）來進行錯誤診斷。它通過遞歸遍歷負責提供授權決策的子系統來完成操作。
例如，訪問代理的ACL可能要求設備完全可信才能訪問一個特定的URL。在查詢這個ACL后，解釋引擎會和設備推斷管道交互，并獲取訪問此資源的必要條件，然后將這個信息發送至前端，并翻譯成通俗語言，用戶就可以通過訪問門戶來找出他們當前狀態存在何種問題以及如何解決這些問題。
●為ACL定義ACL
雖然解釋引擎可以提供有效信息，但它可能會暴露敏感數據。它會暴露受保護系統存在問題的ACL，泄露用戶賬號和設備狀態信息，而這些信息都會為潛在攻擊者所用。為這些數據定義ACL非常棘手，因為我們需要在工具易用性和保護敏感信息之間實現平衡。
根據用戶和設備請求故障診斷信息，我們可以使用不太具體的信息替換輸出中的敏感信息。在極端的情況下，我們可以將敏感信息替換為聯系技術站的提示信息。這樣技術站和SRE工程師就可以通過驗證用戶的身份并以用戶的名義查看相關信息，在幫助用戶的同時不泄露敏感信息。
圖3 當阻止請求后展現的錯誤頁面
●訪問拒絕登錄頁
一旦門戶開發完成，即可將門戶集成到訪問代理，向用戶展示錯誤消息。當用戶遇到HTTP 403錯誤時，他們可以一鍵返回到門戶，查看所有相關錯誤細節（參見圖3）。然后，門戶會向后端重新發送訪問請求，并解釋導致問題的原因。
例如，如果一個資源要求特定群組成員才可訪問，門戶會提供群組名和到群組管理系統的超鏈接，這樣用戶就可以申請訪問權限。門戶在后臺查詢后端的訪問控制列表服務來判斷該資源的授權要求chrome瀏覽器翻譯失敗的解決方法，與用戶當前的歸屬組信息進行比較，門戶前端將比較結果轉換為通俗語言（參見圖4）。這一切都發生在幾秒鐘之內，遠遠快于用戶猜測什么是“組成員問題”或尋求幫助。
圖4 面向員工的訪問拒絕錯誤故障排除指引
將這個流程直接集成到我們的錯誤消息中，允許用戶可以無縫地完成這個過程——并且完全通過自助服務。
●臨時的故障排除
盡管我們期望大多數用戶通過錯誤頁面訪問到門戶，但是我們還提供了一個獨立頁面來支持更多臨時的故障排除。前端門戶的登錄頁面是根據用戶身份和訪問設備自定義的，它會顯示用戶及其名下設備的信息，并突出可能導致拒絕訪問的問題。我們允許最終用戶主動訪問這個工具來了解其名下設備的全局視圖和潛在訪問問題，用戶就能一步到位地解決他們任何設備上的問題。去外地出差或者演示之前，使用這個能力進行設備信任度自查非常方便。
●支持賦能
門戶前端也使技術站能夠快速地執行詳細的故障診斷，提供立即可執行的方案，大大縮短了解決問題的時間。例如，為了解釋一個403錯誤頁面，技術人員就可以使用門戶登錄頁面查詢特定的用戶名或設備標識，鎖定到某個特定設備，確認它是否是一個完全可信的公司設備。如果不是，系統會給出設備不可信的具體原因，以及技術人員該如何解決這個問題（參見圖5）。
圖5 面向服務臺的訪問被拒絕錯誤故障排除指引
未來目標
除了當前的功能外，門戶還提供了進一步實現自動化的可能。我們計劃在將來持續檢查潛在的拒絕訪問問題，并會在這些問題真正出現前，告知用戶如何自助解決問題的方法。同時，對于不能自我修復的重大問題，會啟動自動通知到技術站采取補救措施。我們還希望擴大我們可以自動解決的問題范圍，而無需人為干預。
聚焦經驗
盡管遷移在多個技術領域困難重重，但它也給予了我們足夠的空間可以重新評估用戶支持體驗。通過關注遷移期間和遷移后的用戶體驗，我們可以使用戶能夠輕松地使用復雜的網絡模型。專門設計的工具使出現在用戶側的組件變得清晰易用。這些支持界面的意義是為了允許用戶盡可能地自我修復，從而節省用戶時間，釋放出支持團隊的資源。當用戶需要其他幫助時，我們提供有效工具和信息，使技術站發揮最優價值。
對于絕大多數用戶來說，是完全透明的。當谷歌員工擔心他們自己的業務流程時，模型負責處理全部的訪問邏輯問題。當用戶的確有問題時，我們會快速有效地介入，在合適的時間給他們提供正確的信息協助他們恢復正常。然后我們退回二線，讓他們專注于他們最擅長的事情。
參考文獻：
[1] B. , J. , B. Beyer, and M. ,“: to at ,” ;login:, vol.41, no. 1 ( 2016), pp. 28–35:
[2] L. , B. Spear, B. Beyer, and M. ,“ Part III: The Proxy,” ;login:, vol. 41,no. 4 ( 2016), pp. 28–33:
[3] J. Peck, B. Beyer, C. Beske, and M. , “ : While ,” ;login:, vol. 42, no. 2 ( 2017), pp. 49–55: