【專訪】諮商師:受害者最害怕的,其實就是太多人「幫她做決定」

【專訪】諮商師:受害者最害怕的,其實就是太多人「幫她做決定」
Photo Credit:erfan a. setiawan@Flickr CC BY 2.0

我們想讓你知道的是

因為被性侵害(妨礙性自主)的人,最核心就是「被違反意願」,因此要讓受害者復元最重要的就是要「找回自己的意願」。

編按:因為輔大性侵案件的紛擾,幾乎模糊了社會的焦點,對於真正的加害人,以及受害者的心情少了點同理和空間,TNL採訪了一位有七年經驗的諮商師小楊(化名),請他談一談過去在陪伴相關個案的時候,社會大眾最應該知道的事。

在電話中,小楊語重心長的提到,無論心理師、社工員或學校老師,這種「助人工作者」,心底都留著幾個夜深人靜時依然牽掛著的孩子,跟我們提到他與那個孩子的相遇,已經是將近十年前了。

那時候年輕的小楊才剛分發到單位實習,要到所謂的「家園」(各縣市社會局讓因為家庭照顧不佳而安置的孩子們居住的地方)去做團體諮商。

他還記得,每次上課最難忍受的,就是孩子們都會群起欺負一個小學五年級的女孩,那個總是低著頭、駝著背、臉上掛著鼻涕還嘴角下垂的女孩。

她們總是嫌她看起來沒精神、說話說不清楚、分組不願意跟她一起,彷彿她做甚麼都讓人看不滿意。課程結束後,那個被欺負的孩子來找他,女孩猶豫了很久,好像不斷在找該用甚麼語詞,形容自己的感覺。

終於,女孩想好了,問道:

「哥哥,如果你們告訴我,被爸爸性侵是他的錯、不是我,為什麼關在這裡的是我?」

小楊回想起十年前的自己,是當場愣住,完全不知道該怎麼回答,只懂得跟女孩一起流淚。

其實更多的受害者,是根本不願意「說出來」

很多人可能不知道,一個性侵案件如果被發現,必須要在24小時內通報, 一通報後就得接觸到社工、警察和檢察官,也因為性侵案是公訴罪,被害人也不用去決定要不要對加害人提告。

如果要報案,通常會直接打「113」報案(一支24小時全年無休保護專線,屬衛福部)或是找非營利機構、警察。但一般來說找警察也會遇到社工,找社工最後也會遇到警察,即便直接跳去找非營利機構,在法律上一樣有義務要通報社工(最後警察也會知道)。

因為只要一通報,就會展開案件調查的程序:會跟家長說、開始調查兩造的說詞......很多受害者就是因為不希望讓家人知道、不想再重新回想那段經歷,所以選擇「不要說出來」。

小楊過去曾經有一個個案,女方被性侵但是選擇不通報,但是一段時間後,她的男朋友卻受不了,男朋友覺得兩個人親密關係的時候,總會不斷反問自己跟那個色狼有什麼不一樣?

所以對男生來說,就算那只是一個歷史、不是發生在自己身上,但還是會受到干擾或是覺得難受,可是當男生決定想要找人談談,女生(受害者)卻不是這樣想。

女生覺得那些事讓它過去就好了,可是男生卻過不去;女生覺得「如果讓你這麼不好過,不然我們就分手吧。」但是偏偏這個男生就不是想分手,而是希望兩個人可以繼續走下去,才會很努力想要改變現況。

甚至還有身邊的人還說「你還年輕,幹麻不換一個女朋友就好了?」男生卻根本無法接受這種建議。其實,很多人也忽略了,受害者身邊的人,往往也可能需要幫助。

讓受害者再度受傷的,其實是別人「幫她做決定」

看統計數據的話,被熟人(認識的人)性侵的比例是八成甚至到九成,陌生人性侵的比例其實佔很小部分,可是一般人想像中的性侵都是陌生人、那種在暗巷裡面發生的,但這跟真實數據剛好相反。

小楊提到,往往在受害者好不容易選擇說出來之後(尤其是發生在小孩子身上),就會有大人回說「這很丟臉!不要亂講!」「怎麼可能!一定是你也有問題,我們家這麼單純怎麼會發生這種事!」這類的例子數也數不清,幾乎每一個社工都遇過。

最後,大人在心裡可能都有一些自己的認定,像是「天阿!我的孩子被傷害了! 」「我是不是一個很失職的父母!」於是大人就會反過來對孩子有很多的限制,其實是害怕自己的孩子再受到傷害,但是往往大人(家長)的這些反應、情緒卻會讓被害者再受傷、又繼續累積了傷痛的經驗。

因為被性侵害(妨礙性自主)的人,最關鍵的就是「被違反意願」,因此要讓受害者復元最重要的就是要「找回自己的意願」。

小楊強調,受害者的想法不該是由其他人來做決定,不管是覺得受害者一定要治療、覺得受害者很脆弱、一定要被保護......等,那些幫受害者做的決定都是在「違反意願」,其實都是再次的傷害。

而重建、復元的過程,其實就是讓受害者可以重新找回「自己做決定」的那種能力、有信心的感覺,然後整個環境至少要可以在這件事上,持續的支持受害者。

8000285632_e80f5b4600_b
Photo Credit:Todd Van Hoosear@Flickr CC BY SA 2.0

受害者真正需要的,不是「拯救者」

在陪伴或是照顧受害者最常見的狀況就是,每當受害者心情不好的時候都要陪她,受害者需要什麼都要給她,可是事實上沒有人可以永遠做到這樣,最後那些想幫助、照顧受害者的人終究會離開,那又會對受害者造成再次的傷害,「是不是那些關心我、支持我的都是假的?」「我果然很糟糕!」「我是個有問題的人!」

小楊認為,陪伴或照顧受害者的人,千萬別把自己當作成「拯救者」 。

所以若是身為身邊的人,不但不該幫受害者做決定,還要去想「我們自己也有自己的生活」,要讓受害者知道,我們只能做到什麼程度,可以做到的是什麼?(例如:多久陪她聊一次)不能做到的又是什麼?(例如:24小時不關機隨call隨到)

也就是說,我們不能去滿足受害者所有的要求,所以一定要有原則,而這樣的原則才能讓身邊的人跟受害者的關係得以永續,不然受害者永遠會分不清人際關係之間的「界線」。

性侵案受害者的狀態,就如同「身體界線」被打破。「身體界限」指的是每個人能忍受別人碰觸自己、接近自己的限度,每個人有權利決定自己的界線。

因為我們每個人在成長過程中,都會不斷去累積自己的經驗,學會怎麼去跟身邊的人維持最適當的距離。但是在被性侵之後,受害者原有的經驗會被強力破壞,對於如何判斷自己跟別人之間的關係的「功能」會當機、不知道該跟人保持什麼樣的距離。通常就會出現兩種狀況,要不就是過度的跟別人親近(很黏人)、或是過度跟別人疏離(逃避互動、不信任)。

所以我們每一個陪伴、照顧受害者的人,都要幫她拿捏適當的距離,不然受害者會一直處於「惡性循環」,也就是永遠無法建立穩定的人際關係,或是因為過度黏人,而導致關係一次又一次的破裂、受害者又繼續無限循環的怪自己。


猜你喜歡


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

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


猜你喜歡