1.项目背景

从我入职华为，我就一直在德电公有云云网协同项目组从事交付工作。云网协同是指通过SDN（软件定义网络）软件，将传统网络与云内VPC网络协同编排为互联互通的网络技术，实现客户端点如园区接入，到云内租户私有网络VPC之间的网络连接。本项目借鉴云服务的一站式体验，通过SDN技术打造端到端的业务开通体验，实现客户网络编排业务的快速发放。 在客户目前的企业侧到云的专线业务开通场景中，还停留在原始的通过工单开通专线阶段。由于传统网络专线与云内的网络专线分属德电不同的部门管理，客户首先需要打电话给德国电信的TSI部门，该部门上门了解客户诉求，在客户现场设计布线方案。TSI部门只负责客户端点到云接入侧的布线。当TSI完成走线后，客户继续联系负责云内网络配置的OTC部门，该部门继续完成第二段的网络走线配置，即云接入点到租户VPC的走线。当企业侧到云接入点以及云接入点到VPC两段链路配通后，客户最后要找德国电信的CBG部门，完成最后的网络参数配置，如ip地址、路由等。所以，传统的云专线客户需要前后协调德国电信三个部门，耗时长客户体验差。同时，客户还需要专门的网络运维人员，维护企业侧的设备，人力成本也需要额外投入。在这样的背景下，我们提出了通过SDN软件，打通传统网络与云内网络的连接，实现租户秒级自开通的云专线服务。在云专线引入后，解决了传统专线开通的痛点，减少了客户专线开通的周期，提高了用户体验，解决了客户运营商跨部门的沟通协作，真正实现了客户端点到租户云侧VPC的专线一站式开通。

2.项目方案

该项目方案从总体上讲，是基于华为网络产品线SDN产品和华为云虚拟网络Directconnector云服务，SDN产品负责配置打通企业侧端点到云侧接入的网络链路，华为云虚拟网络VPC负责打通云侧接入端点到租户私有网络的网络链路。通过打通两段网络，实现租户企业侧端点到云内私有网络VPC的网络连接。详细方案如下：
1、PLAS云服务：使用SDN产品打通企业侧到云侧边缘链路：
自开通网络专线服务PLAS，通过SDN技术，纳管企业侧端点CPE设备和云侧边缘的核心路由器，实现企业侧端点到云侧边缘的L3 VPN建立，打通企业侧到云侧边缘的网络连接。通过VPN的网络隔离技术，在复用同一云侧边缘设备的同时，让企业租户能够获得网络专线的使用体验。同时，SDN技术可以让租户动态的调整网络带宽，按需付费，节约成本。
2、Directconnector云服务：基于Netron网络打通云侧边缘到租户VPC链路：
Directconnector云服务提供云侧边缘网络到租户VPC的网络打通，达到企业侧端点接入到企业在云内的虚拟网络资源VPC的目标。Directconnector融合了SDN技术与虚拟网络Neutron技术，通过获取企业租户在云侧接入路由器的配置信息，然后将该租户对应的对端信息配置在公有云中已购买的VPC中，实现云内的链接与传统网络的链接对接。这样企业租户就获得了从企业侧端点开始到在云内VPC资源的网络专线，实现了端到端的网络打通。 如上，企业用户首先订购Directconnector云服务，实现云侧边缘接入到云内租户VPC的网络链路。然后，再订购自开通网络专线服务PLAS，选择并关联已订购的Directconnector服务，实现传统网络的开通以及和云内网络的对接。这样就完成了端到端专线的开通。所有的服务PLAS和Directconnector都是基于云服务的体验而设计，租户无需与运营商做过多交涉，沟通成本，提高了专线开通的效率，真正提升了用户体验，使用户能够体会到一站式开通的便捷。

3.项目交付

3.1 交付准备

在方案明确后，我就开始了正式的项目交付。这个项目是基于我入职时做的BWaaS项目的二期，所以在项目伊始，我就主动总结之前项目的总结经验，输出现网交付的版本需求，提前推动版本层面落地。例如，研发的通信矩阵未经过验证，我要求研发尽快验证交付的通信矩阵策略，没有防火墙环境就模拟，达成防火墙矩阵提前验证的目标；项目界面需要与公有云的方案集成，尽快研究集成方案，遇到了哪些困难及时上升求助。再整个项目的推进过程中，我积极实践PMP的相关知识，从范围管理对需求的管控，到时间管理进度的把控，再到风险管理，全方面多维度的对项目进行管理。范围管理只做需求范围内的事情，包括我总结之前的交付经验识别到的产品的潜在问题，时间管理根据客户的里程碑点，制定我们的版本交付节奏，确保每个里程碑点客户的需求均落入版本。风险管理在项目的推进过程中，定时监控项目状态，识别出有风险的地方，对于影响较大的风险及时上升求助，避免风险演变为严重问题。在我的努力下，整个项目的推进有条不紊，基本按照需求包如期交付特性。在整个过程中，遇到的最大困难是与公有云集成的过程。由于项目成员对公有云组件不熟悉，研发不具备集成能力，导致在具体的集成落地过程中遇到诸多问题，例如待集成服务底层UI框架与公有云框架不一致导致无法集成，鉴权系统流程已经是完整闭环，但是需要接入到公有云的鉴权系统中实现流程集成，而开发人员对该流程不熟悉；业务流量的进入系统的方式需要通过公有云基础组件框架进行导入，开发人员不熟悉公有云的业务流量导入方案，导致在实施过程中无从下手；同时，项目对公有云依赖组件没有投资关系，导致人员支撑不够，项目开发步履维艰。
在遇到上述问题之后，我作为研发项目管理人员，识别了上述问题所带来的后续风险，就是版本无法按预期时间点交付、版本质量也无法保证。所以，我主动帮助研发梳理当前问题清单，梳理后从每个问题出发，找到解决问题的办法。最后，根据版本交付计划，把要解决的问题按照优先级排序。例如，对于项目目标而言，界面能够操作是第一优先级的事情。所以，我首先基于自己对于公有云界面集成的理解，研究公有云的界面实现，包括技术层面和方案层面，在方案上主要研究用户访问到界面资源的流程是什么，在技术上研究界面的前台实现和前后台交互使用了什么技术。在了解了公有云的界面实现方案后，然后，拉通产品的系统设计师和公有云的设计师一起，在我的理解下提出我对方案集成的观点和看法与双方充分讨论，并不断的解决双方提出的问题和遇到的冲突。最终的目标就是，让本产品的设计人员能够理解公有云界面集成的流程，并结合产品的既有实现，输出集成方案。并让开发人员可以落地实施。通过不断的解决问题，实现了与公有云的界面集成、鉴权流程接入、业务流量导入等功能。在后续的测试中，保证了基本功能的可用性。同时也收获了客户的信任与肯定。

3.2 交付经验

在版本稳定后，就进入到了正式的交付阶段。由于整个版本交付在客户侧有严格的时间节点要求，所以我在去往客户现场前做了充分的交付计划。交付计划的目标是在有限的时间内，通过把交付步骤流程化，达到平稳交付的结果，具体如下：
1、I层资源申请：根据产品的资源需求，整理需要申请的底层资源，如虚拟机资源、规格、网卡数量等，用于向客户申请产品部署所需的资源。其中，CPU的申请要标明超分比，磁盘的申请要注意磁盘的数量便于后续的分区，网卡的申请要注明网络平面需求，比如产品需要两张网卡，一个是内网的信任域与外网的非信任域，这在申请的时候要特别注明。 2、防火墙矩阵配置：整理防火墙矩阵用于产品虚机间的网络打通。由于产品共有10台虚拟机，每台虚拟机所承载的业务安全级别不同，所以要把每台虚拟机放在不同的可信区中。处于不同可信区的虚机通信时，需要配置防火墙策略实现不同区域虚机的互通。防火墙矩阵的梳理是一个琐碎又复杂的工作，首先要基于产品的服务部署规划，确定服务所属的虚机节点间通信需求。其次，根据业务方案，整理各服务的通信端口，在整理端口的过程中，尤其要注意端口的通信方向，即某个服务所在虚拟机开放的端口是入流量还是出流量。防火墙的配置非常重要，直接影响到网络的互联互通，如果服务使用的端口未在防火墙上放通，就会导致服务间流量无法转发。 3、交付剧本输出：由于整个交付非常复杂，除了版本自身的安装部署完，还需要对接公有云多个现网组件。所以，我整理了交付剧本指导整个流程，将琐碎繁杂的操作步骤流程化，根据剧本的指导，按照剧本流程一步步的去执行交付动作，并且每个剧本动作都包括三部分内容，第一如何操作，第二操作后如何验证，第三操作失败后如何回滚。比如，申请防火墙流程操作，首先要基于端口矩阵组生成公有云各个信任区的防火墙脚本，然后通过执行脚本开通防火墙策略。在开通后，通过登录各个业务虚机节点，使用端口测试工具检测各个虚机的服务端口是否可以调通。最后，如何配置失败或者引发了防火墙的安全问题，通过回滚将之前的配置删除掉。这样，就做到了实施——验证——回滚的完整闭环。 4、交付计划制定：任何事情都要有所计划，尤其对于在有限时间内的交付工作更是要遵循严格的交付计划，守住每个交付节点。如何制定一个合理的计划，一直都是比较难回答的问题。首先，是把要做的事情罗列出来，能够详细的罗列出事情的前提是你对整个事情有充分的理解和实践，明确的知道起点在哪里，然后从起点出发需要经过哪些路径节点能够到达终点，也就是你最终达成的交付目标。例如，对本项目交付来说，起点就是，当你到达客户交付现场的时候，你首先应该做什么？当然是先申请I层的虚拟机资源，有了虚拟机资源你才能把要交付的软件安装到虚拟机上面去。接下来，机器有了，机器之间是不是需要通信？那么就是要配置网络，开通防火墙策略。机器之间的通信没问题了，就可以安装要交付的软件了。软件安装之后，还需要跟公有云的周边组件完成对接，让我们交付的系统能够和周边很好的配合起来。最后就是端到端的联调测试，上线发布。大体的计划制定可以按照上面描述的方法，从起点步骤出发到最终的目标达成，但是每个点还有继续分解计划的可能。所以总结一下，计划的制定，首先是把要做的事情从你能想到的层面罗列出来，然后针对你罗列的每个点再去分解细化成能够落地执行的动作。就像庖丁解牛一般，清晰的看到了整件事情的全貌。最后在根据可落地的计划，结合有限的时间节点，安排每件事情的周期。 5、工作分工：工作的分配其实就是人力的协调配合。给你一堆工作和一些人，你如何通过最优的配置用这些人完成手头的工作。这个就要结合交付计划来实施。首先，通过交付计划将工作任务按时间顺序排开，找到要先完成的任务内容。然后，将首要完成的工作内容，按照任务优先级排列。最后，对任务优先级较高的任务，识别出是否有可以并行进行的任务，据此在结合人力对每项任务的熟悉程度为每个人分配工作内容。例如，在PLAS软件交付的过程中，首先要做的是申请I层资源。在这个任务中，最重要的是申请虚拟机资源、网络资源，配置防火墙矩阵策略，保证申请的虚拟机之间开通的防火墙端口可用。上述都是优先级较高的任务。然后，把这些优先级的任务排列后，找到团队中对某项任务熟悉的同事，负责实施。比如找到对拉起虚拟机熟悉的同事创建虚拟机，完成虚拟机创建这个子任务。但是他对配置防火墙可能不清楚，如果让他进行防火墙配置可能出现风险导致不可用，造成后期返工成本。因此，再找到对防火墙配置熟悉的同事，接下来完成这项工作。当团队中没有人对这个事情熟悉的时候，就要及时的求助外部专家，将我们的需求讲述清楚，借助别人的力量实现我们的业务目标。这样，通过对任务的细粒度分解，再结合团队资源与任务的精准匹配，实现每个人的能力最大实现与发挥。高质量的完成计划。

3.3 现场交付管理

到达客户现场后，首先是与市场部客户经理对接，了解对齐客户上线计划。然后，根据客户的上线计划，倒排交付计划中的deadline. 在排期工作完成后，就进入到了正式的交付阶段。由于德国电信公有云的现网安全级别很高，客户要求所有上线的新服务必须现在测试床环境安装部署，由客户验收通过后，才允许在现网商用上线。因此，整个交付过程分为测试床交付与现网交付两个部分：

3.3.1 测试床交付

公有云的测试床其实就是与现网配置相同的镜像环境，主要用于给要上线的各个服务提供测试验证的环境。但是，客户对测试床待上线的服务标准要求依然很高，需要遵守现网的上线标准，具体要求如下： 1、变更评审
在客户环境所做的任何变更操作，均需要走公有云运维团队评审审核批准，经公有云运维团队批准后，再汇报给客户运维团队评审，双方评审通过后，由客户对所有变更操作的优先级进行排序，并结合客户运维团队人力排出变更计划，为每个变更分配对应的责任人和变更时间窗。也就是说，所有在客户环境进行的变更操作，都需要经过上线评审，评审通过后，由客户的环境操作人员实施所有的变更，华为技术人员只提供指导和支持。所有的变更操作都需要在指定的时间内完成，这就要求对交付要做的事情时间预估合理，同时要考虑到交付过程中可能出现的风险和问题，提前预留出时间窗处理并对可能发生的风险制定应对计划，在风险成为问题时能够快速响应处理。
这里再说一下变更提交的评审材料，包括Changerequest, Changeguide, runbook. 下面分别来说下这三个材料的功能：
Changerequest描述了你的变更目的是什么，为什么要进行本次变更，变更有哪些步骤，变更的影响是什么，变更需要多长时间。客户会依据你的变更目的，评审本次的必要性和风险性，对于不必要的变更或高危操作有权拒绝会安排到流量较小的时间点。
Changeguide是变更的指导书，用来指导客户如何完成变更操作。德国客户严谨、认真，会对指导书中的细节追求极致。如果华为方在变更实施过程中，所做的操作没有完全遵循changeguide的说明，会被客户质疑挑战，需要尽快给出澄清，否则会导致客户的不满终止变更。
runbook其实就是交付计划，是对changerequest中的变更步骤的计划安排。要对每一个变更步骤预估时间，总的变更时间符合本次变更的耗时。这个材料作为客户变更结束后的验收材料，例如，交付第一天的变更是申请I层资源，拉起虚拟机配置网络。那么changerequest中会说明步骤：第一，创建虚拟机；第二，登陆每台虚拟机配置网卡、路由；第三，配置各虚拟机间的防火墙通信矩阵，保证各节点的业务端口放通；第四，检测各节点的互联互通性。然后，在runbook中，标明每个步骤需要的时间，创建虚拟机要多久，配置网卡多久等等。最后，runbook的总时间要与changerequest中申请的时间窗吻合。 2、变更实施
经过评审后的变更，就可以在客户要求的时间点上进行实施。在变更开始前，负责与你对接的客户会通过邮件跟你取得联系，然后给你一个会议链接。进入会议后，可以看到客户的电脑桌面，所有的变更操作都由客户在他的电脑上完成。华为交付或技术支持人员只能通过文字聊天的方式，指导客户进行变更操作。而且，客户也会拿到你的变更评审材料，评审材料中包含了操作的指导书。如果你的操作不在指导书范围内，客户环境操作人员也有权拒绝你的变更操作。有时候遇到比较认真的客户，会因为你要执行操作与指导书的细微差别，而拒绝执行，导致变更阻塞无法进行。所以，变更的实施需要沟通技巧和对变更的全盘梳理。 首先在变更开始前，最基本的要对变更的操作非常熟悉，要做哪些事情了然于胸。然后，对每个要做的事情，留一手准备。什么意思呢？就是如果你要做的操作失败了，或者出现了预期外的结果，你该如何回退或补救？把补救方案考虑清楚的原因是，要把补救方案也写入变更指导书中，便于在预期外的错误发生时，能够进行回退操作。否则，如果不在指导书中体现操作失败后的操作，客户会拒绝做回退操作，影响整个变更的继续进行。 其次，跟客户的沟通也非常重要。当客户发现你的操作与指导书中不一致，提出疑问和挑战时，首先不要慌乱。站在客户的角度想他为什么会这样做？他的根本诉求是什么？然后，基于他的落脚点，去沟通而不是一味的单方面说服。更不能嘲笑或者鄙视客户不懂技术细节，就听我的这样带有攻击性的语言。我的经验是，首先安抚客户，对他的疑问表示理解。然后及时澄清，澄清的时候从事实出发，不要自说自话，而应该从当前的事实出发结合后续要做的事情，再去思考沟通的话术。比如你在向所有虚拟机安装产品软件的时候，首先要纳管虚拟机，讲所有虚拟机初始化后，再去安装软件。但是在初始化虚拟机的时候失败了，定位后发现是虚拟机的网络配置有问题。解决的办法是删除这些节点然后重新纳管。但是在指导书中并没有体现这里的内容。那么，在你提出删除节点重新纳管的操作时，客户就会认为删除这是危险操作，而拒绝执行。这个时候就需要与客户关键沟通了。首先要了解客户的出发点，他认为在系统上删除节点是危险的。那么我们就要跟客户澄清，这个动作究竟危不危险，不危险的理由是什么？打消客户的疑虑就好了。然后，如果客户这个疑虑被解决了，很有可能继续挑战我们指导书中为什么没有体现？这个其实就是用规定或者规范来挑战你，一般的技巧是如果能找到指导书中提到这类操作的灰 {MOD}地带，就告诉客户其实我们提到了只是不太明显。如果实在找不到对应的描述，那就只好实事求是，告诉客户我们下次注意改进。不同的场景，情况与客户沟通的方式不同，也要依据具体情况来看。但是，基本的沟通思路不变，站在客户角度，用它的方式思考，然后真心的为他解决问题，本着这个宗旨就好了。
3、问题解决
交付实施后，就要转给客户进行验收测试。客户在测试过程中，会基于自己对产品的理解输出测试用例。客户在测试的过程中，会对产品的使用提出很多的质疑和疑问。其中一些，确实是产品bug需要我们及时修复，这个是交付人员需要及时向研发传递并推动解决的，因为确实是产品的bug问题，所以直接对客户反馈问题修复进度就可以了。还有一些是客户对产品需求和使用方式理解不一致，这就需要我们与客户基于产品的设计初衷与需求出发，澄清客户的问题，使客户对产品的理解与产品的设计初衷保持一致。减少由于理解不一致导致的无意义的产品修改，浪费产品研发人力。这其实就是产品交付人员与客户沟通的关键所在，因为产品交付人员本身对产品的设计方案、方案实现等方面很熟悉，因此客户对产品提出疑问和质疑的时候，他们就可以将客户引导到产品的设计初衷去，从产品的设计思路出发，为客户解释澄清产品为什么要这样使用，以及客户的诉求为什么无法满足等等。产品交付人员通过自己对产品的深入理解，以及研发当前的实际情况，引导客户朝着对产品交付最有利的方向发展。尽量减少客户的不合理需求，提高交付效率，降低研发人力浪费。 4、回溯报告 对于转交给客户测试的功能，如果基本功能出现问题，需要给出回溯报告。解释问题是如何发生的，为什么会发生这个问题？问题的解决方案是什么，后续的改进策略和措施又是什么。因为基本功能出现问题，在客户看来是难以接受的，必须要澄清清楚整个问题的来龙去脉，让客户相信你后续的产品功能会高质量交付。否则，就会造成大家对向客户交付的产品质量没有管控，十分随意，最后酿成现网事故引起客户投诉。在回溯报告解释问题原因时要注意，在挖掘问题根因时可能会涉及到产品的设计方案，例如，数据库无法写入的问题背后可能是主从倒换失效等。这里要注意不要暴露过多的细节给客户，导致更深层次的追问和不必要的澄清。从而引发客户对整个产品的设计层面的更大的质疑。因此，对回溯报告中的问题根因的书写，对措辞和产品细节暴露的深度要特别注意，以免引起不必要的澄清。 5、安全测试 欧洲客户对交付软件的安全要求很高。任何交付到客户手中的软件都必须经过严格的客户安全测试，例如渗透测试、防病毒测试、漏洞检测等等。对于安全测试中不通过的地方，需要给出澄清报告，澄清内容包括不满足的原因，是不涉及该安全选项还是安全规格已经满足，只是客户的安全扫描有误报。安全无小事，任何的安全问题都有可能被放大到国家机密窃取的层面上来，尤其在当下欧洲各国对网络和信息安全非常重视，任何安全问题都有可能引起客户的投诉。 6、运维能力测试 软件除了提供满足客户需求的基本功能外，还需要具备运维能力。公有云运维团队对每个上线的云服务运维能力有通用的基本要求，包括虚拟机参数监控、性能监控、业务和操作系统日志采集、告警监控、用户的审计日志。满足基本运维能力才允许上线。 在实际的测试床交付中，由于前期准备的比较充分，在软件的安装、部署、调测的过程中比较顺利，没有遇到比较大的问题。在内部对交付的云服务调试成功后，就转交给客户做业务和安全测试了。在业务测试中，客户主要对云服务的界面进行了细致的测试。当时客户提出的问题数量达到了90个之多，大部分是界面的细节问题，而有一些确实是产品bug需要修改。在处理客户的具体问题时，首先最重要的是弄清楚问题是什么。这是很关键的，如果没有搞清楚客户的具体问题诉求是什么，很有可能误会客户的问题，导致沟通的错位。可以在客户提出问题之后，及时的与客户确认。例如，客户提出了一个界面的优化建议，那么我们了解之后，可以与客户确认是不是要在这里加一个按钮，把xx描述改为xxx. 对问题的确认除了能够明白客户的真实诉求之外，还可以让客户觉得你明白了他要表达的意思，有助于拉近你们的距离。其次，在搞清楚问题之后，就要评估这个问题是否合理。对于不合理的问题，我们要及时给客户解释原因，这里我们为什么这样设计。通过澄清让客户了解我们的设计初衷，并把对产品功能的理解达成一致。有些不合理的问题纯粹是因为客户的理解偏差，如果我们不加思索的答应客户解决就会浪费研发人力，最后的结果可能还不是客户想要的。在整个澄清的过程中，不要畏惧客户的问题和挑战，如果我们能从专业的角度、产品设计的角度解答了客户的疑问，那么客户对我们的专业性就会更加认可，我们在客户那里也就有了信任。再次，客户提出的问题确实是问题的，要把问题按照优先级排序，排序后根据修改问题的周期确定修复时间点，这样做的目的是可以把有限的研发人力资源投入到最关键的问题上，解决客户最关注的问题，而客户最关注的问题是影响项目上线的最关键因素。集中力量聚焦到最关键的因素，这才是达成最终目标的最好办法。而对于一些优先级不高的问题，可以在关键解决后再解决，这样即使无法在deadline解决完全部的问题，但是客户最关注的问题都搞定了，只遗留了非关键问题，那么客户也是可以接受项目上线的。在解决问题的过程中，一定要关注进度，尤其是关键问题的进度。对于进度缓慢的问题，一定要及时上升到研发领导求助解决，而不要因为疏于跟踪进度导致到了deadline，关键问题没有解决影响项目上线。