台達揭露淨零減碳心法，將內部科學減碳經驗輸出為顧問服務，瞄準企業低碳轉型需求

來源：https://www.ithome.com.tw/news/175776

在全球企業加速淨零轉型之際，台達電今天(5/13)分享其內部減碳推動經驗，以及如何將多年累積的淨零治理能力，轉化為對外的顧問與數位服務。

台達永續長周志宏表示，「節能」一直是該公司的企業經營核心。早在2005年台達便開始推動工廠節能，當時創辦人便要求工廠節能50%，「大家當時還不敢相信」，台達以2009年為減碳基準年，到2014年時達到5年間50%的減碳成果。

後續在巴黎協定之後，該公司進一步導入SBT（Science Based Targets，科學基礎減量目標）機制。周志宏回憶，當時他曾詢問，是否真的要承諾科學化減碳路徑，而得到的答案是，「既然答應了就要真正做到」。這成為後續十多年該公司持續推動淨零的重要起點。

2025年碳排已較基準年下降67.4%

周志宏指出，目前台達的減碳成果已超越原先SBT設定路徑。到2025年時，整體碳排已較基準年下降67.4%。

台達是如何做到的？周志宏透露該公司經由4種方式推進減碳，包括節能、自發自用再生能源、採購再生電力，以及內部技術創新。其中，再生能源與再生電力是減碳效果最大的2項措施。

在再生能源使用上，台達自2021年開始推動RE100，至2025年再生電力使用率已達91%。

除了常見的購買綠電之外，台達透過更高難度的即時綠電匹配，以克服使用再生電力的障礙。他指出，以臺灣現行「15分鐘匹配制度」，難度甚至高於多數國家使用的每小時匹配制度。

為了因應這項制度，台達自行開發再生電力匹配系統，整合發電端、用電端與轉供資訊，進行綠電匹配與最佳化調度。

透過內部碳費機制驅動減碳投資

除了從技術與能源管理著手，該公司也在內部建立碳費制度，每噸碳定價300美元，設立減碳基金，以提高各部門減碳的誘因。

周志宏指出，台達過去4年已成立89個COS Center，建立可編列預算與追蹤績效的減碳管理機制，並透過內部碳費基金投入減碳專案。台達累積投入約7,250萬美元內部碳費基金，用來支持各單位推動節能改善、再生能源與減碳專案，共減少37.6萬噸碳排量。

台達希望透過內部碳定價機制，讓各事業單位理解，現在投入減碳的成本，其實低於未來面對碳費或碳稅的代價，因此更願意提前投資節能與再生能源。台達內部碳費制度的重要精神是，讓事業單位願意投資節能與再生能源。

他以內部高耗能事業單位為例指出，該單位自2021年至2025年間，投入4,500萬美元進行節能與再生能源改善後，碳排下降85%，碳費也減少近7成。

在種種策略推動下，台達從2018年開始，碳排放量與公司營收脫鉤，隨著營收向上成長，碳排量逐年減少。

台達開始將ESG能力轉化為對外服務

在建立自身減碳治理模式後，台達也開始將相關能力商品化。

台達ESG整合策劃辦公室資深處長李立仁表示，2023年底台達內部重新檢視永續策略，認為ESG不應只停留在法規遵循與評比，可以轉化為真正的商業價值。

「ESG它要能夠體現成能實踐的商業價值，成為台達一個商業差異化的競爭力」，李立仁說。

因此，台達進一步成立永續顧問與服務團隊，聚焦3大主軸，包括顧問服務、永續數位平臺，以及綠色工廠、智慧建築、微電網與再生能源等淨零解決方案。

將SBT治理經驗轉化為顧問服務

李立仁指出，目前許多企業面臨兩種情況，一是尚未導入科學減碳，但已被供應鏈要求；另一種則是雖然已提出SBT承諾，但實際減碳成果與設定的目標脫鉤，實際效果不如預期。

李立仁表示，台達推動SBT過程中，非常重視治理機制與跨部門管理，包括透過委員會制度，將KPI與責任分配到各事業群、區域與營運單位，並由中央平臺進行追蹤。

此外，企業在推動減碳時，往往會面臨營收與產能壓力，因此缺乏投入誘因。李立仁指出，因此台達透過顧問服務，來協助企業設計「內部碳定價」與碳基金制度。

建立AI能源管理與綠電匹配平臺

除了顧問服務外，台達也將多年累積的能源管理能力發展成數位平臺。

李立仁指出，台達目前已建立全球能源管理平臺，除了追蹤各據點KPI與碳排，也能管理節能專案執行情況，並分析能耗異常。

他表示，台達已累積超過1,000個節能專案經驗，現在開始把專家知識轉化為AI Agent與專家系統，用於節能分析與報告生成。

在綠電管理方面，透過即時綠電匹配平臺，協助企業分析用電特性與綠電配比，降低RE100推動成本。

李立仁指出，隨著未來ISO-GHG與電力時間標籤制度逐步導入，「24/7」即時綠電匹配能力，將成為企業淨零的重要基礎能力。

台達能源事業開發的綠電即時匹配平臺，透過用電歷史分析、發電特性分析、配比最佳化等方式，協助企業以較低總成本達成RE100。

'

Obsidian更新社群外掛審核流程，導入逐版自動檢查與安全評分卡

來源：https://www.ithome.com.tw/news/175773

知識工作者愛用Markdown筆記工具Obsidian推出新的社群網站與開發者儀表板，調整社群外掛與主題的提交、審核和搜尋流程。本次改版重點，是把過去較依賴人工處理的審核方式，改為每個版本都會接受自動檢查，並在專案頁面加入安全評分卡，讓使用者在安裝前能先查看自動檢查結果與專案狀態。

Obsidian是一款採本地優先、Markdown檔案格式的筆記工具，因外掛生態活躍，深受開發者與知識工作者喜愛。官方表示，自2020年開放應用程式介面以來，社群已建立超過4,000個外掛與主題，外掛累計下載量也超過1.2億次。

外掛數量增加後，原本由小團隊人工審核初次提交的流程逐漸難以負荷。過去外掛第一次進入官方目錄時會經過人工檢查，但後續版本並不會逐版審查。Obsidian表示，現在人工智慧輔助程式開發工具讓外掛產生速度更快，提交數量也跟著增加，因此需要一套能持續運作、也能處理大量提交項目的新流程。

新的自動審核系統會檢查外掛與主題是否符合開發者政策，並檢查程式碼品質、已知安全弱點和可能的惡意程式。人工審核不會取消，但會轉向較需要深入檢查的項目，例如下載量較高的外掛、精選外掛，以及社群回報有問題的項目。

在使用者端，新的社群網站提供分類、搜尋、篩選和排序功能。每個專案頁面會顯示截圖、功能說明與安全評分卡。Obsidian也預告，未來外掛頁面會進一步揭露外掛是否會存取網路、檔案系統或剪貼簿等能力，並加入隱私標籤、已驗證作者標籤，以及人工審核結果等資訊。

這次改版也處理了過去累積的提交項目，Obsidian表示，既有外掛、主題和排隊中的提交項目，已搬到新的社群網站，開發者可登入新網站，連結GitHub帳號來認領專案。新系統已在數日內處理超過2,300個等待審核的提交項目，新專案通常可在數分鐘內看到審核結果，通過後會在24小時內出現在應用程式內，供使用者搜尋與下載。

'

AWS公布跨雲端資料遷移架構，以rclone worker叢集將PB級資料搬移至Amazon S3

來源：https://www.ithome.com.tw/news/175774

為了便利更多企業將資料從其他公有雲搬遷至AWS的環境，AWS在官方技術部落格介紹一套分散式跨雲端資料遷移架構，透過開源命令列資料同步與搬移工具rclone，搭配Amazon ECS、Amazon SQS、EC2 Auto Scaling與CloudWatch等AWS服務，因應PB等級資料跨雲端搬移時常見的進度追蹤、失敗重試，以及規模擴展的挑戰。

AWS指出，當企業需要在不同雲端服務供應商之間搬移PB等級資料時，傳統單機或集中式資料傳輸方式，往往會遇到進度難以掌握、失敗後重啟流程繁瑣，以及需要頻繁人工介入等問題。若還需在遷移過程中加入自訂標籤或其他商業邏輯，也會拉長遷移時間，並增加資料漂移風險與成本。

這套跨雲端資料遷移架構主要分為探索層（Discovery Layer）、佇列層（Queueing Layer）與執行層（Execution Layer）。探索層以Amazon ECS搭配AWS Fargate執行，自動列舉來源儲存系統中的物件，並將檔案以每20個為一組而建立批次作業，再交由Amazon SQS佇列分派給後續worker處理。

在執行層，SQS會將每個批次作為獨立工作，分配給EC2上的rclone worker。AWS在這套架構中使用r5n.xlarge執行個體建立Auto Scaling群組，並根據SQS佇列中的待處理工作量，自動擴展或縮減worker規模。每臺執行個體可同時執行6個rclone處理程序，以提高網路頻寬利用率。

AWS表示，這套設計可透過SQS的可見性逾時（visibility timeout）與死信佇列（dead-letter queue）機制，讓暫時失敗的工作自動重新排入佇列處理；若工作兩次嘗試後仍失敗，則會送入死信佇列，方便後續追查，藉此減少人工介入與維運負擔。同時，透過CloudWatch Logs與自訂指標，也能追蹤檔案傳輸進度、失敗批次與傳輸時間等遷移情況。

在實際測試中，AWS以容量為2.7 PB的媒體歸檔資料集，從IBM Cloud Object Storage遷移至S3，整體worker叢集達到15～120 Gbps聚合吞吐量，Auto Scaling群組約在10分鐘內擴展至5臺EC2執行個體，整體遷移約兩週完成，運算成本約2,000美元。

AWS指出，由於架構採用相容S3 API的設計，因此除了IBM Cloud Object Storage，也可套用到Google Cloud Storage與Azure Blob Storage等服務。使用者只需調整端點設定，以及AWS Secrets Manager中的來源端憑證，不必重新部署整體架構。

此外，AWS也解釋，之所以選擇rclone，而非直接使用AWS SDK，主要原因在於rclone可提供跨S3相容儲存服務的統一命令列介面，避免為不同雲端供應商各自撰寫專屬SDK程式碼，降低多雲遷移時的程式開發與維護複雜度。

'