在华为工作，创新力是这么被激发起来的

创新是什么?面对难题，是不是可以不按常理出牌，反其道而行之?

处理灰尘，为什么一定是吹掉，而不是吸到一起?

保存食物，为什么一定是高温杀菌，而不是低温冷冻?

基站不美观，为什么一定要设计精美的外形，而不是加以伪装?

……

也许将问题反过来，换一种思路就是能海阔天空。

2004年我毕业进入华为，转眼已经在无线OSS(运营支撑系统)部门工作了15个年头。回首这些年，我个人的每一步都和网管开放的脚步同步，从写代码到让代码自动生成，从被人指导到指导别人，从提供标准化的“菜品”到提供个性化的“菜谱”，再到实现客户的自助“炒菜 ”……正是创新的思维让网络的运维越来越高效。

授人以鱼不如授人以渔

进入公司两年后，我进入了一个新项目组，做iSStar(华为网管的智能运维平台)，解决用户日常运维的自动化问题。

为什么要自动化?以前运营商需要定制开发网络运维模式，效率低，成本高，运维压力越来越大，简直是累觉不爱，随着网络规模的增长，这显然不是长久之计。iSStar正是我司结合业界的实践，自主打造的“渔之道”。

既然是一个可编程平台，iSStar就要有自己的语言和编译器。但是大家对编译器都是一知半解，竟然没有人主动举手承担。按常理不选编译器是最优选择，可以避开未知的风险，但是没有挑战，怎么会有进步?“让我来试一试吧!”凭着一股初生牛犊不怕虎的勇气，我举手承担了最为复杂和核心的语言和编译器模块。

Python作为iSStar的解释器是否合适?怎么基于Python设计一个新的语言?对Python不熟悉怎么办?设计一个语言对作为新人的我来说，是巨大的挑战。我用了最笨的方法，一个月将Python所有的标准库的代码敲一遍，通过这个方法快速掌握了Python的语法和所有标准库的用法。通过反复选型PK，产品最终通过了语言基于Python做扩展的方案。对Python语法做了简化包装后，自己设计了第一个语言(HSL)顽强地诞生了。

当写作的第一个脚本通过我开发的编译器编译运行起来，我激动的心情久久不能平复。这段经历让自己z明白，学习没有捷径，踏踏实实去做才是最有效的方法。

在iSStar项目后期，我又发现了一个问题：随着业务场景的扩充，客户提出的大量接口需求，但是接口要能够在iSStar的Python环境中被调用，需要手工编写大量相似且无意义的代码做封装。这就有点像充电器和电源插座不匹配，每次都得手工装上转接头才能通上电，效率低而且质量不高。而且因为混用了多种技术，定位问题就像盲人摸象。面对巨大的交付压力，大家有种被卡脖子的感觉，犹如行进在一个看不到终点的马拉松。

因为有过编译器的经验，我的脑中浮现一个点子：能不能把装“转接头”这个动作自动化?既然IDL形式的接口已经有工具可以编译为C++/Java代码，那么也可以编译为Python代码，利用编译器来自动做转换的想法我在脑中萌生。

没有现成工具就自己开发，经过大半个月的攻关，第一个编译器工具在自己手中诞生了，从此IDL->Python的转换彻底实现了自动化，在iSStar中提供接口变得简单，开发效率大幅提升，原先3天才能交付1个接口到现在1天可以批量交付5个以上接口，开发过程从如履薄冰到从容自若。这段经历让自己体会到程序员要敢于突破，有创新才能进步。

忍无可忍则无需再忍

做完这个项目后，我进入CME(网管的配置管理专家系统)项目。此时，我的角色发生了变化，担任了PL，不但要负责技术，而且承担了项目组的整体业务交付和人员管理，对于长期从事技术工作的我，又是一个重大的挑战。

CME大量使用了数据库能力，在CME的这段时间，数据库性能问题的爆发让我头疼不已，经常运行到一半系统就在某处突然挂死，前功尽弃的挫败感油然而生，数据库性能犹如挥之不去的梦魇。

意识到解决数据库依赖的紧迫性，我开始萌生“将计算过程脱离数据库”的想法，因为挂死问题通常是由于数据集的超大和执行计划的不合理导致的。这就像大城市的交通系统，由于车流量太大，分流不合理，就会导致交通瘫痪。

按照大数据处理方法，我们可以对计算和数据做分布式处理，于是我找到“交通堵塞”最严重的一个点作为切入点，用编译器将其转换为Python代码，然后对数据分片交给Python解释器执行。这就类似于建立地铁/高架/隧道等多层次的立体交通系统，对车辆进行合理的疏导，保证交通的顺畅。

虽然过程困难重重，但是我没有放弃，一步一个脚印去做。逐渐，功能稳定了，烦人的挂死问题也随之消失了。这段经历让自己体会到程序员不但要善于技术，而且要善于发现，更要耐得住寂寞。

一封邮件搞定脚本

转眼到了2017年，云化之势浩浩荡荡。尽管云CME号称上线了，却只有一个功能：LTE新建。

操作界面很像单机版，但因为需要额外登录网页、导入基站小区模板、以及手动下载生成的脚本，操作步骤比单机版要多十几步，并且因为是网页交互，响应速度比单机版要慢，用户体验反而变差了，甚至被调侃为“云CME是换了Web壳的单机CME”。

CME的服务代表叶小华当时提出，能不能让用户仅通过邮件就能够使用云工具，免登陆网站，免界面操作，免下载附件，通过一个定制脚本一键式完成配置脚本的制作?

怎么做服务要求的这份“大餐”?这一下把我们难住了，开放可编程的诉求如何在云CME落地?CME现有的接口都是和场景/表格绑定了，接口如何提供?业务模块间的数据完全不统一，数据如何交换?每一点都是巨大的挑战，面对这些困难，我有点巧妇难为无米之炊的感觉。

是采用之前iSStar的老路，还是采用新模式?这是我做过的最难的决定。基于多年在CME的工作经验，我发现CME的业务特点是轻流程、重数据，和iSStar轻数据、重流程的业务模式正好相反，于是提出“大食代模式”：将CME现有的功能定义为“摊位”，将每个功能的输入数据建模称之为“食材”，可编程平台提供基于模型的数据标准操作接口，我们称之为“加工方法”，用户通过编写面向数据的算法脚本，输出数据(菜单：包括食材和加工方法)，然后由平台依次派发各个摊位，完成食材的加工，最后平台完成上菜。

有了设计思路后，我们马不停蹄地启动执行器及API的设计和开发，然后特性迭代上线，完成第一个APP的开发，指导服务完成第一个局点脚本的交付。

一年不到时间，二次开发平台飞速发展，实现全球9大数据中心部署，从0到累计实现60万+站脚本制作，全球开发人员从0到300+，对服务人员效率提升30%以上，作业正确率接近100%，真正实现了工具降成本快速变现，把工具真正变成生产力，同时有效地支撑了服务转型，让服务真正成为我们产品的SRE，实现项目的敏捷交付。

现在，只需要发封邮件，平台就能够自动处理并返回对应脚本，操作步骤大大简化了。对比单机版，云CME在用户体验上总算有了一点点微弱的优势。

随后，我们与一线达成一致决定，往后所有上云功能都必须做到“一封邮件搞定脚本”。正是这条规定，让我们从最开始就聚焦于功能的自动化，避免了把精力投入到非核心功能的开发。

回顾这15年的历程，个人能够随着公司和产品一起成长，是我的荣幸。不忘初心，砥砺前行，在技术的路上不管是顺境或是逆境，都要保持一颗好奇心和专注力，困难和挑战是倒逼我们创新的动力源泉，希望在未来为OSS的持续演进贡献自己的力量。