分類: killtest

1、雲端運算與虛擬化
可以說虛擬化是雲端運算的技術基石，同時雲端運算也是虛擬化技術的進一步發展、變革和昇華。 透過對實體設備進行虛擬化，包括運算虛擬化、儲存虛擬化、網路虛擬化等技術，將 IT 基礎資源進行池化，對上層應用屏蔽底層實體設備，進一步提高資源利用率和系統的穩定性。

虛擬化最早的使用場景多為企業內部使用，這也是企業私有雲得以快速推廣實施的重要原因之一。 但相比虛擬化，雲端運算在彈性伸縮、租戶管理、按需調配及編排、自助計費、 IT 營運等方面得到了長足的補充、提高和完善，並且可以支援超大規模的計算和存儲，跨 區域的網路架構等。

雖然雲端運算最早是基於虛擬化這項技術基石，但隨著近幾年的快速發展， 雲端運算已經完美支援ironic 裸設備、 Docker 容器化等技術，並且相互補充、相互完善，共同促進了整個雲 計算生態圈的發展與完善，為不同的應用場景提供不同的最佳技術實務。

2、雲端運算與容器化
容器化是最近幾年呼聲很高、討論很熱的一種技術解決方案，大有取代雲端運算、雲端平台的風頭，網路上也有類似的論調。 對此，我以為容器化應該是雲端運算的組成部分之一，跟虛擬化技術一樣，可以成為雲端運算的技術基石之一，並且二者在某種程度（穩定性、安全性以及主機隔離性 ）上，二者應該是可以互相補充、互相完善的。

容器化比較適合輕應用部署，其對微服務具有天然的支持，透過工具鏈構築DevOps 持續交付平台，可以大大的提高交付效率，特別對於需求多變、迭代頻繁的業務場景，可以極簡地縮短 交貨時間、提高交付效率，同時也可以快速應對訪問量陡增陡減情況下的快速伸縮。

但是，對於傳統的中大型系統（微服務拆分後，比較適合容器化部署，但收益不是很大，因為其係統需求和訪問都相對比較穩定，變化不大）以及數據庫應用不是很適合，就 關係型資料庫不適合容器部署方面，有以下幾點原因：

（1） 資料安全方面的問題：由於容器底層技術的限制性和資料庫底層開發相容方面的考慮，容器運行資料庫會存在資料安全的問題，特別是容器異常或是崩潰，資料庫未完全關閉的情況下 ，會損壞資料；

（2） 資料庫效能方面的問題：追求關係型資料庫或資料倉儲的高效能時，我們往往會採用裸金屬的方式部署，屏蔽作業系統的一部分瓶頸，或是直接在最佳化之後的OS 上部署，同時 資料庫的效能大多出在IO 方面，採用容器部署運行資料庫，層級複雜、 IO 負載進一步提高，會大大影響資料庫的讀寫效能，與資料庫高效能最佳實務相悖。

（3） 天然的對立面：容器技術特別適合部署運行無狀態的服務，並且其資料持久化依賴於外置設備，而資料庫是典型的有狀態的持久化的服務，二者存在對立的情況，強行 在容器跑資料庫需要考慮狀態持續性以及資料持久化兩大因素。

（4） 資源隔離方面：容器技術在資源隔離方面較虛擬化計畫差不少， Docker 是利用 Cgroup 實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程式佔用自己的資源。 如果其他應用程式過渡佔用實體機資源，將會影響容器裡資料庫的讀寫效率。 需要的隔離等級越多，獲得的資源開銷就越多。 鑑於資源隔離的先天不足，在容器整體規劃方面，如果產生統一伺服器上既有應用又有資料庫，那麼在效能方面會相互影響，而在資料庫的最佳實務中，應用程式和資料庫是要分開部署 ，其二者對伺服器資源的需求也是大不一樣的。

但是仍有部分企業將資料庫部署在容器中，特別是 MySQL ，我認為這也是有一定業務場景支持，也是比較合適的。 如：對負責系統進行微服務拆分和資料庫拆分，每個服務對應相應的資料庫，二者綁定較深，這種情況下為了便於管理和擴展，是適合容器部署的，但是在擴展方面 需要結合資料庫的高可用和讀寫分離架構進行；另外還有一種是比較適合運行的，如資料庫本身就是分散式的資料庫且所儲存的資料並不敏感，安全性要求不高，如網站的流量 分析、搜尋的索引詞儲存等，可以利用分佈資料庫的分片來增加實例數，進而增加吞吐量。

3、 IaaS 、 PaaS 、 SaaS 等
從系統的組成架構面來看，其構成關鍵從實體底層到應用資料的參與因素有 3 個部分：

（1） 基礎設施：底層實體設備包括機房、網路、儲存、實體機器以及虛擬化和作業系統等。

（2） 操作平台：系統運作時的中間件、中間設備等。

（3） 軟體和資料：應用程式碼套件和資料等內容。

依照自己管理和雲端平台管理的範圍簡單劃分 IaaS 、 PaaS 和 SaaS, 具體如圖：

其中 IaaS 成為基礎設施及服務，解決的是維運人員的主要問題，面向維運主題。 主要透過雲端平台技術對資料中心機房、網路、儲存以及運算等實體設備（包括安全設備）進行資源池化，為上層應用提供底層的資源支持，並且圍繞池化後的資源提供租戶管理、自助申請 、彈性伸縮以及相應的維運輔助等服務，進而為IT 建設和管理屏蔽掉底層的複雜性，使其可以更加專注關心上層建設。

PaaS 為平台即服務，多面向於開發者，為系統運作提供必要的開發元件和中介軟體的支援。 透過 PaaS 平台可以為開發者提供快速的環境支援和能力沉澱，大大提高開發效率。

SaaS 為軟體即服務，面向業務人員，透過 SaaS 服務直接提供企業業務所需的系統和數據，不需要本地維運部署和開發，所見即所得，按需申請和使用服務。 常見的有 Google 的 DOC 服務、 salesforce 的 CRM 、有贊雲商城、釘釘辦公室、問卷星、黃金資料等。 使用SaaS 服務可以為中小企業大大的降低IT 資金投入，同時有效地借鑒廠商的最佳實踐，可以盡快的驗證和輔助業務的快速增長，但是隨著業務的發展，特性化和差異化的需求越 來越多時， SaaS 廠商不一定能夠快速回應。 不過 SaaS 服務市場仍有著巨大的潛在價值。

除了上述的IaaS 、 PaaS 、 SaaS 三種服務外，常見的還有CaaS 、 DBaaS 、 FaaS 等, 這些大多是從某一技術類型而言的，如CaaS 容器及服務，透過容器雲平台的建設，結合 DEVOPS 工具鏈充分發揮容器的部署、編排等優勢打造持續高效的交付平台；如DBaaS, 透過建構統一的資料庫平台為業務系統提供穩定、高效、快速的資料庫服務，並且統一管理、統一監控、統一備份 ，對效能方面提前優化和持續優化，可以有效降低資料庫的運維成本提高資料庫運作效率。

4、私有雲、公有雲、專有雲、混合雲和多雲
上述雲端運算的標準定義中講到，依照部署模式來看，雲端運算分為私有雲、公有雲、專有雲、混合雲四種模式。 其實四種模式的理解也比較容易，私有雲即企業內部實施部署、管理與運營，僅供企業內部各業務部門或是各分子公司使用，具備雲的基本屬性；公有雲為大型IDC 廠商或雲 服務商承建及經營，企業作為使用者或租戶，不需要本地實施建設，租用其資源或服務；專業雲多具備產業屬性，是對某一產業進行業務系統沉澱、共通抽取進而建設的一種主要 服務某行業的公有雲服務，如醫療雲、金融雲等。

在實際企業 IT 建置與發展中，很少只使用某一種雲端模式，大多根據其業務屬性、分散地域以及業務需求，選擇幾種雲端模式共同承載其係統和數據，即混合雲的模式。 同時為了進一步提高系統的持續可用性，杜絕把雞蛋都放在一個籃子裡規避單一雲（特別是單一公有雲）故障導致的系統中斷，多採用雲上、雲下互備或是多雲混合的模式， 即混合多雲平台。

原创 岱军 云云众生s
UMass Amherst的Baldur方法能夠自動產生用於驗證程式碼、防範漏洞的證明。

譯自Debugging Software Using Generative AI，作者 Jeffrey Burt 是一位資深記者，擁有三十多年的新聞工作經驗，過去二十多年專注於科技領域。 在過去的16年多里，他曾在eWEEK工作，並在之後成為自由科技記者。

自從OpenAI於2022年11月底推出其ChatGPT聊天機器人以來，生成式人工智慧工具和大型語言模型（LLM）的採用只有加速，深入滲透到各種形狀、大小和行業的組織中，而軟體開發人員並 未對其產生免疫。

生成式人工智慧的用例，如內容創作、對話式人工智慧和語言翻譯，在軟體開發中是多樣化且不斷增長的，涉及程式碼優化和生成、錯誤修復、文件編寫以及持續整合等方面。

根據卡內基美隆大學SEI部落格中的AI專家在2023年10月的一篇文章稱，開發人員越來越認為生成式人工智慧是一個有用的工具。

作者寫道：“關於使用LLM進行軟體開發的最初炒作已經開始冷卻，現在的期望更加現實。”，“對話已經從期望LLM取代軟體開發人員（即人工智慧）轉變為將LLM視為合作夥伴， 並集中在最佳應用它們的地方（即增強型智能）。”

LLM和軟體驗證
上個月，由馬薩諸塞大學阿默斯特分校的電腦科學家領導的一組人表示，他們正在利用生成式人工智慧和LLM的力量來解決驗證程式碼的棘手挑戰，以幫助防止軟體中的漏洞。

具體而言，該團隊專注於利用人工智慧開發一種方法，自動產生完整的證明以用於驗證軟體程式碼。 這是一項費時、昂貴且耗時的過程，通常透過手動程序完成。 更困難的過程是機器檢查：創建一個數學證明來展示程式碼是否符合預期，然後使用定理提供者確保證明的正確性。

Emily First在完成她的電腦科學博士學位後成為加州大學聖迭戈分校的博士後研究員，而她在馬薩諸塞大學阿默斯特分校攻讀博士學位期間的研究涉及LLM和軟體驗證，並成為她博士論文的一部分。 她指出，手動編寫證明所需的時間可能比編寫軟體程式碼本身還要多。

因此，根據馬薩諸塞大學阿默斯特分校資訊與電腦科學曼寧學院的教授、本文的高級作者Yuriy Brun的說法，實際上經過正式驗證的系統數量相當有限。

「這很難，」Brun告訴The New Stack。 “這就是我們介入的地方。我們試圖解決的問題是自動產生這些證明。”

不應該接受有錯誤的軟體
這樣做將有助於解決一個更大的問題：軟體中存在缺陷，這可能是煩人的，或者——如果被網路攻擊者利用或存在於可能對廣泛產生負面影響的複雜系統中——是危險 的。

「軟體是我們日常生活中重要的一部分，」布倫說。 「你什麼都做不了。你不能開車，不能坐電梯，都離不開軟體。不幸的是，今天的軟體通常是有漏洞的。我們幾乎期望在商店購買的任何軟體都會有一些錯誤。這只是 一個難以解決的問題，因此有很多不同的方法來嘗試提高軟體的品質。”

其中一個方法是證明軟體是正確的。 這是一種有效的方法，但也是最困難的方法之一。 在某些領域，這已經被實踐，例如在醫療領域用於某些醫療設備或由NASA使用，「因為如果你的太空船上有一個錯誤，你的軟體崩潰了，那將是代價高昂的， 所以實際上有開發人員和軟體工程師正式證明函數的正確性是值得的。」他說。

一些研究人員已經創建了能夠一行一行地寫證明的模型，先寫證明的前10行，然後讓模型基於已經寫的內容以及試圖證明的內容搜索，找出下一行最有可能是什麼。

建構Baldur
馬薩諸塞大學阿默斯特分校的研究人員將目光投向LLM，作為自動產生證明的可能解決方案。 然而，即使這也帶來了挑戰，最大的挑戰之一是這些模型並不總是正確的。 與其崩潰——從而讓開發人員知道有些事情出錯了——它們會“悄悄失敗”，生成一個錯誤的答案但將其呈現為正確的。 悄悄失敗通常是最糟糕的事情，布倫說。

EnterBaldur，這是馬薩諸塞大學阿默斯特分校團隊創建的一種新的基於人工智慧的證明方法。 研究人員使用了Google的Minerva LLM，該模型經過大量自然語言文本的訓練。 然後，它進一步在118GB的數學科學論文和包含數學表達式的網頁上進行訓練，然後在Isabell/HOL上進行了更多的訓練，這是一種用於編寫數學證明的語言。

然後，Baldur產生了整個證明，使用Isabelle，一個定理證明器，對整個世界進行檢查。 如果檢查器發現錯誤，有關錯誤的資訊會回饋到LLM中，以便讓它從錯誤中學習，然後產生另一個證明，減少或——希望是沒有錯誤。

這樣做給了Baldur「一些上下文訊息，以說，『關於狀態，關於你正在回答我的問題的問題，這裡有更多的信息，』」布倫說。 「當我們給它額外的資訊時，它能夠更好地回答問題。我們只修復了一次，但你可以想像多次修復，對於這些一次只能預測一個步驟的模型來說，即使它們使用大型語言 模型逐步預測，這也更加低效。”

Enter Thor
布倫及其團隊（當時還包括在Google工作的Markus Rabe和伊利諾伊大學厄巴納-香檳分校的助理教授Talia Ringer）研究了Thor，一個用於整合語言模型和自動定理證明器的框架。 獨立運作時，Thor能夠在57%的情況下產生證明，他說。

將其與 Baldur 結合——在北歐神話中是托爾的兄弟——他們成功地在65.7%的時間內創建了證明。 這兩種方法互相補充。

Thor「使用大型語言模型嘗試預測證明的下一個可能步驟，但它也使用了一些被稱為『錘子』的東西，」布倫說。 「錘子是這些數學工具，它們說，『我知道一堆數學標籤。讓我嘗試一下。讓我試試這個，試試這個，試試這個。』就像用錘子敲擊問題，嘗試不同的方法 ，看看是否有效。它同時嘗試所有這些方法。”

Baldur方法不同之處在於它創建整個證明而不是逐行進行，儘管存在重疊，他說：「有一些它們都能證明的事情。但透過嘗試一次性生成整個證明，我們能夠證明一組不同的事情 ，而不是嘗試逐步生成一件事。”

仍有更多工作要做
布倫承認錯誤程度仍然很大，但稱Baldur仍然代表了驗證軟體程式碼正確性的最有效和高效的方式。 AI技術不斷改進，因此他預期Baldur的能力也會提升。

在未來，研究人員計劃透過調整LLM訓練的數據來提高65.7%的數字。 對於驗證而言，目前並沒有太多的數據，因此建立數據集並不容易。 他們正在努力創建一個資料集，以便對模型進行微調。

他們還希望使開發人員能夠向模型提供回饋，這將進一步幫助模型在產生證明的過程中不斷成長。

「開發人員說，『好的，運作得很好，』」布倫說。 「但如果它沒有運行，開發人員通常可以查看[然後說]，『我看到你在這裡嘗試了歸納，但你把它用在了錯誤的地方。』 它可以向模型提供一些反饋，然後模型 可以再次嘗試。這種迭代的方法很可能真正簡化開發人員的工作，但也使模型能夠證明它自己無法完成的事情。”

這創造了一種半自動化的方法。

「原始的迭代方法不涉及開發人員，」他說。 「它是在自己進行迭代，一次只做一件事，因為它是……自己進行所有操作，自己檢查。我們試圖重新引入軟體工程師到這個循環中，因此這是一種半自動化的方法，我們 在很多自動化方面做了很多工作，但然後我們從工程師那裡得到了一些反饋，以引導在我們無法自行完成整個過程的情況下進行處理。”

研究人員從2020年開始致力於這個挑戰，但Baldur的工作始於2023年5月，從在Google內部建構到評估和確保科學正確性，歷時約五個月。 該計畫得到了國防高級研究計劃局（DARPA）和國家科學基金會的支持。