創(chuàng)新是什么?面對難題，是不是可以不按常理出牌，反其道而行之?

處理灰塵，為什么一定是吹掉，而不是吸到一起?

保存食物，為什么一定是高溫殺菌，而不是低溫冷凍?

基站不美觀，為什么一定要設(shè)計精美的外形，而不是加以偽裝?

……

也許將問題反過來，換一種思路就是能海闊天空。

2004年我畢業(yè)進入華為，轉(zhuǎn)眼已經(jīng)在無線OSS(運營支撐系統(tǒng))部門工作了15個年頭?；厥走@些年，我個人的每一步都和網(wǎng)管開放的腳步同步，從寫代碼到讓代碼自動生成，從被人指導(dǎo)到指導(dǎo)別人，從提供標(biāo)準(zhǔn)化的“菜品”到提供個性化的“菜譜”，再到實現(xiàn)客戶的自助“炒菜 ”……正是創(chuàng)新的思維讓網(wǎng)絡(luò)的運維越來越高效。

授人以魚不如授人以漁

進入公司兩年后，我進入了一個新項目組，做iSStar(華為網(wǎng)管的智能運維平臺)，解決用戶日常運維的自動化問題。

為什么要自動化?以前運營商需要定制開發(fā)網(wǎng)絡(luò)運維模式，效率低，成本高，運維壓力越來越大，簡直是累覺不愛，隨著網(wǎng)絡(luò)規(guī)模的增長，這顯然不是長久之計。iSStar正是我司結(jié)合業(yè)界的實踐，自主打造的“漁之道”。

既然是一個可編程平臺，iSStar就要有自己的語言和編譯器。但是大家對編譯器都是一知半解，竟然沒有人主動舉手承擔(dān)。按常理不選編譯器是最優(yōu)選擇，可以避開未知的風(fēng)險，但是沒有挑戰(zhàn)，怎么會有進步?“讓我來試一試吧!”憑著一股初生牛犢不怕虎的勇氣，我舉手承擔(dān)了最為復(fù)雜和核心的語言和編譯器模塊。

Python作為iSStar的解釋器是否合適?怎么基于Python設(shè)計一個新的語言?對Python不熟悉怎么辦?設(shè)計一個語言對作為新人的我來說，是巨大的挑戰(zhàn)。我用了最笨的方法，一個月將Python所有的標(biāo)準(zhǔn)庫的代碼敲一遍，通過這個方法快速掌握了Python的語法和所有標(biāo)準(zhǔn)庫的用法。通過反復(fù)選型PK，產(chǎn)品最終通過了語言基于Python做擴展的方案。對Python語法做了簡化包裝后，自己設(shè)計了第一個語言(HSL)頑強地誕生了。

當(dāng)寫作的第一個腳本通過我開發(fā)的編譯器編譯運行起來，我激動的心情久久不能平復(fù)。這段經(jīng)歷讓自己z明白，學(xué)習(xí)沒有捷徑，踏踏實實去做才是最有效的方法。

在iSStar項目后期，我又發(fā)現(xiàn)了一個問題：隨著業(yè)務(wù)場景的擴充，客戶提出的大量接口需求，但是接口要能夠在iSStar的Python環(huán)境中被調(diào)用，需要手工編寫大量相似且無意義的代碼做封裝。這就有點像充電器和電源插座不匹配，每次都得手工裝上轉(zhuǎn)接頭才能通上電，效率低而且質(zhì)量不高。而且因為混用了多種技術(shù)，定位問題就像盲人摸象。面對巨大的交付壓力，大家有種被卡脖子的感覺，猶如行進在一個看不到終點的馬拉松。

因為有過編譯器的經(jīng)驗，我的腦中浮現(xiàn)一個點子：能不能把裝“轉(zhuǎn)接頭”這個動作自動化?既然IDL形式的接口已經(jīng)有工具可以編譯為C++/Java代碼，那么也可以編譯為Python代碼，利用編譯器來自動做轉(zhuǎn)換的想法我在腦中萌生。

沒有現(xiàn)成工具就自己開發(fā)，經(jīng)過大半個月的攻關(guān)，第一個編譯器工具在自己手中誕生了，從此IDL->Python的轉(zhuǎn)換徹底實現(xiàn)了自動化，在iSStar中提供接口變得簡單，開發(fā)效率大幅提升，原先3天才能交付1個接口到現(xiàn)在1天可以批量交付5個以上接口，開發(fā)過程從如履薄冰到從容自若。這段經(jīng)歷讓自己體會到程序員要敢于突破，有創(chuàng)新才能進步。

忍無可忍則無需再忍

做完這個項目后，我進入CME(網(wǎng)管的配置管理專家系統(tǒng))項目。此時，我的角色發(fā)生了變化，擔(dān)任了PL，不但要負責(zé)技術(shù)，而且承擔(dān)了項目組的整體業(yè)務(wù)交付和人員管理，對于長期從事技術(shù)工作的我，又是一個重大的挑戰(zhàn)。

CME大量使用了數(shù)據(jù)庫能力，在CME的這段時間，數(shù)據(jù)庫性能問題的爆發(fā)讓我頭疼不已，經(jīng)常運行到一半系統(tǒng)就在某處突然掛死，前功盡棄的挫敗感油然而生，數(shù)據(jù)庫性能猶如揮之不去的夢魘。

意識到解決數(shù)據(jù)庫依賴的緊迫性，我開始萌生“將計算過程脫離數(shù)據(jù)庫”的想法，因為掛死問題通常是由于數(shù)據(jù)集的超大和執(zhí)行計劃的不合理導(dǎo)致的。這就像大城市的交通系統(tǒng)，由于車流量太大，分流不合理，就會導(dǎo)致交通癱瘓。

按照大數(shù)據(jù)處理方法，我們可以對計算和數(shù)據(jù)做分布式處理，于是我找到“交通堵塞”最嚴重的一個點作為切入點，用編譯器將其轉(zhuǎn)換為Python代碼，然后對數(shù)據(jù)分片交給Python解釋器執(zhí)行。這就類似于建立地鐵/高架/隧道等多層次的立體交通系統(tǒng)，對車輛進行合理的疏導(dǎo)，保證交通的順暢。

雖然過程困難重重，但是我沒有放棄，一步一個腳印去做。逐漸，功能穩(wěn)定了，煩人的掛死問題也隨之消失了。這段經(jīng)歷讓自己體會到程序員不但要善于技術(shù)，而且要善于發(fā)現(xiàn)，更要耐得住寂寞。

一封郵件搞定腳本

轉(zhuǎn)眼到了2017年，云化之勢浩浩蕩蕩。盡管云CME號稱上線了，卻只有一個功能：LTE新建。

操作界面很像單機版，但因為需要額外登錄網(wǎng)頁、導(dǎo)入基站小區(qū)模板、以及手動下載生成的腳本，操作步驟比單機版要多十幾步，并且因為是網(wǎng)頁交互，響應(yīng)速度比單機版要慢，用戶體驗反而變差了，甚至被調(diào)侃為“云CME是換了Web殼的單機CME”。

CME的服務(wù)代表葉小華當(dāng)時提出，能不能讓用戶僅通過郵件就能夠使用云工具，免登陸網(wǎng)站，免界面操作，免下載附件，通過一個定制腳本一鍵式完成配置腳本的制作?

怎么做服務(wù)要求的這份“大餐”?這一下把我們難住了，開放可編程的訴求如何在云CME落地?CME現(xiàn)有的接口都是和場景/表格綁定了，接口如何提供?業(yè)務(wù)模塊間的數(shù)據(jù)完全不統(tǒng)一，數(shù)據(jù)如何交換?每一點都是巨大的挑戰(zhàn)，面對這些困難，我有點巧婦難為無米之炊的感覺。

是采用之前iSStar的老路，還是采用新模式?這是我做過的最難的決定?；诙嗄暝贑ME的工作經(jīng)驗，我發(fā)現(xiàn)CME的業(yè)務(wù)特點是輕流程、重數(shù)據(jù)，和iSStar輕數(shù)據(jù)、重流程的業(yè)務(wù)模式正好相反，于是提出“大食代模式”：將CME現(xiàn)有的功能定義為“攤位”，將每個功能的輸入數(shù)據(jù)建模稱之為“食材”，可編程平臺提供基于模型的數(shù)據(jù)標(biāo)準(zhǔn)操作接口，我們稱之為“加工方法”，用戶通過編寫面向數(shù)據(jù)的算法腳本，輸出數(shù)據(jù)(菜單：包括食材和加工方法)，然后由平臺依次派發(fā)各個攤位，完成食材的加工，最后平臺完成上菜。

有了設(shè)計思路后，我們馬不停蹄地啟動執(zhí)行器及API的設(shè)計和開發(fā)，然后特性迭代上線，完成第一個APP的開發(fā)，指導(dǎo)服務(wù)完成第一個局點腳本的交付。

一年不到時間，二次開發(fā)平臺飛速發(fā)展，實現(xiàn)全球9大數(shù)據(jù)中心部署，從0到累計實現(xiàn)60萬+站腳本制作，全球開發(fā)人員從0到300+，對服務(wù)人員效率提升30%以上，作業(yè)正確率接近100%，真正實現(xiàn)了工具降成本快速變現(xiàn)，把工具真正變成生產(chǎn)力，同時有效地支撐了服務(wù)轉(zhuǎn)型，讓服務(wù)真正成為我們產(chǎn)品的SRE，實現(xiàn)項目的敏捷交付。

現(xiàn)在，只需要發(fā)封郵件，平臺就能夠自動處理并返回對應(yīng)腳本，操作步驟大大簡化了。對比單機版，云CME在用戶體驗上總算有了一點點微弱的優(yōu)勢。

隨后，我們與一線達成一致決定，往后所有上云功能都必須做到“一封郵件搞定腳本”。正是這條規(guī)定，讓我們從最開始就聚焦于功能的自動化，避免了把精力投入到非核心功能的開發(fā)。

回顧這15年的歷程，個人能夠隨著公司和產(chǎn)品一起成長，是我的榮幸。不忘初心，砥礪前行，在技術(shù)的路上不管是順境或是逆境，都要保持一顆好奇心和專注力，困難和挑戰(zhàn)是倒逼我們創(chuàng)新的動力源泉，希望在未來為OSS的持續(xù)演進貢獻自己的力量。