引言
我是蔣爍淼，觀測雲的首席技術架構師兼産品把控者。今天，我有幸與大家分享我們團隊在設計和實作産品過程中所堅持的核心理念。這些理念不僅是我們工作的指導燈塔，更是推動我們技術不斷進步的動力源泉。
在觀測雲，我們堅信，一個産品的強大生命力和競争力，源自于其内在的哲學和理念。作為團隊的領航者，我帶領着每一位成員，堅守着這些核心理念。它們是我們設計和實作産品的基石，是我們在技術發展道路上的指南針。
以工程師們為中心
觀測雲是一款面向企業級市場的監控觀測産品，旨在滿足最終使用者的需求。我們認識到，産品要想擁有持久的競争力，就必須得到工程師們的認可，使用便捷，并能為他們創造價值。通過提升工程師的工作效率，我們相信最終客戶也将從中受益。
在傳統監控産品中，設計往往以運維人員的需求為主，涵蓋儀表盤、告警、資料接入等多個方面。然而，觀測雲的設計理念有所不同。舉幾個例子：
觀測雲的 Agent 模型采用了類似 OpenTelemetry 的架構，将 Instrumentor（探針）和 Collector（Agent）分離，完全不同于傳統的 APM 廠商。
該架構設計具有多項優勢，在此僅列舉一個關鍵好處。我們認識到，無論是使用 eBPF 探針還是傳統位元組碼探針，都可能對應用程式産生一定影響。同時，為了不斷增強監控能力，探針和 Agent 可能需要定期更新。這種架構允許研發團隊獨立驗證探針的穩定性和資料字段的擴充性，而運維團隊則負責 Agent 的更新和配置調整。通過分離探針和 Agent，Agent 的更新不會幹擾應用程式的正常運作，最多隻會導緻資料暫時不可用。在應用程式更新過程中，我們確定其與探針的相容性已在測試環境中得到驗證，進而避免了因探針更新不當而導緻的整個業務系統的故障風險。
此外，這種架構還提高了系統的相容性，能夠支援多種 Instrumentor，包括但不限于探針、日志采集器以及 Prometheus 生态系統的內建。
使用觀測雲的使用者将深刻體會到其賦予的廣泛自由度，這不僅僅展現在随心所欲地設計個性化儀表盤、靈活配置資料結構、自定義查詢模闆，以及獨創性地設計告警政策上。我們深刻了解研發工程師的微妙心理需求，是以在多處功能設計中巧妙地融入了“僅我可見”的選項，旨在為工程師們提供一個私密的空間，讓他們能夠安心地進行自我調試、儀表盤分析，而無需擔心被他人窺探。這種貼心的設計，正是出于對研發者心理的深刻洞察與尊重，它鼓勵了更自由、更無拘束的創新實踐，進而真正釋放了可觀測性能力的潛力，為項目帶來實質性的價值提升。
前面的模型示例不僅簡化了研發流程，還賦予了他們在探針中自由擴充字段、深化業務洞察的能力，進而助力建構更為精準和全面的分析體系。衆多觀測雲使用者回報，相較于某些标榜為AIOps的産品，我們的解決方案在功能強大性、AI 分析能力上更勝一籌，卻謙遜未以此為核心賣點。原因在于，我們堅信算法的真正價值遠不止于運維（Ops），它應廣泛滲透于離群分析、異常檢測等各個環節，賦能研發團隊。這不僅僅意味着監控 CPU 行為異常，更關乎于深入了解代碼調用在不同場景下的異常表現。
過分渲染 AIOps 概念的産品，往往陷入誇大其詞的誤區，而真正出色的産品則是将這些進階能力無縫融入日常研發運維流程中，成為他們工具箱中不可或缺的一部分。我們緻力于讓技術回歸本質，為使用者提供實實在在的價值，而非空泛的概念炒作。
我們對觀測雲的細緻打磨展現在諸多方面，例如時間控件的靈活性。我們支援直接輸入unixtime，簡化了工程師在時間轉換上的繁瑣操作，避免了使用 Linux 指令或在不直覺的月曆控件中進行選擇。這種對細節的關注是許多同類産品所忽視的。
觀測雲的更新頻率為每兩周一次，這不僅是為了引入新功能，更重要的是，我們緻力于根據使用者的真實回報來優化産品。這些更新可能涉及大量的細節改進，雖然無法一一列舉，但它們共同構成了我們對産品不斷改進的承諾。我們相信，真正使用觀測雲的使用者能夠從這些細節中感受到我們的專注和誠意。
做一個開放的産品
我對開源的态度是明确的：我支援真正的開源精神，即開放代碼并與全球開發者進行交流。然而，我反對那些以開源為名，實則追求商業利益而忽視社群和技術發展的“僞開源”行為。觀測雲在這一點上采取了開放的姿态，我們公開了所有端側代碼，并在 Github 上維護着數十個開源項目。我們鼓勵團隊成員積極參與開源社群，發現問題時送出 Pull Request（PR），以促進相關項目的進步。
同時，我們也持續為開源項目如 Victoriametrics 貢獻代碼。盡管觀測雲是一個商業産品，我們依然堅持開放的原則，但這種開放是有選擇性的。我們的目标是提供一個既開放又可控的環境，確定産品的穩定性和安全性。
我們緻力于整合開源技術，以增強觀測雲的功能。我們全面支援現有的觀測技術架構，例如與 Prometheus 生态系統的深度內建。我們的系統不僅能夠收集 Prometheus 的各種資料類型，包括 Exporter 和 Push 資料，而且在 Push 資料支援方面，我們在穩定性和性能上均超越了 Prometheus 官方的 Push Gateway。此外，我們還加強了對 Prometheus 自發現功能的支援。
在日志采集方面，我們相容多種日志生成方式，例如支援 Log4J 通過 Socket 直接發送日志，避免了日志寫入磁盤的需要。這種支援使得在性能要求極高的場景下，開發者也能夠高效地收集大量日志資料。
對于分布式追蹤（Tracing），我們同樣提供了廣泛的支援，相容了包括 ddtrace、OpenTelemetry、Zipkin、SkyWalking 以及 Jaeger 等多種追蹤協定。這些開源方案在不同應用中可能采用不同的實作，導緻分析上的分散。觀測雲通過統一的內建方式，使得這些不同來源的資料在使用上保持一緻性，仿佛它們是專為觀測雲設計的一樣，盡管它們采集的資料内容可能各有差異。
同樣，我們對開源技術的承諾不僅展現在支援 eBPF tracing 上，更在于我們将其開源，以促進統一标準的形成。與國内其他開源廠商不同，我們緻力于生成符合 OpenTelemetry 标準的 span 和 trace。這意味着使用觀測雲采集的 eBPF 資料能夠與其他技術方式接入的資料一同分析，無需額外的背景系統或專用資料庫存儲叢集。
在技術文檔方面，我們緻力于開放和透明的分享。觀測雲在技術文檔的公開程度上，自信地處于行業領先地位。我們公開了大量的技術實作細節，以便于業界同仁學習和參考。
用認知驅動取代需求驅動
對于熟悉觀測雲的老朋友或初次接觸的新朋友而言，或許已知曉或未曾留意到這樣一個事實：觀測雲不僅提供雲端服務，實作全球無縫接入，同時也支援靈活的私有化部署方案，以滿足不同使用者的特定需求。然而，鮮為人知的是，觀測雲在産品開發上堅守着一個重要原則——我們從未為任何單一客戶定制産品。從中國的本土版本到海外的國際市場，再到那些部署于客戶私有環境中的定制化方案，盡管部分版本因市場政策或技術疊代進度略有差異，但觀測雲始終如一，堅持為所有使用者提供統一、标準的産品體驗。
這是我們的堅持。為什麼呢？
首先，觀測雲堅守為客戶負責的原則。在快速疊代的産品環境中，我們深知保持産品主線的重要性。定制化産品雖看似能即時滿足特定需求，但長遠來看，它們往往與主線版本分離，形成分叉，這不僅損害了客戶的長期利益，也增加了我們維護産品體驗的難度。是以，我們堅決避免任何形式的版本分叉，確定每位客戶都能享受到持續、穩定且高效的産品服務。
其次，我們注重有價值需求的快速響應與标準化。在快速疊代的過程中，我們深知客戶需求的多樣性與複雜性。然而，并非所有需求都能直接轉化為産品功能，特别是當這些需求存在邏輯悖論或表述不清時。作為産品專家，我們傾聽客戶聲音，結合産品架構與行業洞察，将特定需求轉化為标準化的産品功能。這種負責任的做法不僅提升了産品價值，也加深了我們對産品行業的認知，而這些認知又反過來推動我們不斷優化産品，形成良性循環。我們的更新速度遠超客戶自行探索開源方案的效率，確定研發運維工程師們能夠輕松、高效地使用我們的平台。
最後，我們緻力于産品的開放性與靈活性。為了滿足使用者多樣化的個性化需求，我們努力實作各種技術棧的标準化內建，而非依賴定制化。通過建構豐富的靈活性機制，我們完整打造了一整套架構體系，以應對更廣泛的業務場景和需求。這種高度定制化的靈活性要求我們不能簡單地采用開源産品拼湊而成，而是需要自主設計資料引擎、資料庫及UI架構等核心元件，進而確定産品的整體性能和使用者體驗。這種從底層到上層的全面掌控，使得我們的産品能夠靈活應對各種挑戰，為使用者創造更大的價值。
觀測雲是我們團隊精心打造的産品，它不僅承載着我們的技術追求，更融入了我們的價值觀。我們緻力于持續優化和完善産品，以確定它能夠為使用者帶來實際的價值。我們的目标是讓觀測雲在企業中發揮關鍵作用，特别是對于工程師團隊。我們相信，通過不斷的努力和創新，觀測雲能夠提升工程師的工作效率，增強企業的營運能力。我們的目标不僅是滿足使用者目前的需求，更是預見并引領未來的技術趨勢，進而為企業帶來長遠的價值。