選舉觀察:台灣新聞自由的被箝制與網路資訊風向的被操弄

他們其實不在乎什麼挺同反同,但他們在乎的是怎麼利用這些「勢」來影響台灣的政治,影響台灣的媒體,所以你會發現,只要這個「勢」可以影醒台灣政治的,他們就會有興趣。
評論
評論

本文經作者 Joy 同意轉載

之前只是跟朋友聊到韓國瑜的網路資訊有很明顯的操作痕跡,但今天發現一件事讓我覺得毛毛的。覺得一定要趁還有印象的時候記錄下來。

事情是這樣的,前幾天我在滑臉書的時候看到朋友分享了一篇文章,是天下雜誌寫的,標題我印象中有提到愛家公投跟中國因素,當時想說車上不方便看就先轉貼到自己的牆上備份起來。這幾天有時間想說要回頭好好來讀一下的時候,赫然發現該文章不見了!

這很奇怪,這篇文章上架沒幾天,為什麼會突然刪掉呢?一般來說台灣的新聞如果是內容有更動,反正都網頁化了,直接更新內容就好。由於之前已經耳聞過很多因為高層壓力而下架新聞的事件,我覺得這案情實在不單純。但在這之前我應該要先趕快把網路上找得到的資料先備份下來,免得口說無憑。

於是我重新在 google 搜尋「愛家公投 中國 天下」,搜尋結果如下,可以看到文章是三天前收錄到 google 的。針對像這種新聞大站,google 的收錄都是很即時的,所以可以合理推論這篇文章三天前確實存在。但什麼時候被刪除?不確定。

然後我想想看看 google 有沒有留著暫存頁面。所以點進去頁面庫存檔,發現竟然完全沒有頁面庫存。

這就很詭異了。你可能會說,文章都被刪掉了,沒有頁面庫存有什麼奇怪的嗎?但就我個人的操作經驗來說,依照 google 爬蟲的運作,如果今天不是文章來源網站本身主動要求刪除頁面庫存,google 自行刪除已收錄的庫存資料的速度是不會那麼快的。這個很顯然天下應該有使用 google console 去對 google 要求刪除庫存資料,才會那麼快庫存頁面就消失了。

我決定再碰一下運氣,用 wayback machine 網頁時光機找找看有沒有庫存。搜尋結果如下

所以他在 11/6 的時候確實也有收錄過。點進去看他收錄的版本

「反同婚教會背後有中國因素?學者:中國利用台灣矛盾、借力使力」文章上下架時間軸

所以看得出來 wayback machine 爬到的資料,當時已經改成「付費閱讀」了 可能因為爬天下的網站上限超過,所以顯示成「付費閱讀」以至於沒有爬到完整內容。然後從這裡也可以看到該篇文章的發文日期是 2018/11/5。所以可以合理推測這篇文章「反同婚教會背後有中國因素?學者:中國利用台灣矛盾、借力使力」的時間軸如下:

  • 11/5 上稿
  • 11/6 被改成限付費閱讀 wayback machine 爬到的資料
  • 11/7(或更早) 文章被刪除了

但幸好我用標題搜尋 ptt 後發現,ptt 那裡已經有人全文轉錄了(備份網址一)(備份網址二)。說真的看了全文內容後,我個人真的覺得這就是一篇專訪,沒什麼大不了的。但為什麼我眼裡沒什麼大不了的文章,竟然會落得下架?

我在想的問題是:是誰要他們下架?反同教會?中國?還是其他?又就算姑且不論背後的勢力為何,但這是否也意味著確實有外部壓力正在影響甚至箝制台灣的新聞自由?

這也讓我想到之前觀察韓國瑜網路訊息的現象,當時我覺得韓國瑜的新聞感覺好像多到一種不太正常的地步。於是用 google 大神打了幾個關鍵字。我相信在此時刻的台灣,柯文哲的新聞多應該不是什麼很奇怪的事,於是我打了「柯文哲」跟「韓國瑜」比較一下他們的搜尋結果。

這是 10/31 我傳給朋友看的訊息

  • 韓國瑜:約有 46,900,000 項結果
  • 柯文哲:約有 14,000,000 項結果

避免有人說我在虎爛。截圖證明一下

這是我今天(11/8)為了整理這篇文章再次搜尋的結果

  • 韓國瑜:約有 53,400,000 項結果
  • 柯文哲:約有 14,700,000 項結果

這是今天重新搜尋的截圖

中間經過 8 天,柯文哲的搜尋結果增加了 700,000,平均一天增加 87,500。韓國瑜的搜尋結果增加了 6,500,000,平均一天增加 812,500。韓國瑜一天的新網頁收錄數量是柯文哲的 9.28 倍。以我以前在操作公司跟追蹤對手網站 SEO 的經驗判斷,這其實有非常明顯的人為操作。但是會是 KMT 在操作嗎?我認為他們沒那麼聰明。那會是誰在操作的?

另外如果我做 SEO 操作,不會只有「大量生產內容」,還要想辦法讓這些內容「排名可以排前面」,那就必須配合大量的關鍵字搜尋跟點擊的行為,那這件事是否同時發生呢?所以我到 google 趨勢 去查詢,同時輸入幾個政治人物的名字做比對。

紅線是柯文哲,他長期搜尋熱度高不意外。綠線是黃國昌,前面有一個突起是當時在「罷免黃國昌」的關係。從這個趨勢可以很明顯地看出韓國瑜的搜尋熱度不但很高,而且高的很誇張,並且是從 9 月中開始上升,9 月底開始誇張的沖天。

這是只有在台灣,那如果把搜尋結果改成全球呢?

因為全球包含台灣,所以搜尋結果差不多也很正常。韓國瑜看起來有更多外力支撐他在高點。我好奇全球都是哪些區域在搜尋的。來看一下區域搜尋熱度比較看看。

顯然中國對黃國昌很沒興趣啊。然後我進一步想,那如果我把這一年幾個重大社會議題一起拉進來比較的話呢?

勞基法凸起來的時間點就是一例一休修法的前後。我比較意外的是公投從 10 月中後跟柯文哲的搜尋趨勢黃金交叉,也呈現沖天炮的趨勢。

不論是勞基法還是罷免,上升到高點回到一般值經歷的時間差不多都在 20 天內,也就是三個禮拜。但是韓國瑜的搜尋熱度從 9 月中開始上升以來,到現在都還在高點。這本身就是一個不正常的搜尋趨勢。

韓國瑜比志玲姐姐還紅,關心韓國瑜的人比看韓劇的人多

我突然想到,前陣子金庸過世,當時不管台灣還是中國都有很多人弔念,那當時的搜尋趨勢跟韓國瑜比會是如何呢?

結果金庸的搜尋熱度高點竟然只比韓國瑜多一點點而已,而且很明顯一周內 google 也預測會下跌。那我不禁在想,韓國瑜的網頁收錄數跟金庸,志玲姐姐還有蔡英文總統比,誰多誰少呢?今天(11/8)搜尋結果如下

  • 柯文哲:約有 14,700,000 項結果
  • 韓國瑜:約有 53,400,000 項結果
  • 金 庸:約有 58,700,000 項結果
  • 林志玲:約有 31,800,000 項結果
  • 蔡英文:約有 60,600,000 項結果

原來韓國瑜比志玲姐姐還紅耶,我也是醉惹….. 而且我相信以現在這種速度增加,韓國瑜的網頁收錄數量要超越蔡總統不遠惹~不然我來搜一些其他熱門字好惹,例如減肥,韓劇,看看他們的搜尋趨勢跟韓國瑜比又是如何。

原來台灣人對減肥跟韓劇的搜尋熱度還少於韓國瑜。在 9 月底的時候,大家對韓國瑜的熱度就超越減肥了。到 10 月中的時候還超越韓劇。果然只有韓國瑜可以超越韓劇(?

從 google 看公投議題被外力操作的痕跡

回到公投,這趨勢我也覺得有點誇張,不只高過柯文哲,而且還是持續上升。在 10/14 前的上升幅度還算正常範圍,但是 10/14 後明顯搜尋熱度上升的速度變快。且是持續三週上升,這個模式跟勞基法與罷免是第二週到最高點第三週回到正常水平,明顯是有差異的。

所以來看看有哪些地區對公投跟勞基法有興趣。

顯然中國對台灣公投也是很有興趣的,但是對勞基法就完全沒興趣了。

搜尋趨勢的部分我如果把時間軸拉短,改成 90 日。比較韓國瑜 / 柯文哲 / 陳其邁 / 公投。加上一個金庸。

可以看到金庸搜尋熱度一周內就回到平常狀態。韓國瑜的搜尋熱度上升的很不正常。公投的搜尋熱度持續維持還高於柯文哲也很詭異。

搜尋時間軸若改成 30 日。把金庸拿掉,改用減肥來比較。

你相信搜公投的人可以連著兩個禮拜比搜減肥的多嗎?我是不相信啦….

另外,網路搜尋使用者行為如果只看台灣,也不要傻傻的以為那真的都是台灣人自發性的搜尋結果。要記得一件事:中國如果想來台灣設置 VPN 跳板,是非常簡單的事。在網路上把自己的位置偽裝成台灣,特別是中國有錢有資源,一點都不是什麼很困難的事。我甚至敢大膽的推測,這已經是現在進行式了。

所以 上述 google 趨勢 ,若對照「反同婚教會背後有中國因素?學者:中國利用台灣矛盾、借力使力」的來看,我覺得中國利用台灣矛盾借力使力,是很明顯的。他們其實不在乎什麼挺同反同,但他們在乎的是怎麼利用這些「勢」來影響台灣的政治,影響台灣的媒體,所以你會發現,只要這個「勢」可以影醒台灣政治的,他們就會有興趣,例如公投,例如反同。但如果這個「勢」對他們沒有太大幫助,例如黃國昌,例如勞基法,他們就沒興趣。而這才是我們需要提防的。

延伸閱讀:


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 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 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

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。

了解 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。

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