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… Continue reading
如果是在一個小型的區域網路裡可能完全不必要考慮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 。
操作步驟：… Continue reading
雲端運算這個概念與概念起源很早，早至二十世紀八十年代就有SUN 公司提出「 網路是電腦」 的思想，用來描述分散式運算技術帶來的新世界，今天的雲端運算正在 將這理念變成現實。
雲端運算、雲端服務、雲端平台等概念名詞非嚴格來講都是指的同一件事。 百度百科是這樣解釋雲端運算的：雲端運算 （ Cloud Computing ）是基於互聯網的相關服務的增加、使用和互動模式，通常涉及透過互聯網來提供動態易擴展且經常是虛擬化的資源。 雲端運算的定義有多種說法，對於到底什麼是雲端運算，至少可以找到十幾種解釋。 現階段廣為接受的是美國國家標準與技術研究院（ NIST ）定義：雲端運算是一種按使用量付費的模式，這種模式提供可用的、便捷的、按需的網路訪問， 進入可配置 的計算資源共享池（資源包括網絡，伺服器，存儲，應用軟體，服務），這些資源能夠被快速提供，只需投入很少的管理工作，或與服務供應商進行很少的交互。 可以從定義中提取一些關鍵字：按量付費、資源池、快速提供、少管理工作等。 關於雲端運算可以提煉出一個 “5+3+4” 模型，即：
5 個基本特徵：按需自助服務、廣泛的網路存取、資源池、快速彈性、測量服務；
3 種服務模式：雲端軟體即服務（ SaaS ）、雲端平台即服務（ PaaS ）、雲端基礎設施即服務（ IaaS ）；
4 種部署模式：私有雲、社群雲、公有雲、混合雲。
對於雲端運算的理解，從簡單類比來說，常用的比喻有水力發電、水果等日常場景，但從技術角度來看，雲端運算實質就是將資源池化：包括運算資源、儲存資源、網路資源 和安全資源甚至包括管理資源和人力資源等。 這些池化的資源可能是部署在自己的機房供其他人使用（此時你是雲端服務供應商），也可能是你不再需要購買硬體設備和建立機房，直接租用別人的資源（此時你 是雲端服務客戶）。 這樣做有什麼好處呢？ 對於雲端服務供應商而言，將池化的資源進行使用並且加以利用對外界提供服務，既提高資源利用率又能夠獲得額外的收益；對於雲端服務使用客戶而言，不再需要建立機房和購買 實體設備，直接使用池化資源，更快速方便。
雲端運算的主要特點有如下：按需服務、快速部署、彈性伸縮、自助計費、持續可用、超大規模運算能力、成本低（成本是否真的降低有待進一步探討）。… Continue reading
譯自 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和其他現代軟體團隊的應用潛力是幾乎無限的。… Continue reading
隨著私有雲在不同產業、企業普及率越來越高，規劃快速擴大，已成為企業核心平台之一。 私有雲上的系統的資料與資訊安全將依賴於私有雲運算平台所提供的保密性和安全性。 一旦雲端平台安全受到威脅並被利用，無疑地為雲端上應用程式造成了重大威脅。
所以隨著雲端運算市場規模的擴張，也為雲端運算平台的安全帶來了前所未有的挑戰。
私有雲架構面臨的安全性挑戰
本文主要從技術安全挑戰和管理安全挑戰兩個面向對私有雲架構面臨的風險進行闡述。
技術安全挑戰：
網路資料流在虛擬機器之間傳輸時，IT人員對敏感資訊、進階惡意軟體的監控及控制能力被削弱；
私有雲對傳統網路架構的彈性度和頻寬要求較高；
私有雲儲存中的資料面臨資源隔離、加密保護、入侵偵測、資料銷毀等問題；
漏洞頻傳，主機間遷移能力升級過程中對業務有影響。
管理安全挑戰：
私有雲平台管理無平台化支撐，需要藉助統一的管理平台即時檢視運算、網路、儲存等資源；
私有雲平台自動化管理能力亟待提高，使自服務基礎設施成為可能；
私有雲平台要整合供應和編排引擎；
混合雲作為未來的雲端趨勢，在私有雲平台建置過程中要考慮混合雲模型過渡。
私有雲架構的安全防禦措施
私有雲從整個架構來說與傳統環境沒有本質區別，所以從安全角度來說，面臨的安全問題和傳統環境面臨的安全問題無異。 與以往作業系統面臨的七層安全問題一樣，在私有雲情況下依然面臨同樣的安全問題。 但由於私有雲資源【運算、網路、儲存】為集中管控，所以從安全角度來說容易管控，不像以往的分散管控。
在繼承傳統安全問題的同時，私有雲還有哪些新的防護模式要部署？ 同樣我們依然遵守微軟的STRIDE威脅分析模型進行分析與出具防禦措施。
STRIDE威脅分析模型是微軟提出的一套安全設計方法論，六個字母代表六種安全威脅，分別是：
身份假冒（Spoofing）：
身份假冒，即偽裝成某對像或某人。 例如，透過偽裝成別人的身分來操作。
篡改（Tampering）：
篡改，即未經授權的情況下，修改資料或代碼。 例如，非授權人員透過網路抓包或
某種途徑修改某個請求包，使得竄改的請求包提交成功。
抵賴（Repudiation）：
抵賴，即拒絕執行他人無法證實也無法反對的行為而產生抵賴。 例如，A攻擊了某個產品，產品方不知道是A做的，沒有證據證明是A做的，A就可以進行抵賴。
資訊洩露（Information Disclosure）:
資訊洩露，即將資訊暴露給未授權用戶。 例如，透過某種途徑取得未經加密的敏感資訊。
拒絕服務（DenialofService）：
拒絕服務，即拒絕或降低有效用戶的服務等級。 例如，透過拒絕服務攻擊，使得其他正常使用者無法使用產品的相關服務功能。… Continue reading
通信弱電交流學習
如果是在一個小型的區域網路裡可能完全不必要考慮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位址。
二、增加路由器… Continue reading
原创 岱军 云云众生s
採取策略性的結構化的Kubernetes管理，可充分發揮其效能，使其成為推動業務效率與創新的關鍵因素。
譯自Mastering Kubernetes Optimization: A Strategic Approach，作者 Eli Birger 是 PerfectScale 的共同創辦人兼技術長。 他是一位熱情的技術專家，擁有電信(Comverse、Vonage)、網路安全(Imperva、Cyren)和儲存(IBM)方面的背景。 他擁有超過六年的DevOps管理經驗，在這個角色中…
Kubernetes 已經確立了自己作為首要容器編排平台的地位，它因在部署應用程式時擁有超凡的靈活性和可擴展性而獲得廣泛讚譽。
這個開源系統旨在簡化容器化應用程式的管理，提供諸如高效擴展、負載平衡和自動化管理等功能。
然而，掌握Kubernetes 需要在性能、彈性和成本效益之間達致精妙的平衡，這可能是一個複雜的持續挑戰。 對依賴 Kubernetes 運行關鍵應用程式卻又想控制營運成本的企業來說，確保達到最佳平衡至關重要。
掌握 Kubernetes 的第一步關鍵在於對環境有詳細的了解。 這涉及密切監控和分析資源分配和使用模式，以及理解成本影響。
達到這種洞察力對確定低效率和潛在改進領域至關重要。 這通常需要部署可以提供即時數據和分析的監控工具，使團隊能夠做出資訊化的數據驅動決策。 對 Kubernetes 環境中不同元件如何在不同條件下互動和消耗資源有詳細的了解，為有針對性的最佳化工作奠定基礎。
一旦一個組織對其 Kubernetes 設定有了全面的理解，下一步就是朝著主動的、由所有者主導的行動邁進。 這個階段至關重要，因為它涉及將從最初的詳細分析中獲得的見解應用到做出資訊化和策略性的決策。 這些決策涉及 Kubernetes 管理的各個方面，包括資源分配、應用程式擴充和整體基礎架構調整。
此時，組織開始積極管理他們的 Kubernetes 環境，應用資料驅動的策略來優化效能。 這可能涉及調整 pod 或節點的大小，以更好地匹配它們的實際用法，從而確保資源不會被低利用或過度擴展。
它還可能包括重新配置網路策略或調整儲存配置以提高效率和效能。 在某些情況下，組織可能需要實現更複雜的更改，例如修改 Kubernetes 調度程序以實現更好的負載分配，或更新服務編排和管理的方式。
這個階段流程的重點不僅在於節省成本或提高效能，而是在找到既滿足直接營運需求又符合長期策略目標的平衡。 這需要對Kubernetes環境及其與所支援的應用程式的相互作用有細緻的理解。 例如，縮減資源可能會在短期內降低成本，但如果這導致應用程式效能或可用性降低，則可能會對業務結果產生長期的負面影響。
掌握Kubernetes的最後一個面向是採用自治權限調整，這代表了Kubernetes環境管理方式的重大進步。 這個階段的特點是實施設計用於持續和主動優化的自動化流程。
這裡的主要目標是賦予Kubernetes自治和有效率地調節其資源使用的能力，以流暢地適應不同的營運需求。… Continue reading
