凶宅?人其實比凶宅更凶!

凶宅?人其實比凶宅更凶!
Photo Credit: eyeliam CC BY 2.0

我們想讓你知道的是

Photo Credit:  eyeliam  CC BY 2.0

Photo Credit: eyeliam CC BY 2.0

文:葉文忠

相信大家也都會跟我一樣,這些天來,想狠狠的往大眾銀行的玻璃門踹上去。但這人神共憤的事,豈止大眾一家銀行而已,這是銀行的行規,「日出東方,唯我不敗」,每家銀行遇到這樣的case,用法規條文對付弱勢,沒有一個會手軟。

事件始末,其實不複雜,單親媽媽莊明玉,用270萬標下大眾銀行申請法拍位於台南善化的房子,她把自己的所有積蓄45萬當保證金繳了,結果找大眾銀行申請房貸時,行員才告知房子是「凶宅」,拒絕貸款,莊明玉繳不出錢棄標,法院必須再拍,卻註記了「凶宅」。「凶宅」一現形,結果只拍了231萬,與莊明玉標價270萬差了39萬,直接掉了近一成五,按照規定必須從保證金裡扣除差額給大眾銀行,她積蓄瞬間剩下六萬。

莊明玉向六家銀行求貸,銀行竟「統一陣線」的都不貸,莊明玉轉向原申請法拍的大眾銀行求貸,大眾只說「凶宅不會放貸」,她從大眾台南、高雄分行,一路求到台北總行都被拒,求到幾乎下跪。

這件事有「詭」之處,在於大眾銀行申請法拍的房子,自己卻不願意貸款給得標者。大眾但求自己無損趕快脫手,他人死活不管,在莊明玉山窮水盡之時落井下石,如此的欺負社會弱勢,無恥至極。

新聞一出,金管會積極介入,大眾立刻表示「基於道義」退錢,被莊明玉以「若沒反省,不接受施捨」悍然拒絕,「我要的不是錢,是要一個公理正義!」莊明玉終生難忘行員的嘴臉,決心讓「大眾」對社會「加倍奉還」。

還記得嗎?大眾銀行近年常大打形象牌,幾支以台灣弱勢族群展現的不凡力量拍出的憾動人心的廣告,讓人激賞,「生命樹」、「母親的勇氣」還有那印象最深,改拍「不老騎士」紀錄片那支廣告,為了完成夢想,五個老人在人生盡頭前,要完成一次台灣環島的壯遊。

諷刺,太諷刺了!廣告的開頭「五個台灣人,平均年齡81歲」,廣告的結尾「人為什麼要活著?夢-不平凡的平凡大眾」,我們都曾經為這個廣告感動過。廣告用狗血美化夢想,但私下「斷了弱勢人的夢」大氣都不喘一下,這就是銀行業。今天,莊明玉置於死地而後生,那貨真價實,不平凡的平凡大眾,等同以血諫,摘了銀行界向來以「有情」包裹「無情」的面具。

我其實還滿竊喜(當然不是對莊明玉)的,終於可以好好教訓這些殺人不見血的銀行。事件爆出來後,隔天聯合報社論給了一個標:「99比0:銀行是否看見自己的冷血!」,這99指得是前一天彭淮南所說,銀行貸給頂新魏家買九戶帝寶99%的貸款,那種對有錢人卑躬屈膝的嘴臉,怎不讓人寒心與痛心!

從各家銀行拒絕,就知這兩案是「通案」非「個案」,這只是證明了金融界該整頓的不只是遊戲規則而已。銀行業最重要的生財路子便是「放款」與「拿別人的錢來投資」。放款,會審核還款能力,這無法置喙,所以越是弱勢越求助無門,但按理說,經濟能力越好的,越不需要借錢,自備款不是應該更高才合理嗎?為何這制度完全相反呢?今天我們該檢討的,是法規之外,該用什麼辦法讓這些只知算計利益,成天錢堆裡打滾的經營者,懂得憐憫,懂得他們自己正是把社會拉向M型兩端的凶刀。

銀行它總想辦法拉攏你來存錢,你繳個費,連櫃台的行員都會丟出基金投資或保險單來推銷,一個櫃員不夠,後頭的主管也湊上來繼續灌酒,想盡辦法挖出你的錢;另一方面,你也可能會接到銀行的電話,問你有沒有資金的需求?每家銀行都會強力推銷自己的信用卡,巴不得你辦越多越好,每張最好都用到循環利息。

行員們口沫橫飛,總說這投資案有多好,報酬率多高,但書是一定有風險,風險一定自付,銀行不會有半點責任。簽任何申請書或簽辦各類信用卡時總有個合約書,你會逐條細看那申請表格後方密密麻麻,小到必須用放大鏡看的合約內文嗎?如同煉丹術,這是他們經過多年的「修煉」出的條文,每個計較都在裡頭,讓這條文一個個綁到你天荒地老,只要出現任何紛爭,永遠是簽名的倒楣。

Photo Credit:  MiNe  CC BY 2.0

Photo Credit: MiNe CC BY 2.0

話題回到「凶宅」。「凶宅」的背後一定是個悲傷的故事,卻成房市的雷管,踩到就爆,這是民情與信仰使然。社會對「凶宅」的界定,屬於心理層次,只要屋子出過「不正常死亡」的事件,就可能有「怨靈」存在,所以「凶」。只要信仰存在,很難改變人對「幽冥世界」的恐懼,「凶宅」將永遠為惡,肯定加害入住的人。

這由文化衍伸出的民情很難改變,但此類無法鑑定的「瑕疵品」,凶宅因在市場上不具備增值潛力,就有賠錢的高風險,銀行更是「避之唯恐不及」領頭羊。但「迷信行為」,不管是政府、金融機構、教育體系都該「淡化」處理,不該「惡化」它不是嗎?真有神鬼,用「待祝福的房子」看待與稱呼,不是較能撫慰怨靈?撫慰人心?

更有甚者,風水節目推波助瀾,總再三強調房子「不乾淨」會招禍;農曆七月一到猛鬼出籠,恍若台灣鬼屋四處;投資理財也都教育人們如何遠避凶宅,這等危言聳聽,凶宅更難翻身。

當然,神棍們更可極盡煽風點火之能事的說,因為善化這「凶宅」夠凶,交易不但不成,還賠了一屁股,想必快有風水靈異的節目,前去找這房子大作文章了。


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡