構成「羈押」的要件是什麼?交保免羈押是代表無罪嗎?

構成「羈押」的要件是什麼?交保免羈押是代表無罪嗎?
Photo Credit: 中央社

我們想讓你知道的是

「羈押」跟「有罪判決」是兩件不同的事,以多少錢交保而免羈押不就代表無罪、沒事了,因為法院根本還沒進行實體判決。

文:蔡孟翰

每每媒體報導對於重大矚目的刑事案件被告竟然僅只以多少錢交保而免於羈押,就會招致如潮水般的社會大眾批評謾罵法院的裁定如此誇張,那什麼是羈押呢?什麼時候會被羈押,什麼時候不會呢?

其實「羈押」跟「有罪判決」是兩件不同的事,以多少錢交保而免羈押不就代表無罪、沒事了,因為法院根本還沒進行實體判決。刑事案件要先被起訴(通常是檢察官)、法院才能進行審判,法院審判決定被告有沒有罪、有罪才可能判刑、然後執行刑罰(例如被抓去關起來的有期徒刑) 。

但是檢察官在調查犯罪嫌疑人是不是真的有犯罪(偵查)可能是須要時間的、同樣的,法院審判是須要時間的,不是一起訴就可以馬上判決出來,例如證據調查等等。「羈押」就是對於犯罪嫌疑人,怕他在檢察官認為有犯罪可能而起訴前、或法院做出審判前,做出影響偵查或判決的行為,才會先限制被告人身自由,確保之後偵查或審判可以順利進行,所以羈押不是讓被告服刑。

羈押處所是在看守所,也不是監獄。也因為羈押不是服刑,所以有期間限制,不然被告都還沒被判有罪,就被關好久也不妥。因此有羈押期間的限制。而且若之後被告受到有罪判決,羈押期間是可以折抵刑期的。而之前的保釋金在判決之後,被告沒有落跑,也應該歸還給被告,所以就很像押金的意思。

但既然羈押是先行限制未受有罪判決的被告在憲法上所保障的人身自由,所以應該有相當高的標準,一律由法院決定是應該予以羈押(也是學理上所謂的「法官保留」,不能由警察或是檢察官決定要不要羈押)。

刑事訴訟法也規定,必須是被告可能會偷偷落跑(逃亡或逃亡之虞)、或是把犯罪的證據破壞影響之後判決(湮滅、偽造、變造證據或串供)、可能在執行刑罰前可能再次犯相同的罪(也就是所謂的「預防性羈押」)等等情況,法官才可以予以羈押。

但是若法官認為即便有上述情況,即使不羈押也不至於會影響審判產生影響,也是所謂的無「羈押必要」,可以要求具保、責付、限制住居。因此交保候傳,就只是法官認為沒有羈押必要了,而不是認為被告無罪

雖然刑事訴訟法第101條第一條第三款有所謂的「重罪羈押」,但是大法官在第665號解釋認為,重大犯罪的被告還應該要具備逃亡之虞或湮滅證據、串供之虞才可以羈押,對此款要件採限縮解釋。

因此羈押的要件包括:「犯罪嫌疑重大」+「法定羈押事由」+「羈押必要」。

若在檢察官起訴或法院做出判決之前,羈押的原因消滅或羈押期間已滿,或是羈押期間根本已經超過被告若真的受有罪判決後所應該服的刑期,或是被告受不起訴、緩起訴、無罪、免訴等結果,則羈押就應該要撤銷。

刑事訴訟法第101條:「被告經法官訊問後,認為犯罪嫌疑重大,而有左列情形之一,非予羈押,顯難進行追訴、審判或執行者,得羈押之︰

  1. 逃亡或有事實足認為有逃亡之虞者。
  2. 有事實足認為有湮滅、偽造、變造證據或勾串共犯或證人之虞者。
  3. 所犯為死刑、無期徒刑或最輕本刑為五年以上有期徒刑之罪者。

法官為前項之訊問時,檢察官得到場陳述聲請羈押之理由及提出必要之證據。 第一項各款所依據之事實,應告知被告及其辯護人,並記載於筆錄。」

刑事訴訟法第101條之一:「被告經法官訊問後,認為犯下列各款之罪,其嫌疑重大,有事實足認為有反覆實施同一犯罪之虞,而有羈押之必要者,得羈押之:

  1. 刑法第一百七十四條第一項、第二項、第四項、第一百七十五條第一項、第二項之放火罪、第一百七十六條之準放火罪。
  2. 刑法第二百二十一條之強制性交罪、第二百二十四條之強制猥褻罪、第二百二十四條之一之加重強制猥褻罪、第二百二十五條之乘機性交猥褻罪、第二百二十七條之與幼年男女性交或猥褻罪、第二百七十七條第一項之傷害罪。但其須告訴乃論,而未經告訴或其告訴已經撤回或已逾告訴期間者,不在此限。
  3. 刑法第三百零二條之妨害自由罪。
  4. 刑法第三百零四條之強制罪、第三百零五條之恐嚇危害安全罪。
  5. 刑法第三百二十條、第三百二十一條之竊盜罪。
  6. 刑法第三百二十五條、第三百二十六條之搶奪罪。
  7. 刑法第三百三十九條、第三百三十九條之三之詐欺罪。
  8. 刑法第三百四十六條之恐嚇取財罪。 前條第二項、第三項之規定,於前項情形準用之。」

刑事訴訟法第101條之二:「被告經法官訊問後,雖有第一百零一條第一項或第一百零一條之一第一項各款所定情形之一而無羈押之必要者,得逕命具保、責付或限制住居;其有第一百十四條各款所定情形之一者,非有不能具保、責付或限制住居之情形,不得羈押。」

延伸閱讀

本文經法律白話文運動 PLM授權刊登,原文發表於此

責任編輯:游家權
核稿編輯:翁世航


猜你喜歡


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

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


猜你喜歡