分类: News

IT資訊新聞

  • LPIC-1 Exam 101 Objectives

    Exam Objectives Version: 5.0

    Exam Code: 101-500

    關於目標權重:每個目標都分配有一個權重值。 權重表示考試中每個目標的相對重要性。 考試中將涵蓋權重較高的目標,並包含更多問題。

    Topic 101: System Architecture

    101.1 Determine and configure hardware settings

    Weight 2
    Description Candidates should be able to determine and configure fundamental system hardware.

    Key Knowledge Areas:

    • Enable and disable integrated peripherals.
    • Differentiate between the various types of mass storage devices.
    • Determine hardware resources for devices.
    • Tools and utilities to list various hardware information (e.g. lsusb, lspci, etc.).
    • Tools and utilities to manipulate USB devices.
    • Conceptual understanding of sysfs, udev and dbus.

    The following is a partial list of the used files, terms and utilities:

    • /sys/
    • /proc/
    • /dev/
    • modprobe
    • lsmod
    • lspci
    • lsusb

     

    101.2 Boot the system

    Weight 3
    Description  Candidates should be able to guide the system through the booting process.

    Key Knowledge Areas:

    • Provide common commands to the boot loader and options to the kernel at boot time.
    • Demonstrate knowledge of the boot sequence from BIOS/UEFI to boot completion.
    • Understanding of SysVinit and systemd.
    • Awareness of Upstart.
    • Check boot events in the log files.

    The following is a partial list of the used files, terms and utilities:

    • dmesg
    • journalctl
    • BIOS
    • UEFI
    • bootloader
    • kernel
    • initramfs
    • init
    • SysVinit
    • systemd

     

    101.3 Change runlevels / boot targets and shutdown or reboot system

    Weight 3
    Description Candidates should be able to manage the SysVinit runlevel or systemd boot target of the system. This objective includes changing to single user mode, shutdown or rebooting the system. Candidates should be able to alert users before switching runlevels / boot targets and properly terminate processes. This objective also includes setting the default SysVinit runlevel or systemd boot target. It also includes awareness of Upstart as an alternative to SysVinit or systemd.

    Key Knowledge Areas:

    • Set the default runlevel or boot target.
    • Change between runlevels / boot targets including single user mode.
    • Shutdown and reboot from the command line.
    • Alert users before switching runlevels / boot targets or other major system events.
    • Properly terminate processes.
    • Awareness of acpid.

    The following is a partial list of the used files, terms and utilities:

    • /etc/inittab
    • shutdown
    • init
    • /etc/init.d/
    • telinit
    • systemd
    • systemctl
    • /etc/systemd/
    • /usr/lib/systemd/
    • wall
  • SPRING和JAVA如何塑造內部開發者平台

     岱军 云云众生s

    Java 和 Spring 為開發過程帶來的靈活性,影響了目前 IDP 實作標準化和效率的方式。

    譯自How Spring and Java Shaped Internal Developer Platforms,作者 Charles Humble。

    我早就注意到Java促進了編寫程式碼的異常一致的方法。 該語言的表面積相對較小,幾乎沒有粗糙的邊緣,這使得開發人員從一個 Java 專案遷移到另一個專案非常簡單。 對於建構或維護內部開發者平台(IDP) 的任何人來說,教訓是促進一致性真的很重要。

    雖然這始終適用於 Java SE,但並不總是適用於其擴充功能。 如今,企業 Java 開發人員有許多優秀的框架可供選擇,但有一定年齡的人可能還記得在 2000 年代初使用 J2EE 進行程式設計的情況。 J2EE 標準於 1999 年底推出,它使用 Web 和分散式企業應用程式規格擴展了 Java SE,這些應用程式可以部署在諸如 BEA WebLogic 或IBMWebSphere 等應用程式伺服器上。

    J2EE 標準被廣泛採用,但因難以使用而聲名狼藉。 該規範的某些部分,尤其是 IBM 開發的原始企業 JavaBean (EJB) 規範,確實很複雜,並且帶來了相當大的效能損失。 例如,EJB 僅允許透過諸如公共物件請求代理體系結構 (CORBA) 等協定進行遠端方法調用,這與大多數其他業務應用程式形成對比。

    此外,當時設計的應用程式伺服器可以啟動一次並在沒有中斷的情況下運行數月甚至數年。 正如 Java 冠軍Holly Cummins 所解釋的那樣,BEA、IBM 和其他支援完整 J2EE 規格的供應商做了一些非凡的工程工作來實現這一目標。 缺點是啟動它們(就像在開發程式碼時經常做的那樣)需要幾分鐘。 這使得開發人員難以保持流程;作為一名英國人,我過去每次必須重新啟動開發伺服器時都會泡一杯茶(並且經常喝掉),這似乎更多的提升了Twinings 的銷售,而不是我的 編碼效率。

    笨重、緩慢且昂貴
    此外,打包和部署用於生產的 J2EE 應用程式很麻煩。 「我參與其中,」DaShaun Carter解釋道,他是 VMware Tanzu(Broadcom 的一個部門)的研究開發軟體工程師和 Spring 開發人員倡導者。 當 Carter 在一家能源公司擔任 J2EE 開發人員時,他的職責是進行建造。 「當我開始時,構建需要一周時間,並且該規範有 12 個人將 J2EE 應用程式投入生產,」他說。 Carter 能夠使用 Apache Ant 和各種自訂外掛程式來縮小流程。 “我們處於每週構建和測試的周期中,但生成所有 WSDL [Web 服務描述語言文檔] 和構建應用程序仍然需要四個小時。”

    開發工具也很昂貴。 Carter 說,他們的一個工具,統一建模語言工具 Rational,每個席位需要 20,000 美元才能擁有每個開發人員所需的一切。 「這太荒謬了,」他說。

    Spring 的興起改變了範例
    2004 年推出的 Spring 框架做了一些重要的事情。 首先也是最重要的,它推廣了依賴注入的概念,其核心是控制反轉 (IoC) 容器。 它還表明,可以在諸如 Apache Tomcat 等更輕量級的 servlet 容器之上建立更簡單的 Web 和分散式應用程式。 這些應用程式啟動得更快,使開發人員能夠快速成功地開始工作,而且它們仍然是開源且免費的。 大約在同一時間,諸如 Eclipse 和 NetBeans 等開源整合開發環境 (IDE) 開始取代專有 IDE 產品,進一步降低了成本。

    Spring 還提供了一種使用 Java SE 提供的相同編碼一致性來建立企業應用程式的方法。

    不過它並不完美。 Spring 不幸的是在 XML 流行的高峰期開發的,它對 XML 的依賴造成了配置方面的問題。 隨著框架中添加了更多功能,Spring 也被認為過於複雜。

    2006 年在 Java SE 6 中採用註解作為 XML 的替代方案,在一定程度上幫助 Spring 團隊減輕了配置複雜性。 然而,最終最大程度地減少配置問題的,是受 Ruby on Rails 啟發的 Spring Boot,它提供了關於如何建立 Spring 應用程式的高度主觀視圖。

    IDP 如何減少摩擦
    Spring Boot 也透過 Initializr 和start.spring.io推動了模板化的想法。 「這是我了解 IDP 概念的開端,」Carter 說。 “我可以獲取我需要的東西,例如 Spring Data 和 Spring Web,並按需組合在一起。使用 IDP 方法,模式及其原因定義明確,因此它創造了良好的開發者體驗。”

    Initializr 提供了護欄,並允許開發者快速啟動並運行。 「我可以立即開始並期待快速交付,因為 IDP 提供了大量資訊和範例,例如我們如何處理日誌和指標等,」Carter 解釋說。

    在此背景下,IDP 充當傳播者,在公司內部傳播模式,打破孤島並減少摩擦。 正如VMware Tanzu 在Broadcom 的研究和開發高級總監James Watters所說,「它減少了安全性、架構和開發團隊之間的界限。」最終,目標是讓IDP 充當快速反饋、可組合性和模式擴散的真正 切入點,尤其是在大型組織中。

    以 Spring 為藍本的 IDP 降低了開發者的靈活性,但 Watters 借用雲端運算進行了類比,解釋了為什麼這可能是一件好事:

    「雲端運算在很大程度上減少了對第2 層網路的依賴。你無法自訂第2 層網絡,就像你可能在資料中心中所做的那樣。但你可以獲得一個可彈性使用的可 擴展模型。我認為帕累托效率適用於網絡,一直到應用程式模式,而這是IDP 擅長的領域。Cloud Foundry是模式力量的早期指標之一,我認為我們已經看到了許多其他模式的出現, 包括應用程式模板化、預設安全性和建立服務模板化。如果你考慮Google Cloud Run或Azure Container Apps,整個行業都開始表示模式是實現效率和預設安全性的非常好的方法。”

    此外,由於 Initializr 是開源的,並且在其下方有完整的 Spring 框架,因此組織可以根據其需求和文化進行調整。

    Garmin 如何使用模式和自動化
    消費性電子公司 Garmin 的私有雲平台架構師Jonathan Regehr表示,這是他們採取的方法。 作為黑客馬拉鬆的一部分,Garmin 建立了一個工具,最好將其描述為早期後台類型的門戶。 它會產生一個骨架程式碼庫並將其載入到 Git 儲存庫中。 它還會建立 Jenkins 作業,首次運行它並將應用程式骨架一直推送到生產環境,因此開發者只需編寫程式碼即可。 「這個笑話是,你填寫一份表格,小睡一會兒,醒來後就可以開始編碼了,」Regehr 說。

    他承認,該工具現在已經相當老了,他的團隊正在尋找替代品。 即便如此,這也展示了使用模板和自動化來入門的力量。 「如果你仔細考慮監聽器之類的內容,它就是一個模式。我不應該關心如何獲取事件或處理一致性;讓模式處理這些問題,我只需要監督業務價值部分,」Regehr 說。

    當工程師在團隊之間移動時,這種傳播模式的方法具有進一步的優勢,因為它提高了一致性。 正如Monzo Bank 的高級員工工程師Suhail Patel在2022 年解釋的那樣,「[在Monzo] 當你開始處理微服務時,有一條明確的鋪就道路,因此它們看起來都非常統一。你可以為其他團隊 的服務做出貢獻,因為該結構對你來說完全熟悉。”

    Regehr 也同意這個想法。 「我認為你不能指望把某人放到一個專案中,然後讓他們立即發揮作用。人們在加入團隊後會有一個學習曲線。但如果部署相同,程式碼庫看起來相同,並且所有內容的佈局相同 ,他們會說,’好的,我需要了解你的業務邏輯,但其他部分都很容易。’”

    可擴展性取決於決策
    Monzo 和 Garmin 也說明了在平台內做出選擇的重要性。 「建構平台團隊的大規模參與者往往有兩種到四種關鍵模式,」James Watters 說。 “他們概述瞭如何擴展 Java 服務或 Go 服務,而不是嘗試為開發人員可能擁有的每個打開的標籤頁構建一個門戶。這兩種方法非常不同。”

    Garmin 對叢集配置採取了類似的方法。 從語言和運行時角度來看,該環境是混合的。 Garmin 約 70% 的程式碼(Web 應用程式和偵聽器的混合)是用 Java 編寫的。 該公司也運行大量Node.js和 .NET,一些Python和少量 PHP。

    Garmin 運行兩個平台:Red HatOpenShift 用於 Kubernetes 工作負載,而 VMware Tanzu Application Service(部分客戶仍將其稱為Pivotal Cloud Foundry(PCF))用於其餘部分。 隨著數百名開發人員使用VMware Tanzu 平台,Garmin 在一個非生產環境和四個生產基礎上運行超過 9,000 個應用程式實例。 它使用多雲基礎設施,部分原因是收購,也運行一個大型私有雲。

    Regehr 的團隊完全在內部工作,他們遵循「自動化一切」的範例。 例如,為了管理他們的Kubernetes集群,他們編寫了 140,000 行自動化程式碼。 開發人員貢獻少量配置程式碼,並由此和他們的自動化產生所有必需的叢集配置,並將它們放入儲存庫中。

    「我們正在自動生成 110 萬行集群配置,Argo CD正在噴射和建立集群,」Regehr 說。 “我們使用生成存儲庫來執行此操作,這意味著如果我犯了一個錯誤,我可以查看錯誤並修復它,而不是集群因我而消失。”

    短暫基礎建設的優勢
    這種級別的自動化允許基礎設施團隊將所有內容視為短暫的。 「一個例子是Concourse,」Regehr 解釋說。 「我們有一個與每個Tanzu 平台部署配對的Concourse 實例,該實例處理特定於該基礎的自動化。如果Concourse 的磁碟空間用完或其資料庫損壞,解決方案始終相同——燒毀Concourse,運行自動化腳本重新 部署Concourse,然後運行我們的“UpdatePipeline”管道。這個Concourse 看起來與10 分鐘前完全一樣,除了減少了一些作業運行歷史記錄。”

    Regehr 說,採取這種方法也有助於 Garmin 提高安全性。 「如果你想讓駭客一無所獲,其中一種方法就是如此快速地重建你的基礎設施,即使他進入伺服器並構建了他的『邪惡框架』,它也會消失得如此之快,以至於他無法在 它再次消失之前重建它。”

    這可能對基礎設施有效,但程式碼本身呢? James Watters 說,“在我進行的對話中引起共鳴的頭號話題是:我們如何在規模化組織中默認變得更加安全?”

    James Watters 認為,開發者平台充當起點,提供標準化的應用程式模式和整合程式庫,讓你對應用程式進行身份驗證。 「我們還擁有一個預設安全的建置系統,該系統已重新註入 IDP,並且我們可以在創建應用程式的確切時刻提供快速的安全記分卡,」他說。 IDP 還可以向開發人員發出警報,例如,“你知道這個應用程式中存在漏洞並且有可用的修復程式嗎?你想應用它嗎?”

    VMware Tanzu 團隊正在探索人工智慧對產業的影響,其中一些工作已經透過Spring.ai可見。 James Watters 說他對人工智慧的重要性感到“震驚”,但他也看到了安全方面還有很多未完成的工作。 「做更多的事情來自動化安全任務並建立更多模式化和安全的系統,這是我們的客戶希望看到的,」他說。

     

  • 區域網路ip位址不夠用腫麼? 用這三種方法,可以完美解決?

    通信弱电交流学习

    如果是在一個小型的區域網路裡可能完全不必要考慮IP位址不夠的情況,但是在超過「255台」電腦的大型區域網路裡,就必須要考慮電腦IP位址不夠用該如何解決了。

    很多時候企業區域網路出現私網路位址192.168.1.x-255不夠用了,去掉一個廣播位址及一個網路位址後就可能不夠用。 (0是網路位址不可用, 255是廣播位址,除去這2個,可用的就是254個位址)。

    那麼如何解決呢?

    首先,我們來了解一下IP位址:“X.X.X.X”

    x代表0到255之間的任一個自然數,但是,在區域網路裡面,這裡的數字設定是有規則的,一般是由子網路遮罩來分割。

    如255.255.255.0。 說明最後面一個X可以從0到255之間隨意改變。 當網關是192.168.1.1時,我們可以設定成192.168.1.1–192.168.1.254。

    當在一個區域網路內,ip位址超過了數量怎麼辦,這個通常發生在C類的ip位址區域網路中較多,可以有三種方法來解決這個問題。

    一、改子網路遮罩

    因此當子網路遮罩設定成255.255.255.0時,路由器下面的區域網路最多只能”254台”電腦分配相對獨立的IP位址。

    想要增加區域網路IP,那麼可以修改下子網路遮罩就可以了,例如子網路遮罩從255.255.255.0修改成255.255.0.0,那麼我們區域網路裡面的電腦IP就相當於可以設定254乘以254台電腦 ,有64516個IP位址。

    而IP的第三個X也可以從0到255之間任一個數字變192.168.X.X。

    如果還要更多,那麼可以設定成255.0.0.0,區域網路就可以擁有254*254*254台電腦。

    不過這樣設定的話相當於這些所有電腦都處於一個區域網路裡面,而且可以互相訪問,容易引起“網路風暴”,所以我們在修改子網路遮罩時,應該盡量精確。

    例如:255.255.252.0,可以容納,4*254個ip位址。

    二、增加路由器

    也可以透過路由器後面再接路由器來分成多個網段,不過這種方法不太適合超大型網路。

     

    如果原來的網段為192.168.1.1。 那麼可以新增網段,192.168.X.1 。

    操作步驟:

    新增加一台路由器即可! 分配一個IP位址給新增的路由器靜態IP綁定下,然後如果想省事可以啟用DHCP,如果不想省事就自己設定IP位址。

    路由器的網關一定要改! 一般預設的都是192.168.0.1 或 192.168.1.1 ,你新增網段的網關應該是192.168.X.1切記!

    如果你新設定IP位址設定為192.168.2.1的話。 新路由器的IP位址池可以在 192.168.2.2~~~192.168.2.254之間。

    連接方法:

    之前的路由器LAN口和現在路由器的WAN埠相連接。 然後你新的路由器就可以上網了。 可以再接一個交換器插在新路由器的LAN口。

    三、劃分vlan

    最好的方法是透過設定虛擬區域網路“VLAN”,將區域網路裡面的電腦分成多個虛擬的區域網,可以減少網路風暴,而且可以提高交換器跟路由器的工作效率。 有的交換器自帶有VLAN接口,那麼只要將網路線依需要分別接到對應的網段。

     

    透過子網劃分! 你可以將IP位址設定成192.168.0.0/24
    那麼可以劃分192.168.0.x和192.168.1.x二個網段,增加了IP的數量,當然也可以續繼續劃分多個網段。

    網段一:

    192.168.0.x,192.168.0.1——192.168.0.254 ,255.255.255.0。

    網段二:

    192.168.1.x ,192.1681.1——192.168.1.254,255.255.255.0。

    這樣就劃分了兩個vlan,當然也可以分更多。

    四、補充

    這裡面弱電君補充下,很多朋友在專案中會遇到,ip位址192.168.0.0/23這樣的表示,是如何算出它的子碼掩碼是255.255.254.0?

    23是CIDR值。 簡單說就是一個CIDR值對應一個子網路掩碼,然後對網路就行分段。

    每個IP位址的長度為32位元(bit),分4段,每段8位元(1個位元組)。 簡單的說23代表從前往後有23個1,就是11111111.11111111.11111110.00000000

    把這個轉換成十進制就是255.255.254.0,子網路遮罩就是這樣算出來的。

  • 雲端運算的標準定義

    雲端運算這個概念與概念起源很早,早至二十世紀八十年代就有SUN 公司提出「 網路是電腦」 的思想,用來描述分散式運算技術帶來的新世界,今天的雲端運算正在 將這理念變成現實。

    雲端運算、雲端服務、雲端平台等概念名詞非嚴格來講都是指的同一件事。 百度百科是這樣解釋雲端運算的:雲端運算 ( Cloud Computing )是基於互聯網的相關服務的增加、使用和互動模式,通常涉及透過互聯網來提供動態易擴展且經常是虛擬化的資源。 雲端運算的定義有多種說法,對於到底什麼是雲端運算,至少可以找到十幾種解釋。 現階段廣為接受的是美國國家標準與技術研究院( NIST )定義:雲端運算是一種按使用量付費的模式,這種模式提供可用的、便捷的、按需的網路訪問, 進入可配置 的計算資源共享池(資源包括網絡,伺服器,存儲,應用軟體,服務),這些資源能夠被快速提供,只需投入很少的管理工作,或與服務供應商進行很少的交互。 可以從定義中提取一些關鍵字:按量付費、資源池、快速提供、少管理工作等。 關於雲端運算可以提煉出一個 “5+3+4” 模型,即:

    5 個基本特徵:按需自助服務、廣泛的網路存取、資源池、快速彈性、測量服務;

    3 種服務模式:雲端軟體即服務( SaaS )、雲端平台即服務( PaaS )、雲端基礎設施即服務( IaaS );

    4 種部署模式:私有雲、社群雲、公有雲、混合雲。

    對於雲端運算的理解,從簡單類比來說,常用的比喻有水力發電、水果等日常場景,但從技術角度來看,雲端運算實質就是將資源池化:包括運算資源、儲存資源、網路資源 和安全資源甚至包括管理資源和人力資源等。 這些池化的資源可能是部署在自己的機房供其他人使用(此時你是雲端服務供應商),也可能是你不再需要購買硬體設備和建立機房,直接租用別人的資源(此時你 是雲端服務客戶)。 這樣做有什麼好處呢? 對於雲端服務供應商而言,將池化的資源進行使用並且加以利用對外界提供服務,既提高資源利用率又能夠獲得額外的收益;對於雲端服務使用客戶而言,不再需要建立機房和購買 實體設備,直接使用池化資源,更快速方便。

    雲端運算的主要特點有如下:按需服務、快速部署、彈性伸縮、自助計費、持續可用、超大規模運算能力、成本低(成本是否真的降低有待進一步探討)。

  • 生成式AI如何協助DevOps和SRE的工作流程

     岱军 云云众生s

    譯自 How Generative AI Can Support DevOps and SRE Workflows 。

    隨著關於大語言模型(LLM)和生成式AI的討論從熱烈上升到轟動一時,有遠見的軟體團隊戴上耳機,聚焦一個重要問題:我們如何讓這項技術立竿見影?

    這看起來是天作之合,畢竟技術人員會喜歡新技術,不言而喻。 因此,儘管人力資源專業人員可能需要更長時間並更謹慎地考慮如何在工作中使用生成式AI,但開發者、網站可靠性工程師(SRE)和其他技術人員都非常適合嘗試並將生成式AI 工具應用於工作中。 例如,根據Stack Overflow的一項調查,70%的開發者已經或計劃使用AI改進工作。

    問題仍然存在:我們該如何讓生成式AI發揮作用?

    在可預見的未來,用例會不斷湧現,但對現代軟體團隊來說,根據PromptOps CEO兼創始人Dev Nag的說法,回答這個問題很大程度上歸結為溝通,PromptOps是一個面向DevOps和SecOps團隊的 基於生成式AI的Slack助手。

    「我認為企業中的所有工作,特別是對DevOps工程師來說,其實就是關於溝通,」Nag告訴The New Stack。 “不僅包括人與人之間的溝通,也包括人與機器之間的溝通。”

    Nag舉了Slack、Jira或Monday等工具作為例子,但他也將DevOps常見任務中查詢應用程式取得日誌、指標和其他數據,然後根據回應採取行動視為一種溝通形式。

    他指出,儘管這種交流是必要的,但也可能重複且浪費時間,這正是生成式AI能發揮巨大作用的地方。

    Nag說:“語言模型和生成式AI本質上是溝通的超級加速器。它們能夠從過去的數據中找到模式,在你表達想法之前就理解你的意圖。”

    PromptOps最近推出了一款生成式AI工具,它可以透過類似ChatGPT的提示,自動化並優化各種DevOps工作流程,無論是直接在Slack還是網頁端。

    Nag認為,生成式AI在DevOps、SRE和其他現代軟體團隊的應用潛力是幾乎無限的。 在接受The New Stack的採訪時,他分享了六個如今可以將生成式AI應用於DevOps工作流程的範例。

    生成式AI工具的6個使用案例

    查詢不同工具

    DevOps和SRE專業人員經常使用海量工具。 在某些組織,技術「棧」更像一座高塔。

    人工查詢眾多工具的日誌和各種可觀測資料既費時又費力,效率不高。 哪裡有該指標? 看板在哪裡? 機器名稱是啥? 通常怎麼稱呼? 通常會查看什麼時間範圍? 等等問題層出不窮。

    Nag:「這些背景資訊都曾由他人完成。」生成式AI 可以讓工程師用自然語言提示直接找到所需內容,通常還可以自動啟動後續工作流程,無需離開Slack(或其他客戶端)。

    “這極大節省時間,因為我不用再掌握數十種工具。” Nag說,“我可以用英語下達提示,它就可以跨工具幫我完成任務。”

    2. 發現額外環境

    此外,生成式AI可以根據需要自動關聯額外環境,這也很有用。 所以,儘管可以在Slack(或其他地方輸入提示)直接產生所需響應或數據,但生成式AI還可以添加導航層,在適當的時候直接連結到該響應的全文或環境。

    這在速度至關重要的情況下尤其有用,最典型的就是服務中斷事件。 回應事件每花費一分鐘都代價高昂。

    Nag說:“任何任務如果投入足夠時間都可完成。但問題是我們沒有時間和人手,特別是在服務中斷場景,速度至關重要,務必盡快恢復客戶體驗。”

    3. 自動化和快速執行必要係統操作

    就像Kubernetes之類的編排工具因為能根據期望狀態自動執行系統操作而流行起來一樣,生成式AI也可以進一步簡化和加速工作流程中的必要操作。

    Nag說,雲端原生工具和平台自己也帶來複雜性。 執行各種常見運維任務(如預配服務、管理配置、設定故障轉移)通常需要與其他元件互動。

    「這些任務可能接觸許多API。例如AWS API就有200多種服務。」他說。

    它們語法、控制台、命令列各不相同,子命令更是汗牛充棟——幾乎沒人會全部記住。 單就這一點,Kubernetes的學習曲線就令人生畏。

    Nag說,要全面掌握雲原生生態的龐雜細節幾乎不可能。 有了生成式AI,工程師不需要記住各系統與工具的細節。

    使用者只需下達「擴容Pod 2個副本」或「以某種方式配置Lambda函數」等提示。 我可以把它轉換為目標系統語言的實際程式碼,自動執行。 」 Nag說,「LLM幾乎像是這些非結構化資料與結構化資料之間的蟲洞。 」

    4. 撰寫事件報告

    眾所周知,生成式AI在內容創作方面有巨大潛力。 這也適用於系統故障值班人員編寫事後報告的場景。

    Nag指出,這類報告通常需要查看大量Slack訊息、指標、圖表、日誌等資料。

    他說,LLM「可以查看Slack對話——即使是50萬行也沒問題——並總結提取關鍵發現。」它專注相關數據,過濾無用資訊——極大節省人工匯總故障原因的時間。

    這再次證明了「蟲洞」效應,可以將大量非結構化資訊轉化為可操作的結構化資料。

    5. 建立事件

    內容創作類別還包括Nag提到的與事件管理相關的用例:建立工單。 LLM可以在事件或其他IT事件觸發的工作流程中,自動在Jira、Monday等系統建立工單並啟動後續操作。

    有時這些操作正是用例4中的事件報告結果:增強的事件報告可以確定如果事件再次發生要採取的更好做法。

    “下次我要創建警報,可能還需要額外基礎設施等等。” Nag說,“我們可以實際掃描對話,並將其轉化為工單。”

    6. 尋找非技術文檔

    最後但同樣重要的是,Nag說,他們發現越來越需要一種方法,無需大量時間就可以發現和調閱非技術文檔,例如運行手冊或公司政策——不僅包括IT政策,還包括HR福利 等常見業務政策。

    「你不一定知道這些文件的儲存位置。」他說,隨著組織規模擴大,尋找流程可能非常耗時。 類似ChatGPT的提示可以在幾秒鐘內找到所需內容,而不必在各種維基或工具中搜尋。

  • 私有雲架構面臨的安全挑戰與防禦措施

    隨著私有雲在不同產業、企業普及率越來越高,規劃快速擴大,已成為企業核心平台之一。 私有雲上的系統的資料與資訊安全將依賴於私有雲運算平台所提供的保密性和安全性。 一旦雲端平台安全受到威脅並被利用,無疑地為雲端上應用程式造成了重大威脅。

    所以隨著雲端運算市場規模的擴張,也為雲端運算平台的安全帶來了前所未有的挑戰。

    私有雲架構面臨的安全性挑戰

    本文主要從技術安全挑戰和管理安全挑戰兩個面向對私有雲架構面臨的風險進行闡述。

    技術安全挑戰:

    網路資料流在虛擬機器之間傳輸時,IT人員對敏感資訊、進階惡意軟體的監控及控制能力被削弱;

    私有雲對傳統網路架構的彈性度和頻寬要求較高;

    私有雲儲存中的資料面臨資源隔離、加密保護、入侵偵測、資料銷毀等問題;

    漏洞頻傳,主機間遷移能力升級過程中對業務有影響。

    管理安全挑戰:

    私有雲平台管理無平台化支撐,需要藉助統一的管理平台即時檢視運算、網路、儲存等資源;

    私有雲平台自動化管理能力亟待提高,使自服務基礎設施成為可能;

    私有雲平台要整合供應和編排引擎;

    混合雲作為未來的雲端趨勢,在私有雲平台建置過程中要考慮混合雲模型過渡。

    私有雲架構的安全防禦措施

    私有雲從整個架構來說與傳統環境沒有本質區別,所以從安全角度來說,面臨的安全問題和傳統環境面臨的安全問題無異。 與以往作業系統面臨的七層安全問題一樣,在私有雲情況下依然面臨同樣的安全問題。 但由於私有雲資源【運算、網路、儲存】為集中管控,所以從安全角度來說容易管控,不像以往的分散管控。

    在繼承傳統安全問題的同時,私有雲還有哪些新的防護模式要部署? 同樣我們依然遵守微軟的STRIDE威脅分析模型進行分析與出具防禦措施。

    STRIDE威脅分析模型是微軟提出的一套安全設計方法論,六個字母代表六種安全威脅,分別是:

    身份假冒(Spoofing):

    身份假冒,即偽裝成某對像或某人。 例如,透過偽裝成別人的身分來操作。

    篡改(Tampering):

    篡改,即未經授權的情況下,修改資料或代碼。 例如,非授權人員透過網路抓包或

    某種途徑修改某個請求包,使得竄改的請求包提交成功。

    抵賴(Repudiation):

    抵賴,即拒絕執行他人無法證實也無法反對的行為而產生抵賴。 例如,A攻擊了某個產品,產品方不知道是A做的,沒有證據證明是A做的,A就可以進行抵賴。

    資訊洩露(Information Disclosure):

    資訊洩露,即將資訊暴露給未授權用戶。 例如,透過某種途徑取得未經加密的敏感資訊。

    拒絕服務(DenialofService):

    拒絕服務,即拒絕或降低有效用戶的服務等級。 例如,透過拒絕服務攻擊,使得其他正常使用者無法使用產品的相關服務功能。

    特權提升(Elevation of Privilege):

    特權提升,即透過非授權方式獲得更高權限。 例如,試圖用管理員的權限進行業務操作。

     

     

     

     

     

     

     

     

     

    微軟的全系產品都是基於它進行安全考量與設計。 STRIDE模型幾乎是可以涵蓋現在世界上絕大部分的安全問題。

    但這些威脅根據其性質,基本上可以歸結為以下幾個面向:

    資訊外洩:被保護的資訊被無意或有意的洩漏;

    破壞資訊的完整性:被保護的資料被非法篡改或破壞;

    拒絕服務:非法阻止合法資訊使用者對資訊服務的存取;

    非授權存取:受保護資源被非授權個人或組織進行使用;

    竊聽:利用用各種可能的非法的手段竊取系統中受保護的資訊資源和敏感資訊;

    假冒:透過欺騙通訊系統或用戶,達到非法用戶冒充成為合法用戶,或特權小的用戶冒充成為特權大的用戶的目的。 駭客攻擊往往採取此方式,偽裝欺騙用戶,達到目的;

    漏洞攻擊:攻擊者利用系統的安全缺陷或漏洞取得非法的權限;

    內部攻擊:被授權以某一目的使用某一系統或資源的某個人,卻將此權限用於其他非授權的目的;

    抵賴:通常是為內部攻擊的分支,攻擊者否認自己曾經發布過的某則訊息;

    電腦病毒:一種在電腦系統運作過程中能夠實現傳染和侵害功能的程式;

    法規不完善:由於資訊安全法規法律上的不完善,給予資訊竊取、資訊破壞者可趁之機。

    私有雲的安全性面,建議從以下幾個層次去考慮:

    終端層(用戶層)

    終端層也稱為使用者層,主要是確保使用者存取雲端資源時,處於安全的終端環境;

    應用層

    為雲端平台承載的發佈業務,確保發佈的應用程式實現通訊加密、資料脫敏及存取控制等;

    資料層

    確保雲端上數據,包括用戶數據、系統數據及平台數據【VM】,處於加密狀態,可用狀態;

    系統層

    確保雲端上系統,包括雲端平台、雲端宿主和VM處於安全狀態,漏洞及時更新;

    網路層

    網路作為雲端平台的血脈至關重要,要確保網路通路的順暢及通訊加密;

    基礎設施層

    高可用的基礎設施架構,是確保業務連續性的前提條件;

    維運層

    雲端平台內各種資源的存取控制應及時進行安全審計,確保操作可控、運作透明。

  • 改子网掩码

    通信弱電交流學習

    如果是在一個小型的區域網路裡可能完全不必要考慮IP位址不夠的情況,但是在超過「255台」電腦的大型區域網路裡,就必須要考慮電腦IP位址不夠用該如何解決了。

    很多時候企業區域網路出現私網路位址192.168.1.x-255不夠用了,去掉一個廣播位址及一個網路位址後就可能不夠用。 (0是網路位址不可用, 255是廣播位址,除去這2個,可用的就是254個位址)。

    那麼如何解決呢?

    首先,我們來了解一下IP位址:“X.X.X.X”

    x代表0到255之間的任一個自然數,但是,在區域網路裡面,這裡的數字設定是有規則的,一般是由子網路遮罩來分割。

    如255.255.255.0。 說明最後面一個X可以從0到255之間隨意改變。 當網關是192.168.1.1時,我們可以設定成192.168.1.1–192.168.1.254。

    當在一個區域網路內,ip位址超過了數量怎麼辦,這個通常發生在C類的ip位址區域網路中較多,可以有三種方法來解決這個問題。

    一、改子網路遮罩

    因此當子網路遮罩設定成255.255.255.0時,路由器下面的區域網路最多只能”254台”電腦分配相對獨立的IP位址。

     

     

     

     

     

     

     

     

     

     

     

     

     

    想要增加區域網路IP,那麼可以修改下子網路遮罩就可以了,例如子網路遮罩從255.255.255.0修改成255.255.0.0,那麼我們區域網路裡面的電腦IP就相當於可以設定254乘以254台電腦 ,有64516個IP位址。

    而IP的第三個X也可以從0到255之間任一個數字變192.168.X.X。

    如果還要更多,那麼可以設定成255.0.0.0,區域網路就可以擁有254*254*254台電腦。

    不過這樣設定的話相當於這些所有電腦都處於一個區域網路裡面,而且可以互相訪問,容易引起“網路風暴”,所以我們在修改子網路遮罩時,應該盡量精確。

    例如:255.255.252.0,可以容納,4*254個ip位址。
    二、增加路由器

    也可以透過路由器後面再接路由器來分成多個網段,不過這種方法不太適合超大型網路。

     

     

     

     

     

     

     

     

     

    如果原來的網段為192.168.1.1。 那麼可以新增網段,192.168.X.1 。

    操作步驟:

    新增加一台路由器即可! 分配一個IP位址給新增的路由器靜態IP綁定下,然後如果想省事可以啟用DHCP,如果不想省事就自己設定IP位址。

    路由器的網關一定要改! 一般預設的都是192.168.0.1 或 192.168.1.1 ,你新增網段的網關應該是192.168.X.1切記!

    如果你新設定IP位址設定為192.168.2.1的話。 新路由器的IP位址池可以在 192.168.2.2~~~192.168.2.254之間。
    連接方法:

    之前的路由器LAN口和現在路由器的WAN埠相連接。 然後你新的路由器就可以上網了。 可以再接一個交換器插在新路由器的LAN口。

    三、劃分vlan

    最好的方法是透過設定虛擬區域網路“VLAN”,將區域網路裡面的電腦分成多個虛擬的區域網,可以減少網路風暴,而且可以提高交換器跟路由器的工作效率。 有的交換器自帶有VLAN接口,那麼只要將網路線依需要分別接到對應的網段。

     

     

     

     

     

     

     

    透過子網劃分! 你可以將IP位址設定成192.168.0.0/24
    那麼可以劃分192.168.0.x和192.168.1.x二個網段,增加了IP的數量,當然也可以續繼續劃分多個網段。

    網段一:

    192.168.0.x,192.168.0.1——192.168.0.254 ,255.255.255.0。

    網段二:

    192.168.1.x ,192.1681.1——192.168.1.254,255.255.255.0。

    這樣就劃分了兩個vlan,當然也可以分更多。

    四、補充

    這裡面弱電君補充下,很多朋友在專案中會遇到,ip位址192.168.0.0/23這樣的表示,是如何算出它的子碼掩碼是255.255.254.0?

    23是CIDR值。 簡單說就是一個CIDR值對應一個子網路掩碼,然後對網路就行分段。

    每個IP位址的長度為32位元(bit),分4段,每段8位元(1個位元組)。 簡單的說23代表從前往後有23個1,就是11111111.11111111.11111110.00000000

    把這個轉換成十進制就是255.255.254.0,子網路遮罩就是這樣算出來的。