國產(chǎn)化發(fā)展浪潮下，信創(chuàng)產(chǎn)業(yè)已經(jīng)推進了數(shù)年之久，無論是國家還是行業(yè)層面，都給予了高度重視，并發(fā)布了若干政策以及指導(dǎo)意見，為信創(chuàng)的發(fā)展營造了良好的政策環(huán)境。然而，信創(chuàng)發(fā)展過程中面臨諸多問題，從早期信創(chuàng)規(guī)模小和質(zhì)量欠佳，到近一兩年有了規(guī)模但缺少核心業(yè)務(wù)等問題，這些都從實質(zhì)上體現(xiàn)了最終用戶處于被動地位。那么到底是什么原因，造成了這種“叫好不叫座”的現(xiàn)象？

是信創(chuàng)產(chǎn)品或方案還處于未成熟、不穩(wěn)定階段，性能不佳等原因？但這些正是新產(chǎn)品或方案發(fā)展成熟過程的必經(jīng)階段，似乎理由并不充分。筆者相信，如果僅僅是這些問題，很多最終用戶會給予充分理解，并愿意為信創(chuàng)提供廣闊的舞臺，但遺憾的是，目前信創(chuàng)仍然是以行政手段推動的市場。

因此，僅僅以上述理由去解釋信創(chuàng)的問題，可能并未觸及根本原因，反而可能因此引起誤解而影響到解決實質(zhì)問題方法的提出，延緩信創(chuàng)的推進效率，降低信創(chuàng)的發(fā)展質(zhì)量。

那么，讓最終用戶“心甘情愿”地落地信創(chuàng)，到底卡哪一個環(huán)節(jié)？

筆者認為，卡在了讓最終用戶認可的對信創(chuàng)項目質(zhì)量的評估及測試方法上。為了更好理解這一結(jié)論，不妨開門見山地從最終用戶的角度思考以下兩個問題；

問題一：

廠家提供的參數(shù)和指標，都是理想環(huán)境下的數(shù)值，與用戶的生產(chǎn)環(huán)境往往相差較大，而要獲得真實的生產(chǎn)環(huán)境數(shù)據(jù)，則需要引入專業(yè)的測試團隊、方法和產(chǎn)品；但這部分能力和成本，并不是所有用戶都具備或能承擔(dān)得起。

幸運的是，部分地方政府或行業(yè)組織已經(jīng)意識到這個問題；不幸的是，雖然實施了相關(guān)的措施，但仍然缺乏行之有效、有針對性的技術(shù)方案和產(chǎn)品。這方面的難點主要體現(xiàn)在，需要從業(yè)務(wù)出發(fā)，為用戶提供完全與廠商和環(huán)境解耦的測試和可觀測性產(chǎn)品，如果不能解耦，測試和可觀測性產(chǎn)品就會影響測試數(shù)據(jù)的公允性、準確性、客觀性。

特別是在如下三個場景，很可能受到廠家或用戶的質(zhì)疑。

1. 對單一品類多個信創(chuàng)產(chǎn)品的多品牌橫向?qū)Ρ龋?/p>

2. 信創(chuàng)替換前后，國外產(chǎn)品與信創(chuàng)產(chǎn)品的對比；

3. 短期測試的結(jié)論，與長期使用的結(jié)論的對比。

問題二：

如果說第一個問題，技術(shù)力量較強的單位還能穩(wěn)妥解決，那么，面對多個信創(chuàng)產(chǎn)品的集成項目，云環(huán)境、信創(chuàng)產(chǎn)品之間的脆弱性和兼容性問題，則會產(chǎn)生更多的不確定性，甚至出現(xiàn)更多的“扯皮”現(xiàn)象。

客觀而言，這一問題也是新技術(shù)、新產(chǎn)品發(fā)展過程中的一個必然階段，但由于信創(chuàng)屬于非技術(shù)需求推動的大規(guī)模IT架構(gòu)迭代，因此，如有機體一樣復(fù)雜的信創(chuàng)IT架構(gòu)，其各個單元之間的脆弱性優(yōu)化和兼容性適配的過程將非常漫長，但毫無疑問，在如此緊迫的形勢下，這一漫長過程將不被國家、行業(yè)和用戶所接受。

造成如此漫長的適配過程的原因在于，這類信創(chuàng)集成項目，通常涉及從硬件，到操作系統(tǒng)，到基礎(chǔ)軟件組件，再到業(yè)務(wù)系統(tǒng)的多個IT單元，而且這些單元往往都是構(gòu)建于開源的云架構(gòu)之上，如何才能實現(xiàn)如此復(fù)雜的、跨棧的測試和可觀測性（不要局限于CNCF的可觀測性，這是筆者關(guān)注的另一個問題）？從現(xiàn)階段互聯(lián)網(wǎng)能夠查到的技術(shù)資料看，這方面的論述少之又少。

針對如上問題，筆者發(fā)現(xiàn)測試方法由于來自于外部，所以并不存在解耦和跨棧的問題，但可觀測性方法，由于與IT單元伴生存在，所以解耦和跨棧的問題無法回避。

但遺憾的是，在Tracing方向，無論是各類開源或商業(yè)的APM，還是Open Tracing/Open Telemetry，都或多或少地需要介入業(yè)務(wù)運行環(huán)境，而無法實現(xiàn)解耦，并且都局限于業(yè)務(wù)層或云原生，導(dǎo)致缺乏對很多架構(gòu)組件、操作系統(tǒng)的觀測能力。

而在Metrix方向，Prometheus/Zabbix等方案由于更側(cè)重于架構(gòu)和組件的狀態(tài)級監(jiān)控，欠缺細粒度的應(yīng)用組件和業(yè)務(wù)層監(jiān)控能力，所以缺乏對一個完整的信創(chuàng)集成項目的全面可觀測性能力。

由于如上能力的缺失，在筆者參與或了解的多個信創(chuàng)項目，都出現(xiàn)了各種不同程度的質(zhì)疑、試錯、延期等問題，而即使調(diào)通上線、通過驗收，后期仍然會不斷出現(xiàn)各種異常和不確定性，并需要重新邀請第三方公司進行排障和調(diào)優(yōu)的情況。

綜上，通過剖析信創(chuàng)項目落地過程中最現(xiàn)實的兩類問題，可以簡單地得出一個結(jié)論，即要加快信創(chuàng)落地的量與質(zhì)，讓更多的用戶無疑慮地擁抱信創(chuàng)，本質(zhì)上是要提出符合信創(chuàng)特征的可觀測性方法論和與之配套的產(chǎn)品方案。

一方面，要實現(xiàn)與環(huán)境的解耦，才能夠在測試環(huán)境和（準）生產(chǎn)環(huán)境平滑遷移，才能夠公允地測量歐美產(chǎn)品與信創(chuàng)產(chǎn)品的差別，才能夠讓用戶放心地在生產(chǎn)環(huán)境長時間使用，否則，任何與環(huán)境的耦合方法，都可能會因為影響結(jié)論評估的準確性和可靠性，而受到用戶質(zhì)疑。

另一方面，要具備從底層硬件或操作系統(tǒng)，到基礎(chǔ)軟件組件，再到業(yè)務(wù)系統(tǒng)的跨棧監(jiān)控能力，既能夠通過業(yè)務(wù)性能表現(xiàn)去評估一個信創(chuàng)集成項目的整體質(zhì)量，也能細粒度、無盲點地測量每個IT單元的處理性能。

簡言之，要切實突破信創(chuàng)落地最后一公里，如期完成國家相關(guān)政策的目標，有關(guān)部門還需要配套更有針對性的測試和可觀測性方法指導(dǎo)，而行業(yè)內(nèi)每個具備測試和監(jiān)控研發(fā)能力的單位，也應(yīng)該積極深入到每個信創(chuàng)項目，盡快推出切實可行的測試和可觀測性方案。（關(guān)鍵字：信創(chuàng)、可觀測性、跨棧 作者：遠橋隨筆）

免責(zé)聲明：市場有風(fēng)險，選擇需謹慎！此文僅供參考，不作買賣依據(jù)。

關(guān)鍵詞：