COVID疫苗受試者出現不明症狀,不到24小時美國嬌生、禮來相繼暫停試驗

COVID疫苗受試者出現不明症狀,不到24小時美國嬌生、禮來相繼暫停試驗
Photo Credit: AP / 達志影像

我們想讓你知道的是

在禮來公司宣布暫停試驗不到24小時,嬌生公司才由於1名受試者出現不明原因疾病,12日宣布對全球6萬名接種疫苗的志願者暫停進行第3階段臨床試驗。

(中央社)繼嬌生集團(Johnson & Johnson,港譯「強生」)之後,美國藥廠禮來(Eli Lilly)也因潛在安全疑慮,中止最後階段的「COVID-19」(2019年新型冠狀病毒疾病,簡稱武漢肺炎)臨床試驗。24小時內2家藥廠相繼對試驗喊卡,科學家漫長抗疫之路再遇挫敗。

禮來公司昨(13)日已針對一起不明事件,暫停旗下實驗室製抗體對住院患者的第3階段臨床試驗。

美國醫藥大廠嬌生集團12日也因一名受試者出現不明原因疾病,而暫停COVID-19疫苗的第3階段試驗。

嬌生研究領導人瑪曼(Mathai Mammen)昨日跟投資人說,試驗是「暫時中止」且可能跟他們的藥物無關。

《法新社》報導,臨床試驗在最後階段遭遇問題其實並不足為奇。實際上,最後階段試驗的目的是把受試者人數擴大至數以千計或數以萬計,藉此找出可能非常罕見的副作用。

上個月,英國的阿斯特捷利康公司(AstraZeneca)就成為全球第一個宣布暫停疫苗臨床試驗的藥廠,說英國一名患者診斷出有發炎情況,影響到脊椎。

阿斯特捷利康後來在全球恢復試驗,唯獨美國的試驗依舊暫停,原因不明。

針對禮來成為最新一家因安全考量而中止試驗的藥廠,管理美國加州斯克里普斯研究所(Scripps Research Institute)的醫師兼科學家托波爾(Eric Topol)在推特(Twitter)發文直呼驚訝,說禮來前幾個階段的試驗都沒有出現任何嚴重的副作用。

他說:「希望這只是短暫中止,我們很快就會取得細節,小心謹慎總是好的。」

禮來發言人13日在聲明中告訴《法新社》:「禮來支持資料安全性監督委員會(DSMB)的決定,審慎確保研究受試者的安全。」

這項研究8月在美國、丹麥與新加坡的50多座城市展開,目標是招募1萬名受試者。

綜合《紐約時報》《CNBC》報導,禮來研發的藥物是單株抗體,是由單一種類型的免疫細胞製造出來的抗體,科學家希望以此對抗病毒。這樣的治療方法,是使用美國第一批自武漢肺炎康復的患者血液樣本所開發。英國的阿斯特捷利康公司、美國的「Regeneron」等公司也致力於所謂的抗體治療。

禮來的試驗由美國國家衛生研究院(NIH)、美國退伍軍人事務部等組織贊助,讓受試者分別接受抗體治療,與生理食鹽水安慰劑(placebo),作為對照。不過在13日,試驗研究員被告知停止招募受試者。

NIH發言人在一份聲明中說,該試驗已經招募了326名武漢肺炎患者,但監督委員會發現,經過5天的治療,接受抗體的治療組患者顯示出不同的臨床狀態,比接受生理鹽水安慰劑的對照組要高,差異超過了安全性的預定值。

實驗室製造的抗體療法近來備受關注,主要是因為美國總統川普(港譯「特朗普」)日前說他染疫痊癒,有部分要歸功於生技公司雷傑納隆藥廠(Regeneron)研發的實驗性雞尾酒抗體療法。

禮來與雷傑納隆上週都對他們的藥物向美國食品暨藥物管理局(FDA)提出緊急使用授權申請。

根據《彭博社》,傳出試驗暫停後,禮來公司的股票在13日下午的交易中下跌了3.8%。

24小時2家藥廠試驗喊卡,說明了什麼?

在禮來公司宣布暫停試驗不到24小時,嬌生公司才由於1名受試者出現不明原因疾病(unexplained illness),12日宣布對全球6萬名接種疫苗的志願者暫停進行第3階段臨床試驗,目前這名志願者健康情況的詳細資訊仍保密。

一天之內,2家藥廠相繼因為受試者出現不明反應而暫停試驗,這代表什麼呢?

《聖地牙哥聯合論壇報》訪問2位參與武漢肺炎治療研究的科學家,他們指出:

  • 我們不知道的:

嬌生和禮來2家公司的公告都沒有提供具體細節,目前仍不清楚是什麼症狀導致試驗暫停。

嬌生的試驗要招募6萬名參與者,禮來則是1萬名,在如此大規模的試驗中,人們也有可能由於完全不相關的原因而生病。

  • 可知道的:

暫停試驗是臨床試驗工作的一環,試驗的數據由獨立的數據安全監控委員會監控,並由這個委員會來建議試驗可以繼續、暫停、或停止

「開始臨床試驗,暫停,然後重新開始」,科學家表示,除非人們不在乎安全性,否則不會不暫停試驗。

儘管有巨大的壓力,要迅速推出疫苗來對抗已經奪走全球超過108萬人生命的疾病,這些藥廠仍然暫停試驗,科學家認為,如此謹慎的態度,讓人感到放心:「他們在遵守規則,這是你希望看到的。」

全球掀起疫苗戰,各國該發進度如何?

根據《紐約時報》的追蹤表,截至13日,全球共有44支武漢肺炎疫苗正進行人體測試,其中11支正進行第3階段臨床測試,在動物實驗階段的疫苗則有92支。

目前進入第3階段的疫苗,包括了:

  • 美國 - Moderna、Novavax、嬌生(暫停試驗)、禮來(暫停試驗)
  • 英國 - 阿斯特捷利康公司與牛津大學合作(部分暫停試驗)
  • 德國 - BioNTech與美國輝瑞(Pfizer)合作的mRNA
  • 中國 - 中國國藥集團(CNBG)、科興生物技術公司(Sinovac Biotech)、中國解放軍軍事科學院和康希諾生物公司合作疫苗
  • 俄羅斯 - 加馬列亞(Gamaleya)研究中心等機構研發的疫苗「Gam-Covid-Vac」
  • 澳洲 - 卡介苗

根據《彭博社》中國國藥集團正與北京當局協商,計畫讓赴海外留學的留學生接種該公司的試驗性疫苗,知情人士說,各個政府機構仍在製定計劃,尚未做出最終決定。

報導指出,中國國藥集團的2支疫苗雖然尚在第3期臨床試驗階段,但已經獲准在中國緊急使用,提供包括醫務人員,以及在高風險國家工作的國企僱員約數十萬人接種。一旦中國監管機構決定學生可以納入緊急使用範圍,這將創下未完成全面人體試驗疫苗的使用範圍紀錄。

延伸閱讀:

新聞來源:

責任編輯:黃筱歡
核稿編輯:楊士範


猜你喜歡


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

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


猜你喜歡