作者: admin

  • 平台工程如何應對DevOps挑戰

    岱军 云云众生s

    一覽 DevOps 的核心挑戰,以及平台工程是否可能取而代之。

    譯自How Platform Engineering Takes on DevOps Challenges,作者 Kenn Hussey。

    隨著公司持續以前所未有的速度擴展,DevOps 的角色正在經歷重大轉型。 雖然 DevOps 一直是彌合開發和維運之間差距的重要工具,但其局限性和低效率也變得越來越明顯。

    許多人認為平台工程是 DevOps 的自然演進,它解決了 DevOps 的核心挑戰,並使組織更有效地擴展。 隨著重點轉向創建自助服務平台和賦能開發人員,DevOps 的傳統角色正在被重新定義。

    讓我們回顧一下 DevOps 的核心挑戰以及平台工程如何取代它。

    雖然 DevOps 徹底改變了軟體開發和部署,但現代雲端原生技術的日益複雜性給團隊帶來了前所未有的壓力。 隨著組織的擴展,目前 DevOps 方法的限制和低效率變得更加明顯。

    一個主要挑戰是需要在端到端 DevOps 流程中實現更多自動化。 Dynatrace 最近關於 DevOps 自動化的研究顯示,只有 56% 的這些流程是自動化的,導致交付時間更長,效率降低。 在典型的開發人員管道中平均有九項手動幹預,包括審批和安全檢查,這進一步加劇了這種情況。 這些導致了解決時間延長,並可能嚴重影響組織的利潤和客戶滿意度。

    造成這種情況有兩個核心原因。 第一個是工具鏈的複雜性。 DevOps 生態系統中豐富的工具和技術可能導致難以管理的碎片化環境。 這種複雜性為團隊整合和維護一個有凝聚力的 DevOps 工作流程帶來了挑戰,導致效率低下和生產力下降。

    第二個是孤島團隊。 孤島會阻礙協作和溝通,而協作和溝通對於成功採用 DevOps 至關重要。 孤島團隊通常缺乏對彼此流程的可見性,導致錯位、重複工作和問題解決時間更長。

    即使沒有這些問題,團隊也缺乏推動自主營運的關鍵技能,這使得有效實施和維護 DevOps 實踐變得具有挑戰性。 所需的技能,包括編碼、基礎設施管理和自動化,在單一團隊中可能很難找到和培養。

    隨著目前 DevOps 方法的限制變得越來越明顯,組織正在尋求克服這些挑戰並改善其軟體交付流程的方法。 DevOps 團隊必須縮短開發週期以實現業務服務等級目標 (SLO),提高軟體品質並更快地創新。 平台工程應運而生。

    什麼是平台工程?
    平台工程是 DevOps 的一種現代方法,更確切地說,是 DevOps 的一個邏輯擴展,旨在與現有的 DevOps 原則一起工作,同時減輕相關的認知負擔。 平台工程師透過建立內部開發人員平台(IDP)來簡化標準 DevOps 活動,該平台提供單一的應用程式開發和部署工具包。

    作為 DevOps 的策略擴展,平台工程解決了傳統手動方法的缺點、不足和限制。 它自動化了開發和部署管道,簡化了它們以提高效率和有效性,超越了傳統限制。 採用平台工程文化使企業能夠在數位轉型時代脫穎而出,讓他們能夠在當今瞬息萬變的技術環境中蓬勃發展。

    平台團隊可以簡化和提高先前由 DevOps 團隊處理的任務的效率。 你的平台團隊必須有明確定義的產品目標、已建立的 DevOps 程式和正確的思維方式才能發揮其潛力。

    在新科技時代,平台工程師的角色並沒有取代 DevOps,而是擴展了使其成功應對新挑戰和機會的原則。 平台工程將在軟體開發和交付中發揮重要作用。

    平台使 DevOps 能夠大規模擴展
    隨著 DevOps 的興起極大地改變了軟體開發,使其變得更加敏捷和協作,但組織通常需要幫助才能獨立處理複雜性。 平台工程源於為開發人員提供簡單、可擴展且用戶友好的自助服務流程以更快地建立軟體的需求。

    組織可以利用平台工程來:

    簡化流程:透過提供標準化、簡化的軟體開發和部署方法來簡化複雜流程。

    自動化基礎設施和部署:自動化是平台工程的核心,使團隊能夠在最少的手動幹預下配置基礎設施和部署應用程式。

    提供自助服務平台以提高開發人員效率:自助服務平台使開發人員能夠快速輕鬆地存取他們需要的工具和資源,而無需依賴其他團隊或等待批准。

    縮短上市時間:透過簡化流程和自動化任務,平台工程幫助組織更快、更頻繁地交付軟體。

    提高可擴展性和彈性:平台工程使組織能夠建立可擴展且有彈性的系統,這些系統可以處理增加的需求並從故障中快速恢復。

    促進協作:平台工程透過提供一個共享平台和一套通用的工具和實踐來促進協作,使團隊能夠更有效地協同工作。

    平台工程可以幫助團隊快速擴展他們目前的 DevOps 流程來滿足需求,而無需引入不必要的開銷。 平台工程不是依賴單獨的工具,而是建構了一個支援端到端交付的緊密基礎。

    任何平台工程團隊的主要目標是促進工具和配置重用。 重複使用程式碼可以使應用程式交付過程更有效率,需要的工具更少,並且可以改善程式碼一致性。 開發人員可以專注於創新,而不是編寫重複的程式碼。

    平台工程如何優化 DevOps 效率
    軟體開發團隊的需求通常不同。 如果每個開發團隊都建立自己的 DevOps 實踐,您將遇到複雜性、瓶頸和安全漏洞。 平台工程團隊可能會承擔部分 DevOps 職責,例如以下職責:

    自動化 Git 工作流程:平台團隊可以自動化 git 儲存庫的建立、配置和管理,確保整個組織的一致且安全的版本控制實務。

    配置測試環境:透過自動化測試環境的配置,平台團隊可以減少設定和維護測試基礎架構所需的時間和精力。

    為 CI/CD 管道建立配置模板:平台團隊可以為 CI/CD 管道建立可重複使用的模板,使開發團隊能夠快速採用最佳實踐並在專案中保持一致性。

    配置用於秘密管理和使用者身份驗證的中央儲存庫:集中這些功能有助於維護安全性並符合要求,同時簡化開發團隊的存取控制。

    配置用於應用程式效能監控的儲存庫:平台團隊可以設定和維護一個用於應用程式效能監控的集中儲存庫,該儲存庫可為開發人員提供對其應用程式行為和效能的見解。

    以下是您的平台團隊如何優化 DevOps 效率的方法:

    為內部開發人員建立一個工作平台:透過創建一個標準化的自助服務平台,平台團隊可以簡化開發流程並減輕各個團隊的負擔。

    建立鋪設好的道路以減少認知負荷:鋪設好的道路為常見的開發任務提供了預先定義的、經過充分測試的路徑,從而減少了開發人員的認知負荷並最大程度地降低了錯誤風險。

    簡化流程、標準化流程並擴展流程:平台團隊可以識別並簡化複雜流程,制定標準並確保隨著組織的發展,這些流程可以有效地擴展。

    監控關鍵績效指標 (KPI) 和指標:透過此監控,平台團隊可以識別需要改進的領域,並做出數據驅動的決策以優化 DevOps 效率。

    提升團隊績效,為客戶提供更大價值:平台團隊可以持續評估並提升開發團隊的績效,最終為客戶提供更好的價值。

    以下是貴組織吸引合適的工程師加入平台團隊的關鍵策略。

    明確目標並定義現實的時間表:明確傳達平台團隊的目標和期望,並設定可實現的時間表,有助於吸引與組織願景一致的工程師。

    擁抱多元化,促進更好的溝通與協作:培養一個多元化和包容性的團隊環境,可以促進平台工程師之間的創造力、創新和實際合作。

    為平台團隊提供合適的工具和技術:為平台團隊配備必要的工具和技術,使他們能夠有效率且有效地工作,吸引重視良好支援工作環境的熟練工程師。

    DevOps 的未來在於採用平台工程,而不是傳統的孤島式實踐。 為了在當今瞬息萬變的環境中保持競爭力,組織必須將平台工程作為 DevOps 之旅的下一步。 它將塑造團隊協作、整合和簡化未來軟體交付的方式。

    隨著 DevOps 的發展,平台工程將促進無縫的跨團隊溝通並優化工作流程。 透過自助功能和自動化管道,軟體更新將更快完成,從而取代手動任務。

    從 DevOps 過渡到平台工程可能是快速變化的 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,子網路遮罩就是這樣算出來的。