ref: https://ably.com/blog/no-we-dont-use-kubernetes
八月第一篇,就來個有趣的文章,來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes,不但當前沒有使用,甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊,千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。
我個人覺得這篇文章滿好的,因為是認真的去比較導入 Kubernetes 帶來的改變,而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云,人家要我也要,人家不要我也不要...
文章分成兩部分,前述介紹當前 Ably 的環境架構是什麼,而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下,會發現導入 Kubernetes 沒有帶來實質上的好處。
文章開頭先簡述了一下 Kubernetes 這幾年的風潮,從最初 Google Borg 的開發開始談起,作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用,
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中,透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果,對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。
Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider,並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container,取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。
對於 Ably 來說,團隊中沒有任何 scheduler 相關的服務來調度各種服務,這意味每個 VM 就代表一種服務,所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務,用來確保運作的 Container 如果掛掉後可以被重啟,甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。
流量方面,因為每個 Autoscaling Group 就代表一個服務,所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題,畢竟每個機器本身都會被 VPC 賦予一個 IP 地址,所以使用上沒有什麼太大的問題。
接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變,分別有 (原文很多,這邊摘要不然文章會太長)
題外話,由於 Ably 的 Infra Team 數量有限,所以要考慮 K8s 只會考慮 K8s Service,如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM,畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說,透過這種方式能夠盡可能的榨乾機器的資源,整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源,這種被稱為 nosy neighbors 的常見問題已經不是首次出現了, Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用,而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務,不過這個做法跟團隊目前的作法已經完全一致,所以就資源管理這一塊,團隊看不到使用 Kubernetes 的優勢。
2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量,基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務,所以其收費是針對客戶實際上用多少服務來收,如果開了過多 EC2 VM,則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量,
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整,根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點,但是閒置並不代表沒有任何服務部署再
上面,因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說,k8s 有兩個動態調整的部分,動態節點與動態服務,而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。
3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案,基本上團隊只要能夠維持每個服務與背後的機器的關係圖,網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務
K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP,這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller,這些 Container 可以跟 AWS LB 直接整合,讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定,所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。
4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本,後續相關機制就會將 VM 給替換掉,然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果,雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。
上次四個分析基本上就是,使用 k8s 沒有帶來任何突破性的好處,但是 k8s 本身還有其他的功能,所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處
Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭,「除非經過評估,否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊,同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說,光 Storage 每家的做法都不同,而 K8s 沒有辦法完全將這些差異性給抽象畫,這意味者開發者終究還是要針對這些細節去處理。
Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由,畢竟這種用法就跟當初 Google Borg 用法一致,是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時,底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫,所以這個優點也沒有辦法幫助到團隊
Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC,所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。
Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群,社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下,一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s,但是真正理解 k8s 的人微乎其微,所以想要透過社群來幫忙解決問題其實比你想像的還要難,畢竟裡面的問題太雜,很多時候根本很難找到一個真正有效的答案。
Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說,EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的,
還必須要安裝相關的 Controller 並且進行設定,這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes,這意味公司就要花費更多的$$來處理,所以對團隊來說,金錢與工作量都會提高,不同的解決方式只是這兩個指標的比例不同而已。
結論:
1. Ably 覺得 Kubernetes 做得很好,但是團隊目前沒有任何計畫去使用它,至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現,導入 k8s 其實也會帶出不少管理上的問題,反而並沒有減輕本來的負擔
「內部應用程式分享功能已關閉」的推薦目錄:
- 關於內部應用程式分享功能已關閉 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於內部應用程式分享功能已關閉 在 許幼如的職場學習路 Facebook 的最佳貼文
- 關於內部應用程式分享功能已關閉 在 邱顯智 Facebook 的最佳解答
- 關於內部應用程式分享功能已關閉 在 為什麼RD 給的Android App Bundle 連結不能用! - Coding Story 的評價
- 關於內部應用程式分享功能已關閉 在 出手了!Apple 關閉Facebook 開發內部iOS 應用程式功能 的評價
- 關於內部應用程式分享功能已關閉 在 Facebook Android SDK 變更紀錄 的評價
- 關於內部應用程式分享功能已關閉 在 分享一個手機快速瘦身清出空間的方法-清除快取 Line、FB ... 的評價
內部應用程式分享功能已關閉 在 許幼如的職場學習路 Facebook 的最佳貼文
前言:
測試學習是個理論簡單,但實作起來會遇到很多疑問的學習過程。曾經跟Sean Ellis 一起工作的曲卉寫的這本書不但實用,而且還訪問了一大票測試專家。
他們對於測試主題的選擇(大題目還是小題目)、AARRR漏斗的重點,還有測試團隊在組織內的發展也都有不同的見解。
我覺得很值得多看看,所以做了筆記跟大家分享。
這次分3 part,先來一串九個人我印象最深的測試心得,再來九個人的訪談摘要,最後是九個人對於組織與人的看法。enjoy~
..........
《硅谷增長黑客實戰筆記》曲卉
#Greylock Partner / Pinterest(圖片秀), Casey Winters
"不要只做優化,要做有高影響力的事情。不過,得先做優化累積影響力。"
#Mobile Growth Stack / Sound Cloud (Podcast), Andy Carvell
"不要把所有數字綁在一起看,用戶分群是有效優化的開始。"
# GloStation / Postmates(送餐), 陳思齊
"限制供給可以透過奇怪的方式,製造FOMO(害怕錯過fear of missing out) 社交地位(social status)等,讓產品流行"
# Growthstructures / Sofi Finance(學貸轉貸), Steven Dupree
"低垂果實摘完後,會陷入低潮與瓶頸。全公司(或跨團隊)的創新idea大匯集會讓大家一起幫忙,並且不要浪費對失敗案例的紀錄與策略學習。"
#Cerberus Interactive/Acorns (微型投資), Sami Khan
"醜陋、原始的廣告更像是朋友在對用戶說話,有更高機率穿透用戶的防衛心"
#Camera360(修圖), 陳思多
"漏斗的無限解構,原本以為是單純解決留存率問題,結果深究了四層(留存率—>推送更新覆蓋率—>推送更新展示率—>下載權限設定)才達到目的。"
#Square(支付), 羅揚 James Luo
"增長與嚕羊毛黨的鬥智鬥勇,對獎勵的設計要有吸引力,又要養成使用習慣,還要善用推薦者的資訊讓新用戶感受到個性化的感覺。"
#探探(校園招聘)/ 美圖(修圖), 韓知白
"要做增長先要備好基礎設施(行為數據後台,A/B測試框架),才能夠更快速迭代與勤能補拙。"
#專訪 Keep(運動)/豆瓣(社群), 張弦
"有些問題除了用數據作判斷外,直接問用戶可以達到更直接的效用,而且幫助增長團隊打開視野。"
---九篇專訪的摘要全文---
#9-1 Greylock Partner / Pinterest(圖片秀), Casey Winters
-北極星指標是會變動的
-產品(也就是核心地帶)通常是增長的投資報酬率最高的測試,但很難直接說服公司其他成員直接拿產品動刀。
-增長團隊一開始成立時候,選擇三不管地帶,以證明自己;之後才進展到核心地帶
-核心地帶的創造新價值、改善原有價值,通常是產品團隊負責。傳遞已有價值給更多人則是增長團隊負責。
-增長團隊必須是全職的,不能跟人共用成員,否則優先順序會被影響
-做測試時候,如何在容易衡量但效果慢跟全新設計但不知哪個因素產生作用之間做取捨?優化測驗要一個個做,改變方向測驗則直接直搗黃龍。而改變方向的測試才能反應高影響力。
-當低垂果實摘完後,要做高影響力需要高資源的測試需求,而不是低資源但也只需要低影響力的需求
#9-2 Mobile Growth Stack / Sound Cloud (Podcast), Andy Carvell
-對行動應用來說,留存是所有指標中最重要的,因為客人離開沒有成本,但留存會對你有無限好處。留存指標包含以日、週、月計算。
-增長團隊大約7-8人,包含產品經理、分析師、設計師、程序員,最多的是程序員。產品經理需要對分析、UI/UX設計、程序都略懂,才能跟他們溝通。
-以每週的循環討論測試設計、結果與去留。
-SC的做法不是所有用戶綁在一起看留存率,是用戶分群後看留存率,包含新用戶、流失後重新造訪用戶、重複使用用戶。
-當移動應用要藉由更版推送提升客戶體驗的時候,如何達到最好的整體效果?衡量指標是RRF 覆蓋率(reach), 相關性(Relevance), 頻率(Frequency) 三個都達到高水準則影響力最大。但覆蓋率是這當中最重要的
#9-3 GloStation / Postmates(送餐), 陳思齊
-我的前一間公司(Stolen),每個增長流程與工具都做得很好,但就是產品不夠好。當我到Postmaster之後發現他們什麼成長技巧都沒有,但產品很符合市場需求。
-增長最令人喜歡的是,能量化你的影響力,當你實驗做得好,結合了創造力與分析能力得出很好的想法,就像寫程式一樣,你做了某件事就有某個結果。這是令人上癮的。
-增長最令人不喜歡的是,會讓你偏向那些容易衡量並且很快衡量的東西。但有時候最重要的事情,例如產品與市場的契合度,反而不是容易衡量的。
-K因子(referral 用戶轉介人數)持續大於1是不可能的,尤其當你的產品越做越大,群體越來越多。即使是社交軟體,要讓k因子大於1 也需要一些違反自然規律的設計。
-稀缺性可以透過奇怪的方式,讓產品更加流行。從Stolen 得到的認知是,限制供給,造成稀缺性。心理因素是害怕錯過(FOMO) 社交地位(social status)等
-即使在矽谷,增長團隊也不多見。Google就沒有。但是FB就有一大批增長團隊並且擴散到其他地方。增長就是技術驅動,易於衡量的行銷。增長團隊更像升級版的行銷團隊,有了程序員的支持可以把推薦系統做得更精準,未來增長團隊會和市場團隊在一起而不是產品。
-用少於10%的流量,可以做任何測試。
#9-4 Growthstructures / Sofi Finance(學貸轉貸), Steven Dupree
-數學不會就是不會,增長沒效就是沒效。增長可以很快做出改變,並且追蹤哪些改變有效哪些無效。
-增長的低垂果實摘完後,會陷入疲乏,就需要大量idea。創新idea 兩種重要想法:每週五的全公司頭腦風暴 & 忠實紀錄失敗的測試並從中學到策略想法。
-增長團隊刷存在感兩種做法:(1) 在例會中說明有趣但違反直覺的實驗,已讓大家有印象(2) 把大象(重大影響力但耗資源)跟螞蟻(容易但效益有限)的實驗混合起來,避免人家覺得你沒貢獻或者只會做小事情
-新產品開始獲取客人的三種方法:(1) 付費搜索廣告,可以找到真的需要產品並且非常有興趣的人 (2) 抄競爭對手的做法,可以找到他們已經開發過的市場(3) 根據產品特殊屬性的增長手法
#9-5 Cerberus Interactive/Acorns (微型投資與機器人投資), Sami Khan
-靠創意的廣告狂人時代已經過去,excel 跟計算機才是你的好朋友。
-檢視總預算,跨通路預算調整(放大表現好的),通路內預算調整(用七天平均放大表現好的)
-2C新產品上線的建議是先在FB做小量A/B測試,找出好的再往其他通路擴散。測試前要設好追蹤,沒有追蹤,測試學習的迴路就不會成立。
-比起其他app,遊戲是最不需要擔心用戶獲取的,因為人們下載無成本;比較需要擔心的反而是用戶留存。因此要一小批一小批的獲取用戶後,關閉其他溝通通路,只針對這小群人做各種產品測試與改進,確定30 日留存率到達可用水準後才能繼續獲取用戶。
-臉書上,越醜的廣告表現越好。因為大家對電視已經疲乏,精美的廣告創意讓人想到電視會自動跳過,但粗糙的原始的則像是你朋友分享的。
#9-6 Camera360(Photo Editor), 陳思多
-漏斗的無限解構,以解決留存為例。原本想藉由app更新處理留存率低的問題,但發現更新覆蓋率不夠高,後來又發現問題是更新的展示率(被看到)低,而展示率低的原因又是app一開始下載時候的預設權限。所以回頭更改預設權限設定,在更改後次日留存率實現5%增長。(但如何在用戶已下載後調整權限啊)
-各地區的差異化溝通,以美國市場為例,經過逐一測試不同族群發現40+婦女喜歡此產品,於是將廣告視覺改為該族群會喜歡的可愛孩子展示功能,降低33%的獲客成本
-增長的成功要素是CEO的有意識支持。因為增長會用到很多資源,或是影響很多資源。若是沒有CEO的支持,無法成功。
-增長團隊需要的數據分析師,是對產品有深切了解的數據分析人,而不是純粹解讀數字。
#9-7Square(支付服務), 羅揚 James Luo
-留存主要是產品決定的,但在早期留存(D14-D90)增長可以起到很大作用,只要透過各種管道(信件、推送、Retargeting 廣告)重新提醒用戶,就會對早期留存產生明顯效用。
-要做全產品用戶推薦的指標的先決條件,是內部有堅實的大數據團隊,足以做獲客通路歸因。
-通路關鍵三大指標(CPA, ROI, LTV)中,最難建模的是LTV。因為涉及對長期留存率與資本折現率的重要假設。
-好的推薦系統會牽涉到三大項目,獎勵、曝光、轉化。其中獎勵的設計是與嚕羊毛黨鬥智鬥勇的活動。獎勵內容要考慮『有吸引力的額度、合適的條件限制、養成使用習慣的限制,累進式獎勵、考慮對稱式獎勵(利己又利人)』
-即使是最忠誠的用戶,也不會時刻記得你的獎勵項目。
-新用戶進來後,可以用推薦人的資訊提醒他們使用獎勵,不僅給新用戶個性化的感覺,也提醒新用戶『我確實獲得了某人的推薦』
#9-8 探探(校園招聘)/ 美圖(Photo Editor), 韓知白
-美圖的用戶留存指標設在N張照片保存,一開始是基於通路管理的需要,因為有些通路留存數據會有回饋延遲以及作假的問題。
-探探的市場部與增長部的區別在,市場部負責花錢,增長部不負責花錢。
-增長不是先做KPI管理,而是要有好的基礎設施(行為數據後台,A/B測試框架)才能開始觀測指標與迭代增長。
-快速迭代的價值在於,當你沒有人家的靈感,人家一次增長效果比你好3倍(+60% vs +20%)的時候,只要你迭代速度有三倍,還是可以得到一樣的成功增長效果。
-增長要避免的第一個坑就是局部優化,這裡改一點截圖,那裡改一點文案。其實也許改產品名字與圖標是最有效提升app商店轉化率的途徑。增長經理要能夠跳脫盒子思考(out of box thinking)
-剛開始做測試的人,要忘記喬布斯張小龍等產品的大神,他們是靠直覺也很少看數據:正常人要靠數據與即時反饋,勤能補拙。
#9-9 Keep(運動)/豆瓣(社群), 張弦
-全景漏斗,關心橫向的產品功能交互關係。當一個產品不只是工具,還有社交,內容等多種功能。可以根據不同功能設計指標,再看看功能
之間的交互拉提作用,決定整個產品後續的發展。而不是只看單一指標。
-量化與質化的兩腳思維,曾經做測試時候只看指標,以為是A與B的相關性,但從未想過中間還有個C。學到後就會在產品中安插小問卷直接問用戶,但要把握3個題目之內的精簡原則,不可以打擾用戶。
-加法與乘法,做增長後了解了加法與乘法的關係。增加一條溝通管道是加法,優化轉化率是乘法。一般來說,乘法的好處更大一些,但這也是基於加法已經帶來足夠的初始流量,否則盤子太小的乘法也沒啥意義。
-做產品像開船,動力與方向最重要。產品小的時候,著重動力,加速度要夠。產品體量大了後,動力已經比較足了,著重方向,往哪兒發展就更重要。
---以下是關於團隊的摘要---
#Greylock Partner / Pinterest(圖片秀), Casey Winters
"增長團隊必須是全職的,不能跟人共用成員,否則優先順序會被影響"
#Mobile Growth Stack / Sound Cloud (Podcast), Andy Carvell
"增長團隊大約7-8人,包含產品經理、分析師、設計師、程序員,最多的是程序員。產品經理需要對分析、UI/UX設計、程序都略懂,才能跟他們溝通。以每週迭代的循環討論測試設計、結果與去留。"
# GloStation / Postmates(送餐), 陳思齊
"增長最令人不喜歡的是,會讓你偏向那些容易衡量並且很快衡量的東西。但有時候最重要的事情,例如產品與市場的契合度,反而不是容易衡量的。"
#Growthstructures / Sofi Finance(學貸轉貸), Steven Dupree
"增長團隊刷存在感兩種做法:(1) 在例會中說明有趣但違反直覺的實驗,已讓大家有印象(2) 把大事(重大影響力但耗資源)跟小事(容易但效益有限)的實驗混合起來,避免人家覺得你沒貢獻或者只會做小事情"
#Cerberus Interactive/Acorns (微型投資與機器人投資) , Sami Khan
"靠創意的廣告狂人時代已經過去,excel 跟計算機才是你的好朋友。"
# Camera360(修圖), 陳思多
“增長的成功要素是CEO的有意識支持。因為增長會用到很多資源,或是影響很多資源。若是沒有CEO的支持,無法成功。”
#Square(支付), 羅揚 James Luo
“通路關鍵三大指標(CPA, ROI, LTV)中,最難建模的是LTV。因為涉及對長期留存率與資本折現率的重要假設。”
# 探探(校園招聘)/ 美圖(修圖), 韓知白
“快速迭代的價值在於,當你沒有人家的靈感,人家一次增長效果比你好3倍(+60% vs +20%)的時候,只要你迭代速度有三倍,還是可以得到一樣的成功增長效果。”
# Keep(運動)/豆瓣(社群), 張弦
“做產品像開船,動力與方向最重要。產品小的時候,著重動力,加速度要夠。產品體量大了後,動力已經比較足了,著重方向,往哪兒發展就更重要。”
內部應用程式分享功能已關閉 在 邱顯智 Facebook 的最佳解答
犯罪偵查與人權保障之間的平衡—科技偵查法制公聽會
法務部在上個月月初(8日)公告了「科技偵查法」草案,但因為公告期只有5天,又涉及秘密通訊自由、隱私權及科技資訊權等基本權利,並明文授權包括被稱為「國家木馬」、有著高度爭議的設備端通訊監察在內的偵查手段,而遭到各界抨擊。法務部檢察司林錦村司長也在公告結束後表示,考量各界意見多,將進行研議後,再送行政院核轉立法院審議。
為了讓官方跟民間在草案能有機會直接對話,我在9月25日星期五開了一場「科技偵查法制修法公聽會」,邀請司法院、法務部、國安局、調查局、廉政署、海巡署和刑事警察局等各執法機關,和民間司法改革基金會 林永頌律師、台灣人權促進會 Taiwan Association for Human Rights 周冠汝專員、中華民國律師公會全國聯合會 李宜光律師、台北律師公會 王怡婷律師、台灣刑事辯護律師協會 陳奕廷律師、劍青檢改 林達檢察官,一起交流寶貴的意見。
因為與會來賓的發言都非常全面,為了方便閱讀及掌握爭點,我請助理把與會人員的發言,重新依據議題歸納整理。希望有助於聚焦討論。
(如果有誤解或任何錯誤,歡迎隨時指正喲!)
──────────────
【台權會:資訊接露和隱私保障】
台灣人權促進會的周冠汝專員,率先分享國家監控的資訊透明狀況。台權會曾經在加拿大的學術報告中,發現台灣有間諜軟體伺服器,更曾經被偵測到在公共網路上有可以篩選封包、封鎖內容與進行監控的設備,但是從來不知道使用的單位和目的。
除了網路監控之外,還有位置的監控。周專員表示,依據法務部調查局2017-2018年GPS的使用統計資料,監控時間大多沒有超過60天。科技偵查法草案規定超過2個月才有法官保留,會讓大部分的監控都不用經過法官的審查。
周專員強調,問題在於如何監督科技偵查手段的行使,也擔心會如同英國或德國般,促使監控產業的發展。專員表示,立法前應該盤點過去的使用狀況,了解足夠的資訊後,才能和社會溝通並決定調整的方向。
【司改與律師團體:草案規範有所不足】
民間司改會和律師團體,則從法學專業與經驗出發,指出草案有待改進的面向。
1.隱私空間界定狹隘,不符社會通念和司法發展
司改會董事長林永頌律師指出,草案規定非隱私空間就可以拍照、測量、錄音、錄影,但公開場合並不代表沒有個人隱私。此外,法律規定的要件只需要檢察官甚至警察認為「必要時」即可,非常地抽象而不明確,更不需要法官審查,林律師因而質疑是否符合比例原則。
中華民國律師公會全聯會李宜光律師也表示,草案中隱私空間的範圍是被縮小的。一般的搜索,進入大門就要搜索票,但現在庭院也不算隱私空間,因為並非住宅或其他具有隱蔽設施之地上物的內部空間,使得人民的隱私範圍被限縮到限於住家裡面。
台北律師公會王怡婷律師,引用司法院釋字第689號解釋理由,說明現行司法實務已不是用單純物理空間決定隱私保護範圍:「即他人之私密領域及個人資料自主,在公共場域亦有可能受到干擾,而超出可容忍之範圍,該干擾行為亦有加以限制之必要。蓋個人之私人生活及社會活動,隨時受他人持續注視、監看、監聽或公開揭露,其言行舉止及人際互動即難自由從事,致影響其人格之自由發展。」王律師質疑,公寓大廈有開放的大廳,是否也代表國家機關可以在大廳監看人員進出,不構成隱私侵害?這樣是否符合國家應該保障隱私權的作法?另外,公共場所如果能任意監看與聞,也可能涉及到人臉辨識等科技執法的問題。
台灣刑事辯護律師協會陳奕廷律師表示,正如同美國Marshall大法官所言:「隱私不是全有或全無的概念,對個人來說,也不該只有『保有』或『失去』隱私兩種選項。」,草案採取二分法並作為強度設計的標準,會造成誤導。如同大法官解釋意旨所說的,公共領域也有隱私權,不應該再以物理範圍重新界定隱私空間。
2.隱私空間的隱私和第三人的隱私
李宜光律師認為,法案有株連過廣的問題。在對隱私空間的非侵入性偵查,例如對住家使用熱顯像儀的狀況,對先生蒐證時,配偶子女也會被偵測到。此外,蒐證還有馬賽克式的狀況,個人的行蹤和軌跡會被偵測到,並從破碎的拼圖變成一個完整的面,對隱私侵害很大,而且實施時間很長,可能無法通過比例原則的檢驗。
陳奕廷律師指出,通訊保障及監察法第13條已經明文禁止在私人住宅竊錄影音的「大監聽」。雖然科技偵查法的規定沒有涉及錄音,但一舉一動,無論洗澡、親密活動或其他人的資訊,都可以用如熱像儀等儀器一覽無遺。國家就像隱形人在旁邊看你活動,是對隱私更強大的侵害,也是大監聽的復活。陳律師認為,原則上要全面禁止,例外也要有更嚴格於通保法的規定。
3.位置追蹤與隱私保障
對於GPS等位置追蹤的偵查手段,草案規定的要件是「檢察官認有必要時」,且實施超過兩個月的話,要由檢察官聲請法院同意。對此,林永頌律師質疑無需法官保留的兩個月時間過長。陳奕廷律師也強調,這些監控不是驚鴻一瞥,是長期大量的監控,資訊量差異很大,因此要有令狀原則、通報紀錄和僅供本案使用等限制。王怡婷律師也指出了「必要時」沒有客觀標準的問題。
4.層級化法官保留
李宜光律師表示,針對科技偵查的必要性,規範方式有三種程度類型:「有必要」、「有相當理由」和「有事實足認」。如果「有必要」並且由檢察官或司法警察就能認定,範圍真的太大,在比例原則和法官保留等要件上要重新思考。
陳奕廷律師則指出,設備端通訊監察不亞於監聽錄音,包括照片、影片和檔案,都有機會透過草案第14條的規定授權獲取,遠比掛線監聽的範圍更大更多,並質疑草案規定比傳統監聽還要寬鬆。
5.違法取證怎麼辦?
王怡婷律師質疑,刑法第307條違法搜索罪是非告訴乃論之罪,為什麼草案規定違法實施設備端通訊監察和洩密是告訴乃論之罪?甚至在某些狀況下,可以不用事後通知受監察人,又怎麼提出告訴?陳奕廷律師也認為,告訴乃論之罪的設計,律己從寬到極致,刑度上還可能比通保法的規定少,因為沒有「意圖營利」的加重規定,並質疑這樣的刑責程度能否有效嚇阻公務員濫權。
在證據能力上,陳奕廷律師指出通保法第18-1條有「不得作為證據」(證據的絕對排除)的規定,但是草案第27條所規定科技偵查法實施前蒐證證據的證據能力,卻是採用權衡之相對排除的方式,是否能有效遏止國家機關違法蒐證,也有待釐清。此外,德國有外部中立單位的審查。草案條文規定監聽後要移除程式,有沒有任何監督機制存在?陳律師並主張應考量由中立客觀的單位,進行科技上的監督與管考。
6.法律體系
在法律體系上,林永頌律師、王怡婷律師和陳奕廷律師都指出,設備端通訊監察以及數位證據的蒐集和保全等規定,涉及到既有通保法與刑事訴訟法的規定事項,也都涉及對秘密通訊自由的干預,草案更相當程度地準用了通保法的規定,並質疑是否修正整合修正通保法的規定,是更完整妥當的立法方式。
林永頌律師進一步表示,強制處分是程序法重要的概念,以目前的規範來看,應該由司法院提出法案,而且司法院會相對重視相關的法律原則──法務部不是不重視,但同時也有犯罪防治的業務目的。
【劍青檢改:犯罪訴追與合法性監督】
除了律師團體與人權團體,改革派檢察官的代表──劍青檢改的林達檢察官,也以基層檢察官的角度表達意見。林達檢察官表示,從檢察官的角度來看,能立法是好事。因為立法是限制國家權力的作法,也就是保障人民基本權。如果沒有立法,執法人員可能有兩種不同的心態,一種是法律沒有規定所以都可以做,另一種是沒有規定都不能做,但實務上前者比較多。此外,沒有立法的狀況下,也無法統計、知悉使用狀況,立法才能納入管制。只是,談到立法就會走入細節,就會有相關爭議。
對於科技偵查在實務上的需求,林達檢察官舉出了海上走私、盜採林木、製毒工廠和先前發生的略誘少女案件為例,因為環境與犯罪模式的特殊性,如果沒有相應的科技偵查手段,諸如GPS、M化車、空拍機和熱顯像儀等科技設備幫助,就會難以偵查犯罪。
最後,林達檢察官認為,應該思考是否要全部法官保留。全面法官保留是很極端的作法,案件也會衝進法院。然而,國家法律必須考量到司法資源分配的問題,而需要層級化的法官保留。林達檢察官也表示,要和各界溝通對檢察官的信任程度。其實在檢察官的工作上,常常和司法警察發生爭執,因為檢察官對於蒐證程度和證據調查的聲請,有著很高強度的合法性控制。
【執法機關:科技進步與偵查障礙】
執法機關各自分享了第一線人員的經驗和困境。國安局人員表示,當遇到境外敵對勢力的威脅作為時,例如網路駭侵行為,傳統偵查有其不足,而有更新法律的必要。法務部廉政署肅貪組蔡旻峰副組長,指出了傳統通訊監察法制面對現代網路通訊應用的無力,除了無法及時掌握行賄的關鍵證據之外,還必須出動大量人力蒐證,而無法在更多貪瀆案件多所著墨。
法務部調查局廉政處蘇子廉副處長表示,科技偵查作為往往涉及人民基本權的干預,所以執法機關需要法律授權才能確保符合憲法法治國原則。民眾期待司法警政機關抓壞人維護治安,但是偵查法令的設計似乎跟不上科技演進,例如通保法不及於加密的通訊軟體,就造成犯罪的死角,並強調犯罪者和偵查者必須武器平等。
海巡署孫世亮副組長強調,傳統偵查手段有時效延宕績效不彰和精準度不及的窘境,而如果有完整的證據,就可以避免誤判,讓嫌疑人證據確鑿或避免冤情。海巡署犯罪偵查科陳佐霖科長則以盜運砂石為例,表示嫌疑船隻一出海,就會關閉自動識別系統(Automatic Identification System,AIS),造成追查困難。因為法院認為要有法律授權才能使用GPS,海巡人員也就不能使用GPS調查。另外,海巡執法面積有13個台灣大,沒有科技偵查,很難阻絕犯罪於境外。
刑事警察局謝有筆科長表示,犯罪者為了躲避查緝,除了採用通訊軟體進行聯絡,工廠也在偏鄉或人煙稀少的地方。在沒有掌握的狀況下進行跟監,除了會被懷疑而撤掉工廠,也有警察人身安全的問題。因此,警方需要不受人力和時間限制的偵查手段,例如監視攝錄定位追蹤等方法,讓警方能掌握相關犯罪情資。
法務部林錦村司長表示,科技偵查的立法,是因為基層執法人員遇到困境。犯罪組織用先進科技躲避查緝,也要思考給執法部門相對應的科技偵辦犯罪。林司長強調,在給予執法部門科技偵查手段的同時,難免對人權有所侵害,並認為要兼顧犯罪調查和人權保障的面向。
林司長也對草案的立法體制進行了回應。法務部之所以不修正通保法和刑事訴訟法,是因為通保法規範的是通訊秘密,GPS等科技偵查方法並不是通訊秘密的範圍。此外,設備端通訊監察不是台灣獨創,德國、奧地利、瑞士等國家都有。司長也表示,科技辦案難免會侵害權益,是否能依照侵害程度層級化法官保留。司長還特別說明,科技偵查是以刑事犯罪為前提,如果沒有取得令狀,很多無關的資訊應該立即銷毀,偵查結束後,設備端軟體要移除,其他檔案如照片行事曆等也不得使用。而未來將會建立流程,也會有不辦案的中立獨立的專責機關,並會強化資安的保障。
【司法院:保護人權與建立制度】
司法院的楊明佳法官表示,刑事訴訟法、通保法和科技偵查法等各部法律,如果標準不能齊一,會有操作上的混亂與困難。而在層級化法律保留上,應該從侵害基本權的種類和程度思考。例如刑事訴訟法上的搜索扣押,可能侵害到財產權和居住安寧,通訊監察則涉及秘密通訊自由和隱私權。至於科技偵查就可能非常廣泛,目前有熱顯像、M化車等設備,不知道未來還會有什麼。從這個角度來看,應該將科技偵查規定在刑事訴訟法,或考慮用一部特別法將所有科技偵查進行統合性規範。
顧正德法官則認為,無論規定在哪部法律,最重要是內容,法制要完善,監督機制也必須有事後檢驗。顧法官並認為,採用專法較能進行完整的體系規範。在立法上,顧法官認為科技偵查有科技和偵查的兩個面向,最後也要回歸法律面和偵查機關的需求,法務部或偵查機關會更清楚知道犯罪人的手法和犯罪困境,以及必須借用哪些科技手段。
楊明佳法官另外指出,科技偵查要考慮隱私權侵害的程度。草案對於隱私空間的區分方式,可能會造成人民權利侵害的結果。此外,也要考量偵查方法究竟是秘密還是公開為之,更要考慮時間長短是否合理,或者有更細緻的規劃。楊法官並引述司法院釋字第631號解釋解釋文:「國家採取限制手段時,除應有法律依據外,限制之要件應具體、明確,不得逾越必要之範圍,所踐行之程序並應合理、正當,方符憲法保護人民秘密通訊自由之意旨。」,強調要件要儘可能合理明確。
楊明佳法官認為,監督機制也很重要。在通保法上,通訊監察分成建置機關和執行機關。建置機關的資訊是客觀而無法人為調整的,同時搭配相關的監督考核機制,讓建置機關的運作可以公正客觀。但目前科技偵查法草案的規定,大部分是誰有設備就可以做。例如手上有高倍數相機,就能對人家家裡拍照,有M化車就能今天開甲地明天開乙地。楊法官並質疑,如何透過事後監察達到有效管控。此外,證據能力的部分,草案第27條和刑事訴訟法第158-4條都是權衡的方式,是否還要在草案規定、目的是什麼。
顧正德法官也針對草案中的各種偵查手段提出其看法。首先,科技設備在特性上可以長時間進行紀錄,也可以進行分析,甚至可以侵入隱私空間偵查。而即使是非隱私空間,長時間的監看累積,也可以呈現圖像式的生活模式,就是憲法所要保障的隱私權範圍──時間短暫可能沒有侵害,累積到一定量時就會有侵害,所以沒有法官保留就會有違憲之虞。
關於戶外的非隱私空間,顧法官表示還是有合理隱私期待的可能性。至於法官保留的時間長短可以再詳細討論,例如德國規定實施連續24小時或者間斷實施2日,就要法官保留。而科技偵查法草案規定,追蹤位置在2個月以內是檢察官保留,超過才是法官保留,時間會不會太長?時間又要如何計算和監督?顧法官並提出警告,如果沒有做好,會等於空白授權。
此外,顧法官認為,依法院的見解,GPS和M化車會侵害人民隱私權和資訊自主權,裝設裝置也侵害財產權,可能一開始就有法官介入的必要。也要進一步思考,人臉辨識能否使用在追蹤位置?外國有在進行,但會傷及無辜,因此雖然要允許追蹤位置的科技偵查手段,但有些手段是否也應該禁止呢?
至於對隱私空間的科技偵查,顧法官指出,問題首先在於是否允許國家透過科技手段偵查屋內隱私。如果真的有必要,除了法官保留,也要提高門檻和建立監督機制。草案雖然採取相對法官保留的立法模式,如果只需要「相當理由」,可能也無法發揮司法審查的功能。另外,如果未來技術允許,是否可以允許從戶外透過網路打開屋內的手機鏡頭或麥克風?如果不允許,或許要立法絕對禁止。
最後,關於設備端通訊監察的部分,顧法官認為這也是一種通訊監察,並建議可以放入通保法,不要立在專法再準用。此外,顧法官也質疑技術上是否能做到只擷取通訊隱私,以及如何區別通訊隱私和其他隱私(包括照片或上網紀錄等個人隱私)。如果要用人工識別而可以事前接觸資料,就會有問題。
除了前面的議題,還有兩個問題被熱烈討論了一番。
【問題1:電磁紀錄搜索扣押,會不會及於雲端資料?】
周冠汝專員對電磁紀錄搜索扣押範圍提出質疑。首先是透明程度的問題。周專員問道:過去台權會在看統計資料時,搜索票部分的電磁紀錄統計,有多少只涉及裝置,又有多少是取得裝置後再進入其他設備或登入雲端硬碟?周專員表示,如果搜索票聲請書單純只寫電磁紀錄,法官可能很難衡量侵害程度。第二,是否能搜索遠端電腦或雲端資料,涉及存取權的問題。例如協作的文件,是不是屬於通訊的一部分?而且雲端資料也不是單一個人擁有存取權限。周專員也質疑,會不會建置資料庫,供本案或他案使用?王怡婷律師也詢問,電磁紀錄的搜索扣押,是否包括網路銀行的帳號密碼和連接後的交易資訊。
黃致中檢察官說明表示,對於電磁紀錄的搜索統計資料要再確認,但應該沒有單獨統計雲端的部分。而草案關於電磁紀錄搜索扣押範圍的部分,只是澄清性的規定,立法理由也說明是現行刑事訴訟法的補充性規定,所以不會成為遠端搜索的授權依據。至於協作文件的取得,和通訊並沒有關係,因為不是監視製作文件的往來過程。最後,設備端通訊監察的相關規定,是從通保法移植而來,因此不會包括諸如輸入帳號密碼等通訊以外的事項。如果會造成這樣的誤解,會回去研究怎麼樣不造成誤解。
林達檢察官也分享辦案的實務經驗。在偵查機關扣押手機後,會先用飛航模式斷開連線,避免檔案被從遠端消除。而遠端空間的規範,還涉及到軟體的具體功能,例如把擋案存在手機裡,或手機上只有檔名和路徑──如果涵攝到具體案例,就有很多特殊的功能。
陳奕廷律師質疑,搜索票有空間上限制,那如果要搜索電磁紀錄,是要在搜索票上表明針對具體硬體,還是可以對遠端附帶設備進行附帶搜索?美國法上正反意見都有,是有爭議的事項,是否能立法直接包含呢?就像搜索到鑰匙,是不是可以拿鑰匙去把門打開?
【問題2:對隱私空間進行科技偵查的重罪原則?】
李宜光律師表示,對隱私空間應該要特別重視,但是草案第9條第1項規定最「重」本刑三年以上有期徒刑之犯罪,就能採取對隱私空間的監控,連竊盜和傷害罪等輕罪都會包含在裡面,因而質疑是否有寫錯字,並主張應該改成「最『輕』本刑三年以上有期徒刑」。
法務部黃致中檢察官解釋說,這條規定並沒有寫錯,如果認為範圍過大可以討論。而如果是「最『輕』本刑三年以上有期徒刑」,那和誘罪就完全不能用,所以在討論犯罪範圍時,應該要思考哪些犯罪會用到這樣的偵查手段。法務部李濠松副司長補充說明,通保法關於調取票的要件,就是規定最「重」本刑三年以上有期徒刑,通訊監察書才是最「輕」本刑,這是因為隱私權干預程度不同,就設定不同的門檻。
對此,陳奕廷律師認為,該規定是「大監聽」的復活,因此不是法官保留的問題,而是國家能不能做的問題,並對本條規定持保留態度。
李宜光律師更表示訝異,最重本刑三年以上的話,傷害罪等輕罪就能適用。另外,該規定涉及隱私空間,要件也只是「相當理由」,對人權的侵害將難以想像,因為條件寬鬆、罪名很輕,侵害範圍又是隱私空間,手段也有錄影,時間更可以到30天,所以從憲法來看,很難通過比例原則的挑戰。此外,在一般人可以共見共聞的範圍內,雖然沒有隱私權的保障,但一般是指在民事法律的狀況。國家動用公權力監察人民隱私,應該受到更嚴格的限制。李律師並認為,只要是有隱私的合理期待,就像美國大法官說的,就應該要聲請令狀向法院聲請。如果有可能侵害隱私空間,應該檢具證據向法院聲請,而不要任意為之。
林永頌律師則表示,在法律設計上,不是只有「最重本刑」或「最輕本刑」的規範方式,如果有犯罪具體情形上有其需要,那就明列出來。
──────────────
快樂的時光過得特別快,在經過了三個多小時的假公聽會真研討會之後,又到了時間吃午餐。我相信,這樣一場面對面的公聽會,是促進官方和民間理性討論和完善制度最好的方式,更期待未來在規範的制定和政策的研擬上,能有更多對話而非衝突的空間。
內部應用程式分享功能已關閉 在 出手了!Apple 關閉Facebook 開發內部iOS 應用程式功能 的推薦與評價
他們已撤銷了任何破壞該協議開發商的發行許可,「我們必須保護 ... 參與多場精彩的技術演講和實戰工作坊,探索無伺服器和容器應用的最佳實踐和案例分享。 ... <看更多>
內部應用程式分享功能已關閉 在 Facebook Android SDK 變更紀錄 的推薦與評價
已經 為Android TV/Fire TV 應用程式新增「Smart Login」功能。如需詳細資訊,請參閱部落格文章。API 無須進行任何變更即可使用這項新功能。 修改項目. ... <看更多>
內部應用程式分享功能已關閉 在 為什麼RD 給的Android App Bundle 連結不能用! - Coding Story 的推薦與評價
... 內部應用程式分享功能已關閉」這種,連結點開後, ... 接著找到「內部應用程式分享」,開啟它. 噹噹~ 搞定 ‼️ 特別提醒,開啟內部應用程式分享,代表你 ... ... <看更多>