周小川兩難:放棄失調改革政策/有違市場的匯率/失效的量寬?

周小川兩難:放棄失調改革政策/有違市場的匯率/失效的量寬?
Photo Credit: David Dennis @Flickr CC BY SA 2.0

我們想讓你知道的是

文: 鄭子健(九十後香港人)

張五常教授的警告

7年前,張五常教授於《信報》專欄大聲疾呼,力排眾議,反對人民幣兌美元升值。(相關文章已刊輯於《多難登臨錄:金融危機與中國前景》)

教授深入淺出,闡述其小眾惹火的看法:中國雖為經濟大國,但支柱產業仍為低端製造業,主打來料加工和勞動密集型生產,還未談得上與歐美日等高科技強國爭一日長短;中國的競爭對手實際是發展中國家,與之比拼廉價勞動力和生產成本,爭奪出口市場。

這些競爭對手的貨幣皆與美元掛鉤,一般而言,其幣值隨美元上落。假如人民幣兌美元升值,會連帶兌整個美元系統升值,失卻對發展中國家的貿易優勢,拱手相讓出口市場,本地製造業流失倒閉,失業工人「返鄉下耕田」。

為甚麼中國會願意自斷一臂,容許人民幣單方面升值呢?

大家應該耳熟能詳,改革開放要轉向,由出口主導改為內需支撐,貨幣升值有助提升民間購買力,人民樂意消費多一點,增強內需。更為要者,政府想騰籠換鳥,踢走低增值製造業,換置高增值科技產業,藉此撈取更高國民收入。匯價升值既擠走勞動密集型工廠,又幫助新興產業購置機器及借取外債,迅速打穩陣腳,生產高端產品,脫離惡鬥低成本、低價格的出口市場。為此政府還祭出一系列新法例,以保障員工收入增長和規管環境污染為名,順便推高生產成本,吞掉工廠僅餘利潤,迫不及待要殺鳥取籠。

有形之手自信過度,用力不均

對於此等政策目標,張教授嗤之以鼻,偶而加一兩句「蠢到死」,始終認為政策走歪路,未見其利,先見其害。7年過去,人民幣兌美元升幅超過四分之一,升值效果之一大抵如教授所言:低端製造業抵不住成本急增,逃往越南、柬甫寨和菲律賓等東南亞國家,《福布斯》甚至大口誇言,中國的製造業生產成本已與美國不相上下。

與此同時,中國高科技發展確見苗頭,騰訊、小米、阿里巴巴等企業已是家傳戶曉,深圳和北京中關村亦成為中外公認的創科重鎮,即便是下游生產,「紅色供應鏈」也成功搶去日台韓的半導體訂單。可經濟增長卻是青黃不接,高科技產業要的是專業人才,生產程序自動化,用不著聘請血汗工人,結果舊一批勞動人口真的要「返鄉下耕田」,而受益於經濟轉型的新一代,其工資增長也未見得真能帶動內需,即使加上政府支出,本地消費仍只佔國民生產總值約一半。

中國政府用慣有形之手,是次自信過度,用力不均,破壞之手太猛,舊經濟土崩瓦解,但建設之手太弱,新經濟後勁不繼,經濟增長所以由高峰百分之10跌至守百分之7不保,經濟轉型寬猛失調乃主因之一。

人民幣不會出現「持續性貶值」?

時移世易,因整體經濟下行,人民銀行如今需要處理與日俱增的貶值壓力。

自去年11月起,人行有見整體債務達國民生產總值近3倍,通脹、製造業及貿易諸數據皆不利,於是實行寬鬆貨幣政策,3次降準,4次降息,務求增加貨幣供應,提振信貸流通,紓緩下行速度。細閱其資產負債表,顯示人行直接印鈔,注資銀行體系以換取債權,類近美國量化寬鬆之策。人民幣於市面供應持續上揚,其累積貶值壓力亦愈來愈大。

縱使人行多番放水,但藥效一次不如一次,中國經濟未見起色,人民幣需求難免疲弱乏力,市場亦萌生貶值預期,至近日股市崩盤,樓市不振,上月出口大減逾百分之8,製造業嚴重收縮,人民幣貶值壓力更為沉重;又美國加息周期開展在即,資金陸續流出新興市場,如馬來西亞令吉和印尼盾暴跌,至12年前金融風暴的低位。中國作為新興市場龍頭,逃不過去,今年第二季已有共值逾2000億美元資金外流,人行要穩住人民幣於目標匯價區間可不容易。

人行頂住供求雙重壓力近一年,直到兩星期前,才宣布下調人民幣兌美元中間價約百分之2,聲稱為配合當前貿易及經濟情況,強調中國不會打貨幣戰,人民幣不會出現「趨勢性貶值」。明明供求劣勢未變,貶值預期更形熾熱,人行仍可如此豪言壯語,皆因手上還有三萬七千億美元外匯儲備,要強行維持匯價一兩年並不成問題。

錯失自由匯兌的最佳時機

人行宣布貶值當日,同時落實匯制改革,兌換中間價會以商業機構收市報價為基數,預示人行將會逐步放棄直接定價。官方宣傳此舉為匯率「市場化」,且是邁向自由匯兌的一小步。

回想7年前,張教授反對人民幣升值,絕非掩起雙眼,無視當日人民幣升值壓力。他只認為若升值無可避免,實行自由兌換最為聰明。

此因其時歐美經濟實力衰頹,中國動蕩較小,經濟發展方興未艾,挾著長年貿易盈餘,人民幣升值潛力有目共睹,只待人民幣於國際市場自由流通,各國無懼停兌風險,便會爭相納人民幣為儲備貨幣,作為本國貨幣保值之錨,與美元分庭抗禮。屆時人民幣「國際化」水到渠成,匯率會隨各國雙邊貿易情況浮動,相對調節高低,毋須再盲目盯著美元走,硬著頭皮對各國貨幣一併升值,白白斷送自家出口市場和製造業。

過了7年,只能說最佳時機已過,低端製造業已大批撤離,亡羊補牢的效果成疑;人民幣走勢由強轉弱,保值吸引力已大減。人行一旦放手,全由市場主導匯價,人民幣更有插水式貶值之虞,長遠「國際化」效果未見,即時震撼卻足以加速資金外流,形成新一波貶值壓力,做成惡性循環以至經濟恐慌。

那麼由人行於市場間接操作,安排人民幣有序貶值,又如何呢?

人民幣貶值伊始,市場有乘勢拋售的現象,匯價繼續下調,此時人行當機立斷,立刻出手穩住匯價,此舉暗示中國政府還未放棄調控匯價之權,寧願消耗儲備,執意維持匯價於固定區間。大概中南海仍堅持「出口轉內需」和「產業升級」的國策,不願看到人民幣大幅貶值,民間購買力倒頭下跌,削弱消費和投資意欲,兼且令肩上共值一萬億美元外債百上加斤。

周小川兩難


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡