李氏朝鮮燕山君墮落之路(中):活人死人都難逃虐刑,徵集天下美女當官妓

李氏朝鮮燕山君墮落之路(中):活人死人都難逃虐刑,徵集天下美女當官妓

我們想讓你知道的是

正當大臣還在擔憂國王是否過於沈溺女色,耽誤國政,壞了國家大事之際,燕山君用行動告訴這些大臣,只有燕山君才能超越燕山君。

李氏朝鮮燕山君墮落之路(上):權力狂人在宮廷掀起腥風血雨的「士禍」

燕山君在位短短14年間,發生了兩次士禍—「戊午士禍」(무오사화,1498年)、 「甲子士禍」(갑자사화,1504年),內耗極大。

燕山君酷刑生死簿:活人、死人皆難逃受虐

期間,燕山君為了鎮壓朝臣,於酷刑上也多有所創見,依對人體傷害程度輕重,分別創建出底下幾個有名的酷刑—把犯人綁在火紅燒燙的鐵柱上,毒打拷問,除了可以聞到人肉燒焦味,且伴以吱吱作響破皮出油聲,和異於常人可發出來悲鴻慘叫聲,常逗著燕山君哈哈大笑,不出三五分鐘,犯人早已燒死在鐵柱上,以死認罪,史稱此刑為「烙訊」(낙신)與「炮烙」(포락)。

再不認罪者,施以極刑,即把犯人肉身放置在處刑台上,再由施刑者以利刀銳刃,一刀一片細細長長地切斬生人活體,享聞犯人的叫聲與疼痛感,一直切到犯人叫聲停息、斷氣之際,史稱「寸斬」(촌참)。

但是,寸斬也得看燕山君心情,萬一他趕著去後宮嬉玩,處以犯人恐怕就是用利刀直接剖開胸膛,看看心黑亦心紅,判以有罪否,史稱「斮胸」(착흉)。

或是直接命令他人開腸剖肚,看看犯人心腸黑不黑壞不壞、肚子是否懷著什麼詭計,此刑史稱「刳腹」(고복),可想而知的,這一剖胸挖腸,早已就要人命了,至於犯人認不認罪,已非要事了。

若是燕山君興致再高一點的話,下得命令即是「死刑」(사형),死刑的手段除了常見的賜藥(사약)毒死外,斬首(참수)一刑也常見,偶爾燕山君突有奇想,他還會吩咐行刑者,把犯人的殘肢拋到大街上,來場「梟首」(효수)秀,亦或「車裂刑」(거열형),賞犯人一個痛快。

若是罪人已經過世,燕山君也不會輕易放過,輕則以鞭子鞭屍,史稱「戮屍」(육시),重則派出大隊人馬,來到罪人墓前,拆碑挖墳拉棺見天日,施以「剖棺斬屍」(부관참시),加以侮辱死者,最後施以「碎骨飄風」(쇄골표풍),打碎死者骨骸燒成灰燼,任由棺開風散,把死者骨灰吹向高處遠方不知處,死不得其所。

罪大惡極之人死不得其所,連骨灰都要隨風吹

可別小看碎骨飄風這一酷刑,當時它所寓含「道理」極深—罪人骯髒的屍體怎麼能埋在大地內呢?大地為萬物之根基,把罪人屍體葬於此,無疑地會污染大地外,之後從大地上長出來的萬物,當然也是繼承這骯髒的養分,能有多健康呢?依此,對待千古萬世罪人最好的處置方式,莫過於把罪人骨灰盡散於荒野給狐狸吃,或讓狂風吹至大海內,讓此罪惡因子從這世上,消失得無影無蹤才行。

依此,《朝鮮王朝實錄》(조선왕조실록),中宗元年(1506年)九月二日,記載著當年施行「碎骨飄風」史實條錄:

「義禁府郞廳持尹弼商燒骨灰,詣承政院門外以啓,傳曰:「今後燒六奸臣之骨,隨風飄之于海水上。」初,成俊嘗言於王曰: 「方今有陵上之風,漸不可長。」李克均和其言。至是,敎曰:「陵上之人,不可容於天地間。欲埋於地,則地之生木自根生幹,自幹生枝葉,莫不順理,豈可以悖逆之人,汚諸地乎?當棄之草野,使狐狸食之,或沈之於水,毋使存其形體。」於是,始行寸斬之刑,一人陷罪,戮及父子兄弟。又設局曰滌兇廳,掌瀦罪人家宅,立石紀罪。以言事被罪者,號曰奸臣,其深所見忤者,則燒屍糜骨,當風揚之,名曰碎骨飄風,爲刑之慘,至於此極。俊、克均以大臣,造陵上之言,首啓禍端,卒亦不免,何無慮後之智也?」

此外,碎骨飄風之殘酷,人們聞風喪膽,連當時民間還有借用此酷刑來詛咒小人不得好死,民間流傳詩云:「小任崇載大任洪,千古姦兇是最雄,天道好還應有報,從知汝骨亦飄風。」

詩中最後一句內的「汝骨亦飄風」,即詛咒為政小人,終有一日會遭到碎骨飄風報應,足見此酷刑當時之「威力」,不能小覷啊。

而燕山君的這幾招酷刑,看得宮內大臣傻眼,哪怕自己行得正,做得直,遇到這樣一位暴君,就算沒罪,被他綁在火紅熱燙鐵柱上,亦用利刀寸斬,豈有不認罪之理?

時哭時笑的「狂症」,燕山君淫亂徵集天下美女

然而,甲子士禍後,雪上加霜地是燕山君「狂症」,越來越明顯,情緒也越來越極端,時而哭時而笑,有時喜有時悲,舉動也漸不受他人控制,甚至民間百姓也不敢跳起諷刺時政的「處容舞」(처용무)了,怕的就是燕山君一怒之下,又用酷刑來伺候他們這些無辜民眾啊。

燕山君除了輕視作為統治理念的儒學、在酷刑有所創見下,最有名的,還有他的「淫亂史」了。史書記載,燕山君曾下令在全國徵集美女,好入宮培訓為官妓,為此,他下令設立了「採紅使」(채홍사)與「採青使」(채청사)等官吏,下鄉蒐集貌美女子,不管女子成年或未成年,甚者已為人婦者,只要貌美身材好,全數押進宮廷內,挑選人數曾高達2,000多位。

而這些「准」官妓們,被送往的地點是燕山君特地挑選的「神聖」集賢殿(집현전),供他玩樂用—集賢殿就是當年世宗大王召見群臣,創建韓文誕生之地。

眾臣一個個目瞪口呆地看著燕山君的荒謬怪行,且又因燕山君的採紅、採青歷史「壯舉」,這兩官職也成為韓語內「興清亡清」(흥청망청,意指貪圖女色、玩物喪國)一詞來源。

根據統計,燕山君在位14年間,所擁有的女人,包含打雜宮女在內,超過1,000位之多,遠遠超過朝鮮27位君王平均值的600-700位,達四成之多。其中他特別寵愛,也為伎生出身,號稱朝鮮四大妖女之一張綠水(장녹수,?-1506),但這已經是另外一則以後值得書寫的故事了。

RTS1NQM
Photo Credit:Reuters/達志影像

只有燕山君才能超越燕山君:把國家學校改成狩獵場

正當大臣還在擔憂國王是否過於沈溺女色,耽誤國政,壞了國家大事之際,燕山君用行動告訴這些大臣,只有燕山君才能超越燕山君。

他一不做二不休地,把即官方認定的國立大學國子監成均館,改造成為他打獵的游樂場所。更讓後人哭笑不得的是,燕山君把這群知書達禮的儒生,從成均館驅趕出去,封閉了成均館外,同時也花了大筆金錢改造成狩獵場,使朝鮮國庫日益捉襟見肘、民生艱難,但他在場內置放的獵物,卻並非我們所認知的凶猛老虎、山豬或野狼等野獸,而是如同被採蒐入宮的美女一般,放入的是諸如兔子、野鴨等膽小動物,供燕山君盡情嬉鬧玩耍用。

燕山君沈溺打獵癖好,過了500多年,也被後世當今韓國民族詩人高銀(고은,1933-)記載在他的巨作「萬人譜」(만인보,1986年開始創作,到2010年完成,共計30卷)內,高銀於第30卷內,一首名為〈漢江船頭〉(한강 배다리)詩內寫道:「(對燕山君而言)春天是打獵的季節、夏天也是打獵的季節、秋天也是打獵的季節,冬天也是打獵的季節,誰說只有十月是打獵季呢。」

可見燕山君愛好打獵惡行之印象,還深深刻在韓國人心中。

最後,燕山君還頒佈了「禁言令」,因為燕山君得知有人用世宗大王發明且頒佈的「諺文」(언문)訓民正音羞辱他,就下令全國禁止使用。

然而,苛政酷刑真能止得住不滿的民心、防堵起憤概的民氣嗎?

孟子曰:「桀、紂之失天下也,失其民也。失其民者,失其心也。得天下有道,得其民,斯得天下矣。得其民有道,得其心,斯得民矣。得其心有道,所欲與之聚之,所惡勿施爾也。 民之歸仁也,猶水之就下,獸之走壙也。故為淵敺魚者,獺也;為叢敺爵者,鸇也;為湯、武敺民者,桀與紂也。」

若是中國暴君的代名詞是桀、紂的話,那麼朝鮮王朝歷史上,暴君的代名詞無疑就是燕山君了。

然而,正當燕山君大毀佛儒之學、官妓嬉鬧、與成均館馳馬狩獵之際,朝廷官內已經聚集了一股反動勢力,慢慢騷動,準備起義推翻這位暴君了。

李氏朝鮮燕山君墮落之路(下):政變推翻一代暴君,成當代韓劇最愛題材

責任編輯:羅元祺
核稿編輯:翁世航

猜你喜歡


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

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


猜你喜歡