IT認證

Mindblown: a blog about philosophy.

  • 儲存基礎知識-SAN、DAS、NAS技術

    直接附加儲存（DAS）DAS（Direct Attached Storage—直接附加儲存）是指將儲存裝置透過SCSI線或光纖通道直接連接到伺服器。一個SCSI環路或稱為SCSI通道可以掛載最多16台設備，FC可以在仲裁環的方式下支援126個設備。 DAS方式實現了機內儲存到儲存子系統的跨越，但是缺點依然有很多：1、擴展性差，伺服器與儲存設備直接連接的方式導致出現新的應用需求時，只能為新增的伺服器單獨配置儲存設備，造成重複投資。 2.資源利用率低，DAS方式的儲存長期來看儲存空間無法充分利用，存在浪費。不同的應用程式伺服器面對的儲存資料量是不一致的，同時業務發展的狀況也決定這儲存資料量的變化。因此，出現了部分應用程式對應的儲存空間不夠用，有些卻有大量的儲存空間閒置。 3.可管理性差，DAS方式資料依然是分散的，不同的應用各有一套儲存設備。管理分散，無法集中。 4.異構化嚴重，DAS方式使得企業在不同階段採購了不同型號不同廠商的儲存設備，設備之間異構化現象嚴重，導致維護成本據高不下。儲存區域網路（SAN）SAN（Storage Aera Network ）儲存區域網絡，是一種透過網路方式連接儲存設備和應用伺服器的儲存構架，專用於主機和儲存設備之間的存取。當有資料的存取需求時，資料可以透過儲存區域網路在伺服器和後台儲存設備之間高速傳輸。SAN的發展歷程較短，從90年代後期興起，由於當時以太網的頻寬有限，而FC協定在當時就可以支援1Gb的頻寬，因此早期的SAN儲存系統多數由FC儲存設備構成，導致許多用戶誤以為SAN就是光纖通道設備，其實SAN代表的是一種專用於儲存的網路架構，與協定和設備誤以為SAN是光纖通道設備，其實SAN代表的是一種專用於儲存的網路架構，與協定和設備無關，隨著乙太網路的商業化為整體的整合。 SAN的組成：SAN由伺服器、後端儲存系統、SAN連接設備。後端儲存系統由SAN控制器和磁碟系統構成，控制器是後端儲存系統的關鍵，它提供儲存接入，資料操作及備份，資料共享、資料快照等資料安全管理，及系統管理等一系列功能。後端儲存系統為SAN解決方案提供了儲存空間。使用磁碟陣列和RAID策略為資料提供儲存空間和安全保護措施。連接設備包括交換機，HBA卡和各種介質的連接線。SAN的優點：1、設備整合，多台伺服器可透過儲存網路同時存取後端儲存系統，不必為每台伺服器單獨購買儲存設備，降低儲存設備異質化程度，減輕維護工作量，降低維護費用；2、資料集中，不同應用程式和伺服器的資料實現了實體上的集中，空間調整和資料複制等工作可以在一台設備上完成，大大提高了存儲資源利用率；3、高擴展性，存儲網絡架構使得伺服器可以方便的接入現有SAN環境，較好的適應應用變化的需求；4、總體擁有成本低，存儲設備的整合和數據集中管理，大大降低了重複投資率和長期管理維護成本。網路附加儲存（NAS）NAS（Network Attached Storage—網路附加儲存），是一種檔案共用服務。擁有自己的檔案系統，透過NFS或CIFS對外提供檔案存取服務。 NAS包括儲存裝置（例如硬碟陣列、CD或DVD光碟機、磁帶機或可移動的儲存媒體）和專用伺服器。專用伺服器上裝有專門的作業系統，通常是簡化的unix/linux作業系統，或是特殊的win2000核心。它為檔案系統管理和存取做了專門的最佳化。專用伺服器利用NFS或CIFS，充當遠端檔案伺服器，對外提供檔案層級的存取。 NAS的優點：1、NAS可以即插即用。2.NAS透過TCP/IP網路連接到應用伺服器，因此可以基於現有的企業網路方便連接。 3.專用的作業系統支援不同的檔案系統，提供不同作業系統的檔案共享。經過最佳化的檔案系統提高了檔案的存取效率，也支援相應的網路協定。即使應用程式伺服器不再運作了，仍然可以讀出資料。NAS的缺點：1、NAS設備與客戶機透過企業網路連接，因此資料備份或預存程序中會佔用網路的頻寬。這必然會影響企業內部網路上的其他網路應用；共用網路頻寬成為限制NAS效能的主要問題。2、NAS的可擴充性受到設備大小的限制。增加另一台NAS設備非常容易，但是要想將兩個NAS設備的儲存空間無縫合併並不容易，因為NAS設備通常具有獨特的網路標識符，儲存空間的擴大有限。 3.NAS存取需要經過檔案系統格式轉換，所以是以檔案一級來存取。不適和Block級的應用，尤其是要求使用裸設備的資料庫系統。 SAN和NASSAN和NAS經常被視為兩種競爭技術，實際上，二者能夠很好地相互補充，以提供對不同類型資料的存取。 SAN針對海量、以資料區塊為導向的資料傳輸，而NAS 則提供檔案層級的資料存取和共用服務。儘管這兩種技術類似，但嚴格意義上講NAS其實只是一種文件服務。 NAS和SAN不僅各有應用場合，也相互結合，許多 SAN部署於NAS後台，為NAS設備提供高效能海量儲存空間。 NAS和SAN結合中出現了NAS網關這個元件。 NAS網關主要由專為提供檔案服務而最佳化的作業系統和相關硬體組成，可視為一個專門的檔案管理器。 NAS閘道連接到後端上的SAN上，使的SAN的大容量儲存空間可以為NAS所用。因此，NAS網關後面的儲存空間可以根據環境的需求擴展到非常大的容 量。 “NAS閘道”方案主要是在NAS一端增加了可與SAN相連的“介面”，系統對外只有一個用戶介面。 NAS閘道系統雖然在某種程度上解決了NAS與SAN 系統的儲存設備級的共享問題，但在文件級的共享問題上卻與傳統的NAS系統遇到了同樣的可擴充性問題。當一個檔案系統負載很大時，NAS網關很可能成為系統的瓶頸。

  • 網工基礎 | 資料中心技術:LISP

    LISP是什麼？LISP是基於網路映射-封裝的協議，其優點在於無需對主機協議棧做任何修改，也不需要對網路中現有的基礎設定做大規模改進，只需添加相對較少的具有特殊功能的隧道路由器以實現映射-封裝。 LISP採取了「Jack Up」的架構，透過在原始的IP網路層下添加路由層（原始的IP網路層標識節點身份訊息，添加的路由層標識節點位置資訊）實現「身份與位置分離」的想法。 LISP的設計旨在提高站點的多宿性，增強ISP多家鄉技術。在LISP中，IP位址的使用與傳統的網路無異。 LISP的IP位址被分為兩類，一類是終端識別(Endpoint Identifiers, EIDs)，另一類則是位置識別(Routing Locators, RLOCs)。 EID用於標識主機身份，其長度為32位元(IPv4)或128位元(Ipv6)，用於填寫LISP裡層包頭的來源位址或目的位址。來源主機取得目的主機的EID與現有網際網路的實作方式無異，例如透過DNS查詢或SIP訊號交換。來源主機所在的站點擁有自己的EID前綴塊，當來源主機請求EID時，站點透過現有的機制分配EID給來源主，EID也可作為來源主機的「本機」IP位址。由於EID標識主機身份，EID必須全球唯一且不能用作RLOC。值得一提的是，EID塊可以依照層次劃分、獨立於拓樸或易於映射系統操作的方式進行分配。另外，EID位址區塊的分配可以根據本地佔地結構，以方便站點內資料包的路由；但站點內的結構對外不可見。 EID不是全球可路由位址，其路由範圍僅限於本地站點。RLOC用於標識主機位置，其長度為32位元(IPv4)或128位元(Ipv6)，用於填入LISP外層包頭的來源位址或目的位址，它是gress Tunnel Router, ETR)的位址，是EID到RLOC的對應結果。 RLOC通常是由業者依照拓樸編址，它也是PA位址，易於聚合，是全球可路由位址。一台ETR上可以分配多個RLOC位址，使得一個EID可以對應多個RLOC，以實現多家鄉技術和流量工程技術。在LISP中，為了實現映射-封裝技術，引進了兩個新的實體－入口隧道路由器(Ingress Tunnel Router, ITR)和出口隧道路由器(Egress Tunnel Router, ETR)。 ITR是來源主機發送資料的預設閘道。當來源主機需要向站點外的傳送資料時，資料將傳送至ITR並由ITR進行封裝。 ITR首先查看來源主機所傳送封包的目的EID，並執行EID-RLOC的對應。之後，ITR將所獲得的RLOC位址作為外層包頭目的位址以及自身的RLOC位址作為外層包頭的來源位址封裝到來源主機所傳送的封包上並依照路由表轉送出去。簡而言之，ITR接收主機發送的資料包並進行封裝，並向更廣闊的網路轉送。 ETR是LISP封包外層包頭的目的位址所指向的路由器。ETR收到發送給自己的LISP資料包後，將資料包解封裝，把外包頭剝離，並根據內包頭的目的EID轉送資料。另外，ETR也負責向映射系統註冊本站點內的EID。 LISP的基本規則如下：1. 主機所傳送的資料包，其目的位址只能是EID。主機對EID-RLOC的對應完全透明，並認為以EID作為目的位址可以穿越網路到達對端節點。 LISP路由器截獲本站點內以EID為目的位址的封包，封裝RLOC位址並將其轉送至EID不可路由的核心網，最終到達目的節點，但此操作並未改變現有主機傳送封包的過程。 2. EID是分配給主機IP位址。 3. LISP路由器通常只處理RLOC位址。 4. RLOC位址通常指派給路由器。 5. 由路由器發起的封包，其來源位址可以是EID也可以是RLOC。當路由器充當主機的時候，其封包來源位址為EID。但此時路由器所使用的EID不可以在作為RLOC使用。 EID僅可以在自己所屬的站點路由。 6. EID可以依層次劃分方便管理，同時，也能促進映射系統的可擴展性。 EID的層次劃分獨立於網路拓樸。 7. EID也可依照適合本地路由的方式組織。 LISP的協定流程當LISP域內來源主機發起通訊時，與傳統網際網路一致，來源主機首先查詢DNS系統並取得目的主機的EID。來源主機將自己的EID作為資料的來源位址、目的主機的EID作為目的位址傳送資料至ITR。 ITR檢查EID-RLOC快取是否有相關條目，如果存在，ITR直接封裝封包並轉送至網路中，外層包頭來源位址為ITR的RLOC，目的位址為目的主機所對應的ETR的RLOC。資料到達目的主機所屬的ETR後，由此ETR對資料包進行解封裝，移除外層包頭並依目的主機的EID轉送。 ITR如果沒有對應的快取條目，ITR會向映射系統發送Map Request訊息，查詢對應映射資訊。 Map Request訊息被映射系統轉送到目的主機所屬的ETR上，並由該ETR透過發送Map Reply訊息回覆ITR目的主機EID所對應的RLOC。當ITR收到Map Reply後，快取目的主機EID-RLOC的映射條目。此後，ITR/ETR所傳送的資料包不再經過映射系統，直接透過核心網路傳送。另外，ETR也可根據Map Request資訊快取來源主機的EID-RLOC來映射條目。示意圖如下：

  • WASI 1.0：WebAssembly 将会在 2026 年无处不在

    導讀：WebAssembly 元件模型標準化的最後階段，其能力能夠逐步取代容器，因為容器對於許多應用程式來說並不算理想，無論這些應用程式是否在 Kubernetes 中。伴隨著 Wasm 3.0 和元件模型發布， 它代表 WebAssembly 技術又取得了巨大的進步。預計WebAssembly 走向成熟的最後階段，將在 2026 年 2 月發布的WASI 0.3.0版本中真正到來。元件模型標準化的最後階段意味著 WebAssembly 將能夠逐步取代容器，而容器對於許多應用場景（無論是否在Kubernetes 環境中）而言並非理想之選。這些應用場景包括邊緣設備、非同步、事件驅動部署和無伺服器環境，以及需要在單次發布中同時覆蓋大量（甚至可能無限量）節點的用例。 事實上，WebAssembly 的應用範圍早已超越瀏覽器。微軟Azure 首席產品經理Squillace表示，WebAssembly 已在瀏覽器、伺服器、CDN 和後端服務等生產環境中穩定運行，證明了其成熟度和廣泛的適用性。「WebAssembly 幾乎可以在所有環境中運作。」Squillace說道，雖然WebAssembly核心部分有意設計得較為底層，難以直接使用，但最近的規範更新實現了更高層次的抽象。引用類型和介面類型允許元件公開有意義的API，而無需開發人員了解WASM內部機制，從而使這項技術更容易被工程師接受。 Squillace表示，對於那些對組件特別感興趣的人，字節碼聯盟對工程師免費開放。該聯盟的重點在於支援工程師和開源開發，而非市場推廣，並提供包括文件在內的各種資源，使開發人員能夠從零開始使用WebAssembly元件。 Squillace也提到，這些選擇並非互相排斥。 WebAssembly和元件模型並非旨在取代語言、模組或容器，而是為了實現互通性、安全性，並擴展軟體在不同語言和環境下的功能。 Squillace表示，WebAssembly並非完美無缺，但這並非重點。重要的是它所帶來的可能性。這是一個由參與者共同建構的令人興奮的領域，因此，他說道，這次關閉實際上也是一個新的開始。核心規格雖然 WebAssembly 的核心部分有意被設計得較為底層，比較難於直接使用，但最近的規範更新實現了更高層次的抽象。 Squillace 表示道，引用類型和介面類型使得元件能夠公開有意義的 API，而無需開發人員了解 WASM 的內部機制。 Squillace 的原話：「核心層面的規範工作…使得組件模型能夠真正傳遞複雜的結構，從而形成有意義的 API。」目前，基於 Wasm 的解決方案尚不能完全取代容器，但在許多能夠充分發揮 WebAssembly 有優勢的場景中，Wasm 的應用正日益普及。 「組件模型是採用 Wasm 的一個重要原因，即使它仍處於發展初期。即便如此，WebAssembly 的應用範圍已經非常廣泛，在許多無伺服器和邊緣應用中都佔據了重要地位。」 Endor的執行長兼聯合創始人Daniel Lopez提到。「許多用戶，甚至可能是大多數用戶都沒有意識到它正在被底層使用，尤其是在 SaaS 和無伺服器服務中。Wasm 已經為許多應用程式和用例提供支援。如果能夠進一步標準化，並獲得開發者和行業參與者的廣泛支持，這些都必將加速 Wasm 的普及。」Wasm 3.0 並未最終確定組件模型。雖然…

  • 桌面雲為何未能廣泛普及？

    原創 YZY 閒聊服務器存儲 桌面雲端（又稱雲端桌面），其核心原理與阿里雲、騰訊雲等伺服器一致 —— 將運算功能部署在遠端伺服器，終端僅承擔顯示與資料讀取任務，無本機運算與儲存能力，搭配瘦客戶端使用時，可外接顯示器、鍵盤、滑鼠及 U 碟等裝置。 2010 年左右，桌面雲方案逐漸成熟並開始推廣，各大廠商紛紛推出相關產品。當時廠商與專家普遍預測，政府和企業會大規模採用這項技術，核心原因是它能精準解決多個用戶痛點：管理高效：運算與儲存集中在伺服器端，可遠端管控終端開關機（綠色節能是當時多數廠商的核心行銷點），系統故障也能在伺服器端統一排查解決；資料安全：終端僅負責顯示，所有資料集中儲存於伺服器，從根源杜絕了資料洩密和違規拷貝的風險；擴容經濟：前期完成伺服器系統搭建後，後期只需按需採購瘦客戶終端即可實現擴容，相比採購單台PC 能降低大幅成本。然而經過多年發展，桌面雲並未如推廣時預期的那樣取代傳統 PC，如今市場佔有率仍以傳統 PC 為主，即便在政府和企業場景中，桌面雲的佔比也未達到 50%。照理說，新技術出現後往往會逐步替代老技術，桌面雲未能廣泛普及的核心原因的如下：前期投入高：伺服器基建需要一次性投入巨額資金，對不少用戶而言門檻過高；維護門檻高：運維人員不僅要掌握 PC 和軟體相關知識，還需精通伺服器技術，專業要求遠超傳統 PC 運維人員不僅要掌握 PC 和軟體相關知識，還需精通伺服器技術，專業要求遠超傳統 PC 運維人員；時，僅影響單一設備，重啟或重裝系統即可解決；但桌面雲端伺服器端一旦出現問題，可能導致多個甚至所有終端無法使用，影響範圍極廣；隱私顧慮：如今微信辦公已成常態，而微信兼具工作溝通與私人社交功能，若所有資料均儲存於公司後端伺服器，員工無法避免個人隱私設計使用「高畫」：「大型電視設備外端」的本地運算能力更具優勢，桌面雲端難以滿足高效能需求。總結桌面雲端的適配場景更偏向高保密需求、公私資料嚴格分離、業務高度集中的產業，例如醫院、公檢法、軍工等領域，更能發揮其資料安全、集中管理的核心優勢。

  • 純粹程式設計者：氛圍程式設計究竟有沒有用處？

    導讀：曾經，有些程式設計純粹主義者認為 BASIC 語言有害，而現在的人工智慧甚至連 BASIC 都無法做到。一個前景光明的項目，必然需要一支團隊 —— 這是公認的事實。這支團隊必須由經驗豐富、判斷力強、具備分析邏輯能力和良好人際溝通技巧的優秀開發者組成。而AI 編碼在其中的定位仍存在巨大爭議。但企業 IT 領域對 「氛圍程式設計」（Vibe Coding） 的態度卻十分明確：要嘛是在推銷它，要嘛是對它敬而遠之。原因很簡單。程式碼產生工具的賣點是 “透過自然語言指令快速出結果”，無需使用者掌握程式碼工作原理的專業知識。這一點在某種程度上確實成立，精心挑選的兩分鐘演示也確實令人印象深刻。從這方面來看，氛圍程式設計與已經存在了 30 年的低程式碼 / 無程式碼運動甚為相似。但氛圍程式隨後便會暴露致命缺陷：它具有不確定性。低程式碼 / 無程式碼平台的介面對使用者輸入的回應是一致的。無論是調整字體，還是徹底換一個全新思路重新開始，迭代優化都能順利推進。而氛圍程式設計則可能在相同指令下，不同時間給出截然不同的結果。想要調整結果，很大程度上取決於 AI 如何解讀你的需求，以及它對自己最初想法的執著程度 —— 通常這種執著還相當強烈。更別提當你的工具不斷改變時，如何維護一個沒有人類完全理解的程式碼庫了。如果 30 年後低程式碼 / 無程式碼領域都沒有出現太多成熟的生產級應用，那麼氛圍程式設計的前景無疑更加黯淡。即便氛圍程式設計實現了其最基本的功能 —— 快速生成原型來探索想法 —— 也會遭遇 「原型無法捨棄」 的問題，最終演變成難以控制的 「怪物」。一旦某個原型看起來能運行，來自外部的壓力通常會迫使團隊立即在此基礎上進行開發。這種情況在任何環境下都已經夠糟糕了，而 “氛圍” 根本無法應對這種局面。不過，在某個方面，氛圍程式確實擁有其他工具難以比擬的吸引力。自從開機就能直接進入 BASIC 解譯器的家用電腦時代以來，新手用戶終於能透過簡單輸入就能實現一些功能了。林納斯・托瓦茲（Linus Torvalds）上週將它視為一大優勢，認為這與當年從電腦雜誌背面抄錄程序的日子頗為相似。這話並不是沒有道理 —— 如果你經歷過那個年代，就會記得修正數百行晦澀代碼中的邏輯錯誤或打印錯誤是多麼可怕的經歷 —— 但這幾乎完全偏離了核心問題。當年的 BASIC 語言也遭遇了與如今氛圍程式設計類似的批評，被認為會助長糟糕的程式設計習慣，催生結構混亂、難以理解、無法維護的程式碼。程式界泰斗埃德加・迪傑斯特拉（Edsger Dijkstra）在《GOTO 語句有害論》中就提出了這一觀點，而這句話在數十年間一直被廣泛引用。這就好比說，那些拿起樂器只是想試試身手的孩子，或是被沒有正規訓練背景的老師教導的孩子，永遠只能做出糟糕的音樂。通常情況下確實如此，但大多數優秀的音樂家都是這樣起步的。音樂的起源就如此。如果你發現自己熱愛它，就會不斷進步。而BASIC 語言的情況也是如此。但氛圍程式設計卻沒有這樣的成長路徑。這並非完全是它的錯。在現代運算環境中，要實現 “有用的功能”，就需要編寫包含 API、複雜結構的程式碼，核心邏輯之外還充斥著無數繁瑣的附加部分。透過反覆調整指令來 “瞎折騰”，無法建立起編寫程式碼所必需的內在理解框架；而沒有了那種突然頓悟帶來的多巴胺獎勵 —— 這種獎勵正是許多人早期程式設計經歷的動力源泉 ——…

  • 追溯SAP會計憑證是從哪裡開始的

    原創 小曉課堂會計憑證SAP系統在資料處理，無論是業務處理，或是財務處理都會產生大量的憑證，無論是什麼憑證，最終的反映形式就是會計憑證。會計憑證是什麼，就是Accounting Documents會計憑證。每個筆記帳都一直以憑證形式存儲，每一憑證都作為前後一致的單位保留在系統中，直至將​​它歸檔。唯有完整憑證可以計入SAP系統；「完整」是指借貸餘額為零。 其近一步的條件是完整、準確輸入系統配置時定義為「必輸（Required）」的欄位。儲存憑證或進入不同憑證項目時，系統會自動根據配置檢查必輸項目是 否已經輸入或是否按照標準輸入，並發出適當的提示訊息，拒絕進行下一步動作，如果輸入錯誤的話。每張憑證都有一個憑證抬頭（Document Header）和兩個以上的行項目（Document Items）組成。憑證抬頭：對整個憑證有效的訊息，例如四個日期、文字摘要、憑證類型等等。行項目(Line Items)：僅包含特定項目的訊息，如記賬碼、科目編碼、金額、稅碼、成本對像等有科目、記賬碼等配置綜合決定的信息。憑證類型創建會計憑證需要有很多內容支撐，例如我們上面說的憑證抬頭和憑證行項目資訊裡的數值，都需要我們提前把相關配置做好後，在進行會計配置的創建。使用國內財務軟體的企業，一般將會計憑證分為收款憑證、付款憑證和轉帳憑證，也有企業只使用一種憑證類型。使用SAP後，你會發現SAP中有多種會計憑證類型。憑證類型用於記錄SAP FI中的各種業務交易。 SAP已經交付了許多標準憑證類型，但也可以根據公司的要求建立新的憑證類型。憑證類型有助於組織識別和分析業務交易。 SAP根據業務類型區分會計憑證，例如RE是採購發票憑證、RV是銷售發票憑證、WL是銷售出庫憑證、ML是物料分類帳憑證，等等。系統自動產生的會計憑證由SAP預設憑證類型，通常都不會調整。在專案執行時，一般根據企業會計需求，定義手動輸入的會計憑證類型，原則上依據業務類型區分憑證類型（極少有企業定義一種憑證類型）。 SAP中會計憑證類型具有以下功能： 1）易於識別憑證對應的業務；2）定義了憑證編號範圍；3）定義了允許記帳的科目類型。透過應用程式配置設置，我們可以將交易定義並限制為特定的憑證類型。憑證類型決定憑證的編號範圍：系統透過不同的憑證類型編號範圍儲存一種憑證類型的所有憑證。編號範圍可以是外部定義也可以是內部定義。那麼，接下來我們就來看看憑證類型的配置，我這裡使用的是S/4 HANA系統，但正常這些配置應該都是一樣的。設定路徑：財務會計 – 財務會計的全域設定 – 憑證 – 憑證類型 – 定義單據類型或使用交易代碼OBA7 執行進去之後我們就可以看到所有SAP預先定義的憑證類型。 雙擊其中一個憑證類型就可進入詳細設定。 編號範圍編號範圍是為審核每個公司代碼在一個財務年度中的每一憑證而設定的。所有被過帳的交易必須設定一個憑證號碼。在一張憑證被過帳前,必須為憑證類型 設定一個號碼範圍， 這些號碼可以由系統內部設定或由使用者 在外部設定。特定的憑證類型的憑證編號只能在既定的編號範圍內選擇,並且是唯一的。若手工收入編號，系統會判斷，該編號是否在既定的編號範圍內；如果是的，會繼續判斷是否唯一。會計基礎工作規範要求憑證編號連續，在SAP系統中，如果發現憑證有誤，不可像國內ERP系統可以刪除重做，只能沖銷，不能刪除。設定路徑：財務會計 – 財務會計的全域設定 – 憑證 – 憑證編號範圍 – 定義憑證編號範圍或使用交易代碼FBN1 輸入或選擇一個公司代碼 點選“”可以查看配置的憑證編號範圍概覽。 點選「複製」按鈕可以將憑證編號範圍配置從一個公司代碼複製到另一個公司代碼。 點選「檢視」按鈕， 可查看此公司代碼下設定的憑證編號範圍。 點選「間隔」按鈕，可查看目前編號分配狀態。 點選「狀態」按鈕， 可以修改公司代碼的編號範圍。 我這裡是新的公司代碼，所以，這裡看是沒有資料的，正常應該是像下面這個截圖一樣，每一年都是有具體編號範圍數值的。

  • 思科為AI生態換了一套「看人」的方式

    AI時代，選擇合作夥伴，正在變成一門比選技術更難的學問。思科給了一個新的解法，不是再造一套複雜的認證體系，而是換了整個底層邏輯：讓能力被看見，讓價值被衡量。作者 | 王聰彬來源 | 至頂科技新時代的企業紛紛押注AI，但現實卻遠比想像殘酷。約95%的企業AI、生成式AI試點未產生可衡量商業價值或ROI。這項結論來自於MIT在2025年針對300家企業的研究發布的《The GenAI Divide: State of AI in Business 2025》報告。是模型不夠先進？算力不夠充足？顯然不是。 AI專案越來越需要“結果”，企業卻越來越難判斷，誰有能力將它跑通。顯然在AI時代，選擇合作夥伴，正在變成一門比選技術更難的學問。思科給了一個新的解法，不是再造一套複雜的認證體系，而是換了整個底層邏輯：讓能力被看見，讓價值被衡量。為什麼過去那套「夥伴邏輯」正在失效過去的合作夥伴體係都是講究誰的銷售能力強、誰的覆蓋區域大、誰擁有更大的規模。這套邏輯在以產品和設備為核心的IT時代運作良好，也支撐了產業的快速擴張。但當AI進入企業核心業務，客戶從“買設備”變成“買結果”，從“交付完成”延伸到“持續運營與優化”後，原來靠頭銜區分夥伴的邏輯，就已經失效了。 AI專案本質上是一項高度依賴系統整合與持續營運的長期工程。這種變化，一方面合作夥伴需要提升自身能力，一方面需要一種清晰、可見的全新連接方式，讓技術、合作夥伴、客戶效連接在一起，在同一價值坐標系中協同推進落地。 AI的出現，為思科合作夥伴帶來了前所未有的IT市場變革。思科董事長兼執行長Chuck Robbins則看到其中更大的機會。 2026年1月25日思科將推出全新思科360合作夥伴生態系統，而改變的核心就是，讓客戶能更清晰、快速地找到「真正滿足業務需求的合作夥伴」。 Chuck Robbins談到這項改革的核心在於：提高獲利能力、增強可預測性，並幫助合作夥伴在人工智慧時代贏得更多業務。思科全球副總裁兼大中華區執行長黃志明表示，思科360合作夥伴生態系統打破了沿用20餘年的傳統模式，以「精準匹配、能力聚焦、共贏增長」為核心，透過清晰的伙伴分級認證、專業的技能賦能和創新的激勵機制，讓每一位有專長的伙伴都能發揮最大價值。為何現在推出新的合作夥伴生態系統，主要有兩大原因，第一，合作夥伴長期以來一直希望簡化流程；第二，技術市場的快速變化以及人工智慧的影響也需要對合作夥伴計劃進行重新設計。目前思科正在圍繞三大目標建構產品組合，無論是AI就緒的資料中心、面向未來的辦公場所，或是數位韌性建設，思科360合作夥伴體係都以價值交付為導向重構合作邏輯。並藉助優化的夥伴定位工具加速能力匹配與資源協同，在提升客戶體驗的同時，推動端到端解決方案更快落地。所以思科360合作夥伴體係不僅是思科生態策略的重要升級，更是思科深耕大中華區市場、賦能客戶與夥伴共贏的堅定承諾。如何用能力標籤解決「看不清楚」的問題AI落地是一項高度系統化的工程，對專業能力的要求可以說前所未有。幾乎所有企業都希望選擇更專業的合作夥伴，但現實是，在高度複雜的專案環境中，「專業」本身卻變得難以辨認。統一的頭銜、廣泛的能力，很難準確反映一家夥伴在某一具體領域的專長和真實能力。其實市場中並不缺乏有能力的夥伴，如何被企業發現、辨識才是關鍵。也正是這種“看不清”，直接放大了AI專案的不確定性。思科360合作夥伴生態系的關鍵改變，正是從這裡切入。思科全新的合作夥伴資質體系取消了傳統金牌、進階、優選的分級體系，所有合作夥伴註冊即入門。透過新的資質系統、專業化認證、核心技術能力及思科賦能服務(Cisco Powered Services)等模組，合作夥伴能夠清楚地向客戶展示其在思科全產品組合（例如：網路、雲端及 AI 基礎架構、安全性、Splunk、協作和服務等）領域的差異化能力及優勢。其中最關鍵的變化是全新「能力標籤」能夠區分合作夥伴的能力範圍，客戶可以依照業務需求篩選合作夥伴。例如想做網路擴建，找「思科網路精英合作夥伴」；想做安全項目，找「思科安全精英合作夥伴」；想上協作產品，找「思科協作精英合作夥伴」。這種模式更傾向以客戶為導向，在面對具體需求時，客戶看到的不再是籠統的分級，而是能否做這件事的專家，讓選擇路徑更直接。在AI時代，這種對能力可見度的重構，正成為專案成功的關鍵前提。思科大中華區副總裁兼大中華區合作夥伴事業部總經理周丹指出，當合作夥伴透過高價值的解決方案與服務，為客戶創造更大價值時，不僅會贏得客戶，也將贏得思科更大力度的投資與支持，實現可持續的盈利增長，以及“服務客戶”與“自身發展”的雙向奔赴赴赴。思科360合作夥伴系統是對客戶決策方式的重新理解，在專業能力的基礎上，具備更強技術能力以及完整的生命週期管理能力，可提供更貼合客戶需求的專業解決方案。合作夥伴的角色正在更加「被信任」當能力被更清晰地識別，變化首先發生在合作關係本身。合作夥伴開始從傳統意義上的通路節點，轉向更深層的價值共創者。現在通過思科認證，具備在某一產品領域專業技術能力的合作夥伴都將是Cisco Portfolio Partner。他們都具備在某一產品領域（例如：網路、雲端及 AI 基礎架構、安全性、Splunk、協作和服務等）專業技術能力。思科大中華區副總裁兼大中華區合作夥伴事業部總經理周丹表示，思科360合作夥伴生態系統意味著更精準的價值匹配：我們整合六大技術方向，透過四大價值指數全方位評估夥伴能力，讓客戶能快速找到最適合自己的「專家型夥伴」－無論是AI前沿應用、安全防護升級，讓客戶快速找到最適合自己的「專家型夥伴」－無論是AI前沿應用、安全防護升級，或是全數更順暢、更高效能流程。同時，思科也設立了精英合作夥伴，他們不僅在技術上具備高階能力，還在客戶服務方面投入大量資源，建立了成熟的商業實踐體系。獲得精英級認證的合作夥伴，不僅擁有深厚的銷售與創新能力、還具備涵蓋全生命週期的交付能力，並能根據客戶需求提供專業化、客製化的實施服務。此外，思科精英合作夥伴還可透過獲得思科核心產品、服務和解決方案匹配的專業化認證，進一步強化並展現其深厚的專業能力和技術實力。合作夥伴普遍對思科360合作夥伴生態系統表示認可。 Alykas總裁兼執行長認為，計劃向客戶傳達了：這對他們有什麼切實好處，而不僅是合作夥伴或思科能從中獲得什麼。 「人工智慧正在真正重新定義我們與OEM合作夥伴（無論是思科還是其他公司）共同創造的價值。這不僅僅是新技術的問題。它使我們能夠真正與這些OEM合作夥伴共同研發智慧解決方案，這些解決方案真正專注於加速客戶成果，從而釋放成長機會，」iT1首席營收長David Harper說道。在中國，目前華訊網絡以26年金牌合作夥伴累積為基礎，已在5個產品組合（Portfolio）獲得精英資訊，讓客戶深度體驗思科先進的技術與產品，又能藉助華訊網絡的專業服務能力，加速技術產品向實際業務價值的轉化；港寬科技借助新的身份和能力標籤，讓網絡與安全、協作、雲與雲與安全、協作、雲與雲與安全、協作、雲與AI 基礎架構等核心優勢由客戶快速識別，並以客製化方案與端對端交付能力提升合作效率；網安捷通將其在零信任安全、雲端與AI就緒基礎設施等關鍵方向的專業性前置呈現，大幅壓縮溝通成本、加速需求匹配；凱維斯則讓客戶在合作前判斷匹配度，讓專案協同工作更穩健。信任開始成為合作關係中最重要的資產，這也正是AI時代合作夥伴角色變化的重點方向。思科360合作夥伴資質體係就像一張合作夥伴的“能力與交付成績單”，企業透過這張成績單企業可以更快建立信任，降低決策不確定性。當生態開始圍繞「AI成長」運作思科已連續三年發布《人工智慧就緒指數》（Cisco AI Readiness Index），今年報告顯示，全球僅有13%的企業被認為「完全做好了迎接AI的準備」。這意味著，多數企業面臨的並非是否上AI的問題，而是如何補齊AI基礎設施，或是技術債。與傳統IT專案不同，AI專案天然具有跨角色、跨領域的特徵，算力、資料、模型、應用與業務目標高度耦合，參與各方的邊界正在變得模糊。專案成敗不再取決於某一個技術環節，而取決於多方能否圍繞同一業務目標持續協同，並對結果形成共識。思科360合作夥伴生態系統則實現了對客戶、合作夥伴、思科三者協作模式根本性的重構，他們將成為圍繞同一目標反覆迭代、持續優化的價值共同體。未來的AI生態將發展為一個可持續、高韌性、以客戶業務目標為中心的合作網絡。要將技術價值高效傳遞到每位客戶，離不開完善的管道，思科全新的合作夥伴資質體係正是這價值傳遞的核心載體。依托這體系，思科以技術創新為驅動力，將最新的平台能力、專業支援和工具傳遞到每位客戶手中。隨著思科致力於為企業提供邁向人工智慧時代所需的基礎設施和解決方案，其龐大的合作夥伴比以往任何時候都更加重要，這也是全面升級思科360合作夥伴生態系統的原因之一。 「如果沒有合作夥伴，人工智慧的下一階段將難以真正落地。」思科總裁兼首席產品長Jeetu Patel 強調，思科360合作夥伴生態系統正是透過系統性賦能合作夥伴，釋放其在資料中心、邊緣運算等關鍵場景中的能力，把AI成長機會轉化為可交付的產業成果，共同推動技術創新與規模化應用。而思科正持續推動網路、安全以及 Splunk 等核心能力與AI的深度融合，建構面向未來的AI基礎設施底座。思科360合作夥伴生態系統則進一步放大這些能力，協助合作夥伴將思科的技術優勢轉化為可落地的解決方案，在客戶的AI基礎架構中發揮關鍵作用。思科大中華區資深副總裁兼技術長侯勝利表示，通過認證的合作夥伴不僅具備卓越的技術能力，能夠獲得思科最新的技術賦能與專業支持，基於思科平台的不斷創新，為客戶提供從設計、整合到運維的全生命週期服務。全方位的支持，將協助客戶把技術優勢轉化為生產力，協助業務目標的達成。 「當你越來越深入參與思科360合作夥伴生態系統時，思科會提供額外的專業化培訓或認證，並激勵你發展自己的業務，其中許多都與人工智慧有關，」iT1首席行銷長Shelliy Cymbalski說。當能力被看見、成果被衡量、激勵被對齊，一個更具韌性、創新力的AI生態才真正成形。思科將在新的合作體系下，與夥伴攜手將技術優勢轉化為客戶可見的成果，建構一個以價值為核心、永續演進的AI生態。

  • 大廠排名梯隊有哪些公司

    大廠排名梯隊有哪些公司以下是綜合市值、業務規模、產業影響力等因素整理的大廠排名梯隊及代表公司： 第一梯隊（市值超千億美元或產業絕對龍頭） 騰訊：市值超7000億美元，社交、遊戲、金融科技等領域全面領先，擁有微信、QQ等國民級應用，遊戲業務全球知名。阿里巴巴：市值超3,500億美元，電商、雲端運算、物流等領域佔據重要地位，阿里雲是國內領先的雲端運算服務商，淘寶、天貓等電商平台影響力巨大。拼多多：市值超1,600億美元，以低價策略與社群電商模式快速崛起，海外業務Temu表現突出，成為全球電商市場的重要力量。字節跳動：市值超萬億人民幣，以抖音、今日頭條為核心，涵蓋短視頻、資訊、社交等多個領域，用戶規模龐大，創新能力強。 第二梯隊（市值接近千億美元或細分領域領導） 小米：市值超1300億美元，智慧型手機、智慧硬體、物聯網等領域佈局廣泛，造車業務為估值加分，生態鏈企業眾多。網易：市值超800億美元，遊戲、音樂、教育等領域表現突出，《逆水寒》《蛋仔派對》等遊戲產品影響力大，網易雲音樂在音樂流媒體市場佔據一定份額。美團：市值超800億美元，本地生活服務領域龍頭，涵蓋外帶、飯店、旅遊、到店餐飲等業務，用戶基礎龐大，服務覆蓋範圍廣。京東：市值超400億美元，電商、物流、科技等領域協同發展，自營電商模式註重品質與服務，物流系統高效、便利。 第三梯隊（市值介於300-500億美元或垂直領域頭部企業） 攜程：市值超400億美元，線上旅遊服務領域領先，提供機票、飯店、旅遊路線等一站式服務，旅遊市場回暖帶動業務成長。百度：市值超400億美元，搜尋引擎、人工智慧、自動駕駛等領域佈局，AI技術實力較強，但傳統搜尋業務面臨競爭壓力。快手：市值超300億美元，短影音平台用戶活躍度高，直播電商、內容創作等領域發展快速，與抖音形成競爭格局。貝殼：市值超300億美元，房地產交易服務平台，整合線上線下資源，提供房屋買賣、租賃、裝修等服務，產業影響力逐漸提升。 第四梯隊（市值100億美元左右或新興領域潛力企業） B站：市值超300億美元，二次元文化社區，年輕用戶群龐大，內容生態豐富，遊戲、廣告、直播等業務多元化發展。小紅書：市值超200億美元，生活風格分享平台，用戶以年輕女性為主，電商、內容行銷等領域發展迅速，品牌影響力逐漸擴大。得物：市值超100億美元，潮流電商平台，聚焦年輕消費者，商品種類豐富，社區氛圍活躍，電商模式創新。Shein：市值超100億美元，跨國電商平台，以快時尚服飾為主，價格低廉、款式多樣，海外市場成長迅速，成為全球知名的時尚品牌。以上梯隊劃分僅供參考，不同維度的評估可能會導致排名有所差異。

  • HPE Comware高級產品認證考试-HPE6-A89

    HPE Advanced Product Certified – ComwareHPE Comware高級產品認證考试-HPE6-A89HPE Networking Comware Exam:HPE6-A89 通过HPE6-A89認證考试證明您具備 HPE 網路 Comware 架構的基本和進階知識，包括第 2 層和第 3 層技術，以及利用協定無關組播 (PIM) 的密集和稀疏模式組播解決方案。 参加HPE6-A89需取得 HPE 學習中心的存取權限並取得 HPE 學習者 ID。如果此認證需要筆試或線上考試（HPE0、HPE6 或 HPE2），則需要在我們的監考/線上考試供應商 Pearson VUE 建立使用者個人資料。實作考試（HPE1 或 HPE0-AxxxP）由 PSI 或 Aruba 教育服務提供，因此無需建立 Pearson VUE 使用者個人資料。 認證證明您具備 HPE 網路 Comware 架構的基礎和進階知識：~二層技術，包括多實例生成樹（MSTP）和鏈路聚合（Trunks）~第 3 層技術，包括靜態路由、具有多區域實現的開放最短路徑優先 (OSPF) 和邊界網關協定 (BGP)~利用協定無關多播 (PIM) 的多播解決方案，支援密集和稀疏兩種模式。 适合参考人员認證的典型候選人是網路或系統管理員、網路工程師或顧問，他們將 HPE…

  • 最難的ANR問題解決心得

    原創 王小二的技術棧 如果問我什麼ANR問題最難解，那肯定是no focus window anr。這個anr的觸發原理很簡單，inputflinger中focus window長時間為null，這個時候來了一些key事件需要分發，就會導致anr。那這個問題難解在哪裡呢，導致focus window長時間為null的原因很難從日誌中分析。整個問題的發生問題的線路太長，APP-AMS-WMS-SurfaceFlinger-InputFlinger。如果這個focus window是觸發ANR問題的應用主線程繁忙或阻塞，導致了進入這個app後，沒有及時的觸發activity的visiable的調用，這個問題可能還比較好解決，一般通過問題應用的主線程相關的日誌以及data/anr的trace，或者通過字節移動之前做的主線程的message的history功能，可以快速的日誌中找到相關的問題。1.CPU負載高，ANR in日誌看到2.記憶體不足，導致swap機制線程負載高，ANR in日誌看到3.死鎖等問題，data/anr的trace檔中看到。 最難解的問題就是這個鍋不是出ANR的應用，而是別的原因，導致了focus window沒有觸發更新，而且一般這個問題是monkey跑出來的，很難找到復現路徑，我舉例幾個我遇到過場景。一、Launcher啟動應用程式動畫異常，導致了遠端動畫沒有及時finish二、轉屏動畫過程中，部分需要ready的介面沒有繪製完成，導致了轉屏逾時。三、手勢上劃的遠端動畫沒有異常結束，導致介面處於recents動畫階段四、SurfaceSyncGroup機制中，部分介面沒有ready導致了已經準備顯示的activity也沒有visible五、莫名其妙的別的ANR觸發的dump導致了目前應用的運行異常 大家可以發現這種情況下你可能很難從日誌中快速發現問題點了，尤其一看data/anr的trace文件，出問題的應用主線程就在looper中休眠著呢。這時候只能盡可能的去看adb日誌中，尋找出現anr時候的蛛絲馬跡，盡可能的還原現場，這種問題就是及其難的，有時候就需要不斷加日誌，不斷的復現，再去解決。在公司，這類問題，也是摔鍋的大戶，因為app分析不出來，framework也很難分析出來，然後這個問題還能偶發的複現。如何破局，我覺得系統中要對一些window事務切換的場景做一些針對性日誌增強，這樣子一旦出問題的時候可以比較快速定位出問題的場景。盡可能的縮小分析範圍。當然要大家分析這類問題都抱著認真的態度，而不是monitor幾個版本，不復現就解決了。可以說目前我有效解決過的偶現的no focus window不超過10個，有時候也是稀里糊塗的在解決別的內存洩漏，cpu異常的問題中順便運氣好解決了，希望今天的感想對你有幫助。好久沒更新文章了，感謝大家沒有把我拿關，祝大家國慶中秋快樂！ ！ ！PS：最近換了一下iPhone 17以及IOS26，其他都很不錯，唯一就是系統的流暢度是我有史以來體驗最差的新iPhone，我去線下體驗了Pro，也是一副鳥樣，很多基礎的滑動切換場景都會偶發的卡一下，因為我之前我性能優化，對畫面很敏感，看的最難受，希望蘋果公司好好努力優化吧。

Got any book recommendations?

Get In Touch