不知不觉时间过得非常快，转眼从毕业出来工作已经有四年之久了。我从毕业出来之后，就一直在华为工作，在华为的这些年，遇到了许多有趣的人、有趣的事，大厂之大可能很多事情外人也不了解，只是觉得华为是个光鲜亮丽的光环，但事实并没有表象上看到的这么美好，这背后的辛酸只有亲身经历了才知道，很多时候哭着哭着也就长大了，偶尔能够笑一笑，就已经是很开心幸福的事情了。

在华为待在四年也算是在舒适圈内了，也许再坚持干多几年，钱也有了，后半辈子也不愁了。如今跳出了这个舒适圈，面临更多的挑战，但是人生的下一个篇章也许就要展开了，面对新的环境、新的同事、新的岗位，我的未来又会何去何从呢？

在这里，我尝试着将我在华为四年的工作经历做一些总结，不仅是留下一份档案，也鼓励一下未来的我，不管未来的路如何选择，我希望自己能够拿得起，放得下，不要后悔自己的选择。

一、去光产品线搞通信去了

毕业刚进华为，当时选择岗位的时候，在HR的游说下把调剂我到别的产品线，当时想着先进华为再说，也就这么被迷“忽悠”下进了传送与接入产品线，做解决方案测试。

这对于我来说这个是一个全新的领域，因为我不是学通信出身的，对传统通信领域这一块的认识可以说是一张白纸，不过既来之则安之，我抱着学习的心态，从头开始学习网络通信的基础知识，其中就涉及了三大领域的知识——数通、接入网和传送网，部门也有详细的培养计划，对于新员工要学习相关的课程，每个月要定期汇报学习进展，最终转正答辩之后才算正式转正。

当时还特意搞了一个知识地图，整理了一下，结果里面90%都是我没有接触过的领域。之前在我的脑海中，网络是《计算机网络原理》里面讲的OSI的七层模型，以及为事实标准的TCP/IP四层架构的模型，所谓的链路层、网络层、传输层和应用层，但实际通信行业，在实际工作中更关注物理网络架构，也就是由一台台设备、站点互联而构成的接入网、传送网、骨干网和核心网。

我们办公地点的楼下是一个通信实验室，也就是一个硕大的机房，第一次进到机房的时候整个人都惊呆了，因为机房里摆放的不是普通的电脑，而是密密麻麻的服务器、机柜，以及庞大的接入侧的OLT和承载网的OTN设备，机器运行的轰鸣声震的耳朵嗡嗡的响，入场必须要戴上耳塞，否则待10分钟都会让你心脏难受，血压升高。

盘根错节的网线和光纤在机房里肆意游走，一台机器上就有很多块板，而一块板上又有十几个口，每个口上都插满光纤，密密麻麻的光纤就像迷宫一样，让人很容易迷失在里面失去方向。我们常常需要使用专门的激光笔，来从这乱麻中找到光纤的位置，给光纤的一端打上标签，标明它的用途和对端所在的机柜位置。我们曾经一起搬过一台传送网的设备OSN9800 M24，我们想把它搬到机柜上，可是三个人都搬不动，最后实在不搬动，请了搬家公司的两个身强力壮的人过来搬，才把这台看上去不是很重的设备上到机柜上。

虽然这听起来是个体力活儿，没什么技术含量，但是对于我们的岗位来说却很重要，因为搭建镜像环境是执行测试的基础，我们必须要精确无误的还原现网的网络环境，才能进行解决方案的端到端的验证，复现现网问题，进行功能性、安全性、DFX等验证。我们同事之间经常互相调侃，世界上最远的距离是，我在楼上坐在椅子上测试，你在楼下搭环境，要不今天你去搭环境？

我的裤子脱下来给你穿

我印象比较深刻的一个项目是P2MP(Point to Multi Point)，也就是点到多点的项目，还因此出差到惠州，支撑惠州移动试验局的项目，而这也是我人生中的一次出差。而令我印象深刻的，还是这次出差闹了一个特别有趣的笑话。

当时和施工队那边约好了下午到企业园区作业，但是施工队并不清楚园区有硬性的着装要求：干净整洁，不能传短裤，而施工队一天跑几个站点，穿着简陋，汗臭味浓，衣服裤子都是粉尘，导致无法进去施工，被安保人员拒之门外，即使是领导打电话和企业园区负责人沟通，仍旧不允许入园。当时是陷入了两难的境界，尤其是施工队师傅，情绪很激动，觉得受到了歧视，打算撂担子不干了。

当时时间紧迫，按照进度施工队的跳纤必须今日完成，完成后，我还需要入驻现场，部署仪表进行打流测试。施工队去购买衣服或者换一批施工队，时间肯定是来不及的。所以，我当时我灵机一动，当然也是想不到其他更好的方法了，于是我跟师傅说，“师傅你穿我的裤子进去吧”。后面给同事讲起这件事，都觉得特别搞笑。

测试这份工作，也许没有开发这样钻研底层架构这么深刻，在计算机行业的黑话中，测试是在鄙视链的最末端，实际上我并不这么认为，测试也有它可以做到极致的地方。在测试设计时要考虑未来可能应对的各种场景，在测试执行时要严谨而细致，忠实客观的面对测试结果，有较强的信息整合能力，能够撰写好的测试报告，另外测试工作中必不可少的沟通能力也很重要，而且还要能吃苦，有体力，毕竟上山下乡，下机房也是常有的事。

二、干回了老本行，安全运维开发？

华为喜欢强调干一行爱一行，但我还是感觉不太喜欢做测试的工作，一方面是所在的产品线跟所学专业不太相关，属于传统的CT领域，而我更倾向于IT领域，另一方面，测试这份工作比较被动，接触不到核心的代码逻辑，你只能提出问题，但是不知道问题发生最本质的原因是什么，即使发现问题也没有解决问题的主动权，就显得很被动，而开发人员有着解决问题的主动权。

于是在机缘巧合下，在同事的引荐下，我认识了GTS的安全架构师老傅，他说他在搞安全运维大数据平台，跟我的专业匹配度也比较高，一方面是信息安全，另一方面是大数据，我也表示很感兴趣，于是就通过华为的内转途径，到了新的部门，从事安全运维的开发岗位。

刚来的时候，以为会马上上手搞安全运维的平台，结果发现原来只是一纸PPT，那时候的的运维平台是一个叫做iDOE的运维平台，主要的功能还是帐号管理、告警&监控、工单、自动化（部署、巡检、故障处理）、统一采集框架这几个模块，集成在平台上的安全能力是基本没有的。那时候，功能基本都是基于技术中台的ADC(Application Developer Center)，也就是应用开发中心去开发的功能，用的是比较热门的无码化/低码化的开发模式。简单来说，就是平台提供了相应的组件，可以通过托拉拽的方式去编排前端页面，而后端的接口与服务也可以这种方式实现快速开发，我们把这称之为无代码化，简称无码化；而除了托拉拽的方式，平台也提供能力可以编写自定义的脚本实现较为复杂的功能，这就是低代码化，简称低码化。

我也是后来才知道，老傅也是刚来部门不久，今年的重点任务就是安全运维的能力构建，因为目前iDOE的安全相关的运维能力太弱了，主要安全作业还是依靠人工，各类安全服务主要依赖华为云，以及一些三方厂家，游离在不同的平台无法统一运维，并且需要要定期通过手动导出告警、报表等数据，用Excel统计和分析数据，以周报月报的形式抄送相关部门给予通报，耗时耗力，一直被诟病为人肉运维。

万事开头难

构建安全运维平台的第一步就是需要有一个趁手的工具，基于技术中台的低码开发技术，适用于快速开发的简单场景，不适用于安全运维这种复杂而多样化的场景。所以当时老傅手下，还有一员大将军哥，是一位技术大牛，着手基于Springboot框架去做一层封装，封装一些常用的能力，后来这个微服务的框架就叫做Neuron。

低码开发	基于SpringBoot开发微服务
主要使用JavaScript语言，弱类型，不利于制定编码规范	使用Java开发，强类型，利于指定编码规范
适用于小规模项目，不好做模块化	面向对象的思维模式进行建模，工程易于抽象、复用和重构，能够支持大型项目和合作与开发
全栈式开发，一人完成前后端的开发	专注于开发后端，前后端分离
只能在平台上进行调试	可在本地起服务调试
主要面对非专业的编程人员也可上手开发，可快速开发	对开发人员的专业素养要求较高，开发难度较高
支持简单场景	可定制化复杂场景的开发

我也看过Neuron框架的代码，第一反应是水平实在是高，有两三层这么高，而且代码写的非常优雅，让人看完神清气爽，但理解起来就不是那么好理解了。Java的下限可以很低，低到写一个接口，写一个Service，写一个Controller；但Java的上限也可以很高，你可以用Java写框架代码，自定义各种注解，定义泛型的方法，利用Java的多态去定义接口，这里面真的有很多高阶的技巧，不仅仅只是实现功能那么简单。

写框架代码一般是作为公共模块给其他模块使用，像Neuron框架就是作为其他微服务必须依赖的基础包，就会涉及到很多微服务的调用，这里面考虑的东西就需要比较严谨，我这里举一些例子抛砖引玉：

• 考虑兼容性：框架代码更新时必须考虑高版本向下的兼容性，废弃的方法、接口和类不要直接暴力删除，可以打上@Deprecated注解进行标识，方法的修改需要特别注意。至于我自己就踩过这个坑，给一个方法多添加了一个入参，结果导致引用这个方法的微服务都出现了异常，直接就是严重问题
• 善用枚举类型：对于框架代码许多方法的参数，不要使用魔鬼数字，比如int类型，尽量考虑使用预先定义好枚举类，大大提升了代码的可读性与易用性，像许多三方件的SDK，也是很喜欢定义枚举类型，不需要注释，光通过枚举类型也能了解参数的含义
• 善用多态：同样的方法名可以用不同的参数组合，提供给其他模块调用，有的参数多一些，可以有更多自定义的空间，而有的参数少一些，对于一些基本参数则赋予默认值或者是空值，方便其他模块的简单调用
• 恰当的定义参数变量：当参数过多，一般大于五个时，会导致公共方法不那么好用，此时就要考虑合并类型相似的变量到一个类中，并起一个辨识度高、好理解的名字，便于其他模块调用。我曾经在框架代码中写一个告警发送与确认的公共接口，就又遇到参数有30+个的情况，这时候就需要定义合适的参数变量，将相关联的参数合并在一个类中，同时还需要筛选出告警接口中必填的几个参数，并不是所有的参数都需要用的，而选填的参数则在方法中赋予默认值

虽然框架代码很高深，但是并不影响使用，就像你可以不用深究Java的源码你也可以使用Java是一个道理，许多方法已经被封装为一个个类，你只需要了解这个类中有哪些方法可以使用，它的入参出参是什么，适用于什么场景，有什么限制条件就可以了，就像是站在前人的肩膀上，你可以看的更高更远。

安全运维业务面面观

既然我们现在有了一个趁手的工具，那么我们就可以着手建房子了，如果说把安全运维平台比作是一个城市，那么这座城市应该如何规划？这就属于安全运维业务的范畴了，建城市需要有城市建设规划图，建房子需要有房屋规划图，那么安全运维业务也需要有业务规划图。那么如何规划呢，最好的方式就是参考业内标杆，阿里云、腾讯云、AWS、微软、谷歌这些前辈，参考自身SRE的运维场景去规划安全运维平台需要有哪些功能。

安全运维业务除了功能特性的划分，还有角色权限的划分，不同的角色各司其职，肩负不同的职责。

• 安全运营经理：安全运营中心的核心角色，负责安全运营工作的管理和执行，能够统筹执行安全运营的各项工作并有效实施相关措施，由安全运营经验丰富的安全专家担任。
• 安全运营专员：安全运营的核心角色，主要负责安全运营工作的执行，能够有效实施相关措施完成安全运营工作，由安全运营专家担任。
• 告警分析员：分析和处置安全威胁相关数据，利用分析工具和技术来判断、分析安全威胁，为安全运营团队提供威胁情报和建议。由经验丰富的安全分析师担任。
• 风险分析员：分析、处置各类安全风险，能够有效推动各类安全风险修复并指定加固措施，并为安全运营团队提供资产安全防护建议。由经验丰富的安全人员担任。
• 安全系统维护员：负责维护和管理安全设备和系统，能够有效实施相关配置和管理措施，并可持续键控和维护这些系统。同时能配合安全运营团队完成安全措施的执行。由经验丰富的运维人员担任。

在安全体系架构中，我们会将风险和威胁区别对待，风险可以认为是可能未来会引发损失和消极影响的因素，只是当前还没有发生；而威胁是已经发生的事情，就不如说黑客入侵事件，已经造成了实质性的后果。

除了安全运维以外，我还主要维护IDOE运维平台中账号管理的模块，这一块有大量的遗留资产（屎山代码），偶尔也有会一些需求需要做。主要涉及帐号权限申请、帐号管理与帐号配置，对一些三方系统的帐号申请去做对接，同时将帐号纳管到运维平台上，做统一的管理。不同于安全运维的后端，是基于SpringBoot的Neuron框架的开发的微服务架构，账号管理这一块是基于技术中台的低码化进行开发的，这部分的技术架构可以说和前者是完全不一样的，前面也有提到低码开发和微服务架构的一些区别。

作为开发人员看到的一些问题

现在想来也是不可思议，我们整个开发团队，前后端加起来也就十人左右，中间还经历了很多人员变动的事情，但是总归磕磕碰碰，将大的任务分解下来，大事化小，小事化了，通过不断的小步快跑迭代，加上Neuron框架开发起来非常高效，两年下来大体的功能也都实现的基本差不多，期间和可信使能部的人合作，也一起合作开发了许多功能特性，微服务的数量直接增长到了十几个。

但这同时也带来了很多问题，就是这两年来我们主要在堆砌特性功能，缺乏对用户体验的打磨，这也导致了我们的客户，SRE运维团队抱怨连连，经常bug很多，数据同步不准确，功能不易用，没有达到心目中的标准。这也导致了测试团队压力非常大，后面就不断通过提高测试标准，卡门限的方式，督促开发团队提升产品质量，这也导致本来需求堆积严重的开发团队也怨声载道，开发和测试的关系愈加紧张。更加火上添油的是，公司安全可信的达摩克里斯之剑越来越锋芒毕露，各种可信安全的整改，导致许多要求逐渐变味，QA的教条主义，也导致了许多规则有些过犹不及。

包括但不限于以下问题：

• 评比检视意见的数量，本来是鼓励大家多提意见，结果演变成了大家刷数据刷榜
• 每月统计各种黑事件，邮件通报部门，导致大家互相甩锅，开发也畏手畏脚，生怕被通报
• 三方件的整改流程繁琐挤占开发时间
• 各类安全漏扫平台职能重复，扫出的许多安全问题，误报率很高，但是需要花大量的时间让开发来排查
• 无视功能影响的重构要求，很多代码坏味道，比如重复代码、重复的类、数据泥团、循环依赖等等，确实是需要主动重构，但是经常为了指标无视工程体量和功能影响，直接大规模重构，结果导致不可估量的事故

许多规划的东西也许只停留于纸面上，对于我们研发人员来说，我们要具备将图纸化为现实的能力。而作为开发人员这近三年的开发经验，让我认识到了那种理想与现实的割裂感，那便是许多管理者对底层研发人员的蔑视，他们天生就有一种优越感，认为底层的工程师就是可以随时替换的耗材品，而殊不知工程师们恰恰应该是最应该具有工匠精神的那一拨人，所谓工程师文化，那便是追求卓越与完美的理念，只有当他们信仰自己的产品时，才可能爱惜它、珍惜它、呵护她，才可能用心去做。试问一下，如果他对此感到反感，那又如何做出好的产品？

公司流程的安排，是基于商业利益之上，更高层面上的合法、合规、安全的考量，各种职位的高低，也是公司为了提升合作效率而设置的，只是苦了下面的研发人员，在这些繁琐的规矩中逐渐被磨灭了创造伟大产品的热血，最终沦为一颗没有思想只是单纯执行任务的螺丝钉。所以，我一直在反思，是否可以改善流程，既能保证研发人员的自由和效率，保护他们创造的热情，同时也保证产品的合法、合规和安全，我相信会有更优的方法的，只是需要我们不断去探索与实践。

安心磨好自己的豆腐

管理的事情，是一个非常纷繁复杂的混沌系统，其中牵扯许多的利益方、人性、政治、法律这些东西，甚至可以说没有一个很好的模型去描述它，对于我们来说，也许就是安安分分磨好自己的豆腐就行了。所以，在认识到这些问题对我而言，并没有更好的办法去改变它，我认为把自己的职业和本分做好就可以了。

在安全运维团队待了一段时间之后，随着经验和能力上来了，我也渐渐承担起更重的担子，比如说作为MDE，负责的东西不仅仅是开发了，还需要承接来自SRE的需求，参与需求分析与设计，评估工作量，分解需求，以月度为周期，进行敏捷版本交付，会有更多版本上的事情要操劳。

另外团队建设上也提出了更高的要求，完成手上的工作只是本分，还需要为团队做贡献，比如说：

• 带新人熟悉环境，融入团队，部门定期会组织技术分享培训，也会被分配议题做专题研讨，技能传承
• 作为Committer，MR代码检视，定期团队代码评审
• 作为现网问题接口人，处理各类现网问题，区分问题和需求，问题走问题管道，需求走需求管道
• 每月版本清理CodeCheck指标，清理漏洞，召开漏洞评审会议，做三方件升级这些公共事务，大家也都分下来大家一起扛

所以说事情会多很多，杂事也不少，那种能静下心来写代码的时间越来越少。因为随着职级越高，需要看得更远，对你的职业素养和要求也就越来越高，承重也越来越大，不会说还是干跟以前一样的活儿。在华为有个词用的很多，也很有意思，叫做“拉通对齐”，顾名思义，拉进大家的距离，通一通气，对齐一下颗粒度，可谓一个词就概括了沟通交流的精髓。在华为有很多“拉通怪”，你别看他不干什么实事，但是天天在那里指手画脚、口吐芬芳，但是职级却不低，他其实也是有他的价值所在，只是衡量的标准不同罢了，很多进度的推进、资源的调度和项目的运作，恰恰靠的就是这些人做的，我们不能以我们Low Level的角度去评判他，大家发挥各自的特长，才能把事情做好。

令我印象最深的项目

如果要说让我印象最深的一件事件，就是参与了可信使能部的RASP的项目。

我的一个同事进RASP项目已经一年多了，但仍然对很多代码还是不理解，RASP的工程代码就像是一个框架层，支持你在上面去开发插件包，将插件包加载到框架中，框架就会作为一个javaagent，去对Java虚拟机中的字节码去做拦截和修改。开发插件包本身并不是太复杂，就跟前面说到的Neuron框架一样，按照预设的模板去开发和调试就好了，使用起来并不复杂，而真正复杂的是框架本身。

但相比于项目而言，我印象更深的是认识了一位非常厉害的专家源哥，在于他共事之前就已经听说过他的大名，被称为GTS产品线的第一严格、华为Java编程规范的制定者之一，曾经听说有位同事找他合代码，MR愣是两个星期都没有合进去，提了30多个检视意见，改的那位同事心理崩溃给整哭了，后来是在产品经理打电话的催促下，在版本发布的压力下，才让代码合进去。

我看过RASP的代码，基本可以说像天书一样，而这个项目的核心代码都是源哥写的，这让我非常佩服，因为我能意识到我和他的差距真的是太大了，智商好像不在一个层次上。有些东西好像并不是靠努力就能追赶上的，越是深入某个领域，越是能体会到这种感觉。就是那种你可以追赶，但是永远只能看到他的背影的感觉。

我有幸领教过源哥的亲自指导，他不会放过代码中每一个单词的拼写和命名、不会放过每一个空格与空行，更不会放过每一个方法、每一个类。

他对编程规范有着近乎严苛的标准，对每一行的代码实现有着完美主义的追求。

他不仅严于律己，也严以待人，他是有“工匠精神”的人，对代码有着偏执的信仰，不会为了版本和指标而妥协，更不会为了讨好他人而放低自己的标准，因为他坚信存在着某个标准，在那个标准中一切都是完美而和谐的。

每一行代码他都会仔细看，是否有更好的写法，是否这样的写法就是最优的，你再去思考一下有没有更好的写法，你这个UT写的没有意义，这样写是不是可以更好。甚至有的时候，他会直接丢出来一个git patch，“我写了一个代码样例，你照着这个改吧”，基本就宣告了你的全面阵亡。

感觉他像电影《爆裂鼓手》里面的乐队老师，

“没事，每个人都是被骂起来的。”

“有时候我想骂人，但是怕打击人的进取心，所以有时候我就忍着。”

就像亚洲的很多家长一样，认为孩子就是要打着骂着成长起来的，之前B站上还看到有人调侃到，魔鬼难度之上还有个Asian难度。这我不想用我的价值观去支持或者反对这样的做法，毕竟也有在这种环境下坚韧成长起来的大树，我只是想表达一下我自己的观点，那就是每个人的身心健康比功成名就更重要。

三、从研发到一线

有次部门领导找我聊天喝咖啡，问我想不想到一线去发展，部门正好有输送的指标，我考虑了一下，也想去试一下，我是一个喜欢挑战的人，我认为去一线行销体系，不一定是坏事，不像很多人认为研发输出到行销就是背指标，毕竟发展方向不一样，研发这边要求对某项技术要钻研的深，而行销体系更重视人与人的交互。

于是在领导派我去西安学习了半个月业务之后，我转入了战略预备队，经过为期两周的军训和课程培训，我顺利来到了中国区的共享业务交付部报道，我来新部门的时间不长，也就只有短短四个月，但是这四个月的时间，我被派往了泰国支撑本地运营商AIS的数字转型项目，还是收获颇丰。

在海外的第一周是最难熬的，人生地不熟，而且语言又不通，一个人躲在被窝里哭，压力大到想吐，但是好在我的适应能力还算比较强，第二周开始就感觉适应多了，慢慢上手业务之后，也感觉没有那么难了。

在国外工作给我最大的感受是，学习了多年的英语终于派上用场了，第一次去国外出差，让我认识到了英语是多么的重要！和客户沟通要用英文，问路要用英文，买东西吃饭要用英文，哪里都要用英文，要不然就无法和别人交流。在国外出差两个月的时间，学习到了非常多的项目运作的知识，也发现一线和研发差别非常大，一线需要直面客户，面对面和客户交流，要直面客户对方案的挑战，就像是炮火纷飞的前方阵地，但如果能解决客户，获取客户的认可，压力立马就消失了，马上神清气爽。而研发位于战场的大后方，远离战场，面对的压力不是那种直接的，而是那种跟随版本交付的有规律的压力，像是按摩椅，一阵一阵的给你来一下，一直会在那里一直压着。

我之前一直以为，我是适合做研究的那种人，但是尝试了新的岗位后，我发现自己也有做一线交付的潜力，自己还是有social的潜能在那里，所以有时候尝试新的岗位不见得是坏事，可能会发现自己新的潜能点，不要畏惧困难和未知的事物，勇敢去接受挑战就好了。

四、结语

四年的时光，相当于一个大学，三分之四个中学，六分之四个小学，三十年人生的十五分之二，希望一切安好，愿自己重新上路，走一条属于自己的路。路漫漫其修远兮，吾将上下而求索。

本博客文章除特别声明外，均可自由转载与引用，转载请标注原文出处：http://www.yelbee.top/index.php/archives/199/