藥物戰爭【 Vol. 3 】:犯人、病人與常人 ── 毒品入/除罪化的單一想像

藥物戰爭【 Vol. 3 】:犯人、病人與常人 ── 毒品入/除罪化的單一想像
img.secretchina.com

我們想讓你知道的是

此為《藥物戰爭:從認知自由、猜火車到藥物除罪爭議》的第三部分:1998 年修法《毒品危害防制條例》,便已明示「除刑不除罪」的除罪化理念,但儘管施用毒品罪由抽象危險與刑法基礎都難以立論,至今依舊無法擺脫「社會危害性」過度渲染的評價;若是在討論中缺去藥物的多元面向,雖然為「強力管制」的論述開啟了方便之門,卻恐難以理性思考何種藥物政策才能真正治理「毒品」的危險,或是開發「藥品」的實益。

藥物戰爭:從認知自由、猜火車到藥物除罪爭議
【Vol.3】犯人、病人與常人──毒品入/除罪化的單一想像

文:王允翬、邢懷安
資料呈現:胡中瀚

1839年6月3日夏,廣州虎門的淺灘上出現兩個四十五公尺見方的大池子,旁邊更搭起了數座棚廠;在周圍人群好奇的簇擁和文武官員的巡視下,一旁的工人忙著將各塊「煙土」割成四瓣,丟入鹵水當中,灑下石灰並以長棍用力拌攪,一時池水騰沸,惡臭之氣逼天。就在一天前,欽差大臣林則徐寫下《祭海神文》,為了放流銷煙毒水所造成的污染,向大洋水族致歉,並祈求:

諸凡毒矢強弓,會須暫徙;庶使纖鱗凡介,勿損滋生。猶願明神昭示冥威,永祛妖物,馴彼犬羊之性,俾識撐黎;杜其蜂蠆之萌,專輸幪布。嗚呼!有汾澮以流其惡,況茫乎碧澥蒼溟!雖蠻貊之邦可行,勿污我黃圖赤縣,幸邀肹螿,鑒我肫誠。伏維尚享!【註1】

從過去的鴉片戰爭,至最近數十年來各國政府向藥物宣戰(War on Drugs),藥物的危害似已深植人心;一百六十年後(1999年),大法官在釋字第四七六號中依然痛陳,煙毒的遺害「垂百餘年,一經吸染,萎痺終身,其因此失業亡家者,觸目皆是,由此肆無忌憚,滋生其他犯罪者,俯首即得」。或許我們已習於如此的社會文化背景,就在前日顧立雄立委提出「醫療前置化」的修正草案時,立刻觸發了煙硝四起的論戰。

在這一系列的討論中,我們試論了認知自由的可能,發掘毒品/藥品在歷史長流中的一體兩面,也點出藥物潛在的成癮性與傷害性;那麼我們該如何為「毒品之害」的想像,給出更精確的定義?為何最近數十年來,歐美國家對於藥物除罪化的聲浪始終不絕於耳?

無論入罪或除罪,非法或合法,都必須從「毒品」【註2】的本質說起。

藥物除罪化/合法化的光譜?

今日若身在荷蘭,走入街頭的「咖啡店」(coffee shops),便能夠以個人使用的名義購買少量的大麻、哈希什(hashish)等藥物。不過荷蘭並未就此變為恣意縱情的「人工天堂」,因為其實這樣的行為在當地仍然非法──只是在著名的「容忍政策」下,若私下持有與使用在規範之內,警察不會強行取締,但不可在公共場合使用。當地人多將使用藥物視為自主的健康選擇,如同決定是否抽菸或飲酒;而荷蘭政府的態度則是為了防堵地下交易,以避免使用者因藥頭套誘而接觸更危險的藥物【註3】。

Coffee shop
www.dinafem.org
荷蘭街頭的「咖啡店」;在阿姆斯特丹,一克大麻售價約10歐元(約新臺幣350元)上下,預捲好的大麻菸約6歐元(約新臺幣210元)

某種程度上,目前荷蘭的低階藥物已近乎合法化(legalization)【註4】──而合法化與除罪化(decriminalization)的概念,差別在哪呢?

國內一般所指的除罪化,是透過立法程序,將法律原先規範的犯罪行為排除在刑罰之外,也就是廣義的「非犯罪化」與「非刑罰化」的統稱【註5】。

也就是說,關於藥物除罪化的爭議,第一個面向恐源自於字面上的誤解:廣義的除罪化,未必是全盤放棄罪刑的合法化,而僅是取代原本的刑事罰,轉為保安處分、緩刑等制裁方式,期待能對行為人有更好的矯治效果;或是將刑事罰轉為較輕的行政罰的「輕刑化」;或是執法機關實際上很少加以取締,達到事實上的除罪化。「除罪化」具有各種程度與方法之分,也必定需要完善的配套措施。

其實臺灣在1998年,將戒嚴時期遺緒的《肅清煙毒條例》修法為《毒品危害防制條例》,便早已明示「除刑不除罪」的「除罪化」理念【註6】:有鑑於藥物氾濫嚴重、監獄人滿為患,世界潮流開始反省單以嚴刑峻罰的威嚇並無法防制藥物的危害,因而將藥物使用者由原先的「犯人」視為「病人」,以觀察、勒戒、戒癮治療等積極處遇(intervention),協助其戒除藥癮並回歸社會;只有無效而仍有使用傾向者,才強制戒治或入獄服刑,以實現刑罰的最後手段化。

此外,第二個爭議面向,則在於多種藥物犯罪的分辨,大致可分為販賣使用兩種:縱使在藥物刑罰較為寬容的國家,其目的也是針對「施用毒品」與「持有毒品」等使用面進行除罪化與矯治。至於販賣行為呢?若是在未經許可或管制之外,尤其是跨國集團的非法走私,則依舊採取刑事甚至重刑制裁。

而單以「毒品」一詞籠統涵蓋各種藥物,其實容易忽略性質與危險程度的不同:例如臺灣列於第一級毒品的海洛因與鴉片,成癮性與致死風險皆高,相較之下第三、四級毒品對於人體較為安全,在醫療上也有做為鎮定劑、安眠藥等應用。即便是國外(如荷蘭、美國)對於藥物使用有進一步合法化的討論,目前也僅著眼於安全、成癮性較小且人體傷害低度者(俗稱軟性藥物,如大麻及其衍生物)開放的可能性,而危險較高的硬性藥物則仍明令管制。因此,清朝末年的鴉片,今日幾乎不可能獲得普遍的開放;而多數國家對於藥物合法化的保守「禁區」,也保持審慎觀望的態度。

討論至此,我們不難想像藥物除罪化/合法化其實有如光譜上的各點,有著深淺不一的程度;而更可發現,所謂的「醫療前置化」,其實仍不脫《毒品危害防制條例》修法當初的除刑不除罪原則,只是對於現行「除罪化」戒癮治療的擴充與多元處遇的討論,更遑論對「合法化」有進一步的推展。

spectrum

大法官言下的深惡痛絕,似乎在今日許多的網路討論區獲得印證;然而對照國外論壇,支持大麻合法化的論述卻屢見不鮮,在亟力宣傳其安全性之餘,亦有「個人自由權利」的主張。我們不禁要問,觀察國外對於藥物除罪化、甚至合法化的熱議,其背後除了「以矯治取代刑罰」的論述之外,還有其他的立論基礎值得思考嗎?

何謂「毒品」?

根據教育部國語辭典「毒」字條的定義,毒品為「能讓人成癮並危害健康甚或生命的麻醉品」;儘管其概念似乎簡單易懂,但在法律上要如何界定「毒品」,卻是許多爭議之處。翻開現行的《毒品危害防制條例》第二條,條文指出:

本條例所稱毒品,指具有成癮性、濫用性及對社會危害性之麻醉藥品與其製品及影響精神物質與其製品。

毒品依其成癮性、濫用性及對社會危害性分為四級,其品項如下:

一、第一級:海洛因、嗎啡、鴉片、古柯鹼及其相類製品。
二、第二級:罌粟、古柯、大麻、安非他命、配西汀、潘他唑新及其相類製品。
三、第三級:西可巴比妥、異戊巴比妥、納洛芬及其相類製品。
四、第四級:二丙烯基巴比妥、阿普唑他及其相類製品。


猜你喜歡


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

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


猜你喜歡