敏捷與DevOps

作為基礎設施的編撰工具，Pulumi 額外提供了基於屬性測試 (Property testing) 概念的 Policy as Code 工具 (“CrossGuard”)。基於這個工具，專案團隊或者是組織可以為所有採用 Pulumi 所撰寫的基礎設施程式，建立獨立於所有 IaC 專案的普遍規則 (比方說資源區域、數量、網路設定、IAM 等)，團隊亦可基於此再添加關於專案的額外限制。透過建立完成的可測試規則，開發者可以在本地端、持續整合流水線、以及在最後佈署前(已經產生基於各公雲或基礎設施服務的組態檔時)進行測試確認，避免需要透過人工檢閱比對，或者是已經佈署完畢後再進行確效，所產生的人力或資源的浪費。 本篇文章作為 Policy as Code 系列文章的起頭，會採用 Python 建立一個簡單的 Policy as Code 專案，為稍後建立基礎設施全面性的規則作暖身。 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.

轉型就是一種營運模式的變動，單以組織內的任一職能單位來推動與進行轉變，其結果往往不如預期。 Agile 與 DevOps 這兩個在轉型鎂光燈下的寵兒，仍繼續在世界舞台上發光發熱，看著大型科技服務公司們的成功與新興的服務公司竄起，這些都成了追逐改變的主要驅力，大家都希望能夠在下個十年仍然持續茁壯。但當大家提及 Agile 與 DevOps 時，第一印象常是技術單位(比方說 IT)，貌似只要這些單位有了這些能力就會飛翔，或者是只有這些單位有能力推動相對應的改變。這些改變都是以技術單位為中心然後展開。但最終其結果呢？或許有了些新的工具、或許有了些新的名詞，但所謂的振翅高飛卻還需要些時日，大家都苦於找尋那轉型的聖杯。以我個人來看，聖杯是迷幻的，然而轉型的確有較好的方式與工具來協助提高成功的機會。 以價值驅動的服務 這幾年由於各種技術的躍進，服務越來越能以貼近每位使用者的方式來提供，然而這樣的交互模式，進一步的提高使用者對於服務取得的期待。除了服務本身，企業內的各個單位(比方說銷售、客服等)也必須能夠有相匹配的反應速度，讓使用者被提供的服務環繞著，並且取得確切的成果。上述所提及的就是最耳熟能詳的 端到端 的價值，而剛好 Agile 與 DevOps 的核心都在確保價值的產出。 那這些為什麼就獨厚了技術部門呢？ 其實也不盡然獨厚了技術部門！反倒是說，錯誤地獨厚了技術部門，才是讓所有轉型展開發生困頓的主因。 技術部門坐落於生產和後續服務維護的位置，也就說它們的產出與使用者的需求直接掛鉤，由於這幾年響應速度變快的原因，使得原本透過銷售與客服的隔熱服務，穩定產出服務的技術部門，反而必須更勇敢地向前一步與使用者互動。在此，必須意識到的是，由於數位思維的發展，公司內的營運與技術之間的融合，顯然技術部門很難自身於外，因此不管是做事的心態也好、或擔負的責任也好，都將技術部門推向 轉型漩渦的中心 。處於中心只不過是個客觀的事實(或許)，而漩渦所覆蓋的範圍才是轉型的全部！

在自動化建置靜態網站基礎設施之一中，我們介紹了如何全面使用 Google 來打造靜態網站的基礎設施，但以一個單純作為靜態網站來說，起初的用戶量與使用情節必然是不太複雜，但全面使用 GCP 的解決方案也就代表了採用負載均衡與 CDN 等相關服務元件，而採用這些元件由於服務水準匹配的原因，也很難降低相關元件(e.g. 負載均衡)的等級，因此，即便流量再小，也必須支付一個月約莫 2x 美元的費用。因此，本文章將介紹利用 Cloudflare 來取代 GCP 的負載均衡與 CDN 相關服務，由於 Cloudflare 有提供免費級別的用量，這對於單純的初期靜態網站來說，應該十分夠用了！接下來，我們就來看看如何用 GCP + Cloudflare，並且基於 Pulumi 打造一個零元的靜態網站基礎設施吧！ 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.

議程總是與會議內容不符？ 會議冗長，重要的卻沒談到？ 參加的人很多，意見卻少的可憐？ 開到意識脫離？ Lean Coffee 是由 Jim Benson 和 Jeremy Lightsmith 所發想，而發想後的最初實踐空間的確就在一間咖啡廳內！Lean Coffee 的議程安排是由參與者所共同決定，所以會議前，相關議題並不明確，但唯一明確的是聚集在一起的人，有共同的目標與興趣，也具備此目標下的相關討論背景知識。雖說議題是由會議進行過程決定，但議程的推進過程卻十足具有結構，並且能有效地針對提出的議題，產生結論與後續行動。 整個開會的基礎概念是基於敏捷、看板與 Lean ，並且以人為優先來考量整個會議的安排，民主式地抉擇討論，並且提高參與感和個人的貢獻，以便形塑真實的共識。 環境與工具 便於走動與張貼的環境，可以善用團隊常用的戰情室； 白報紙一張或白板一個； 建議人數 <= 10 人/組； 白板筆 x 三種顏色 ； 便利貼一包 x 兩種顏色； 點點貼紙 >= 30 點/組； 計時器； 安全可開放討論的氛圍。 流程 利用 3 ~ 5 分鐘的時間，讓參與者透過腦力激盪將感興趣的議題寫在便條紙上； 輪流到白板前，用一至兩句簡短的描述自己的主題； 將相同或者相似的主題進行整合； 一人三點進行議題投票； 將看板 (e.