Augustin Lu

盧建成(Augustin Lu)
CPHT (靖本行策有限公司) 創辦人、EXIN 台灣區業務拓展總監、台灣軟體工程學會 常務理事

鑽研軟體工程並且接軌實務經驗超過十五年,範圍涉及軟體設計、流程、雲計算、人工智慧,並且歷練新產品開發與交付、(跨國)團隊建立、企業營運等種種議題。對於融合工程與管理的力量,為企業轉型挹注能量充滿熱情。矢志成為知識與最佳實踐的媒介和促進者,和企業與技術相關從業人員成長的最佳夥伴。

鑽研軟體工程並且接軌實務經驗超過十五年,範圍涉及軟體設計、流程與人工智慧,並有相關譯作;

  • 《非監督式學習|使用 Python》
  • 《Python for DevOps|學習精準有效的自動化》;

EXIN 授權全系列認證講師;
鳳凰項目、挑戰埃及與火星任務 台灣唯一授權沙盤講師


出自 Augustin Lu

DevOps 實踐現況與回顧

DevOps 實踐現況與回顧

一些統計的數字… CloudBolt2 針對公司員工數大於 1000 人的組織進行了 DevOps 的現況調查,並且釋出了相關的統計數據3。DevOps 近幾年打得火熱,尤其在疫情期間對企業的自動化、流程改善、團隊運作起到了相當大的幫助。整份報告著重在自動化的調查,數字的確發人省思。以下為摘要: 只有 4% 企業認為自己在 CI/CD 的使用與實踐達到專家級別; 只有 5% 企業有能力單日數次發佈服務變更,然而 85% 企業發佈服務變更需要數天、數周或者更久; 只有 11% 企業認為自己的 CI/CD 流水線環境是可靠且受控; 有 88% 的企業表示正在考慮或已經使用 Terraform 作為基礎設施的發佈工具,然而卻只有 5% 的企業對於使用後感到滿意。 關於 Terraform 與 Infrastructure as Code Infrastructure as Code (基礎設施即程式碼) 的概念已經有 25 個年頭,而 2015 年 Terraform 甫一出現就吸引大家目光。

繼續閱讀
敏捷於疫情下對組織的助益

敏捷於疫情下對組織的助益

敏捷在疫情中,為企業帶來了什麼實質的影響? 從麥肯錫2的兩項調查統計來看 在客戶滿意度、員工參與度、與營運績效來看,在同一企業內,敏捷程度較高的部門表現顯然優於敏捷程度較低的部門。 基於亞洲與歐洲電信運營商的組織應變速度來看,敏捷成熟度最高的組織較成熟度最低的組織有著近兩倍的差異。 不可諱言地在疫情前,轉變對於組織來說,並不必然是極為迫切的事情。因為市場變化雖然強勁,但壓迫力卻並非立即性地逼得企業喘不過氣來。疫情來臨時,交付管道的失效、聯繫方式的失效、工作空間的失效等等問題,讓供需兩方彼此交互增強對於變動的需求。敏捷基本上是想找尋一個系統性的方式來解決最終結果的不確定性。畢竟,商業環境唯一不變的真理就是改變。 從疫情中過渡到後疫情 對於組織來說,什麼才是所謂「系統性」的方式? 這就得同時從團隊層級與企業層級兩個不同層級來探討,畢竟敏捷並不是組織內某個單位的事情,而所謂的文化改變,也不可能忽略組織的營運與治理。但不管哪一個層級,以敏捷的角度來看有兩件事是重要的: 1. 貼近於現實的可調適能力; 2. 可視性。 透過看板、電子協作工具,以及基於上述工具的指標儀板,組織才能在霧濛濛的不確定性市場中具備視覺能力。有了這些視覺能力,組織才能夠以更為全面的視角,客觀地衡量現況,進而調整自己的步伐。具備了這項基礎的能力後,才能讓調整步伐的能力有效展現。這就會回到了「如何實際地讓自己具有貼近於現實的可調適能力」這件事上。具體作法不外乎是 企業層級能夠盡快響應市場變化,調整方針與重要項目;團隊層級能夠基於這些改變的方針與實際場景的差異,具體地進行微調,來達成目標。 為了能夠做到這些事情,企業必須要思考的不會是如何帶入別人成功的套路,而是要去反思當前的營運模式、流程與治理方法。 企業作為一個法人,正如同自然人一般。面對外部刺激的反應,可以從大腦下達指令,然後產生相關反應,也可以在一些「特定條件」下,「授權」各部位直接採取行動。不管是從大腦下達,抑或是特定條件下的授權行為,為了能夠更有效率且無誤地發生效果。需要的不只是應急措施,更重要的是能夠重複的「成功規則」。因此,在得益於敏捷的實務作法,而在此次疫情中獲益的組織,在疫情之後,應該要去思考的是: 1. 疫情中採取了哪些應該持續下去的改變,還有哪些問題並未被解決; 2. 匯整經驗,融入日常營運,並且強化與擴大這些經驗的成熟度與覆蓋度。 後記 敏捷不僅是一種方法,也是一種能力。面對疫情所帶來的紛亂,提升企業的敏捷能力,便是提升企業韌性的最好策略。 1. Photo by Elena Mozhvilo on Unsplash 2.

繼續閱讀
為你的自動化基礎設施拉上保險系列之四 - 主機弱點掃描

為你的自動化基礎設施拉上保險系列之四 - 主機弱點掃描

安全的運行環境對於雲端服務來說,是個重要的議題,而對於使用者來說更為重要。 因此,對實體或虛擬主機進行弱點檢查與監測,能為雲端服務提供一個安全的基礎,也能滿足組織對於資安的基本要求。然而,安全威脅多樣,且各式作業系統的組態設定又各有巧妙,要如何才能有效率地完成這個工作,對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定,主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作,它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時,應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查,也可能來自 OVAL 所識別的弱點測試。

繼續閱讀
讓安全為數位轉型護航

讓安全為數位轉型護航

COVID-19 的疫情進一步地加速了全球數位轉型的腳步,按微軟 CEO Satya Nadella 所述1「當前兩個月所獲得的數位轉型進展是過去需要兩年才能達到的成果」。數位轉型透過數位的力量為客戶帶來更好的使用經驗,提升企業競爭力的同時,也進一步地擴大了可被攻擊的接觸面積,根據 Ponemon2 的 2020 研究報告指出,受訪者中有 82% 表示其數位轉型項目至少經歷一次資料外洩的問題。另外,為了能夠更了解客戶,提供更完善的服務,資料的收集與應用更是當前商業競爭的重中之重,然而隨著日漸提升的資料隱私保護意識,與相關規範的建立與落實,資訊安全已然無法視為NICE TO HAVE的選項,而是MUST TO HAVE的因子。因此,在考慮數位轉型策略的同時,將安全納入考量,並且雙軌併行,才是當前企業所應該考量的作法。 鑑於此,筆者認為企業把資訊安全融入數位轉型中,有五個關鍵步驟! 1. 了解組織的資訊安全能力 唯有了解自身當前的狀況,才能知道與需求之間的落差! 在規劃數位轉型計畫的同時,誠實地面對組織當前實施安全的現況與能力,才能夠了解與期待之間的落差,並且建構可行的路徑。所謂可行的路徑,便是逐步地將安全工具、驗證能力、與安全文化逐步地與數位工具與商業服務進行融合。也只有透過一開始便考量安全,才能夠務實地將安全融入數位轉型的過程中。 數位轉型所涉及的層面包含了工具採用、文化和流程變更、與人才培養,過程必然對組織裡的每個人產生衝擊。如果將安全作為轉型成功後,才進一步加強的目標。可以想見的是安全將永遠會是拖慢並且減損轉型成果的障礙! 2. 將所屬產業的安全需求納入規劃 企業經營自然無法自外於當地法規對於所屬產業的要求,也無法無視消費者對於企業的期待。因此,數位轉型絕非暫緩合規要求的理由,相反的是一開始便將合規需要納入轉型中,才是事半功倍的最佳途徑。試想當組織內的成員好不容易適應新作法後,卻要立即地面對加入額外要素的作法變更。調適與落實所產生的成本將會是企業無法承受之重。 對於並無具體法規規範的產業來說,基於自動化工具所採用的安全規範與指引,將會是比較直覺且成本較低的選擇,比方說 NIST 與 OWASP。

繼續閱讀
數位時代的治理與管理方法 - VeriSM

數位時代的治理與管理方法 - VeriSM

隨著 COVID-19 疫情的發展,數位轉型不再是個猶豫與曖昧不清的選項。 當昔日可選項變成必選題時,企業不得不細細思量轉變所帶來的意義與價值,以便在市場、利害關係人、公司永續與競爭力之間取得平衡。綜觀這幾年台灣企業在數位轉型議題上多半圍繞在新技術與工具的採用,這樣直觀且具體的作法的確為企業帶來了短期且明顯的改變與效益,不過這樣的效益卻很難延續與擴大,甚至有時還會與企業原有制度和流程產生衝突。或許過往的小打小鬧,還能期待透過時間來找尋解套的方法,但在轉變的需求強勢叩門時,企業需要一個具備系統性的指引方法,來協助自身透過重新審視治理的方式來確保目標達成的同時,還能提供組織應變市場快速腳步的能力! 從資訊部門到全組織 大部分企業內的資訊部門所肩負的多半為企業內部系統,主要的工作在於除錯與維穩,因此資訊系統的管理著重於資訊部門內部… 「穀倉效應」在指出組織內部由於各自責付功能與利益的不同,而產生協同困難,價值流不效率的問題。我們可以在近似領域的不同職責單位 (如,同屬技術領域的維運、安全、開發等各單位) 觀察到這樣的現象,而在不同領域(如技術與商務單位)這樣的問題也就更為嚴重。得助於雲端運算,企業有機會採用數位的方式,更有效地為客戶提供服務。 但是,如果服務管理仍只限於資訊部門,那將會有怎樣的結果呢? 試著思考以下的問題: 1. 如果資料安全僅在資訊部門,資料安全真的安全嗎? 2. 心急如焚的顧客上線尋找協助,需要轉幾手才能安撫顧客,提高滿意度呢? 3. 資訊部門在採用大量開源工具時,如何確保智財與法務上的安全? 4. 當引入新的工具與技術,如何知道它為公司帶來哪些效益呢? 如何知道錢花在刀口上呢? 5. 如何確保上線的新服務,不僅能為公司帶來利潤,同時也符合當地政府的期待呢? ... 那麼,數位時代下的服務是什麼呢?

繼續閱讀
User Story Mapping

User Story Mapping

牆上掛著滿滿的待辦事項,大家你一言我一句地為團隊產品貢獻自己的想法與點子! 上述是當我們談起設計思維,甚至是敏捷時,頭腦中會浮現的景象。然而,當待辦事項在不同成員齊力產生出不同抽象程度的工作項目時,試問我們要如何有效地從中找出最重要的事情,並且準時地交付給客戶? User Story Mapping 是管理使用者故事的一種有效技巧,不僅能夠協助團隊逐步地構建產品的待辦項目,也能夠用來整理已經開始迷航的待辦項目黑洞。它具體有以下好處: 以使用者為出發點,透過使用者旅程逐步具體化使用者故事; 確保所有參與者圍繞在同一個產品目標與主題上; 具有全局觀的排序,產生可執行的釋出計畫; 簡單易懂的可視化待辦事項結構; 引起討論,促進協作。 環境與工具 便於走動與張貼的環境,可以善用團隊常用的戰情室; 白報紙數張(如果不夠大可以接在一起)或白板一個; 建議人數 <= 8 人/組; 白板筆 x 三種顏色 ; 便利貼一包 x 三種顏色; 計時器; 安全可開放討論的氛圍。 流程 步驟一:由召集者或者是產品管理者,說明此次的目標,並且確保所有參與者了解 (~ 10 分鐘): a.

繼續閱讀
為你的自動化基礎設施拉上保險系列之二

為你的自動化基礎設施拉上保險系列之二

Policy (政策) 政策! 是什麼東東 ? 提到政策,就會不小心想到治理、授權等等讓人頭皮發麻的詞。然而,政策在軟體服務中是相當常見的某種需求。簡單來說,軟體服務的政策是什麼呢? 一組管理軟體服務行為的規則。 舉凡,定義哪些是受信任的主機、使用者能夠存取哪些功能、網路路由、和服務可以部署到何處等,都能視為服務管理政策。所以當你試著實作 feature toggle、試著實作管理員和一般用戶等功能時,便已經涉及到服務政策的機制了。 傳統上的作法,工程師會在服務中實作相關的資料存取與檢查。先不論此類實作所耗費的額外運算資源,如果有多個團隊在實作多個服務,而都需要基於相同規則進行檢查時,要如何進行?如何能夠和服務管理政策管理者有更好的合作?落實管理政策與提供服務彼此之間如何不互相拉扯等待,而導致服務提供效率降低? 追根究柢,可以把問題濃縮成: 如何讓開發團隊專注在產品主功能開發,讓政策管理者能夠用一致的方法進行管理,而且兩者之間的更動不會輕易地影響對方? Open Policy Agent 為這個問題提供了一個新的解決方式! Open Policy Agent (OPA) Open Policy Agent(OPA, 讀音為 歐趴) 最初是由 Styra 所建立,後來貢獻到 CNCF。目前由 Styra、Google、Microsoft、和 VMWare 構成開源專案的主要貢獻者團隊,撰文的當下它也已經順利地從 CNCF 畢業了。OPA 實現了一個輕量的政策管理服務,因此可以作為服務的 sidecar 運行,也能作為獨立的政策管理服務運行於整體服務群內。軟體服務可以基於給定的資訊透過 RESTful API 的方式「查詢」相關政策的判斷結果。此舉成功地解耦了政策管理的相關實作,讓軟體服務可以專注於使用者功能,至於政策則可以透過一個獨立的服務來實現。政策的管理者與資源的提供者,可以透過統一的管理服務來更新相關政策,從而改變團隊的合作模式,並且可以更高效且一致地施行政策。

繼續閱讀
三個必須掌握的 MLOps 核心概念

三個必須掌握的 MLOps 核心概念

是否正在煩惱如何更有效地促進資料科學家、軟體工程師、和維運工程師之間的合作? 是否苦於找尋如何穩定地研發與交付機器學習模型服務? 是否正在找尋如何持續維持機器學習模型服務效能的方式? 如果曾經為以上的問題煩惱,或者是希望持續提升團隊交付機器學習服務的能力,那麼 MLOps 肯定是你不會錯過的議題。 機器學習模型並非是交付機器學習服務中 唯一 的工作,由上圖1,可以了解模型本身只不過佔據了實現模型服務的眾多任務中的一小部分而已。機器學習模型服務的開發,不僅僅涉及如何實現模型,還含括了軟體開發與後續維運的議題,因此相較於常見的軟體服務開發來說,複雜度更高也更容易產生技術債務的累積。MLOps 是希望能夠透過 DevOps 的優良實務作法來提升模型服務交付的水準,並且降低或免於技術債務的累積。DevOps 所提倡的持續整合與交付和溝通與協作,也讓習於沉浸在資料與模型實驗的資料科學家們有機會以全局的角度看待服務交付的議題,並且讓整個價值流上的其他人員可以更有效地與資料科學家們合作註2 三個核心概念 1. 版本控制不只侷限於程式碼 版本控制的基本目的是為變更建立可追蹤性,以便作為之後除錯與改善的基礎。 程式開發者透過 Git 之類的工具,為程式實作進行版本控制可能是相當直覺的作法,而這樣的作法,對於資料科學家或者是模型工程師來說,應該也不是太陌生的操作。透過對程式碼進行版本控制,可以妥善管理模型與資料處理的相關實作內容。但對於一個機器學習專案來說,只是管理程式碼實作則是遠遠不足的! :thinking: 試著想像一下機器學習專案可能會遭遇的場景! 首先,用來建立模型的資料會隨著時間的推移與相關的系統操作而持續發生變動。另外,在進行模型開發過程中,也會對資料進行處理與篩選,這些過程都會影響當下模型的實作與訓練結果(如精確率、召回率等)。為了能夠提供之後改善的基礎,以及提供模型建立的可再現性,環繞於模型建立的相關資訊都應該進行版本控制,當然也必須包含訓練完畢的模型本身。

繼續閱讀
為你的自動化基礎設施拉上保險系列之一

為你的自動化基礎設施拉上保險系列之一

作為基礎設施的編撰工具,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.

繼續閱讀
全面轉向 CentOS Stream,憤怒了嗎?

全面轉向 CentOS Stream,憤怒了嗎?

去年底公佈 CentOS Stream 來替代 CentOS1,也就是說原先的 CentOS 的發佈版本終於迎來它的終焉之時。 簡言之,CentOS 原先作為 RHEL 釋出後的開源版本,如今將重新定位在 Fedora 與 RHEL 釋出之間,成為 RHEL 釋出前的版本,也因為這樣的位置重置,讓原先 CentOS 的用戶立馬就吵翻了天。 不開心! 為何? 先不論是否背叛了開源社群,或者是因為誰而促使這樣的狀況發生。造成這樣的不適感,筆者認為最大的原因有二: 已如理所當然的長期免費資源,如今不再這樣可口。 除 CentOS 6 與 CentOS 7 仍按照原先生命週期外,CentOS 8 並不會按照原先預期的約定,直接改止於 2021 年底。這讓已經投入 CentOS 8 轉換且以此展開產品發展計劃的個人或企業,直接面對這突如其來的變化,反應可想而知不會太好。 關於第二點,雖說按目前軟體發展的模式,尤其紅帽這類大型公司,在持續測試整合上的能力已經相當成熟,不管是相容性與主次版本的相關測試案例,應該都能提供對應的保障,但是一聽到是先於企業版本的發展版本時,誰又願意進一步嘗試或者是相信呢?CentOS Stream 並非突然在 2020 拔地而出,而是在 2019 年時便已經問世,開源使用者固然有關注的義務,然而突如其然的轉換聲明,使用者溝通上顯然不足。不過說到此處,基於第一點,說實在很難找到兩全的方法。或許紅帽能為一些先於RHEL釋出的新功能,提供一些開關,讓使用者對於過新的變化至少有個簡便濾除能力。

繼續閱讀
數位轉型案例探討系列之一

數位轉型案例探討系列之一

General Electric (奇異公司,以下會統一使用GE2來稱呼) 為一個跨國且跨不同產業領域的產業巨擘,2008 年,在 Jeff Immelt3 的支持下開始了轉型之旅,期間各種閃耀的成果與報導不斷,是討論轉型時不能錯過的案例,尤其在討論仍處於熱潮的工業 4.0 時,更應該看看他們的歷程與故事。或許屬於 GE 的最終烏托邦尚未浮現,然而它們的故事仍會繼續,並且探索新的價值。 紀事 2013 年, GE 開始使用自家所打造的工業物聯資料分析平台,Predix,來分析運行於實際場域的機器。 2014 年, GE 聲稱透過 Predix 平台實現了超過 10 億美元利潤4,並且在同年,Jeff 於推特上的一則發文,開始了它們更加積極的數位轉型之旅。 "If you went to bed last night as an industrial company you're going to wake up a software & analytics company.

繼續閱讀
我可能不會需要微服務?!

我可能不會需要微服務?!

微服務所帶來的彈性,以及它與CI/CD,與敏捷等所帶來的效率,讓你心動不已嗎? 微服務和容器、CI/CD、Kubernetes、敏捷等概念有著互相增強彼此所帶來效益的能力。這幾年伴隨著各類技術的發展,台灣自然也沒少了這股熱潮,而這樣的趨勢仍然還在沸騰中。身為一個技術工作者,或許早已看不慣公司裡陳年的大系統,正想一展長才,響應潮流,而管理者或許因為數位轉型與創新的壓力,開始希望從這熱潮中,找尋成功的方程式。 微服務並不是去年才出來的概念,而自家的系統也不是今天才開始運行。先想想「值得嗎?」 微服務是首要之務嗎? 重構系統將其微服務化是一件極大的工程。相信大家對於微服務所帶來的好處朗朗上口,然而分散式系統的管理複雜度和資源的額外開支,在朗朗上口之餘,也必須認真對待。另外,在過程中可能帶來的業務穩定性衝擊與業務發展資源不足的問題。更重要的是,它所帶來的效益不見得如你所想像的!這幾年穿梭在各類系統架構中,常常必須苦惱不已地進行抉擇,分享幾個思考點,或許能夠在大家踏上旅程前,先想想是否已經可以無悔走上重構: 原先系統的狀態 向原先系統磨刀霍霍之前,先想想「目前原先系統修改的需求高,修改頻繁的發生嗎?」、「大多數新的實作是否仍然增加在原先系統,還是其他服務裡?」如果,原先系統已經處在維護狀態,或者是新的實作大都與原先系統無關,那麼或許更重要的是在流程或其他面向上的優化。 系統已經可預期或已出現容量瓶頸 原先的設計已經限制住系統本身處理當前或者是未來的使用量。如果時常進行尖峰調度,而且調度應變困難,抑或者調度也很難再處理使用量的增長。那麼首要之務,找出瓶頸的服務接口與對應功能類別。作為之後,首要改善之所。 工程資源 任何的改善變更都需要人。如果工程人員已經吃緊,而又另外增加重構改善等任務,那麼下場很可能是不減反增的技術債、業務進展發生開發瓶頸、與惡化的勞動條件。人永遠不是資源,而是企業成長的夥伴!持續性地超支所衍生的代價,恐怕會降低重構的成功機率,以及削減重構所帶來的效益。 原始設計是否良善 單體式(Monolith)架構其實也沒什麼罪惡。如果原始設計已經維持著良好結構,也能正確體現低耦合與高凝聚等特性。那麼它的後續維護其實不見得比較難。難以維護往往是因為求快的實作,導致軟體內部設計耦合度過高,牽一髮動全身,發生問題還無處找之類的狀況。因此,不管在任何時候都好好設計軟體,會讓自己後顧之憂少許多。一個隨便實作的微服務,其實也沒比良善實作單體服務高明到哪?更甚而是不僅要面對可怕的設計外,還要負擔分散式管理的複雜,恐怕問題只是雪上加霜。 如果面對一個既有系統時,已經發生容量問題,設計又差,時常又要新增功能,往往耗損在應對,而非新發展,那麼或許重構是幾乎是你首選了,盤點一下人力狀況和工作配比,為自己重構之路爭取一些支援,反而是你現在該煩惱的,而非是要重構或不重構了。 然而,世事總是讓人陷入兩難,大多數情況都是有點糟,但不是太糟,那麼?

繼續閱讀
數位轉型對於企業價值的改變與衝擊

數位轉型對於企業價值的改變與衝擊

追求獲利與永續是企業的基本訴求,而數位轉型則是企業希望能夠達成訴求的手段。如果將數位轉型比喻成一支箭,那麼箭頭代表著解決客戶需求的產品、服務、與解決方案,而企業的技術、工具、與能力則代表著箭桿,至於箭羽則是價值、信念、與原則! 箭桿是箭的主要組成,它的各種特質(撓度、長度等)影響著與弓的適配和行徑,左右了搭弓和飛行,然而缺乏對於目標的理解,搭配錯誤的箭頭,則會降低箭的破壞力。正如數位轉型,目標的確立是一切的開始,這樣才能使用正確的箭頭,正中客戶的口味,實現客戶價值。技術、工具、以及組織各項能力,相對於客戶來說,則如同箭桿一樣,具有各種特質,卻是單一而統整的存在。它構成箭的基礎,需要的是各項特質恰到好處的配合。 不要在鋪陳了!到底什麼時候要講箭羽? 還有轉型最愛提的組織文化呢? 箭羽的最主要功能是 — 為飛行的箭提供穩定度。風為箭的飛行增加了不確定性,影響箭是否能夠準確地射中目標,而箭羽能夠透過重量與羽毛(或類似羽毛的構造),在多變的風中,穩定箭的飛行,而對比到企業,則與企業的核心價值、信念、與原則所帶來的功能一致。 轉型 vs. 組織文化 討論數位轉型時,不免會提到「端到端的價值」。這邊的價值更準確地說是客戶價值,然而能夠 正確且有效地 傳遞客戶價值,靠的則是企業的核心價值。核心價值說來抽象,讓我們換個角度,試著用問句來思考一下! "這個產品的主要解決了什麼問題?" "這個產品與其他產品的差異是什麼?重點是什麼?" 我想上面的問題應該一點也不陌生,它的核心議題是目標、願景、解決的問題等。讓我們再想想其他的問句… "哪些要素持續激勵著目標的達成?" "哪些事情讓我們更容易成功?" "有哪些考量,是交付時不能夠妥協的?" 這些問題所勾勒的價值,便是企業的核心價值。因此,除了「客戶價值」之外,核心價值則扮演著穩定的要素。說到這邊,不免惹人疑問的是,核心價值高高掛,但可能說比做更好聽… 「信念」根據維基百科的解釋2 — 信念是反應個人見識正確與否的思想意識。相比於核心價值,信念是關於人根據過往經驗對於現況環境的假設,它更多是反應感性方面與經驗的累積。 抽象而顯性的價值與具體卻難以清楚解釋的信念,構成企業內做事的原則,而原則左右著做事的方式。 文化是透過組織成員基於組織內成文與不成文原則下,通過行為而具體可見(註3)。 文化很抽象,但透過拆解,可以由核心價值、信念、與原則來更進一步地了解它。回到轉型議題上,當討論轉型,不免立馬想到一些最佳實踐,比方說 SCRUM、SAFe 等。這些實踐都很好,不過更多時候應該作為發想的起點與參考,而不是單純的照單全收。因為實踐最直接的對應是「做事的方式」,具體的作法或許能夠帶來顯著的變化,然而卻會讓「實踐者」忽略了這些實踐背後所體現的價值與信念。當改變後「做事的方式」與原來的「價值和信念」發生不一致時,轉型成果則更傾向曇花一現,甚至是失敗作收。

繼續閱讀
數位轉型的四個軸向

數位轉型的四個軸向

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

繼續閱讀
擁抱人工智慧!But how?

擁抱人工智慧!But how?

人工智慧對數位轉型產生莫大衝擊以及推力。我想很少人會對這句話產生質疑… 人工智慧在圍棋上打敗人類後,想像空間與可能性便在不同領域持續發酵,彷彿電影內的情節就要活脫脫地呈現在日常生活中。根據市場的調查與推估,以亞太區為範圍的市場規模1 (含括硬體、軟體與服務) 就高達 624 億美元!這樣的趨勢仍以類似指數的曲線往上增長,預期 2027 年的亞太區規模將來到 7337 億美元。不管從個人發展或者從企業發展來看,這是多麼夢幻的成長空間呀!但不管多麼的夢幻,以實際的角度來看,更重要的是 — 你是否在這夢幻樂園內,並且實際從中獲得好處了嗎? 預測與落地 按 Gartner2 所做出的預測,到 2022 年,只有 20% 左右的資料專案產生實際商業價值,而八成失敗的人工智慧專案有 96%3 的原因來自於資料品質、標記、模型建置。另外,再從 VentureBeat AI4 進一步可以發現 87% 所謂資料科學專案並未走進最後的正式環境,投入使用。

繼續閱讀
自動化建置靜態網站基礎設施之二

自動化建置靜態網站基礎設施之二

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

繼續閱讀
Lean Coffee

Lean Coffee

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

繼續閱讀
最小可行治理 (MVG, Minimum Viable Governance)

最小可行治理 (MVG, Minimum Viable Governance)

一聽到治理(Governance),大多數的第一反應肯定是流程、簽核、惱人等待與時程拖延等那些讓人提不起勁的事兒,但偏偏這些要求都是來自天上避也避不了,只能無奈含著淚,進行著說不上認同的流程:vomiting_face: 組織在面對治理的時候,常會陷入頭痛醫頭腳痛醫腳的狀況,在遭遇外部事件或內部事件後,就逐漸增加治理活動,先不論員工是否喜歡,對組織最大的影響就是價值交付的能力,而這也是組織競爭力的基礎。治理是企業內進行任何活動都無法免去的要素,畢竟它確保著組織的願景與目標,但如何有效地運用治理達成企業目標,同時又能讓創新與響應變化保持彈性,而不是迎頭痛擊成長的機會呢?考慮一下最小可行治理 (MVG, Minimum Viable Governance),相信這個概念一定能為您帶來啟發與裨益。 首先! 什麼是好的治理呢? 好的治理就是讓公司內的生產活動(包括專案、產品等)能夠在組織應允的人力、物力等資源情況下,被成功的交付,達成預期的設定。治理的目標是保證公司利害關係人的權益,確保組織有效地利用資源,達成所設定的願景與策略。治理活動通常是由公司內的XX委員會或PMO等團體進行,而主要的管理點則由公司內的高管們來進行授權,以便讓整個治理能實質落地。另外,治理相關的資訊都應該被充分地描述與解釋,並且文件化,以便讓員工取得一致的共識。 因此,在考慮治理又希望能夠降低治理成本時,應該要思考的是 — 所進行的產品與專案需要滿足組織相關利害關係人哪些需求,而這些需求又重要到讓您深刻地銘記在心,值得日以繼夜地為它苦惱! 以下條列一些思考治理時的一些關鍵要素。 治理的關鍵要素 1. 願景一致 這邊的所謂願景一致,有幾個面向。 第一個面向,產品與專案的主要負責人,需要確保產品與專案的願景與公司原本的治理目標相符,並且能夠循著被預期的治理活動進行,進一步讓所有利害關係人買單。 第二個面向,願景如何落到團隊中每個成員上時,而且是否體現結果上的一致。 第三個面向,更高階的管理人員由於能觀察到公司內所有的生產活動,因此必須確保所有專案與產品與公司策略方向一致。這邊的重點是方向上的指引與關注,但並不是進行微管理!因為其結果一方面會降低團隊的自主性,另一方面則會讓整體生產活動效率低落。組織內不同角色有不同的關注要項,多給組織內的專才一些信任,往往好處會大於專案失敗或遲延所帶來的懲罰。 2. 理解不確定性 大部分的組織對於預算的審定與安排大多按年,或者是按專案初期規劃,一次性的配置預算。根據 2019 Gartner Research,有 89% 的專案是採用傳統的預算編列方式,但根據 PMI Research,2019 年的專案中,也僅有 20% 的專案真的在錢與時間上準確。實務上,不管是因為怎樣的理由,我們很難看見因為採用敏捷,在專案上的預算編列就有所調適,最終您仍要落到鉅細靡遺的前期計畫,然後期待一切都對。

繼續閱讀
自動化建置靜態網站基礎設施之一

自動化建置靜態網站基礎設施之一

對於形象與分享用途的網站來說,靜態網站可以說是首選。各大公雲都有對應的支持做法和文件。Pulumi 作為基礎設施即程式碼工具的新秀,相關範例與分享還是比較少,但 Pulumi 所提供的一般程式開發體驗,卻是讓我無法捨棄它。目前所瀏覽的網站建置也是基於 Pulumi 完成並且進行管理的。鑒於目前網路上的資源稀缺,身為知識愛好者的我來說,當然要毫不猶豫地將這過程分享出來!:triumph: **在開始之前 擁有一個 GCP 的帳號,更重要的是,它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK,並且確認已經設定好 application-default Python 為 3.x <== 這非常重要!! 準備好 DNS (本網站是使用Google Domain) 架構說明 如同此篇文章的開頭圖片一般,整體結構極為簡潔。就是在 Google Cloud Storage 前,設定導流規則的負載均衡器,並且搭配 CDN。如此一來,一方面可以直接選擇使用 us-west1、us-central1、或 us-east1 的免費額度,也能兼顧用戶從不同地區存取網站的速度。 開始著手實作 Pulumi 程式 1.

繼續閱讀