前言：美國政府數位服務教戰手冊（U.S. Digital Service Playbook）（上）

帶入有經驗的團隊成員（Bring in experienced teams）

此處所謂的經驗包含了專案管理、軟體工程跟設計的經驗，例如團隊裡面應該有這些成員：

• 打造過受歡迎且高流量的數位服務
• 處理過數位服務的資安議題
• 評估過不同第三方技術選項或管理過委外專案
• 開發過行動與網頁應用程式
• 使用過自動測試框架，有系統部署（DevOps）經驗（例如知道什麼是 Continuous Integration）
• 另外也必須有外部夥伴支援預算處理及法律議題

如果不把乙方算進我們的團隊，且將第一點的「打造」跟第二點的「處理」解釋成「委外處理」，我想甲方團隊勉強能滿足前三項，而最後一項通常有其他部門（總務、法規會）支援；如果連乙方團隊都算進去，我想還是沒辦法滿足倒數第二項，可能是我看得太少，至少我之前接觸過跟聽過的廠商，沒人在做自動化測試（有手動迴歸測試就要偷笑了），更不用說 Continuous Integration 或較新的 DevOps 觀念了（當然，甲方也不懂）。

選擇現代化的解決方案架構（Choose a modern technology stack）

我們數位服務的技術架構必須與時俱進，才能讓專案有效率及省成本地進行，並且容易擴充。不管是在選擇基礎架構、資料庫、開發框架、程式語言或其它技術選項時，都應該選擇符合潮流、避免被單一廠商綁定、且現今大多數企業用來打造類似服務時所採取的方案。

• 考慮以雲端服務為基礎，且一般企業廣為採用的解決方案。
• 在技術架構的所有層級都考慮開源解決方案。
• 軟體必須要能佈署在不同的常見硬體架構上。

一個很好的檢查方式是新成員需要多久時間才能把本地開發環境建起來（我們政府的甲方不做開發工作，所以這個問題…可以用來問乙方）。如果我們的架構是常見且開源的，則建立本地開發環境的時間就很快，這也有利於專案管理及成員交接。

將服務佈署在能應付不同流量的環境（Deploy in a flexible hosting environment）

這一點是談雲端服務的其中一個基本概念：隨需（On demand）。把服務佈署在所謂雲端主機，但卻必須手動管理環境中的資源，就是假雲端，徒耗人力跟經濟成本，也削弱了災害復原的能量。

• 你的服務必須能應付尖峰流量；除了真實使用者外，若你的服務也能透過 API 提供，或預期會有國外使用者，這些流量都必須考慮進去，在尖峰流量時能自動增加資源；沒有這麼多流量時自動關閉資源（對照組：前陣子的戶役政系統、實價登錄查詢系統…）。
• 我們只為目前使用的資源付錢。就算不使用外部雲端服務，你還是要知道你的服務如何針對流量隨需調配資源，而非過猶不及。
• 你的服務有沒有 Data redundancy，例如其中一台掛掉了，可否能自動由其他台接手？若不行你的災害復原計畫為何。
• 靜態資源考慮經由 CDN（Content Delivery Network，可想成離你最近的Cache）提供。
• 服務建立在常見的硬體配置上。

自動化測試跟佈署（Automatic testing and deployments）

這一點在講 CI（Continuous Integration），如同之前提過的，依據我粗淺的經驗，我們政府的甲乙方都不知道這是什麼…

• 現今的軟體佈署已經能作到讓自動化測試的腳本（scripts）在幾分鐘內驗證數以千計的情境（scenarios），接著在一天之內多次自動更新程式到正式環境中。工程師們也能將壓力測試自動化、模擬真實流量以找出效能瓶頸。雖然手動測試仍是不可替代的，但上述的自動化測試能提供一定程度的保證，讓開發者不會因增加新功能而損壞舊功能，或無意間重新導入已修正的 bug，進而增加修改軟體的信心跟速度。
• 撰寫各種層級的測試個案（單元、元件、整合），每一次 build 時都自動執行。瞭解你的 test coverage。
• 當然，build 跟 deploy 也要自動化，採用 CI 工具，或至少要用script。瞭解 build 跟 deploy 所需的時間。
• 定期對模擬環境執行壓力測試，依據真實流量跟預估的最大流量調整你的壓力

用可重複的流程處理安全及隱私議題（Manage security and privacy through reusable process）

專案開始時就要請隱私權、資安及法律支援專家確認資料如何收集、保護、使用及保留，通知使用者相關資訊的方式（包含資料收集時與萬一資料外洩後），使用者要求資料更正的管道，以技術面來說，確保服務安全的一個方式是廣泛地測試解決方案架構的各個層級，或採用已驗證過的元件，然後在打造不同服務時重複使用經過測試跟驗證過的元件。服務的佈署最好也腳本化，確保正式環境在資安及設定上的一致性。

這方面我沒什麼經驗，但我認為目前政府的數位服務在資安技術面沒有什麼大問題（雖然我親身經歷過廠商管理的主機中毒，並散播到全國各機關，但我們的反應還算即時），如果有問題的話是出在管理者與承辦人的資安素養。

讓資料說話（Use data to drive decisions）

我們提供的服務到底有沒有用？好不好用？讓客觀資料說話。在系統面要有即時監測的量化指標，在服務面也要提供使用者回饋的機制。

• 即時監測系統的使用情況，系統面的監測項目，例如軟硬體效能，回應時間，資料產出量（throughput），系統錯誤率等，確保我們能經由自動監測，量化目前系統的忙碌程度（ex. 50%, 95%, 98 %），並自動發出適當的警告；服務面的監測項目，例如同時在線人數，或使用者行為等，幫助我們了解服務是否滿足使用者需要。並對內及對外公佈我們採用的評量指標。

必須回答的關鍵問題例如：

• 你知道系統的預期及實際回應時間嗎？有多少 requests 的回應時間超過 1秒/2秒/4秒/8秒？
• 你知道系統前十名的交易（transaction）是什麼嗎？其平均回應時間為何？
• 系統每月正常服務的時間是多久？
• 系統掛點後你們的標準處理程序是什麼（當然不只是重開機）？

開放為原則，封閉為例外（Default to open）

政府資料的開放是近年常見的議題。政府蒐集的資料，本身很可能就與人民有關，且蒐集資料所需的成本也是來自人民的納稅，因此將資料開放是很合理的事。除了資料外，更可以考慮工具或流程的開放，讓公眾、非營利組織或任何有興趣的機構更容易取得、參與、回饋及重製，發揮開放的最大綜效。

• 提供機制讓使用者可以回報錯誤或議題，並迅速回應。
• 分類並維護資料清單，以批次下載或 API 的方式提供公眾完整的資料集（dataset）。如果可以的話，也開放政府服務的專案或工具原始碼、分享所使用的流程。
• 解決版權問題，包含資料集本身，及第三方介接資料後產製的衍生資料或軟體工具，都要能讓公眾無償使用。

這方面我沒什麼經驗，但我認為目前政府的數位服務在資安技術面沒有什麼大問題（雖然我親身經歷過廠商管理的主機中毒，並散播到全國各機關，但我們的反應還算即時），如果有問題的話是出在管理者與承辦人的資安素養。

讓資料說話（Use data to drive decisions）

我們提供的服務到底有沒有用？好不好用？讓客觀資料說話。在系統面要有即時監測的量化指標，在服務面也要提供使用者回饋的機制。

• 即時監測系統的使用情況，系統面的監測項目，例如軟硬體效能，回應時間，資料產出量（throughput），系統錯誤率等，確保我們能經由自動監測，量化目前系統的忙碌程度（ex. 50%, 95%, 98 %），並自動發出適當的警告；服務面的監測項目，例如同時在線人數，或使用者行為等，幫助我們了解服務是否滿足使用者需要。並對內及對外公佈我們採用的評量指標。

必須回答的關鍵問題例如：

• 你知道系統的預期及實際回應時間嗎？有多少 requests 的回應時間超過 1秒/2秒/4秒/8秒？
• 你知道系統前十名的交易（transaction）是什麼嗎？其平均回應時間為何？
• 系統每月正常服務的時間是多久？
• 系統掛點後你們的標準處理程序是什麼（當然不只是重開機）？

開放為原則，封閉為例外（Default to open）

政府資料的開放是近年常見的議題。政府蒐集的資料，本身很可能就與人民有關，且蒐集資料所需的成本也是來自人民的納稅，因此將資料開放是很合理的事。除了資料外，更可以考慮工具或流程的開放，讓公眾、非營利組織或任何有興趣的機構更容易取得、參與、回饋及重製，發揮開放的最大綜效。

• 提供機制讓使用者可以回報錯誤或議題，並迅速回應。
• 分類並維護資料清單，以批次下載或 API 的方式提供公眾完整的資料集（dataset）。如果可以的話，也開放政府服務的專案或工具原始碼、分享所使用的流程。
• 解決版權問題，包含資料集本身，及第三方介接資料後產製的衍生資料或軟體工具，都要能讓公眾無償使用。