比爾・蓋茲:AI 有風險,但是可控

五月 17, 2024 by · Leave a Comment
Filed under: killtest 

为开发者服务的 21CTO
導讀:蓋茲最近的說法,AI存在著風險,但整體可控。
北美當地時間 7 月 11 日,比爾・蓋茲(Bill Gates)在個人部落格中發表了一篇文章,他闡述了對當下人工智慧發展的一些看法。

比爾・蓋茲:AI 有風險,但是可控
640
图片来源:gatesnotes 站点
這篇部落格文章題為《AI 確實存在風險,但是可控》,蓋茲在其中提到了當前 AI 具有五大風險。

概要如下:

AI 產生的錯誤訊息、深度偽造訊息,可能被用來欺騙民眾;

AI 可以自動檢索電腦系統中的漏洞,這大大增加網路攻擊的風險;

AI 可能會搶走人們的工作;

AI 系統會編造訊息,並表現出偏見;

使用 AI 工具可能意味著學生無法學習基本技能,如論文寫作,同時也擴大教育成就差距。

比爾・蓋茲也強調說,這並不是新技術首次導致人力資源市場發生巨變,AI 帶來的影響雖不及工業革命那般巨大,但肯定比得上 PC 問世所帶來的影響。

同時,比爾・蓋茨指出,“我們有更多理由樂觀地認為,人類可在處理 AI 風險時,最大限度地發揮自身優勢,但我們需要快速行動”,他提出如下幾點建議:

各國政府需累積 AI 的知識,以便推出應對 AI 的相關法律法規,如法律需明確哪些使用「深度偽造」的情形是合法的或違法的。

私人 AI 企業需保障自身能夠安全、負責地開展工作,包括保護隱私、確保 AI 模型符合人類價值觀、最大限度減少偏見、使技術盡可能受惠於大眾且防止被犯罪分子利用。

最後,比爾蓋茲鼓勵大家盡可能關注… Continue reading

防火牆術語

五月 10, 2024 by · Leave a Comment
Filed under: killtest 

防火牆術語

01 網關
在兩個設備之間提供轉發服務的系統。

網關是互聯網應用程式在兩台主機之間處理流量的防火牆。

這個術語是非常常見的。

02 DMZ非軍事化區

為了配置管理方便,內部網路中需要向外提供服務的伺服器往往放在一個單獨的網段,這個網段便是非軍事化區。

防火牆一般配備三塊網卡,配置時一般分別分別連接內部網,Internet和DMZ。

網路中的資料由一個個資料包組成,防火牆對每個資料包的處理要耗費資源。

吞吐量是指在不丟包的情況下單位時間內通過防火牆的資料包數量。 這是測量防火牆性能的重要指標。

04 最大連線數

和吞吐量一樣,數字越大越好。

但是最大連線數更貼近實際網路情況,網路中大多數連線是指所建立的一個虛擬通道。

防火牆對每個連線的處理也好耗費資源,因此最大連線數成為考驗防火牆這方面能力的指標。

封包轉送率:是指在所有安全規則配置正確的情況下,防火牆對資料流量的處理速度。

05 SSL

SSL(Secure Sockets Layer)是由 Netscape 公司開發的一套Internet 資料安全協定。

它已被廣泛地用於網頁瀏覽器與伺服器之間的身份認證和加密資料傳輸SSL協定位於TCP/IP 協定與各種應用層協定之間,為資料通訊提供安全支援。

06 網路位址轉換

網路位址轉換(NAT)是一種將一個IP位址域對應到另一個IP 位址域技術,從而為終端主機提供透明路由。

NAT包括靜態網路位址轉換、動態網路位址轉換、網路位址及連接埠轉換、動態網路位址及連接埠轉換、連接埠對映等。

NAT常用於私有位址域與公用位址域的轉換以解決IP位址匱乏問題。

在防火牆上實現NAT後,可以隱藏受保護網路的內部拓樸結構,在一定程度上提高網路的安全性。

如果反向NAT提供動態網路位址及連接埠轉換功能,還可實現負載平衡等功能。

07 堡壘主機

一種被強化的可以防禦進攻的計算機,被暴露於因特網之上,作為進入內部網絡的一個檢查點,以達到把整個網絡的安全問題集中在某個主機上解決,從而省時省力,不用考慮 其它主機的安全的目的。

05.硬體防火牆和軟體… Continue reading

企業傳統資料庫遷移到國產或開源資料庫的六個重要階段

五月 3, 2024 by · Leave a Comment
Filed under: killtest 

韩锋频道 twt企业IT社区
【導讀】越來越多的企業正面臨將傳統資料庫遷移到開源或新型商業產品上,本文整理了在此過程中,困擾企業的一些常見問題,結合整個遷移過程中的六個階段進行說明, 這是一篇優秀的實用文章。 希望對讀者在資料庫選用及評估資料庫遷移風險等方面有所啟發。
【作者】韓鋒,CCIA(中國電腦協會)常務理事,前Oracle ACE,騰訊TVP,阿里雲MVP,dbaplus等多家社群創辦人或專家團成員。 有著豐富的一線資料庫架構、軟體研發、產品設計、團隊管理經驗。 曾擔任多家公司首席DBA、資料庫架構師等職。 在雲端、電商、金融、網際網路等產業均有涉獵,精通多種關聯式資料庫,對NoSQL及大數據相關技術也有涉獵,實務經驗豐富。 曾著有資料庫相關著作《SQL優化最佳實務》、《資料庫高效優化》。

隨著近年來資料庫的變化,正有越來越多的企業面臨將傳統資料庫遷移到開源或新型商業產品。 在這過程中,會面臨諸多問題。 這裡就將常見的一些問題整理出來,希望能夠在資料庫選型及評估資料庫遷移風險等方面有所幫助。 為了描述清晰,我將整個遷移過程劃分為幾個階段,其中橙色標識工作為資料庫團隊來支援。 以下將就每個階段,詳細展開說明。
640 (1)
1. 階段:遷移準備
1) . 遷移規劃

在進行遷移之初,首先要對遷移工作做個整體規劃,並制定好對應的原則方針。 例如明確遷移範圍、遷移方式、是否可停機、窗口期等等。 這些資訊是作為後續遷移的指導原則,遷移方案的發展很多需依靠這項規劃。 要避免出現快要遷移,發現預期不符合要求的狀況,提前做好必要的規劃。 此外,除技術因素外,其他如組織、管理、資源等,也在此階段一併考慮。 遷移是個很複雜的過程,涉及的各個面向很多,盡量在專案之初就有個全面的掌握。

2) . 業務梳理

要完成資料庫遷移,上層的業務系統也是需要考慮的,甚至在某種程度講,配套的應用遷移更加重要,在後續的遷移過程中佔比也更高、難度也更大。 因此,在遷移準備階段,就對涉及的業務有個全面的梳理非常有必要。 這裡需要梳理的訊息,非常廣泛。 包括但不限於對業務系統涉及的軟硬體環境、與資料庫互動、業務系統間呼叫關係等。 後續在做應用系統改造規劃中,上述資訊非常重要,其有助於評估工作困難、工作量等。 這裡舉個例子,某系統之前使用Oracle,開發採用C語言,在遷移到某國產庫時發現,資料庫不支援C driver,好不尷尬。

3) . 方案選型

在做好業務整理後,就是資料庫選型。 這過程也是遷移準備階段比較耗時的工作。 如何從眾多的資料庫產品中選擇一款符合自己要求的,要考慮的因素很多。 比較建議的做法,是在公司內部之前就制定出推薦的方案矩陣,根據對資料庫能力需求、系統重要程度等,制定一個產品選型矩陣。 如果前期有這個基礎,就比較簡單,只要按圖索驥即可。 如果沒有的話,需要從頭完成一連串的工作,包括初步研究、技術評估、資料庫評測(功能、非功能、業務等)、適配性評估等。 這裡強調一個原則就是盡量在方案選型中保持最大的自由度,也就是不綁定單一廠商,隨時保持可替換能力。 因此在方案選用中,不能本著業務少改造、遷移最簡單、成本最低的方案,而是應選擇長期可替代的原則。 建議的做法是選擇相容通用協定的產品,盡量弱化資料庫端能力,選擇使用標準資料庫功能的產品最好。

4) . 技術培訓… Continue reading