至今爭議未止的319槍擊案(下):專案小組給出答案,但各界並不買單

至今爭議未止的319槍擊案(下):專案小組給出答案,但各界並不買單
時任刑事局長的侯友宜陪同李昌鈺查看319槍擊案相關證物|Photo Credit: Reuters / 達志影像

我們想讓你知道的是

319槍擊案至今已經過了17年,即便專案小組給出了一個答案,但很顯然各界並不買單,期間包括「三一九槍擊事件真相調查特別委員會」等單位,甚至是案件當事人都質疑這樣的結論,使得這個案子至今仍各說各話。

文:唐嘉邦(重大歷史懸疑案件調查辦公室調查員)

神探辦案   

3月29日,也就是陳義雄被發現死亡當天,李昌鈺推薦的三名美國刑事和彈道專家先行抵達台灣開始調查工作,他們會見了陳水扁總統,並檢視傷口,認為傷口確實是槍傷無誤。同時也取得事件發生時的所有證物,並到現場勘察,把採樣到的資料帶回美國與李昌鈺共同討論。   

4月9日李昌鈺抵達台灣,當天他立刻祕密拜訪總統府,親眼看過陳水扁和呂秀蓮的傷口後,又到調查局取得所有證物和照片進行研究。接著李昌鈺又馬不停蹄地南下台南,訪問奇美醫院並與當天參與治療的醫生談話,再度確認之前受外界懷疑的X光片、照片沒有問題。

晚間李昌鈺也來到案發現場,採用雷射技術重建彈道,判斷兇手可能是躲在公車站牌附近射擊,而且由於車內滿布細微玻璃碎片,確認是由外向內射擊所造成的無庸置疑。   

經過反覆試驗研究後,根據刑事局及李昌鈺提出了現場重建報告,確認了槍擊案的詳細熱區位置,報告指出,「熱區應為金華路三段12至18號間,其中以金華路三段14至16號間可能性最高。」   

RTRH3IG
Photo Credit: Reuters / 達志影像

確認了兇手射擊熱區及彈道後,專案小組「以彈追槍」。發現兩枚掉落在現場的不銹鋼彈殼無論外觀、大小、內部組成結構均相似。另在彈殼上有相似的環狀紋痕,應是同一台機器或是同一類型的機器所製造出來。   

刑事局於2004年5月,調查發現另外兩件槍砲案「何墩卿案」與「楊志清案」中查獲的槍械,與319槍擊案涉案槍彈為同一來源後,循線追查槍彈上游,查出319槍擊案的槍彈為男子唐守義所製造。   

警方在調查唐守義所製造的槍彈流向時,從已溺斃的陳義雄親友處得知,陳義雄曾買過槍。親友證稱,陳義雄於2003年12月22日以「防身」為由透過數名中間人以新台幣4萬5千元購得唐守義所製造的槍彈。   

獲悉後,再度針對陳義雄是否涉及319槍擊案進行調查,同時還要釐清陳義雄所謂的買槍是為「防身」之用是甚麼意思?   

原來陳義雄曾於2003年4月25日,在台南市水萍塭公園參加《TVBS全民開講》節目錄製,他在節目上發言批評陳水扁執政導致經濟衰退,還說:

你們民進黨大家若要講一直要支持阿扁,等於說要寵這個囡仔寵乎壞,若寵下去永遠台灣就一定會倒。

結果節目結束後,陳義雄遭到大批阿扁支持者包圍,若非是有警察保護離開,差點就被圍毆。但之後陳義雄還是常在公園等處遭人認出,並與對方發生衝突,為此陳義雄擔心會遭到報復,才有購槍防身的打算。   

同時,專案小組也在此時作出陳義雄確實是319槍擊案兇手的推論。專案小組調查發現,原來陳義雄妻子在專案小組公布疑似涉案的禿頭黃衣男子影像後,曾經詢問丈夫是不是他本人,但陳義雄支吾其詞,僅表示「事情我做的,我自己會處理。」陳義雄還在客廳將黃色夾克剪碎,並丟到神明廳的金爐燒掉;事後又主動要妻子幫他修短頭髮。

RTRFK37
Photo Credit: Reuters / 達志影像
奇美醫院在替陳水扁照X光時,在衣服裡發現彈頭

報告出爐  

專案小組在《0319總統、副總統槍擊案專案報告》中如此記載:

事實上,陳義雄的死亡原因,在 93年3月29日陳義雄被發現溺斃當天晚上,家人都已知悉陳義雄是自殺死亡的,原因是家人已發現陳義雄在房間抽屜內的遺書,由於家屬在看過遺書後,認為陳義雄自殺最主要的原因,是因為涉及總統及副總統被槍擊的案件。

但這封所謂陳義雄的遺書在哪裡呢?專案報告中表示,家屬在陳義雄死後開了家庭會議,為了避免家庭未來遭到不必要的紛擾,決定燒毀遺書。專案報告中就寫到家屬銷毀證物遺書是為了「顧慮家人以後的生活,希望此件世人所矚目的槍擊案件謎底,隨陳義雄的死亡永遠石沉大海。」   

至於陳義雄背後是否有幕後黑手指使,專案小組認為,從陳義雄生前的電話通聯、資金流通、監視器畫面、家人目擊者供詞、犯案槍彈為一槍兩彈等部分,都顯示陳義雄為獨自作案。   

這個說法不管你信不信,總之檢調單位是信了。2005年8月17日,台灣最高法院檢察署檢察總長吳英昭正式宣布319槍擊案結案,由於涉案的陳義雄已死亡,全案予以不起訴處分。   

專案小組最後做出的結論報告是這樣:

93年 3月19日,陳總統及呂副總統的選舉造勢車隊行經台南市金華路三段時,(陳義雄)趁著現場人聲鼎沸、萬頭鑽動,與震耳欲聾的鞭炮聲掩護下,連續向陳總統座車開了二槍後,沿著金華路右轉武英街再左轉大智街逃離現場,原以為神不知鬼不覺,未料在逃離的過程中被沿路的錄影監視器拍到了,影像公布之後,陳義雄不想連累家人,在留下遺書交代完後事,以自殺結束了自己的生命。

總之,319槍擊案就這樣落幕了⋯⋯。

當事人之一,呂秀蓮翻案   

當然,這樣的結局不要說藍營無法接受,就連綠營也看不下去。2007年4月,案件當事人之一的副總統呂秀蓮在接受媒體訪問時公開指出,檢警調在案發後的處理與調查都有疏失。她也不認同警方指陳義雄涉案的結論,而且她懷疑319槍擊案的真正目標並非陳水扁而是她。   

呂秀蓮還分析,認為319的真正幕後黑手有可能是以下幾種可能:

截圖_2021-11-10_上午8_59_24
Photo Credit: 疑案辦

2010年3月18日,這時已經卸任總統職務的陳水扁發表「阿扁札記」,文中也促請政府要重啟調查319槍擊案。他表示完全支持「三一九暗殺事件」應該重啟調查,不但要重新查、仔細查,更要徹底的查,「到底誰是兇手,如果不是陳義雄,那又是誰?」   

319槍擊案至今已經過了17年,即便專案小組給出了一個答案,但很顯然各界並不買單,期間包括「三一九槍擊事件真相調查特別委員會」等單位,甚至是案件當事人都質疑這樣的結論,使得這個案子至今仍各說各話。不同陣營的人士及支持者,各自選擇相信他們所相信的說法。   

不過,319槍擊案真的有許多環節很難讓人理解,比如:兇手如何在上千警力維安及眾目睽睽下於人群中開槍射擊,而竟然沒有人發現?   

案發現場萬頭鑽動,兇手持著一把改造手槍竟能在不傷及無辜的情況下,連開兩槍精準擊中目標?專案報告說陳義雄買槍行兇,但槍在哪裡?   

案發後,被指為兇手的陳義雄死因實在過於離奇,而且這麼巧,連遺書都被燒了,什麼都沒留下來,會不會是被滅口?   


猜你喜歡


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

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


猜你喜歡