参观华为
2001年，当我们以令人震惊的速度，拿出新一代综合交换机iNET时，迎接我们的不是鲜花与掌声，而是血淋淋的现实——中国电信客户根本不允许我们的产品入网！
这意味着，我们被客户彻底抛弃了！这一惨败几乎断送了核心网。C&C08机曾经带来的荣耀与辉煌，也瞬间灰飞烟灭。我们凭什么重新开始？又如何奋起直追？
失败的原因，和我们此前做的一个选择有关。2000年，受互联网和IP业务的影响，下一代电信网络的发展出现了两种演进策略：ATM（基于电信的实时高可靠性传输技术）和IP（基于互联网的简单传输技术）。
我们的团队由于C&C08机128模块的巨大成功和惯性思维模式，坚持认为基于ATM的综合交换机才是客户真正需要的，而基于IP的软交换只是IT厂商的玩具而已。我们不仅没有及时听取客户的需求，还积极反对软交换的演进方案，甚至在与客户面对面交流时，对客户的决策进行抨击，导致客户对我们的解决方案彻底失望，后续很多客户在试验工程选型中摒弃了华为iNet。
由于偏离客户需求、盲目自信、以自我为中心，我们的产品败走麦城，两年多来几百人的巨额投入打了水漂，核心网跌进了深深的泥坑，研发团队面临被解散的局面。
那时的我还是一个刚进公司5个月的新员工，怎么也没想到，自己加入华为开发的第一个产品，就马上要被终止生命。我非常沮丧，觉得前途一片灰暗，不知道还能不能继续在华为干下去……
就在我彷徨绝望时，突然听到了一个“绝处逢生”的消息——公司没有放弃我们，决定及时调整战略方向，选择IP技术，重做平台！这个消息就像一丝曙光，照亮了落入漆黑悬崖下的我们。
我们从解散的边缘被重新组建起来，成为新的软交换平台团队。“败军之师”要想正名，唯有胜利。
新的平台选择了新的硬件架构，全面基于IP，一切都要从头开始。我们必须在不到一年的时间，完成从操作系统、数据库到通信机制等基础功能的构建。产品经理开计划会时，不止一次地问我们：“你们能不能按时交付？”我们的平台项目经理李华斌拍桌而起：“保证不拖产品后腿！”
我当时承担的是OS部分。那是我第一次接触OS，看到几百页犹如砖头厚的全英文手册，整个人都懵了。记得那年春节放假，我在家里天天捧着手册在看，玩命的用功引来父母的担心：“是不是因为感情上受了什么打击了？”重压之下，我取得了飞速成长，仅仅一个半月后，我就成为了项目组“死机问题专家”。
而项目经理李华斌不仅承担了最复杂、最具挑战性的IP通信模块开发，主导平台和产品的联调，还要作为救火队员四处奔忙，哪里有问题，就扑到哪里……等到我们终于成功打通第一个电话时，他却病倒了。别人问他干嘛要这么拼命，他说，就是想着不能让平台在我们手里做没了。
2003年，软交换平台渐渐成型，构建了众多基础架构和技术：支持百万级的大容量分布式技术、99.999%电信级高可靠架构、全IP交换……这些亮眼的特性，让我们的产品在关键技术和性能竞争力上，大幅超越了友商。
重新回到“以客户为中心”道路上的我们，因为得到了中国电信的认可和宽容，才在中国的土地上，重新站起来。偏离客户需求所付出的惨痛代价，让我们深刻认识到，解决方案竞争力的构建，必须围绕客户诉求，只有真正解决客户关心的问题，我们的产品才有可能获得成功。
随着第一代平台上网，我成为了平台的维护经理。可由于缺乏平台问题定位手段和远程化支持能力，我们闹过不少笑话。
2005年，马达加斯加G运营商反映，使用我们的设备时，他们的网络经常出现电话语音质量变差或无声的情况。马达加斯加使用卫星做中继传输，承载的可都是高价值的旅游客户，运营商非常担心：信号质量这么差，我们的客户流失了怎么办？华为快想办法啊！
我们反复进行模拟实验，但都没能重现问题。一开始我怀疑是卫星信号不好，或者由于天气干扰、地磁暴动等原因，导致卫星链路出现频繁闪断。但通过消息跟踪，发现并非如此，而且从消息跟踪的轨迹来看，都是消息成功发送出去后，在卫星链路中无故消失，对端也没有收到任何信息。
这究竟是怎么回事？难道是卫星遭遇太空小碎片攻击，导致传输异常？我们自觉脑洞开得很大，但也不能排除这个可能，于是硬着头皮跟客户交流：“能不能确认下卫星有没问题？”客户满脸疑惑：“如果是卫星遭遇攻击，怎么可能只造成通信故障？只有消息跟踪轨迹，证明不了什么，你们能采用第三方工具，给出更有说服力的证据吗？”
我们只好派信令专家老黄去现场，通过信令仪去抓数据包来分析。结果老黄虽然技术很牛，但普通话不太标准，穿着又很随意。第一次出国就在海关被拦下了，到最后飞机都起飞了，他还没有换到登记牌。后续经过反复沟通，他才改签了机票，2天后赶到现场。这期间我们真是等得心急如焚，更加坚定了要拼命提升远程消息跟踪能力的决心。
几天之后，定位有了进展，终于找到了问题根源——就是因为连接我们软交换系统的卫星链路消息传输时间很长，有时会超出代码中预设的发送超时时长，导致一些数据出现冲突。
找到原因解决了问题，客户和我们都松了一口气。想起我当初竟然会怀疑“卫星被攻击”，不免有些好笑，还好这“黑锅”最后没让它背。
如今，虽然我们的局点分布越来越广，但随着平台问题定位手段越来越丰富，很少再有这种飞半个地球赶往现场攻关的场景了，当然也不会再闹“卫星被攻击”这种大乌龙了。
2006年，西藏地区S客户反馈，我们的设备发生了一次单板死机重启问题。还没分析出原因时，一个月内又连续发生了两起类似事件，客户开始质疑华为：你们的产品到底行不行啊？
问题进一步升级，我们成立了软硬件联合工作组，封闭攻关。大家一起分析日志、走读代码、查看单板器件，经过一次又一次的分析和推演，发现是数据bit跳变（二进制位0变成1，1变成0）引起的。但是，为什么会跳变呢？究竟是软件问题，还是硬件问题？大家全都摸不着头脑。
在不到十平米的临时会议室中，软硬件各领域专家一起冥思苦想。由于各种线索都被验证不可能，大家有些沮丧，气氛很沉闷。碰头会快结束时，负责设备管理的同事自言自语道：“不会西藏太高了，有高原反应了吧？”
“啊，真的可能啊！”我们的硬件专家阿杜突然眼睛发亮，“也许西藏辐射大，比如太阳黑子引发的射线，导致内存和cache的数据发生跳变！”
之前怀疑“卫星被攻击”，现在又怀疑“太阳黑子惹得祸”，这次的猜测会是真的吗？
被点燃的火花迅速蔓延到每个人身上。我们马上去查询太阳黑子的活动曲线，以及辐射导致芯片失效的案例，竟然真的找到了相关的证据！我们还对西藏地区近年日照时数做了研究，发现单板死机问题出现的时候，西藏地区太阳黑子活动明显较往年活跃。
太阳黑子？这怎么可能？客户一脸不信任。我们一向大胆假设，小心求证。于是，在1000公里之外的西安国家核物理实验室里，平台专项攻关组立刻进行辐射专项试验，模拟高能粒子轰击，很快重现了数据跳变问题。
“找到原因了！”在一线测试的兄弟兴奋地挥舞着测试报告，“我们还要把测试时间放长一些，把规律找出来。”
根因找到了，但如何解决？最好的办法当然是更换硬件，选择抗“太阳黑子”能力更强的涂层，但动作太大了，客户不愿意。于是，我们通过增加内存，采取cache自动定期巡检、回写纠错等方案改进，终于解决了单板死机问题。
后来，我们又突破多项技术专利，实现在错综复杂的系统中，精确定位被“太阳黑子”影响的位置，并迅速修复。
欣喜之余，大家相互调侃，通信工程师不仅要知道通信知识，还得上知天文、下知地理啊！
第一代软交换平台的成功让我们占据了市场领先的位置，但通信行业的发展是爆炸式的。2007年，友商计划推出刀片架构的新平台。当时，还在维护部的我接到了主管的电话：“回来开发第二代平台吧！”
我对亲手做出来的第一代平台充满感情，因而没有犹豫，就投身到新平台的开发中去。
首先面临的是软件架构的选择。产品架构师力挺旧架构：“把第一代平台直接搬到新的硬件上来，这样工作量最小，能最快推出，而且稳定性好。”但平台架构师坚持采用新平台：“如果我们不采用新的平台，无法与友商拉开竞争差距。”
两方争论不休，我自己心里也很矛盾，我觉得在技术上我们应该选择新架构，但在交付上旧架构更安全。最终，经过多次产品线专家的集体评审决定：决定向前看，用新的架构，确保核心网产品后续5年的领先优势，并向未来持续演进。
然而知易行难。我们的平台和产品联调时，出现了大量问题：第一次用Linux操作系统替换自研操作系统，可Linux包有1G多，安装1个单板需要4~5小时，难度很大，插拔网卡需要重启，无法满足电信即插即用要求；引入Oracle数据库替换自研数据库，可升级倒换时长，不可控；新的操作维护架构，问题定位需要的日志量很大，第一个实验局开局时，问题定位需要开车用硬盘送日志……
内部交付验收后，服务兄弟洋洋洒洒地写了几十页PPT，指出平台近100个问题，投诉到产品线。那段时间，每天内部测试涌现出100多个问题，还有超过100万行的工作量待开发。我们就像泥足巨人，完全动弹不得。
“架构做错了，用第一代平台架构，早就好了。”我们被巨大的质疑声淹没。那时作为平台部长的李华斌顶住压力，到产品线推动业务决策，给我们的需求减负，重新调整范围和计划，这也是产品线第一次与研发部和各产品深入沟通，逐步让大家理解和支持我们。
背负着产品线的期望和市场的压力，我们背水一战，对硬骨头进行系统梳理。首先拿Linux操作系统开刀，系统加载在电信系统中需要20分钟，根本让人无法接受，我们想到让系统“瘦身”。但一轮下来，并没有达到预期，还要10分钟！
“不行，最多只能40秒，没得商量！”我想，如果赶不上老架构，市场根本不会接受。于是我们继续攻关，预加载、固化……又缩短了一半时间，达到了5分钟。再往下就更艰难了，我们不停想方案验证、找专家讨论，十八班武艺能上的都上，1秒钟1秒钟地抠。
最终，我们实现了操作系统40秒完成在线加载，并同时提供内核黑匣子、支持热插拔、高精度定时器等多个电信级特性，成功打造了第一个公司级的电信Linux操作系统。之后，我们还针对数据库Oracle，联合厂商一起解决升级效率以及各种小概率出现的死机，终于按时通过技术评审。
一次次跌倒后再爬起来的“挣扎”，面对起起伏伏的质疑声，经历几百个日日夜夜、几百个平台兄弟姐妹的拼搏……第二代平台以其先进的技术架构，奠定了核心网产品技术竞争力的基础，服务于全球超过30亿用户。
2009年，我们拿下一个个山头项目时，某领先运营商C发了一个标书，其中一条可靠性要求，让我们无比震惊：升级无损，升级业务不能中断，不能影响已接续通话！
不可能！这是我们的第一反应。手机、电脑升级一个版本，都要重启，所有软件都要关闭，要好几分钟。现在运营商的要求就像电脑一边升级，一边还要继续播放电影。这怎么做得到？
作为设计部部长的我，感受到排山倒海的压力。我召集各方面专家成立了专门的无损升级攻关团队。
大家首先想到的方案，是使用双平面的方式升级，就是将系统划分两个平面，新旧两个软件版本同时跑，而不是一次性全局复位，节约中断时间。新旧版本切换仅仅需要一个指令，这样一来，业务中断只出现在切换这一瞬间，10秒以内。按这个方案，在现网运行的老版本不能动，必须在新版本做文章。通信隔离，HA分区，OM支持……我们想办法实现了两个平面同时运行，相互不干扰。
但如何让已经接通的电话不中断？唯一的方法是将呼叫数据备份到新版本中。但每个版本的数据结构都在发生变化，在数以千计、万计的数据结构中，1个字节的差错，都可以导致难以挽回的错误。怎么办？人工比对？大家一筹莫展。
此时，平台专家老林提议，能否通过编译器的技术原理来进行解析和对比分析？对啊，真的可以！我突然想到，以前定位问题时经常要用到相同原理，我们马上找来编译器原理书籍来分析，并最终实现了自动对比方案。
2009年底，我们在实验室完成了无损升级的关键原型。系统升级，所有呼叫不断话，新业务中断在5秒以内。2010年4月7日，我们正式和客户签署商用合同，实现在北美的第一次突破。
2011年，我成为核心网平台首席架构师。当时IT行业云计算已经兴起，我们敏锐地意识到这对电信CT也会产生革命性的影响。但公司内部也有不同声音：第二代平台竞争力仍遥遥领先，再开启新一代云化平台不仅需要大量投入，还面临失败的风险，我们真的要革自己的命吗？
在这充满迷雾的岔路口，我深感责任重大。我们的下一跳在哪里？要用什么样的架构？
在这种情况下，一方面，我们瞄准KVM、OpenStack等化云化关键技术进行研究，另一方面，就云化积极和公司、客户去探索论证。
2012年初，我们派出了一批专家，远赴公司瑞典研究所，进行平台云化架构技术研究。2012年5月，我们与V运营商首次就云化进行沟通，我们的概念和架构得到客户的认可，他们当场表示，希望和我们做联合创新。2012年10月，欧洲相关标准组织喊出了NFV（网络功能虚拟化），这与我们的云化构想不谋而和。
我们调整方向，将技术研究版本转为正式的版本开发。然而，未知的难题更多了，架构先进性、成本、性能、可维护性等，每一个主题都要反复论证：是否是业界趋势？成本可控吗？运维可操作吗？
我经常整夜无眠，有时睡到三更半夜，突然想到一个好的点子，就赶紧爬起来写。就这样，与行业专家、产品架构师进行30多次的讨论后，我们最终采取了最彻底的分层云化方案，完成I/P层分离架构、自动化部署等一系列关键方案和架构的突破。
2013年3月，我们和V运营商一起，完成了世界第一个云化PoC（概念验证），2014年10月，全世界第一个基于NFV架构商用。之后，我们连续突破了北美、德国、中东等全世界多个顶级运营商。在新的时代，我们又站上行业之巅。
