本專區由 DevOps 團隊提供資訊和技術支持，歡迎社區成員申請加入管理小組。
DevOps（Development 和 Operations 的組合詞）是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。
管理員
加載中
置頂
發表了博客
10/26 10:20
一、配置解法 飛碼LowCode前端技術（一）中飛碼提出了至少需要滿足2個大能力點以及對應16個細化點。在業務復雜的場景下數據具有流轉性質，事件的觸發會改變數據、同時也會觸發其他事件等情況。飛碼使用數據驅動+事件驅動的模式解決數據流轉性與事件不確定性問題。數據驅動+事件驅動的模式決定了需要飛碼的編輯態具備數據可配性、事件可配性。為LowCode或NoCode解營銷域下的場景奠定夯實基礎。整體設計詳見圖1 圖1 在飛碼LowCode... 展開更多
置頂
發表了博客
10/18 12:10
 > 船停在港灣是最安全的，但這不是造船的目的 ## 完成使命的 SRE 過去 10 年，SRE 完成了體系化保障系統穩定性的使命。但在這個過程中，SRE 也逐漸變成了龐大的組織。而 SRE 本身的定位是保障系統穩定性，許多時候會因為擔心穩定性而減緩發布。雖然我們希望軟件的發布又快又穩，但無論是根據日常經驗，還是從 DORA 的報告中，我們都能看... 展開更多
置頂
發表了博客
10/18 11:23
技術管理者需要不斷地努力改善團隊狀況，比如提升研發效能、幫助成員成長，或者優化組織結構等等?？梢哉f，推動變革是「技術管理者」這一角色的重要使命之一。 關于變革的挑戰總是復雜，而如何在不同的環境和問題中影響團隊也是一項艱巨的任務。在實踐中，我發現以更加實際的視角看待問題會有所幫助。 ## **\# 技術管理者的工具箱** 盡管公司和技術團隊各不相同，但大多數情況下，技術管理者有權決定團隊如何開展工作，以及如何... 展開更多
置頂
發表了博客
10/18 10:06
一、背景介紹 黃金眼PAAS化數據服務是一系列實現相同指標服務協議的數據服務，各個服務間按照所生產指標的主題作劃分，比如交易實時服務提供實時交易指標的查詢，財務離線服務提供離線財務指標的查詢。黃金眼PAAS化數據服務支撐了黃金眼APP、黃金眼PC和內部各類大屏的數據查詢需求。為了業務能進行正確的數據洞察和決策，需要保證PAAS化數據服務提供數據的準確性。 隨著業務需求的快速迭代，數據服務經常需要對查詢口徑，查詢維... 展開更多
置頂
發表了博客
10/18 09:46
1 前言 1.1 架構分類 在軟件設計領域，企業架構通常被劃分為如下五種分類： 如何理解架構分類依據及其彼此之間的關系？業務是企業賴以生存之本，因此業務架構是基礎、是靈魂，其他一切均是對業務架構的支撐；根據業務架構形成與之相應的產品架構和數據架構；最后通過技術架構落地實施。 應用架構用于對產品架構進行細分，通過應用集成形成產品。但是應用架構區別于產品架構的本質不應該只在粒度，更重要的是產品直接承接業務，按... 展開更多
置頂
發表了博客
06/09 22:18
在實踐中，很多團隊對于DevOps 流水線沒有很透徹的理解，要不就創建一大堆流水線，要不就一個流水線通吃。實際上，流水線的設計和寫代碼一樣，需要基于“業務場景”進行一定的設計編排，特別是很多通過“開源工具”搭建的流水線，更需要如此（商業的一體化平臺大部分已經把設計思想融入自己產品里了）。 流水線的設計與分支策略有關 流水線的設計與研發活動有關 清晰的代碼結構，標準的環境配置，原子化的流水線任務編排，再加上... 展開更多
置頂
發表了博客
10/08 11:56
背景 隨著業務的快速變化和技術的不斷發展，系統面臨著諸多挑戰，例如流量峰值、依賴服務故障、硬件故障、網絡中斷、軟件缺陷等，這些因素都可能影響到系統的正常運行。在這種背景下，彈性設計（Resilience Design）應運而生。彈性設計是一種系統的設計和構建方法，系統的設計原則應該本著不信任外部資源（外部API服務、網絡設備、存儲、消息等）100%可用的原則，在關鍵處理路徑上針對上述可能發生故障的點進行容錯加固設計，保... 展開更多
置頂
發表了博客
09/14 16:25
在過去，傳統的應用程序部署和管理通常是一個復雜且耗時的過程。這包括硬件和服務器的采購、配置、維護以及應用程序的手動部署和擴展。隨著云原生概念的普及，雖然帶來了擴展性、可用性等方面的改進，但也意味著運行單個腳本部署一個完整應用程序的日子一去不復返了。 "開發者應該能夠端到端的部署和運行他們的應用程序和服務，你構建它，你運行它"，這樣的話看起來沒有問題，但對于大多數公司來說，這并不現實，復制完整的 De... 展開更多
置頂
發表了博客
08/29 14:44
導言 項目本身無好壞之分，項目管理有做好與做壞之別。在互聯網大廠的體制下，想要做壞一個項目很難（可以通過換人、追加資源等方式消除風險），想要做好一個項目不容易，需要團隊及PM付出大量心血和精力。在這些做好的項目中，我們也觀察到很多PM做的疲憊不堪，甚至厭倦做項目管理工作，更有甚者一度對項目管理工作對技術人員的價值產生懷疑，所以，對于技術PM來說“優雅”做好項目管理至關重要。 優雅是一種態度和狀態，能夠全... 展開更多
置頂
發表了博客
08/29 15:59
在不斷發展的DevOps世界中，深入了解系統行為、診斷問題和提高整體性能的能力是首要任務之一。監控和可觀察性是促進這一過程的兩個關鍵概念，為系統的健康和性能提供了寶貴的可見性。雖然這些術語經?？梢曰Q使用，但它們代表著理解和管理復雜系統的不同方法。在本文中，將探討監視和可觀察性之間的差異，提供示例來說明它們的應用，并強調各自的又是。同時，本文還將深入研究用于有效監測和可觀測性的技術和工具。 監控:了解系... 展開更多
置頂
發表了博客
08/28 15:52
本文分享自華為云社區《 數字工廠深入淺出系列（十二）：生產制造關鍵業務模型拆解與平臺化演進》，作者：云起MAE 。 制造型企業的信息化/數字化系統建設，根本目的是服務于企業的業務運營和管理決策，提升企業資源利用率、內外部組織協同效率，優化產品設計與質量，最終實現商業成功。無論生產制造型企業為客戶提供哪些類型的產品，都需要圍繞以下幾個問題開展活動： 面向哪些類型客戶賣什么類型產品（商業活動） 產品提供哪些... 展開更多
置頂
架構師
發表了博客
08/14 01:43
大家好，我是張晉濤。 Kubernetes v1.28 是 2023 年的第二個大版本更新，包含了 46 項主要的更新。 而今年發布的第一個版本 v1.27 有近 60 項，所以可以看出來，在發布節奏調整后，每個 Kubernetes 版本中都會包含很多新的變化。 其中 20 個增強功能正在進入 Alpha 階段，14 個將升級到 Beta 階段，而另外 12 個則將升級到穩定版。 可以看出來很多都是新特性。 我之前每期的 「k8s生態周報」都有一個叫上游進展的部分，會發一些... 展開更多
置頂
發表了博客
08/17 18:24
之前有一篇文章 “扯淡的DevOps，我們開發者根本不想做運維！” 得到了許多開發者的共鳴，每一個開發人員，都希望能夠拋卻運維工作，更專注于自己開發的代碼，將創意轉化為令人驚嘆的應用。然而事不盡如人意，到了云原生時代，開發者的運維工作似乎并沒有減少，而是變成了在 K8s 上的應用部署和管理。 對運維人員來說，只需要維護好底層的 K8s，便可以在彈性、便捷性上得到巨大提升。然而 K8s 對于我們開發者而言還是太復雜了，... 展開更多
置頂
發表了博客
08/16 10:09
1. 現狀·問題 你還記得你排查jar沖突的付出么？ 為了有效控制jar包更新帶來的未知jar引入和變動，我們經常使用dependency-tree來查看依賴關系排查問題，通常是出現問題再被動分析和排查，此時人力成本是巨大的，同時系統已出問題，沒有后悔藥。 2. 分析原因 jar包依賴是異變的，且隱形的，jar沖突導致的問題經常發生，研發無法每次都關注其變化。 3. 采取措施 采用“敏捷”思想，小步走，每天定時監控jar包依賴關系的變化，讓風... 展開更多
置頂
技術主管
發表了博客
08/15 17:17
毫無疑問，在過去幾年里，你可能已經多次聽到過可觀測性這個詞。對于很多人來說，很難理解這個詞的真正含義。對許多人來說，他們錯誤地將其等同于"監控"。雖然可觀測性的根本定義以及它所包含的一切都不在本系列博文的討論范圍之內，但我強烈建議您購買一本由 Charity Majors (twitter)、Liz Fong-Jones (twitter) 和 George Miranda (twitter) 合著的《可觀測性工程》（Observability Engineering）一書。 不過，本系列博文將介... 展開更多
置頂
發表了博客
08/08 19:29
01、Zadig vs. Jenkins：關于時代的選擇 最近，我的合伙人 Grant 在官方公眾號發布了一篇名為 《是時候和 Jenkins 說再見了》的文章，引起了社區的廣泛關注和討論。作為曾經最被廣泛使用的持續構建交付工具，Jenkins 的江湖地位似乎被挑戰了。評論中有一條被高度點贊頂起： 作為 Zadig 的創造者，我認為有必要與大家分享一份詳細的比較文章。我的職業生涯伴隨著工具、技術和基礎設施的不斷迭代，從十幾年前的 TeamCity、Hudson，... 展開更多
置頂
發表了博客
08/10 11:39
文章開始之前，我想先請大家思考幾個問題： 你的產品待辦列表中有多少項工作？ 其中最早的待辦事項是什么時候創建的？ 你和 Scrum 團隊多久會維護一次列表中那些從沒進過迭代的「釘子戶」事項？ 我第一次問自己時，得到的答案是這樣的： 產品待辦列表中有 450 個待辦事項； 最早的一項在三年零七個月前創建； 至少有 100 個事項被完善和評估，卻從未被規劃進迭代。 我開始反思產品待辦列表（Product Backlog）和產品待辦事項（P... 展開更多
置頂
發表了博客
08/09 09:55
在軟件開發領域，GitOps 和 DevOps 是加強協作和實現軟件交付流程自動化的重要技術。雖然這兩種模式都旨在提高軟件開發生命周期的效率，但它們的核心原則和實施方式卻各不相同。 本篇文章將幫助您了解 GitOps 和 DevOps 之間的差異、它們的工作流程，并了解哪種方法更適合您的企業，以及決定采用哪種方法時要考慮的因素。通過閱讀本文，您將對 GitOps 和 DevOps 的不同方面有一個清晰的了解，從而為您所在的企業做出合適的選擇。... 展開更多
沒有更多內容
加載失敗，請刷新頁面
