我的程序员==>项目管理之路

我是2014年毕业，先去了一家小公司最开始做C语言，当时毕业的时候没考虑太多，只考虑了工资和报酬，现在想想还是挺幼稚的。没有做全盘的人生规划。而且当时面试的时候也不知道需要准备，需要刷题，自己傻乎乎的去笔试华为，阿里等公司，结果可想而知。哈哈。

接下来就是在小公司工作了2年，最开始是做LTE协议栈PDCP层，主要是C语言。最开始工作很积极，我是一个做事认真的 人，这是我的优点，而且动手能力很强，适合做一些新事物的探索。但是当时的工作重心还是在成熟产品的维护上，所以我的作用和能力展示不出来。每天都在进行网络问题的定位和排障中。但是当时我的能力不足以支撑这些工作，所以我就开始深入TCP/IP协议进行研究和实践，当时记得自己研究的挺深的，从理论TCP/IP协议栈每一层的构成，到实践使用wireshark抓包，把网络这块弄得比较熟悉了。AB两台机器在ping包的过程中，是如何交互的。而这期间，自己又阅读了一些经典的书籍，比如代码大全等，那时候就对自己的代码质量要求很高，希望自己不仅仅是能实现功能，而是能做的更好。现在回想起来，自己对代码的卓越要求其实一直深入在骨子里，而只是一直没发现而已。在自己阅读的过程中，我也学到了很多的思想。让我当时最受用的是，优化性能的思想。先测量，再优化。这在之后的性能优化过程中，让我负责的用户面流量直接上升了一个量级。开始接到流量优化的任务时，大家都一筹莫展，不知道从何入手。我的师傅让我挨个测试，用撞大运的方式去测试。但是我使用了测量的方式，在用户面收报文的入口处以及在整个处理流程中打点，进行耗时测量，找到了瓶颈点在平台层。我就在平台层中继续打点，发现其中的mac子层耗时最高，走读代码发现平台层多了一些内存拷贝的操作，然后我通过优化拷贝次数的方式直接将性能量级提高了40%。当时特别有成就感。总结下来，这是吸收知识，用于实践的过程。而且真正产生了效益。

协议栈的开发前前后后做了1年，感觉自己的提升没那么高了。就想去做一些web相关的东西。恰好公司要做云测试平台，自己一直对云计算也很有兴趣就加入了。我当时是负责前端的开发，第一次接触了js,python,css,html这些技术。当时每天都在学习新知识，感觉也很充实。还记得那会每天上午看书，下午开始编码实践，中午休息的时候也在看慕课网的js视频，学习了很多高级原的知识，比如类、闭包等，自己的提升也很快。从对前端一无所知，到自己主导整个前端的开发和设计，这段经历我的最大收获就是对编码的要求不断提高，自己最开始写的代码其实是很初级的，只是一些基本的流程顺序结构。但是在项目进行中，需要大量的使用开源组件，在使用开源组件的过程中，我没有止步在用这个层面，而是深入到实现细节中，学习别人的代码是如何写的。这也就直接引发了我对好代码的追求。从命名规范、到整洁度、复用性等等方面，我都会做多方面的思考。在持续深入的过程中，我还接触到了依赖注入的方式，知道了代码还可以通过如此灵活松耦合的方式组合在一起，让自己的视野和编码习惯又上了台阶。所以，我的编码习惯和对代码的追求我觉得就是那个时候建立起来的。而这种习惯我当时说不清楚，现在我觉得就是对技术内核的探索以及如何把事情做得更好的一种追求。程序员总是说自己是码农，大部分也说自己是CURD人员。但是，代码想要写好可以有很多的方法和技巧，即使一个简单的业务流程涉及CURD，我们能不能考虑用设计模式的责任链完成？可不可以用pipeline的方式做到？那么再进一步pipeline是如何实现的？它的实现机制对于我们的开发有没有什么帮助？这都是可以去思考和深挖的。而大部分程序员都是止步CURD，功能做完就好了。完全没考虑到代码的复用性以及可读性，将来交接给别人或者一段时间后自己看都不知道啥意思。这样的coding是毫无意义的，写完的东西就像是应付老师的寒假作业一样，堆砌在那里。其实，技术的发展很快，但是核心的东西不会有大的变动，比如高性能框架其实就是linux的几个库函数的实现的，java的各种数据结构也都是最基础的链表、数组组合而来的。但是如果只关注高性能框架，每天都有各种高性能框架出来，这样去学习追逐是没有尽头的。但是你抓住了epoll模型，队列模型的内核，其实高性能框架就是这些模型的排列组合而已，这才是根基。再举个昨天学习tomcat和Servlet的例子，之前一直以为tomcat是深不可测的东西，又能把web服务容器化，又可以实现多应用部署，感觉很深不可测。结果看了源码之后才发现，tomcat就是Java的Servlet容器，只不过是把java的核心组件进行了实现和封装而已。所以，你看平时我们觉得开源的东西很多，技术迭代快，其实最根本的还是语言相关的基础特性，像HashMap是用链表实现的，ConcurrentHashMap是用红黑树实现的一样，还是最基础的东西。所以不要被大量的开源技术和所谓的技术迭代吓倒，抓住本源的东西，就能笑到最后。

从2016年我越来越感觉之前公司的成长到达了瓶颈，在云测试平台还未完全投产的情况下，就让我负责另外一个网管产品M2000的特性开发，这个产品是基于Java的web应用，也是我第一次接触javaweb开发，很多新的东西让我重新开始学习：Spring,Struts2等等。当时的我已经有了自己的学习经验，并没有一下子陷入到复杂的具体技术中，而是先看之前产品的源码，先能够动手干活。其实基于原有代码做开发的好处就是，你不必了解整个架构的全貌，就可以在其中一个环节进行开发，当然了，如果你想要深入了解必须要了解整个系统的全貌，从系统如何启动，到如何进入到业务逻辑中，最后到执行业务逻辑。以及在整个过程中，开源框架是如何发挥作用的，是如何像一根针一样把这些流程贯穿起来。当时在上手Java开发不到1周的时间，就开始主导网管参数批量修改的特性。这个特性的背景是一个网管可以管多套基站，每个基站都有共性的参数，如果我想批量修改这些基站的参数，需要一个个进入基站的界面进行修改，很麻烦。所以想做一个批量修改的功能，支持一个修改操作对多个基站的修改能力。我再做这个特性的时候，第一个想到的就是先去梳理整个修改流程，梳理流程后找到特性可以实现的切入点，最后进行技术选型实现特性。我具体的讲下每个环节：梳理流程这块，先去走读代码研究修改基站参数的用户操作流程是什么，首先是用户点击某个基站链接，跳转到该基站的详情界面，再选择某参数进行修改。所以整个代码流程就是用户选择基站——查询基站id调用查询基站详情接口返回基站详情信息——选择修改参数——调用参数修改接口完成修改。流程梳理清楚后，接下来就是考虑特性如何实现。其实也很简单，就是查询的时候先查询该网管下的全部基站列表，批量选择基站列表后，列出这些基站共同支持的参数，对于这些参数判断他们是什么类型的比如枚举or数值等等，然后给出用户可以修改的方式，枚举的给出下拉框选择，数值型的给出输入框，最后分别调用选择的基站列表修改接口执行修改。第三，在技术选型上，很容易就想到了多线程。通过一个请求的创造多线程的方式，每个线程处理一个基站的修改操作，如果一个线程失败了，整体就会失败。而且当时还引入了异常机制，所有的错误都是用异常的方式抛给前台。同时，线程的操作还是用了线程池来实现。这在我第一次接触Java的过程中，实属难能可贵。总结一下，第一次的java开发经历让我体会了带团队的感觉，把任务分给他，告诉他怎么做，但是当时没有设置验收标准。要告诉他做到什么程度就是成功。而且，在需求方面，我没有去了解需求的含义，知道要干啥就去干，没有去具体的了解需求的背景，比如这么多参数都需要改吗？经常改的是哪些？会不会有所有基站都改的场景？这些东西都要去澄清，需求的澄清可以避免额外的工作。在技术方面，多线程修改基站中，就存在着部分失败的问题，其实当时就需要事务的概念。如果部分失败，事务如何回滚？这些其实都可以去考虑，否则会出现基站间参数不一致的问题。所以技术问题有些时候不单单要从技术出发，还需要有一定的产品思维。比如需求是否合理？是否有改进的空间？在实现需求的过程中，技术人员经常会想使用最新最炫酷的方式实现。但是产品人员其实关注的功能的可用性，对客户有什么价值，客户需不需要这个东西？所以，技术人员需要有一定的产品思维，这样既可以达成整体的目标，也可以让自己明确精力应该聚焦投入到哪里去。

工作了2年后，做的事情开始是一些重复的事情了。当时最多的就是网管软件要出版本，每次出版本都是复制粘贴，感觉很无趣没有提升。基于此我提出了网管界面自动生成的改进方案，在内网博客公开。也得到了领导的肯定。当时我的想法是，将重复性的工作进行自动化，现在看来，我那会就有了持续改进把事情做好的心态，而不是仅仅把工作做完了就行了，我觉得正是这种心态，才驱使我不断的去追求最好、做到极致的追求。但是当时的我不知道如何推进方案，只是在领导面前提了一下，感觉领导也不是很乐意做这个事情，我觉得有点受冷落。再加上公司后来业务不聚焦，和我的心态的变化，我有了离开的想法。恰好这时候华为招聘联系我，说是做云计算的业务，让我过去试试，我就果断的去面试了。

在华为的面试，我当时做了一些准备，现在来看还是比研究生毕业的时候长进了一点。我把自己做的作品，做了gif动图展示，让大家能够看到我的demo.这是比较好的一点，但是我当时仍然没有去网络上查看面经，准备相应面试题目的意识。直到上个月我才发现，原来面试一家公司需要做这么多的准备，当时真的太草率了。我还记得，一面是HR的技术面，让我介绍自己，问了我做的项目，针对我做的项目问了一些技术细节。现在想想自己回答的其实有瑕疵，这也是前期没有好好准备的坏处。面试无爱护这几个套路，问你做过啥项目，通过你提到的关键词，不断深挖，所以提前准备项目描述和涉及的技术点的讲解，包括跟这个技术点相关的一些内容，是保证面试成功的很重要一环。二面是技术面，给了几道算法题让做一下。我看了一下，好多都是基础算法，但是工作用的太少了，基本都忘了。挑了一道不是太难的，用js写出来了。然后是一些基本的问题思路定位，我很好的展示了自己的逻辑思维能力，二面其实我的表现还是很不错的。终面是部门领导的面试，就是闲聊一些东西，当时只问了一个技术问题，什么是服务化？我也是各种喷，从传统烟囱式的软件到服务化有什么改变，我理解的服务化是什么等等。总结下来，整个面试自己的准备还是不够充分，说白了还是对面试的流程不了解，愣头青的往里闯。如果事先查询下面经，知道了有哪些套路，好好准备，其实可以更好。

从2016.6年开始，我就在华为工作了。本来想做开发的工作，结果去做了市场项目交付。其实交付工作更偏向于前端，将研发的产品交付到客户手里，涉及到软件的安装部署调测，问题澄清等等，工作内容更需要端到端的思维。刚入职的时候，还是跟随测试组一起测试产品特性，了解熟悉产品功能。当时我负责产品的性能测试，基于snmp协议测试产品的告警性能。当时用了Jmeter工具开发了一个告警插件，多线程的向告警接口发snmp请求，冲流量。让我对测试工具有了一定的了解。这段在测试组实习的经历，让我对产品的特性有了进一步的了解，也认识了测试组的一些朋友。

从10月份开始，我就正式进入交付组开展工作了。我们当时的组叫重大项目交付组。听起来挺唬人的。我当时交付的一个项目是跟公有云相关的，我们做的是一个SDN的系统，实现云网协同的功能。项目的目标是把这套SDN的系统包装成公有云的云服务，在公有云上线。刚接到这个项目的时候，我没有一点头绪，新的工作内容让我之前的开发经验无从施展。所以，我的第一想法是求助导师，导师先让我跟随测试组一起测试，逐步了解项目。而整体测试组当时都集中在杭州，所以我的第一次出差就开始了。之前的工作经历，从来没有出过差，感觉工作能出差还可以玩，挺兴奋的。于是，就背上了书包，带了几件衣服出发了。临行前，还问了组里的人定酒店的事情，组里有一个牵头的兄弟说，大家住在一起，方便沟通。但是他们住的酒店已经没房了，所以我自己就定了一个最近的酒店。到了杭州之后，我觉得很兴奋。第一次出差工作，感觉自己又是从大公司来的，荣誉感、自豪感油然而生。转眼来到了正式工作的时候，还记得那天我走到杭研所，园区里湖水清澈，树木茂盛，心情大好。感觉自己真的是来对了公司，选对了工作。然而，到达指定工作地点后，噩梦才刚刚开始。在华为做项目，压力是很大的。由于我们的产品前期准备不成熟，质量太差，导致跟组里其它产品联调的时候根本无法工作，成为了瓶颈。而我每天就是协助研发定位问题，有的时候一个问题好几天定位不出来，挫败感很强。后来我的导师来到了现场，过来之后，先是发邮件给大领导，建立了一套工作标准，比如当天的问题必须要当天搞定，每天晚上通报进展等等。这也是我第一次感受到，邮件的威力。邮件其实是一个人管理思想的体现，也是一个工作结果的呈现。邮件可以让干活的兄弟们感受到压力的存在，时间点的紧迫，也可以让领导们知道当前的进展和项目组的努力。这是一个很好的协调上与下的工具。然而，即使标准定了出来，研发感受到了压力，但是仍然无法提升问题定位效率，在每天解决问题的过程中我发现，有时候解决了的问题会再次复现，那我就主动思考，可不可以把遇到的问题整理出来，将对应的解决版本标在后面，这样的话，如果后面的新版本复现老问题的话，可以把老问题修复的版本号拿出来，与新版本对比，不就可以提高问题解决效率了吗？后来我推动建立了问题单库，将问题与解决版本号的信息录入到问题单库中。既能体现我每天的工作量，又可以提高问题解决效率，一举两得。想想，那个时候自己就有了持续改进提升效率的想法了。即使提升了效率，但是由于版本质量确实不尽如人意，导致产品特别脆弱，研发团队没日没夜攻关了尽半个月，才把流程打通。虽然联调的过程很痛苦，但是我在这个过程中学到了很多东西。比如从产品层面，我学到了要交付的产品有哪些特性，这些特性是如何实现的，这些特性又是如何组合起来对客户提供功能的。从交付层面，我学到了一个版本是如何规划、实施、运作的，从版本路标的确立，到每个版本包含的需求包定义，再到排期，人力规划等等方面。让自己从研发写代码的视角，第一次站在了更高的角度去审视整个产品交付过程。我觉得这是我很大的收获。

在辛苦的联调了近一个月后，我带着自认为成熟的产品奔赴德国一线进行交付。我自认为，版本已经跑通了，这已经达到交付的标准了，熟不知，挑战才刚刚开始。到达德国波恩之后，我是最后一个到达的。先是跟系统部的各位领导和同事打了招呼，感觉氛围很不错。大家寒暄之后，就回到酒店了。当时的氛围很融洽，让我误以为交付是很轻松的，也很容易完成。到了第二天，交付正式开始。整个交付过程分为软件安装部署、版本调测、流量测试几个环节。在软件安装部署阶段，由一个本地员工操作。他在整个过程中，没有遇到太大的问题，还算比较顺利。但是到了版本调测的阶段，我当时觉得，在研发环境都测试了这么久，肯定没问题了。结果可想而知。问题集中爆发出来，比如由于德国的时区与国内不一致，出现了很多因为时区不一致引起的问题。还有客户界面做的相对比较粗糙，字体，图标，按钮都是很原始的结构，让人感觉很不舒服。总之，系统部的市场人员提出了几十个问题让我解决。因为我第一次接到这样的挑战，内心是不知所措的。我不知道如何处理，也不知道该如何处理。现在总结起来，就是当时的我对交付工作的一些能力不具备，比如客户提的问题，应该如何答复？是不是先澄清问题，站在客观的角度去评判这样做是否合理？如果不合理，就跟客户讲解不合理的原因，希望客户关闭问题。如果合理，就要推动研发按照客户的想法去修改。如果研发可以修改，那么最后，如果不能修改，讲清楚困难反馈给客户，在未来的时间点什么时候解决。然而当时的我，不知道这些。只能不停的找我的师傅，项目的DPM管理，想他求助。由他来应付一些。还记得他当时的应付策略就是扯皮，不做，完全是胡搅蛮缠。这对我也有一些影响，认为这是好的处理方式。其实，从沟通层面来讲，每个人都有各自的目标和诉求。市场的一线人员提出这些问题，目标就是希望按照他们的意思修改，让客户满意。而研发管理人员希望不要增加额外工作量，减少人力浪费。最终就是这两个目标如何平衡的问题。也就是找到中间地带，既满足让一线满意又能减少工作量。达到共同的目标。这些问题，最后的处理结果就是，我的领导也没权利决定，要继续上升到他的领导，PDT经理决策。当时我就感觉，这么一个小事情，要这么麻烦？扯来扯去。但是现在想想，每个职责都有自己的权利范围。DPM的职责是管理项目进度，看护项目能成。但是对于产品的修改需要人力投入去做，这个决策只能由开发代表或PDT经理决策。每个人站的立场不一样，他只能管理自己范围的事情，而不能越级决策。如果这样做了，他的领导就会很不满，承诺领导不想做的事情导致的结局就是领导觉得这是在浪费人力和工作量。这也是一种做事的智慧。只做自己范围内的事情。
最后，我这块的软件交付总算在吵吵闹闹中做完了。期间熬了好几个通宵，在这个过程中，我认识到对客户交付的产品是什么样的质量。对客户交付的产品，不能像研发认为的那样，能用就可以了。还要考虑很多客户层面的东西。比如易用性，友好性等等。这从根本上来讲，就是研发人员与产品人员对同一件事情的看法和角度的不同。研发人员认为东西做出来，能用就是过关，而市场人员要站在客户角度，考虑这个产品是什么样子的，客户的需要是什么，怎么样做才能抓住客户的痛点进行营销。所以视角、站位的不同，本身就会引起双方的冲突和争执，有分歧再正常不过了。还好，最后给客户的演示整体很顺利，客户也很满意。首次的交付就这么告一段落了。
回国后，我的试用期就到了，开始准备转正答辩。由于在交付过程中表现的不错，对整体方案也有大致的了解，最后我的转正考评很不错。这也给了我很大的动力继续把交付做好。经过了上次交付的教训，我开始思索如何能把交付做好？为什么到了现场会这么灰头土脸，有哪些工作是我可以提前准备好的？这又是我骨子里的想把事情做得更好的基因，在推动我前进。我发现，之前在一线做得不好的方面有：对方案不熟悉导致系统出现问题时，不知道责任主体是谁，只能拉研发从头到尾定位，效率极低；版本质量不过关，测试场景不充分导致现场与环境相关的问题频发；交付过程不清晰，端到端如何操作没有梳理出来，导致到现场没有自己的计划，胡乱工作一气，遇到了问题也没有对应的应对策略。基于以上的痛点和教训，我开始思索如何改进，能够让我在现场更加的得心应手。首先，对方案有一个全局的学习，了解了整个系统方案有哪些组件，这些组件都是做什么的，如何配合和交互的；其次，学习客户在使用系统的时候都有哪些场景，在这些场景下是如何使用的，客户的业务流是如何在系统中流转的。这样对方案有了一个整体+细致的了解后，就对整个系统心中有数，然后结合在系统上的具体操作，验证自己对方案的理解，通过理论+实践的方式基本上对整个方案就有了比较好的理解了。在对方案有了了解之后，对于现场环境与研发不一致导致导致的系统问题，我牵头梳理出都有哪些问题，然后推动研发测试验证这些场景。比如时区要设置为欧洲时区，比如环境的其它参数等等，严格按照现场环境的参数验证。这样就能测试出很多的现网问题。最后，在自己对方案理解并且版本质量有一定保证的前提下，开始端到端的把整个版本安装部署，调测一遍。去验证方案和版本的质量，在这个过程中，同样也会验证安装指导书。审视整个过程有没有什么坑在里边。并按照从版本安装部署，到业务系统的对接测试，再到系统调测这个顺序，梳理出自己的交付剧本。这个剧本就是指导我再一线交付的流程图，每一步要做的事情是什么，在做这个事情的过程中参数是什么，需要注意什么，失败了怎么办，自己搞不定了应该求助谁。把这些日常工作中遇到的问题，全部记录在剧本中。这样在一线交付的时候，就有了底气。通过剧本指导交付工作，在交付工作中遇到了剧本里没有涉及的内容，还可以继续改进剧本，下一次会做的更好。
正式的商用交付时间点还是到了，我揣着兴奋与激动来到了匈牙利的布达佩斯，德国电信公有云的数据中心，准备大干一番。在飞机上的时候，我又再次把要做的事情从头到尾梳理了一下，并按时间点排序，细化到每天的任务，再次细化到每个任务应该如何去执行。由于给了我两个下属，所以我又把梳理出来的任务做了明确的分工。当时的这些工作其实已经有了项目管理方法的雏形：把要做的事情梳理出来是定义范围，要做哪些范围内的事情。然后将要做的事情分解为具体可以执行的工作包是创建WBS，并按人头分配。接下来，按照活动里列表对活动进行优先级排序，按照做事的四象限总结出任务优先级高低。最后，估算每个活动的持续时间，制定进度计划。在到达一线后，就迎来了挑战。先是让我当着所有的人面讲解安装计划，当我说出来需要8天时候，领导直接拍桌子把我骂了一顿。我当时的心情非常的难过，因为我对自己的产品胸有成竹，计划自认为做的天衣无缝，结果到了展示的时候却被挑战。但是后来证明，领导的挑战不是没有道理。在正式交付之前，需要把要做的事情准备好。在准备的过程中，我才真正认识到在一线的现网交付与研发的不同之处。首先是资源的准备，需要多少台VM，多少个IP这些基础资源。这个在研发的时候已经梳理过，也有成熟的材料。但是现网又有很多不同，比如你的VM之间是亲和的还是不亲和的？你的VM资源要落在哪个AZ里？网络要申请哪些网段的？这些细节问题。我当时很多都是第一次听说，完全摸不到头脑。其实这就是对现网的具体情况了解不足，前期没有做好充足的功课。误以为虚机这些资源都是别人准备好的，我们上来安装软件就可以了。这块的教训就是，做任何一件事情，都要从头到尾的通盘考虑，与做过这些事情的人详细了解都要做什么？这样就能规避我自认为有些事情不用做的问题，把这些工作前置到前期准备中来。
第二，就是通信矩阵的梳理。这里我又是第一次听说，其实究其根源还是自己对现网的交付流程和产品特性不熟悉。所以一头雾水。而且由于产品当时整理通信矩阵很仓促，这里也没有验证过，导致通信矩阵的质量很差而且我对这里完全不懂。结果可想而知又是一团糟。这块总结下来就是对交付的全流程不熟悉，导致准备的时候完全疏忽。第三就是，德国客户只允许本国籍员工操作后台系统，所以沟通效率非常低。需要提前把要做的事情整理成与客户交流的文字，一条条的与客户交流。虽然在没来一线前，做的准备工作不够充分，但是到了一线后，还是弥补了一些。这里要着重提一下通信矩阵，在准备通信矩阵的过程中，体会到了现网操作的规范性。首先要提出通信矩阵变更申请，由安全组评审，评审后才由专门的操作人员实施。当时我对通信矩阵一知半解，这也为后续因为通信矩阵没有打通的原因埋下了祸根。

在正式交付的第一天，是做虚拟机的拉起。这里介绍下，一线的交付是有明确的时间点要求，即在规定的时间内完成当天的任务，如果没完成，就要回溯问题的原因并通报给高层领导。当时由于初次做计划没有考虑的特别多，在我看来这是再简单不过的事情了。创建个虚拟机能有多难？配配网络、磁盘就好了。结果发现不是那么简单的。首先是，由资源组的规划人员规划的虚拟机处于不同的可用区。在拉起虚机时，不同的虚机需要进入不同的可用区管理域拉起，而每个管理域都有不同的虚拟机管理软件。其次，再拉起过程中，网络的配置也是相当复杂，规划的网段没有出现在VLAN池中需要手动创建。由于之前对这里的了解只是皮毛，不知道如何创建，所以导致求助他人耽误了很多时间，好在虽然耽误了很多时间，但是最后还是按预期完成了。这在项目管理中其实就是风险管理做的不好，在实际的交付过程中，肯定会遇到各种各样的问题，妄图不遇到任何问题是不现实的。但是遇到问题之后，如果有风险管理意识，提前识别潜在风险，制定风险应对计划并在风险发生时实施风险应对计划，就能很好的管控风险。比如，在我上面遇到的问题中，如果能提前制定风险应对计划，在网络配置出现问题是应该找谁求助或者提前让家里验证，那么我在遇到这个问题时，就会很从容。知道求助谁，也知道如何去尝试配置，而不会像无头苍蝇一样到处乱撞，不知所措。
不管怎样，第一天的交付总算在跌跌撞撞中完成了。而第二天开始安装三方软件，大数据分析产品FI。在安装FI的过程中，前期通信矩阵准备不充分、没有经过验证的问题暴露无遗。首先是，安装完成后，界面根本无法打开。原因是，访问页面的VM在管理域的一台跳板机上，而跳板机没有放通与后台界面间的通信端口，导致防火墙拦截了请求，无法访问界面。当时多亏现场有一位兄弟是FI的SE，以及对防火墙实施的审核没那么严格。偷偷的把防火墙加上去就可以使用了。不过这只是噩梦的开始，当时遇到这个问题后，我并没有反思总结相似的问题，没有考虑到如果后面的工作遇到了同样的问题怎么办？这个小问题是不是影射了更大的问题以及隐患？应该让研发好好验证通信矩阵等等。果然，在当天晚上的交付任务中，我的职责是升级现网的Paas平台。在升级的过程中，我全程只负责操作，由研发的运维专家指导我操作。我当时天真的以为，靠别人就够了，我就老老实实操作干活就行了。熟不知，这样没有管控的情况下的行为，造成了后续的灾难。由于现网的Paas系统，时区不一致，研发要求重启节点恢复时区。结果重启后，造成了总线故障。但是当时并没有任何的迹象，我们也以为升级成功了，也就没管。但是到了第二天早上，铺天盖地的投诉邮件就来了。由于升级故障，导致租户面无法登陆，客户投诉升级。我也是第一次经历了客户的重大投诉，十分的胆战心惊。客户的投诉直接让公有云的现网运维团队领导转发客户投诉邮件，到我们这边产品线的大领导和项目领导，压力十分巨大。当时公有云的运维领导，也给产品线的领导施加压力要尽快解决。我们这边产品线的领导的应对方式是，先安抚公有云运维的领导，承诺已经成立专家组紧急攻关该问题。并定期同步进展。终于，在大家的努力下，最后的问题定位为我们的重启操作导致了这次故障，由Paas研发团队承担全部责任。在这起事故中，有很多值得总结和深思的地方。首先，由于我完全听信于他人的操作，对所做的事情一无所知，导致了对于一些高危操作没有及时意识到制止，比如重启、删除这些高危操作。导致了这次故障。其次，在现网操作后，没有对业务进行测试，而是自认为升级成功了，其实对业务的影响并没有仔细的评估过和测试过。最后，在事故出现后，没有主动的思考如何解决问题，而是想着如何推卸责任。这也是自己做的不好的地方。
在经历了现网升级故障后，一线运维组要求整改。对整个交付过程反思回顾并给出整改方案才允许继续交付。之后每天做的事情就是和研发商讨整改方案，输出现网故障的根因分析。通过长达半个月的整改方案梳理，我学习到了如何处理客户的投诉的。对于客户遇到的问题，首先是快速规避问题，恢复业务，这是最最重要的。其次，业务恢复后，要告诉客户我们正成立了专家组定位问题原因，安抚客户。最后，在问题定位清楚后，要结合客户的心里预期，谨慎的编写现网故障问题根因分析RCA。讲清楚整个故障的前因后果，以及后续的改进措施。再次取得客户的信任。
由于公司内部部门墙的原因，这次交付在长达一个月的挣扎中夭折。我们转战到德电系统部，开始了新一轮的交付工作。德电系统部的交付工作不同于现网的交付，压力没有那么大。但是方案不同于最开始的基线方案。由于当时的交付环境缺少公有云的基础环境，所以不具备直接安装的条件。在与研发SE讨论过后，给出的方案是自行搭建整套公有云基础环境。这个方案我当时并没有过多的质疑，而是觉得SE都觉得可以那就一定可以。结果给自己挖了一个大坑。由于SE的评估错误，没有全面的考量，导致对环境搭建的预估过于简单。在实际操作中，需要安装4个公有云组件，但是如何将它们连接起来对外提供服务却没有人知道。想求助对应的产品支撑人员，但是由于当时的项目对公有云没有投资，导致无人支撑。这使得本就艰难的安装任务变得更加步履维艰。在如此艰难的环境下，我根据之前在研发做开源项目的经验，通过研究安装文档、安装脚本、查看报错日志、搜索基础组件对接的方案等，最后完成了公有云的基础环境搭建。当搭建成功的那一刻，我无比的兴奋。因为完全是凭借自己的努力，完成了一套公有云环境的搭建。然后，基于这套自行搭建的环境，我进而把整套网管软件安装部署到公有云环境上去，完成了最终的项目演示。在系统部的这次经历，同样让我收获颇多。首先培养了自己积极推动事情向前走的动力。在做事情的过程中，总会遇到种种困难，遇到困难第一个想到的应该是如何解决，如何达成自己的目标。是通过技术解决？还是求助上级？还是怎样。当然，在遇到困难解决的过程中，不要忘记让最关注项目目标的知道，不要自己做了100件事情，结果领导只知道1件。这也是有效输出的过程。其次，对于别人说过的话要敢于质疑，别人做决策的时候其实并没有你想的那么全面，他们也是基于自己对这个项目的认知做的决策。事实证明，后来我对这个项目的认识要比大多数所谓的SE高的太多。并不是说他是高等级的SE他说的就是对的，敢于质疑怀疑，相信自己的判断，这才能够将事情成功的筹码抓在自己手里。
项目的第一阶段交付，就以在德电系统部的交付告一段落。回国后，领导们也对我的能力给予了认可，认为我在公有云的基础组件安装部署过程中，表现优秀，在人力支撑不足，对各基础组件是首次接触的情况下，完成了整套环境的搭建。所以当年的绩效考评也给了比较高的得分。这也让我感到了鼓舞和力量，继续把交付做的更好。虽然说，我的首次交付经验是痛苦的，在一线受尽折磨与打击，但是我的成长同样也是巨大的。我明白了如何在交付前做好充分的准备，充分的准备能够让后续的交付更加从容。比如学习方案，做好计划安排，时间计划安排并持续跟进，识别风险，梳理问题及时推动闭环，结合现网环境在研发做好充分测试避免问题集中在现网爆发。让我在交付前的准备更加全面具体。这也为我后续的交付项目顺利完成打下了坚实的基础。
在第一个项目交付结束后，我休整了一下，就投入到第二个项目浙江电信云网协同项目。借鉴第一个项目的教训，我在得知自己要负责该项目时，就积极的动手准备项目资料。先是找到项目的一线经理，跟他了解项目方案。在拿到方案后，我首先跟研发的架构师讨论方案的实现方式，在明白了方案的具体实现后，基于自己的理解与一线经理讨论是否满足项目需求。然后在了解了方案实现，并确认了方案满足客户诉求后，我投入到研发测试中，与测试沟通特性测试方法。比如如何发放一条业务，如何弹性调整带宽等。最后，根据指导书，从安装部署、对接调测、业务发放将整个流程串联起来，端到端的审视整个流程是否存在问题。这样就保证了，在正式交付前提前预演，自己对整个交付流程有了全局的认识，对后续的交付起到了有力的支撑作用。在正式交付开始前，要先跟客户沟通上线的资源计划：需要多少VM，磁盘，网络资源，内存，CPU等等。由于我们的解决方案是全量的版本，因此需要的16台VM，但客户只需要基本的功能，因此不允许申请这么多的资源。双方存在分歧，一直僵持不下。产品线给出的方案是自掏腰包，出物理资源给客户免费使用，用完后收回资源。但是客户不同意该方案。在博弈了几次后，产品线领导向客户妥协，对解决方案进行裁剪，只提供基础功能。在与客户的博弈过程中，其实就是在关键沟通。产品线领导与客户的出发点不一样，都希望能按照自己的需求来实现。但是这是不可能的，必须要找到共同的空间去沟通，不然只能是各自为战。这个共同的空间出发点肯定是项目能够达成的目标，以目标为终点创造共同空间。项目的目标就是让产品上线，与客户的网络连接，那能不能我们只把与客户网络交互的系统放在客户的资源池中，其它的组件放在别的地方，分离部署，这样既满足了客户对资源的要求，也可以不影响整个产品的既定方案，达到双赢的目标。
最后，这个事情达成的方案是服从客户的意愿，由客户在公司云资源池中分配5台VM，产品裁剪资源需求满足客户的要求。部署方案敲定后，我就赶往一线启动项目交付。由于之前积累的交付经验，以及前期对解决方案和部署方案的熟悉，使我在整个交付中游刃有余。积极与客户负责人沟通讨论部署的资源需求和网络需求，并推动落地。资源拿到后尽快启动安装部署，但是在安装部署的过程中还是遇到了客户负责人ip分配错误的问题。在与客户沟通后，他也承认这是他们的问题，但是要求我们修改配合他们，当时求助了项目经理后也觉得是小问题就让我修改了。在环境搭建期间，电信要进行新环境的安全扫描，这是我第一次遇到的。在扫描的过程中出现了很多的安全问题，让我一度非常紧张。这个其实就是当时的心态不够沉着冷静，有问题再正常不过了，哪有什么事情是那么一帆风顺的？想法很重要，你对于一件事情的看法直接决定你的情绪感受。这对于后面我看待事物也有很大的提升。在安全问题出现后，我积极推动研发进行安全问题澄清，最后的结论是客户的安全工具存在问题有误报。其实拿到这个结论的时候，自己就应该思考下，如果直接这样去答复客户是否合适？就相当于你告诉客户，你们的东西是错误的有问题的，这样去讲即使事实如此，但是客户面子上不一定能够接受。所以可以换一种沟通方式，我们的目标是希望客户知道这些都不是问题，同时要考虑到客户的感受不能直接了当的怼过去，说是这是你们的问题。所以首先可以基于事实出发，表达华为的技术团队经过专业的评估，发现这些问题用其它的扫描工具比如xxx已经不存在了，我认为可能是我们使用的扫描工具存在误报，能否换一个扫描工具进行扫描呢？这种沟通方式，既没有说我是对的，也没说你是错的，而是从事实出发，讲我的观点和看法，找到共同空间，让对方重试一下工具，重新审视下是否合适。
在安全这关过去之后，后面的交付就比较顺利了。但是在最后端到端整体交付时，出现了一些小插曲。有一天，项目经理突然让我们去客户现场调试设备，本以为这只是一次普通的调试，结果到了之后又说要今天把系统接入现网，一时间搞的我很是被动。因为之前都没有提到过这块，突然之间要打通系统和现网的网络，交付压力还是很大的。在整个端到端联调中，也出现了很多的问题。现场的项目经理上升到了我们的领导，我们领导也很重视这个事情问我情况。当时搞的我压力很大，领导也让研发的版本经理牵头成立专家组，攻关问题。在大家的共同努力下，问题终于得到了解决。从这件事情中，我总结下来的收获：第一，对于每一件发生的事情，都要深度思考，思考后续可能发生的事情并对这些可能发生的 事情做好准备。比如让我们去客户现场调测设备，会不会出现客户在场想要看整体业务开通的情况？如果会，但是当前系统能力不具备这种能力，应该怎么办？如何给客户答复？第二，当进展遇到阻塞时，应该怎么办？其实一线的经理会直接上升到领导层面，你理解了他的逻辑之后，对自己后面的所作所为也是一个指导。那么，当这种进展阻塞的情况出现时，就要及时通知到部门领导。让他们有所准备，不要突然被搞的很被动。这样，领导处理起来很从容，对你的印象也就很好了。第三，自己的准备其实还有加强的地方。比如，要清楚的知道项目经理的目标是什么。他是要让业务端到端开通，那么整个项目的目标也就是这样的。所以，站在这个角度，反推对我们产品的期望，就知道自己做到什么地步才是符合要求的。