日本記者在敘利亞被綁架3年獲釋:我自作自受,但當地需要有人發聲

日本記者在敘利亞被綁架3年獲釋:我自作自受,但當地需要有人發聲
Photo Credit:Reuters/達志影像

我們想讓你知道的是

日本社會有不少輿論在安田純平2004年第一次前往中東地區遭綁架時,就認為安田自己不聽勸告,前往戰區取材才會被綁架,應該自負責任。

遭到敘利亞武裝組織綁架長達3年的日本記者安田純平上週終於獲釋並平安回到日本,面對外界質疑他為何前往戰爭熱區,甚至認為他應該自負責任,日本政府不需要救援,他昨(2)日也首次在東京召開記者會公開表示感謝和歉意,並說自己遭綁架的確「自作自受」,但他仍然相信媒體要不畏風險,才能讓世界關切那些困在戰亂中的人。

《中央社》報導,安田在2015年6月為了採訪敘利亞內戰,從土耳其進入敘利亞後就失去聯繫,外界研判是被當地武裝組織抓走。日本政府發言人、內閣官房長官菅義偉則在10月23日召開記者會表示,接獲情資得知安田純平被釋放;日本政府並在24日確認是安田本人。

《新頭殼》報導,現年44歲的安田純平是日本埼玉縣人,曾擔任報社記者,長期關注中東情勢,成為自由記者後,2015年6月為了採訪敘利亞內戰,冒險從土耳其南部的安塔基亞,之後在6月22日徒步越過敘土邊境,進入敘利亞西北部戰火猛烈的伊德利卜(Idlib),就此失去聯繫。

一直到同年12月下旬,無國界記者組織(Reporters Without Borders)在官網發布消息,指出安田已經遭到綁架。據《NHK》當時報導,安田被蓋達組織(Al-Qaeda)分支努斯拉陣線(Al-Nusra )的成員綁架,呼籲日本政府營救,但外務大臣岸田文雄以人質安全為由,不願證實綁匪是否要求贖金。

《聯合報》報導,安田這次終於能夠獲釋,傳出是由卡達與土耳其政府居中談判,卡達並付出300萬美元(約台幣9300萬元)贖金,日本官房長官菅義偉表示,日本未支付贖金,也不曾與武裝組織直接談判;日本政府請求卡達、土耳其等關係國的協助,更具體的部分他不便多透露。日本首相安倍晉三則感謝卡達與土耳其政府提供的協助。

《自由時報》報導,敘利亞人權瞭望台組織(Syrian Observatory for Human Rights)執行長Rami Abdel Rahman向《讀賣新聞》透露,卡達之所以和土耳其合作營救安田,並願意付出如此高的贖金,目的是為了要在國際社會獲取好名聲。

拘禁的三年時光「就是地獄」

《中央社》報導,談到被拘禁超過3年的心境,安田在返國飛機上對記者團表示,一直有不知道要被關到什麼時候的恐懼感,也不知道何時才能獲釋,甚至還有可能被殺;因為無法獲得新的資訊,只能一直想過去的事,但不管怎麼想,都淨想一些負面的事情。

安田說,被拘禁的時光就是地獄,不管是在生理上還是心理,每天想的都是「今天還是回不了家」,漸漸變得無法控制自己。他還表示,有時會開始感覺在單人囚房中生活是理所當然,然後自己就會被這種想法嚇一跳,這也讓他非常痛苦。被拘禁的期間因為不能講日文,安田也坦承自己現在要找出正確的日文語彙有困難。

至於談到被釋放時的心境,安田說,他所有的行李跟物品都沒了,讓他感到很生氣;40個月完全無法工作,連相機跟工作的器材還被搶走。《日本共同社》報導,安田說,無論如何很高興能回到日本,但接下來會發生什麼,要怎麼樣走下去,現在完全沒有頭緒。安田的說法透露出一方面感到安心,但另一方面感到困惑的矛盾心情。

《香港01》報導,安田稱自己雖然被囚禁,有段時間被持續虐待,但仍獲准每天寫簡單的日記。武裝份子有提供紙筆給他,因為寫日記所以才大概知道被囚禁了多少日。

安田說,最早是在2018年3月被告知可以釋放回家,並把他轉移到另一個設施,不過後來拖了大半年直到10月,才真正移送往土耳其,正式重獲自由。

這3年當中,有多次安田求救影片釋出,在今年7月一隻出現在社群網路上的影片中,一名貌似安田的人身穿橘衣,並說自己的名字叫Umaru,是南韓人,《中央社》報導,安田在返回日本的飛機上表示,被拘禁時發生一些事,必須改信伊斯蘭教,所以他選了Umaru這個名字,然後依照武裝分子的規定說話。

至於為何自稱南韓人?安田說,如果他說自己是日本人且說自己的真名,其他被拘禁的人若獲釋可能會向日本或其他相關組織通報他的所在地,武裝分子擔憂這樣就會曝光,所以禁止他說真名,也禁止說自己是日本人。

安田應該對自己的被綁架「負責」嗎?

事實上對於安田純平被綁架,在日本國內有不少爭議,有不少日本輿論,在他2004年第一次遭綁架時,就認為安田自己前往戰區取材才會被擄走,應該自負責任,根據日本的談話節目,日本社會輿論後來還出現了「安田並非日本人」的仇恨言論,更質疑安田是「職業人質」、「自作自受」,應追究責任,希望政府不要出手救援。

《中廣新聞網》報導,安田返國後在東京「日本俱樂部」召開記者會,對於他自己被扣留而連累日本政府與日本社會,為了營救他而費盡心力,深感歉意與謝意。

遭綁架的日本記者安田純平公開道歉
Photo Credit:Reuters/達志影像

他也表示,各界對他的批評與檢驗是理所當然的,他也能夠理解;他說,既然決定自行前往危險地區,當然就應該自己擔負責任。這次發生在他身上發生的事,也是他自己「自作自受」。《香港01》報導,安田純平也說,要前往紛爭地帶就要有一定的覺悟,他在被擄後,被要求寫信給家人時,曾在信中寫上暗號要求妻子「若遭遇不測不要理會他」。

但他強調,前往紛爭地帶取材是必要的,因為當地獲得的資訊與外國所看的消息情報並不一樣,敘利亞內戰有不少無辜平民,過著慘絕人寰的生活,這些「絕對需要有人公諸於世」,世界上必需要有記者勇於前往戰爭地區,獲得前線第一手的訊息,《中央社》報導,安田純平認為,「你需要來自第三方的資訊,而非各個政府的資訊。」

敘利亞自2011年爆發殘酷內戰,已奪走超過36萬條人命。對記者也成了極度危險的戰區,許多記者遭到俘虜,當中一些人已遭綁架者殺害,這當中也包括安田純平的朋友,另一名日本自由記者後藤健二就被斬首

安田說,他不確定是否會重回敘利亞或再赴新戰區。但他希望自身受到高度關注的例子,能讓人注意到敘利亞內戰,「我希望大家能關切那裡(敘利亞)正在發生的事,以及未來會如何發展。」

新聞來源:

核稿編輯:羊正鈺


猜你喜歡


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

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


猜你喜歡