参观华为
16年3月14日，德国电信在CeBIT 2016大会上宣布正式发布开放电信云，并选择华为为其提供基础设施和技术专家支持。这是华为IT业务首次突破欧洲顶级运营商。
消息传至华为杭州研究所，办公室里一片欢腾。在这场历时一年多的大会战中，年轻的杭州团队围绕云操作系统解决方案，走过了一段艰辛而又充实的道路。
2014年12月的一天， UVP团队公有云PM黄鹏接到云计算性能部主管的电话，问他的团队能否帮助联合攻关SAP公司的HANA（高性能分析设备）认证。原来，德国电信正在寻找公有云联合运营伙伴，而德电有近70%客户使用SAP公司提供的HANA业务，具备SAP HANA 认证资质是准入前提。
SAP将典型客户场景提炼成2000多个极其严苛的测试用例，每个用例必须在其指定的时间范围内通过虚拟化平台测试，全部用例通过后才能满足认证条件。当时我们有1000多个用例已经通过测试，虚拟化平台整体性能指标维持在50%左右，却一直苦于不能继续往上突破。
接到任务，UVP团队成员许志闯、蒋毅飞火速赶往SAP中国区总部西安，在指定的测试环境中蹲点进行性能调优。根据以往经验，突破一两个关键点就能实现性能大幅提升，然而蒋毅飞很快发现，调整单个性能参数往往是按下葫芦又起瓢，整体用例通过数量基本保持不变。原以为两周就可以搞定的攻关任务两个月还没有进展，每天接到产品线的“进度催命call”，团队心急如焚。
为了进一步定位问题，2015年3月，黄鹏等人飞往SAP德国总部拜访，刚一见面，就遭到SAP工程师质疑，“这么久还没有进展，是不是不行啊？”每个人脸上火辣辣的，但依然态度诚恳地请教了几个用例中的底层内核相关问题。这让专注于上层应用开发的SAP工程师态度一百八十度转变，他惊讶于团队在用例分析上的深度，并主动给我们分享了典型用例的分类细节，让团队对用例分类有了更准确的定位。基于此，大家针对未通过测试且数量最多的用例类别快速展开分析，逐渐发现了CPU、存储、内存等多个领域共二十几个待攻克的性能关键点，。沉下心来，团队成员一头扎入到从底层CPU到虚拟化平台的研究分析中，一点点啃下了各领域的“硬骨头”，终于在5月将性能提升至80%。
重振旗鼓的兄弟们按照相同方法瞄准其余尚未通过的用例进行分析，在7月，实现性能提升的又一次突破，所有用例通过测试。HANA认证终于顺利过关，华为云解决方案获得了德电的入场券。2016年CeBIT展上，华为成为业界第一家通过SAP HANA多机认证的公司。
大家回溯发现，一路走来，整体代码改动量并不大，然而每一小步，都凝聚着持之以恒的分析和钻研，蒋毅飞感叹，“这也许是厚积薄发的另一种体现吧。”
德电公有云是基于OpenStack的IaaS (Infrastructure-as-a-Service)，是一朵开放的“云”。伴随开放而来的，除了经济便捷的服务，也有不容忽视的安全风险。德国电信十分重视公有云服务的安全性，并将其视为厂商准入门槛之一。
考虑到欧洲客户一贯的高标准严要求， 2015年11月底，OpenStack集成开发团队交付第二个商用版本时已完成大量安全红线整改，还从欧洲专门请来几位资深安全专家“把脉”，确保系统安全性达到公司各项安全标准。所有人都成竹在胸，然而12月，客户发来了一封封邮件，认为交付版本的安全要求远远达不到“准入门槛”。几百条超出以往公司标准的严苛条件一时间让大家懵了，一场突围战迫在眉睫。
痛定思痛，团队很快敲定了策略，对外立即派驻安全接口人员，赶往客户现场实时收集第一手信息，主动对齐客户的思路和要求；对内火速成立整改小组，由组长傅斌杰统一组织网络、存储和UVP等团队对口一线联合攻关。一个月里，大家边查资料边讨论设计方案，常常一天连口水都喝不上。为了确保服务器能支持德电要求的版本安全加密协议，主攻Web-UI领域安全的小兰日夜奔忙，一周还没见上新搬来的室友。在大家的并肩努力下，来自操作系统、公共组件、Web-UI等领域的上百个安全问题被逐一攻克。经过这场“百科全书”式的安全大考后，团队负责人徐承武坦言，“我们基本上和各领域的问题都过了招，相信之后再遇到它们就跟遇到老朋友一样，能轻松搞定。”
然而安全无止境，层层构筑的安全屏障会使“云”越来越笨重，影响系统易用性及用户体验。对此，团队还主动从最终用户的角度分析并设计开发了一键加固系统安全等功能特性，减少用户的操作步骤，让体验更轻盈，维护更便捷。从“被动突围”到“主动进攻”，终于成功跨越安全这一准入门槛。
作为德电公有云的“大脑”，FusionSphere是业界少数完全基于OpenStack开源架构并真正投入商用的云操作系统。网络是云操作系统的神经，然而相比计算和存储，开源网络领域的全球商用在公司缺少技术储备，也无可参照的业界经验，如何在三个月内快速突破OpenStack网络商用这一业界“无人区”，是横亘在公有云FusionNetwork团队面前最大的考验。
OpenStack开源社区的原生方案是基于实验性质设计和实现网络功能，但在商用场景下，开源网络的性能不足以支撑大规模用户使用，不到一千个用户上线就会导致网络系统全面瘫痪。刚接到任务时，团队成员徐聪、王睿和高家睿首先尝试通过网络参数调优来提升性能，在反复调试了十多个关键参数后，情况并没有任何改善。核心服务的CPU负载一直居高不下，所有新任务不能下发执行。原生方案的网络任务分配方式出了问题，但又不知道问题出在哪里。
此时距离交付时间只剩一个月，大家却连一行代码都无从改起，感觉已经“山穷水尽”的徐聪手机关机整整两天，惊得大家一度以为他要“撂担子”了，然而这两天“任性”的封闭却带来新的转机。徐聪和他的团队决定抛开纠结很久的性能参数问题，追本溯源去研究OpenStack网络的底层调度机制和整体框架。大家埋头于历史资料和文档中，研究原生方案的设计背景和目的，并对照业务执行流程，一步步打开各个环节去阅读对应的代码。通过这种抽丝剥茧式的分析，团队发现原生方案的架构并不支持多客户场景下虚拟路由器功能，大家不得不硬着头皮推翻原生架构，挺进网络“无人区”的最深处。
无数个夜晚，大家自发聚集在一起分析疑难问题，带着打破砂锅问到底的劲儿，反复质疑和推敲整体架构的每一个细节，办公室里常常上演激烈的辩论赛。在这个过程中，团队还从OpenStack社区的一个设计方案中获得灵感，并借鉴该方案的实现，将网络任务分配机制进行彻底改造。成功源于坚持，在修改了数千行原生代码，修复了无数个bug后，最终方案出炉，实现了商用场景下用户大规模网络部署。第一次看到CPU低负载运行，徐聪心中感到无比幸福。这一创造性的解决方案不仅突破了OpenStack网络商用的“无人区”，同时也成功应用于客户公有云项目，为其注入了强劲的网络性能动力。
回望这段时光，所有的艰辛都释酿成了隽永的馨香。然而路漫漫其修远，随着全球公有云朵朵花开，我们的万里长征才刚刚起步。守好质量生命线，确保运维零事故， FusionNetwork团队LM徐齐刚道出了大家的心声，“我们正经历IT产业最好的时代，为客户提供高质量的云服务，接下来一定要踏踏实实地走好每一步。”
