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

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

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

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

……

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

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

授人以魚不如授人以漁

進(jìn)入公司兩年后，我進(jìn)入了一個(gè)新項(xiàng)目組，做iSStar(華為網(wǎng)管的智能運(yùn)維平臺(tái))，解決用戶日常運(yùn)維的自動(dòng)化問題。

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

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

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

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

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

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

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

忍無可忍則無需再忍

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

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

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

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

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

一封郵件搞定腳本

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

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

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

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

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

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

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

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

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

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