2014~2017 的一些项目
一些项目的流水账，在一个个项目中成长，而一个个项目也决定了我的未来。
某科研院所园区新建项目
刚入司的第一个目标是学习 Cisco 安全，所学知识在这个项目里就用到了，所有安全设备的安装实施由我来负责，核心设备的安装也有我来，过程非常顺利，直到后来，同事重做了我安装的核心设备…
这就需要谈到理论和实践这两个词。
不得不佩服 Cisco 是家伟大的公司，产品设计领先，官方文档也非常好，即使没有什么资源，也可以从官方文档里学到很多知识，和”最佳实践“。
网络的核心是实现端到端连通性，为了保证连通性通常需要各种冗余，从设备内到设备间，随着网络演进出现了一大堆高可用相关的技术，VSS 就是其中一种，后来很多交换机或者其他设备都具备类似 VSS 一样的软堆叠方案。
这种方案在文档中描述很全面，无论是功能还是防脑裂都有详细的文档记录，因此在项目之初我想都没想用了这种架构，这种架构还有个好处就是可以使用 LACP 等链路捆绑技术，链路冗余也可以做的很好。
之后大概一个月听说现场工程师把 VSS 拆了，换成了传统的 STP+VRRP 架构。
有次在公司技术分享会上，谈及这部分的设计，我举手问为什么不使用 VSS，根据文档看能够最大程度提供高可用，保证故障发生后快速切换。技术总监听到这个问题，耐心做了解答，大致记得他说：”经过多年的实践，STP+VRRP 是最可靠稳定的，而 VSS 会碰到切换时间长的问题，造成网络长时间不能恢复“。
后来简单分析过背后的逻辑：STP+VRRP 下始终是两台大脑在同时独立工作；而 VSS 下是单个大脑，另一台即使是热备，大脑切换也需要时间。
这就是理论和实践的差距。往往一个传统的技术，即使配置可能会复杂，也可能有些限制，但是它就是很稳。
多年后我一直记得这个事，几年后还真碰到过 H3C 设备 IRF 脑裂问题，或者设备重启丢配置等问题，没有大脑的设备恢复起来也是异常麻烦…
下图：客户买的思科设备，做工精良
某城商行核心 N7K 引擎扩容项目
这个项目一开始比较出乎意料，因为一般核心网络设计一定是各种冗余，但这个项目里核心设备竟然用的单引擎。
后来打听了下，原来项目规划的是双机单引擎板，有了双机，单引擎这种额外的冗余显得就没太大必要，但是有次银行做灾备演练时发现竟然没切成功，造成业务中断。返回来查时发现某些汇聚是单线接入到单个核心，并不是像理想的状态双线接到两个核心…
这个问题一时半会儿没办法解决，只能给所有核心设备增加引擎，提升单机的可靠性…
这个项目的难度还是有些高，主要问题在于新购买的引擎软件版本低，已有设备软件版本高，还得先去升级新引擎软件版本，再做扩容，而 Nexus 这种百万级的核心设备基本找不到备件来做降级以及测试验证。于是实施前花了很长时间啃文档，完善实施流程。另外割接时间只有 2 小时，在银行的灾备演练之前进行，如果我的工作完不成，会直接影响后面的灾备演练，一堆人可能都会白来现场。
即使准备的万全，最终还是翻车了，碰到两个坑：
第一个坑是给引擎升级完软件后，发现系统竟然报内存不足，后来看到原来引擎配置了 8G 内存，而新的引擎配置了 4G，新版本的 NXOS 需要 8G 才能跑起来。之前设备采购谁都没想到这个问题…
另一个坑是在做引擎切换时，原来的引擎竟然挂了，起不来了，后来根据日志判断是内存坏掉了，最后没办法只能把新引擎的两个内存条都拔下来换上，最终进行了回退。
后来和公司前辈反馈了问题，根据经验判断是某个年份采购的思科设备均有内存问题，断电重启后内存会挂，后来在一个运营商的项目也碰到了，几年后我和思科的人聊起往事，他也承认了这个事实。
有了前车之鉴，公司 PM 立马加急采购内存，为了防止意外发生，额外采购了 2 条 4G 内存 ，最终证明该来的还会再来，第二次割接时另一台 N7K 的内存也挂掉了…
这个项目工作量并没有多少，但是我一个人独立完成的第一个项目，还记得割接前在监控室几十个人在等待，他们能否早早回家取决于我是否顺利割接，也记得第二天凌晨，出门的时候牛肉面馆已开门，吃个早饭安心的睡了。有辛苦，也有收获、认可和满足。
下图：每次到了兰州，都得来个拉面加个蛋
某园区新建项目
介入这个项目时，实际上实施已经有一段时间了，一来项目缺人，二来碰到虚拟化的一些疑难杂症，项目上亟需外援。
开车和 PM、总监、其他小朋友一起到了现场，第一件事就是解燃眉之急，为啥同一批服务器，同一批网络设备，有些服务器网络通，有些不通，找不到任何规律。
已经忘记的排查思路是什么样的，只记得检查过软件配置没问题，然后去测交换机直连服务器时，发现网络通了…
之后一一测试发现，只要直连网络就能通，进而推测是配线架搞的鬼，后来丢给总包，找师傅重做配线架去了。
在这个 Case 里，会发现真实世界的排错并不是独立掌握好一门技术就好，曾经试用期学的虚拟化帮到了我，之前各种实验对我的排错思维敏感度提升也有一些帮助，或者换句话说，知识广和知识深同等重要。
在这之外，项目里基本涵盖了常见的各种思科设备，N7k 当核心，C45xx 做汇聚，无线全家桶，一个项目下来收获不少。
项目里还有一件事让我耿耿于怀，当时总包 PM 是个黝黑的小伙子，很年轻，一开始的时候很是佩服他的胆识，直到他当着我的面，开始质疑我的技术…
也不知道是不是出于年轻人的冲动，我打心底里不想再支持他的项目，后来迟迟没给他一些测试报告，结果闹得不咋愉快。
就像《头脑特工队》里的场景一样，不愉快的记忆有时候反倒印象深刻，如果当时的我不在乎那些评价，或许是另一种结果。
某公司的无线网扩容及改造
这是我做的第一个也是唯一一个无线项目，伴随着无线项目，还有一些遗留的 PIX 防火墙、ASA、专线。
这个客户应该是 2015 年开始接触的，最早是在他们办公区卖上网行为管理设备，第一次接触这类设备，当时对于国产设备能实现的功能感到惊叹，能上什么网站、不能上什么网站都能进行控制，设备能够识别的协议也很丰富。也是这个项目，让我接触到了老早已经淘汰的 PIX 防火墙，曾经只是在 CCIE 的培训中接触过 PIX，因为当时模拟器还只能模拟 PIX 防火墙，所以多少熟悉一些，项目整体顺利，只是在未正式上线前出过一次小故障（可能和当天另一个变更有关），导致所有用户无法上网，为了这事还专门去总部和领导汇报，当时并不觉得这是多大的事。
回到无线项目，公司在 2015 年的思科网络项目还算比较多，不过来来去去也就交换、安全、无线三类设备，公司有闲置的 WLC（无线控制器）和 AP，于是早早地玩了下，还测试过 ACS 对接之类的，所学基本都在这个项目里用到了，为了这个项目，其实也没少加班去看文档，做验证。
项目本身不是特别复杂，但从没人这样做过，大概背景如下： 客户有三个园区，之前有两个地方布置了无线，现在想在第三个地方也安装无线。原来的系统都是独立的，使用本地认证，所以这次项目除了扩容无线，也想做一下统一管理，实现三个地方的用户漫游。
这里面牵扯到三类系统，AD/DNS，ACS 和 WLC，三个东西加一起有一定难度，但如果有环境多做实验，学起来也快：
- AD/DNS：公司在本地并没有 AD，所有用户都在总部的 AD，所以此处只是去申请 AD 权限，为无线用户新建 OU，把相应的用户加进来
- ACS：在新大楼部署 HA ACS，为三个中心提供统一 AAA 服务
- WLC：新大楼部署 HA WLC，其他两个地方部署单节点 WLC，但是所有 WLC 在一个组，所以当单节点设备故障时，AP 可以连接到其他 WLC，保证无线网络始终可访问
这个项目最终比较顺利，一个项目下来和客户关系也比较好，个人认为还是技术上得到了客户认可，后续两年有很多零碎的事基本都是我来处理，包括 PIX 换 ASA、多线路路由调整、二期无线系统优化、ACS VM 迁移、某业务故障转移集群部署等。某种程度上来说，我成了客户的运维。
这些零碎的事并非全无价值，可以看到涉及的面比较多，也基本和我知识的转型匹配。
这里很多事情也比较轻松，基本在下午下班后都可以进行，很少熬夜，工作时间也不长，有些不影响网络的变更在上午或者中午就做了，下午可以提早回家，所以一直以来也比较喜欢跑这个客户。
不过不好的地方就是收益不大，每年靠维保和零碎的买一些设备，还投入这么多人力，在公司层面其实算是亏的，不过这也不是我关心的，领导没去想这些，我更没理由去想。
差不多在 2016 年，我们对一期的无线项目做了改造，原因还和之前的设计相关，我们发现虽然 WLC 之类的都有高可用，但 ACS 只在一个中心，当中心间网络阻塞的时候，某些地方的无线认证会失败，所以最终还是在每个地方都部署了 ACS，多组 ACS 间做配置同步。同时也对广域网路由做了调整，保证三个中心间全部是双线（MSTP 专线+IPsec VPN），这里面其实已经牵扯到最早的 SDWAN 解决的痛点，多中心加多链路的管理痛点。
某单位核心网改造及机房搬迁
这个用户是我第一份工作花时间最多的用户，一切都起始于他们的机房搬迁，伴随着机房搬迁，有一笔新的费用想把之前大楼的思科设备更换为华三。
客户有两个部门，一个系统部一个网络部，但总共加起来也就 3 个人，这个项目是网络部门主导。
项目有两个难点：1、设备间兼容性，2、尽可能不断网割接
最终定下来的方案是先在新机房安装新的核心，将原有核心的配置进行翻译后配置到新核心（包括路由、Zone 防火墙等），然后跳线连接到原有的核心，接着逐步进行每个楼层设备的更换，将其连接到新的核心，最后再做网关的割接。
整个项目大概持续了三个月左右，中间很多时间花在排错，比如配置缺了、网线年代久远，达不到千兆、网络因为各种原因不通、思科和华三设备间生成树有问题等。
期间有个大楼的项目还返工，原因是距离超过 500 米，但实施方没注意用了多模光纤，最后只能重新布线，加购单模模块。
总的来说项目算顺利，在一个已有的环境中做改造，必然会碰到各种奇怪的问题。
这个项目唯一的损失，是在现场丢失了一副刚买的 Bose 降噪耳机（二手的），为此心疼了很久。不过耳机的保护袋最后被我拿来做卡包/钱包，到现在也已经用了快 10 年，虽然仿真皮有些破损，但照常在用。
紧接着网络改造的项目，便是虚拟化的迁移以及改造项目，这个项目对我之后的发展至关重要。
公司领导比较关注这个项目，想做一些创新，刚好资金也允许购买一部分的 VMware 原厂服务，来统筹新数据中心的设计。
VMware 原厂请到了前员工 T，T 是我刚入职时另一个小伙伴的堂哥（惠普过来的那位），可以说是他让我间接学了 VMware 虚拟化，刚好这个项目的客户是我负责，我也有一些虚拟化基础，于是顺理成章的，和他一起来做项目。
这个项目中，T 并不像往常一样会全程参与做设计和实施，而是更想借这个项目来培训前东家的技术团队，所以项目的很多文档都是由我来写，他进行培训和指导，最后也由我来实施（部分产品除外）。这一切都是值得的，经过这个项目，我很快了解了业界最新的技术（网络虚拟化 NSX）以及最优的技术架构。
记得这期间有几件小事：
1、写完设计文档后给甲方汇报，结果因为之前很少公开发言，开始很紧张，于是 T 接过去自己讲，T 非常善于表达，逻辑也很清晰，那个汇报我学到了很多，也知道了自己与原厂之间的差距；
2、牵扯到虚拟化网络相关设计时，T 发现当前的架构并不是他预期中的（这与我对数据中心 Spine-Leaf 架构理解不深有关系），于是他拿出几只水彩笔给我讲解理想中的架构，之后我很快就理解了他的意思，快速去机房配好了交换机。自这之后，我也继承了他用彩笔画图的习惯，做项目或者讲解东西真的很高效；
3、项目中客户购买了新的存储交换机，需要我们来实施，因此前从未碰过这类设备，于是请来外援（专门搞系统的同事），他来了之后发现项目中的设备他也没碰过，只能两个人一起查文档，摸索着配置，最后还是顺利配好了，总结就是这玩意比路由交换简单太多；
4、当时每天基本 9:30 左右到客户现场，中午去楼下德克士吃个套餐，来杯咖啡（偶尔去远处的 KFC），然后回办公室趴桌子上午休一会儿，晚上下班后等高峰期过后，再去隔壁街吃个快餐（最喜欢蒸菜），然后坐着公交晃悠着回家。一段时间后，甲方信息部副总发现总能看到我在办公室，有次见我领导时还连连夸奖，说我对项目很重视，一直恪守现场。
这个项目对我来说是比较轻松的一段时间，早期繁忙的实施过后，基本只是零碎的故障处理、做一些优化、写一些文档之类的，我也在这段时间学习了之前不熟悉的产品（云管理平台）。
在 2016 年一期上线后，和我一同负责这个客户的售前了解到一个新商机，客户有个大数据计算平台要上，需要新的计算和存储资源，刚好赶上 VMware vSAN 6.0 发布没多久，这种分布式存储天生具备大容量、高性能和可扩展的特性，很适合客户的这个应用，于是我和售前一拍即合，他负责借硬件，我负责实施，很快搭建好一个平台交付给客户测试。
开始测试的第一个月很顺利，结果第 30 多天突然出了故障，分布式存储的一个节点故障了，故障原因不明，当时并没有正式下单，于是通过关系找人排查了下，发现与硬件兼容性有关，这时我们才发现，vSAN 对于硬件有着很高的兼容性要求，HDD 和 SSD 的固件和驱动都得是指定的版本，更别说型号…而我们用的刚好是不知名厂商的 nvme…
好在第一次故障后节点重启竟然就没事了，虽然不兼容，但，又不是不能用。
这次我们也长了个教训，既然一时半会儿借不到兼容的设备，那不妨给当前的测试系统做个备份，刚好在同时期，veeam 火起来，也来我们公司宣讲过，于是二话不说，给客户部署了起来。
20 余天之后，果不其然，故障再次发生，而且比上次严重，在单节点故障后，第二个节点也发生故障，三节点集群彻底崩溃，回天无术，只能通过两天前的备份进行恢复（数据量实在太大，一次备份得耗费十几个小时），最后虽然丢了一些数据，但好在业务系统不用重部，业务侧表示当前实际已经进入预生产，很难再容忍故障，于是只能督促销售团队，快速完成软硬件采购，正式交付了这个项目。
还记得最终上服务器的时候，拿到了 Intel 数据中心级 nvme SSD 卡，一张就一万多元，真的感觉是手捧金子，小心翼翼。
从 2015 到 2017，相继在这个客户的项目里学习了 VMware SDDC 三件套 vSphere、vSAN 和 NSX，还学习了 vRA 及 UP 云管平台，这对我日后转型专做 VMware 意义重大。
在 2017 年快离职的时候，我把这个项目中所有的材料做了汇总，形成了一系列标准文档交给了同事。
下图：客户现场外的夜景
这个项目之后的事1
在这个项目实施完成后，公司想借鉴这个项目的成功经验，在同行业以及其他一些重点用户上去推广，我有幸参加过其中两个项目。
第一个是同行业的单位，在青海，我也借着这个项目去过几次青海，通常都是一起安排一些兰州的事，先火车坐到兰州，忙完兰州的事再乘高铁去西宁，那时候可能是出差多了有些疲劳，去一个城市顶多吃吃当地特色，也不会特别安排去某些有名的店，只是搜搜附近评价好的餐馆去打个卡。
这个客户虽然是同行业，但因为地域相对落后些，IT 水平也差一些，所以有比较重的历史包裹，对于新架构的接受度也相对难一些，不过即使如此，我们还是花了很多时间和客户一起去梳理环境，理出一个可行的改造方案。
可能是因为上个项目做的比较深，我在对 SDDC 的理解多了很多，在这个项目里，即使我不负责售前的事，但有时候和客户交流，我会自然而然地想去传递一些理念，会有一种想要分享的冲动，这和我一开始工作时的状态差异很大。
另一个项目在新疆，可以说是 1:1 复刻之前所做的事情，但是更进了一步，将单中心的方案扩展到了双中心。
架构有差异，所以设计也多了很多需要考虑的点，其中最重要的就是如何保证两个中心为业务提供最高的 SLA，因为客户的两个机房距离不远，所以我们最终推荐的是 Metro Cluster（延伸集群）的方案，即两个数据中心分别有自己的物理服务器，组成一个跨中心的大逻辑资源池，这种架构设计好了是可以不需要人为干预来实现做到站点级故障的自动切换的，而切换时间只需要几分钟，站在基础架构层看，这个项目很有前瞻性。
为了这个项目顺利，公司投入了很多资源，包括最优秀的 PM，专家组的各位成员，本地最资深的工程师，还有我这个“相关经验丰富”的工程师，虽然几年之后得知这个项目并不“顺利”，但在当时，谁能想到。
项目应该做过两期，从 2016 年下半年开始入场进行交流、测试，在此期间狠狠地学习了 NSX-v，对于其中的组件、原理理解的都比较深，在当时测试时还会发现过一些小的产品问题。
除了 NSX，也第一次测试了 vSAN 延伸集群，还记得 2016 年，因为第一个项目中碰到一些 vSAN 问题，于是读完了 vSAN 的所有设计文档和排错指南，还整理成一系列博客发布在了一些 VMware 的群里面，当时的积累再次在这个项目里用到。做技术就像升级打怪，一路排障一路学习。
整个测试和售前阶段都挺顺利，我们花了很多时间做验证，验证到自己满意为止，在测试完成后我和一位专家组同事共同完成设计方案，然后新疆本地的同事负责服务器及虚拟化的部署、我负责网络相关组件以及 vSAN 验证集群的部署，最终实施完也成功上线。
接着我就因为家庭原因离职，去了上海，这个项目交给了一个年轻的同事 Z（也是我曾经的室友）配合本地技术来做后续运维。
这个项目的不顺都是发生在我走之后，有时候真会觉得命运捉弄。
在我离职半年之后，我开始做一些 NSX 相关的宣传视频，有次新疆的那位同事微信问我，那几个视频听着像是我的声音，我说是的，然后和他寒暄了几句。
后来又因为一些事，西安的同事问我当时这个项目的细节，我回说新疆的那个本地同事最熟悉，为什么不去找他，这才得知，在我离开公司后不久，他得了癌症，而上次他微信联系我时，没有丝毫的迹象。再之后，就得知他已经辞世。
2018 年的某一天，同事 Z 联系到我，当时我刚好在外地出差，他用很消极的声音和我说，做一个升级变更时弄坏了环境，现在有些业务虚拟机丢失了，问我有没有办法恢复，仔细询问之后，发现他是为了图快捷没有严格按照产品说明来去维护，造成了集群中数据不一致，这种底层的问题我并不知道如何解决，只能让他去寻找其他途径来支持。
后来在杭州一次市场活动上碰到前同事，聊起这件事，说是这次故障造成客户的业务停了好些天，公司也做了一定赔偿给客户，那个数目挺大，一个人打工好些年才能赚回来。也不知道公司对 Z 的处罚是什么。
后来，Z 也离职了，从西安搬到了深圳，去了一家友商，看他干着还挺快乐，有次聊起天，还说这家公司特别适合我，做技术比较有成就感，希望我能过去，那时候我也有了自己的目标，于是婉拒了。
再后来，2019 年的某个晚上，我刚好在客户现场值守，接到了前技术总监的电话，说是 Z 自杀了，因为我之前和 Z 接触挺多，想从我这里打听些消息，很可惜，我和 Z 在一些事情上有过过节，其实在 2016 年之后就很少接触了，那天晚上，我的心里五味杂陈，我发了这样一条朋友圈：
“没有选择生的权利，可以选择死的权利。即使各种波折，各种不爽，在你做自己的那段时间里，仍然精彩。放下所有对你的成见，对你说一声，一路走好。也期望所有对不起你的人有所反思。”
我隐约记起他曾经和我诉述他爸的暴脾气，用皮带打他和他弟等等，我似乎感觉到了他的痛。
这个项目之后的事2
也许是因为我的网络背景，使得我成为公司做 NSX 比较合适的人选，而刚好项目里用到了这一产品，在 2017 年，刚好 VMware 有个 NSX Ninja 的活动，请老外来做 NSX Level 300 的培训，我顺理成章地去参加了。
第一个五天是 ICM（安装、配置、管理），第二个五天是 TS（排错），因为有项目经验，所以培训非常认真的听了，也学到不少东西，而大部分人，因为工作在身，可能会时不时去接个电话，或者半天一天的不来上课。
在课上也有另外两个很专注的同学，一位现在已经是我的同事，另一位一直在合作伙伴待着，发展也挺好。
这次的培训就像是给我的未来打地基一样，包括技术上的积累以及人脉的积累，2017 年离职之后，我到上海主做这个产品的推广，招我进来的人就是当时 Ninja 活动的举办者，而推荐我的人，是之前一起做项目的一位专家。
某公司 VPN 改造
这可能是我工作期间碰到最难啃的骨头，因为结局是花了两个周末，和销售说放弃了这个项目….
具体项目细节现在忘得差不多了，不过发现 2018 年竟然非常生动的写过这个故事，链接在此：
Horizon View POC
因为试用期时学完了 VMware 虚拟化，而当时因为工程师变化（由独立的项目部转为工程师下放到每个业务部），部门里没有其他多余的人来做 VMware 的项目，于是只能由我上，摸石头过河。
在 2015 年，我依次给三个客户做过 Horizon View 的 POC，第一个是做 GPU 虚拟化+ RDSH App（应用虚拟化，在同一个系统上运行多个应用实例，供多个用户同时远程连接来使用），第二个是办公桌面发布到互联网，第三个是 GPU+VDI。
在当时 GPU 虚拟化出来时间不长，公司拿到了 NVIDIA Grid K1 及 K2 卡专门用于验证，Horizon 支持 RDSH 及 vGPU 的时间也不是很长，在区域内基本没多少人用，拿着原厂写的手册一步步摸索着，反复做各种测试。
其实对于熟悉电脑装机的我来说，这些搭建起来没有什么难度，服务器也就只是个大号的 PC 而已，RDSH 也就是个远程桌面而已，vGPU 也就是一个 GPU 给多个用户去切片使用，在当时还只能做到内存的切割，CUDA 核心本身还是所有用户共享。这些东西都很基本，理解清楚里面的关联关系很快就能搭好，反而 VDI 里最难的是优化性能，同时不降低用户体验，直到现在我依然没有体系的了解过桌面优化。
第一个 POC 是一个制造业用户，其实在当时并不知道制造业用虚拟桌面/应用的本质，后来经主管指导才知道。
制造业在各个环节都会使用一些我们平时不怎么听说的工业软件，比如 CATIA，Pro/E，Solidworks，Creo，CAXA，Teamcenter 等，到现在我也不是很熟悉这各个软件分别是做什么的，但他们都有一个通用的点，就是授权很贵。有时候用户为了节省授权，会尽可能地少安装几套，然后共享使用，而应用虚拟化，有些时候就是为了方便这样使用。
这个项目的目的，就是通过应用虚拟化来减少各种开销，节省整体成本。一方面，用户希望一套 OS 上的软件可以供多个用户来使用，这样能节省软件购买成本，另一方面，因为这类软件大多对显卡有一定性能要求，因此需要配置专业的图形卡，而当时刚好 NVIDIA 出了适配虚拟化的 GPU 虚拟化方案，于是用户也想尝试一下，这样可以节省 GPU 的硬件开销，提高使用率。
总之奔着这两个目标，前后花了近两个月的时间进行验证，最终只实现了目标 2，目标 1 始终未完成，当时的结论是，这个软件并不支持在同一个 OS 上开多个实例。
虽说 POC 最终没有达到客户预期，但通过 POC 我倒是学到不少东西，在这次测试之后，周六公司的内部培训上我给大家分享了 Horizon View 相关的安装、使用经验，以及碰到的坑，之后我的个人标签里便多了一项“虚拟桌面”，之后公司的一些虚拟桌面项目还找我支持过。
在 POC 之后，也去支持这个客户网络相关的工作，比如设备调试、排错之类的，记得有一次帮他们解决了一个部分用户无法访问 OA 系统的问题（物理层问题），那天回家他们信息科主任还顺路用小电驴带我去公交站。
这个单位的 IT 团队人很少，总共也就三四个人，要负责服务器、网络、PC 等众多东西的运维，经常看到他们在拆装 PC，不过可能是因行业特殊，平时并没有什么工作压力，到点可以下班，暑期会有高温假，公司偏远但分配房子，某些时候还挺羡慕。和他们混熟以后也会聊些工作之外的话题，其中一位帅哥还尝试给我介绍对象，不过当时我并没有安定的想法，多次都婉拒了。
最后一次听到这个客户，是同事说另一个友商成功的解决了当时的虚拟应用问题，打听了下，对方在 VDI 方面经验丰富，而且和厂商的合作比较多，所以最终只能安慰自己，我们公司没有这方面的基因。
第二个 Horizon View 的 POC 比较简单，办公用途，本身桌面数量不大，安装完毕后大部分时间是我自己在测试，当时做了磁盘性能测试、公网发布测试等，有了第一次的经验，这次配置起来很轻松，我也借机在这次 POC 里去做一些性能优化，使得互联网访问时能流程一些。
说到这里，似乎在 2015 年之后，我更喜欢通过实践来了解一个东西的本质，一般我会通翻一遍部署文档，然后自己摸索着做，虽然有时候会碰壁，比如装的时候不知道怎么就失败了，回头再看文档时发现文档会有这方面的注意事项，但也是这样的反复试错，可以让我对一个东西的记忆更加深刻。
最后一个 POC 也是一个制造业用户，只是他优先考虑的是如何使用虚拟化技术来提升资源利用率以及安全性。在以前企业需要为所有设计人员都配备图形工作站，硬件成本和管理成本都比较高，有了桌面虚拟化之后，多个几个用户可以共享一些服务器，动态调度资源，资源利用率得到提升，同时虚拟桌面有数据不落地的特性，可以很好地避免图纸泄露等问题。
这个客户是我碰到的比较细致，但也比较耿直的客户，我当时并不知道如何 say no，基本保持我一贯的风格，对方需要什么，我就干什么，最终耗了很多无用的时间在这个用户身上。
整个 POC 从开始就不顺利，碰到过电源功率不足、服务器不兼容 NVIDIA 显卡、更换了服务器后 Mezz 卡不兼容显卡、测试周期过长中途换硬件等等，一番 POC 的结局是，客户使用我们的硬件做了一个月的产品设计，但期间还说性能压测比不上类似配置的工作站等等。
这次 POC 后我基本没再接触过这个用户，和我搭配的售前也是苦不堪言，一开始说项目会采购一系列软硬件，后来说要推迟，后来又说预算不够还是想继续用图形工作站，再后来说想做个网络改造规划，售前得知这个改造项目是三年后的事，就不咋搭理用户了，投入产出完全不成正比。
在 2015 年年底，刚好 VMware 办了一个虚拟桌面的培训，在北京，得老板赏识让我去参加了，那是我第一次去 VMware 的办公室，第一次感受国际大公司的氛围。
这也是我毕业之后第一次去北京，在培训结束后，短暂地去了趟天津，回到母校和几个同学见了见，大家都很好，但是学校变化很大，人是物非。
下图：在 V 记培训时丰盛的午饭*
下图：在毕业两年后重回母校
某电厂广域网络改造
这个项目大概是 2016~2017 年持续在做的，项目内容比较复杂。
客户做广域网改造有多种原因：
- 客户在两个省有十多个分支，分支之间的网络都是通过集团的传输设备接通，而这些设备不受客户的控制，且网络中传输的报文没有加密，这存在一些安全风险
- 因为一些专有设备，有几个中心之间的网络是二层打通的，而且这些专业设备没办法配置三层网关，固件写死的
- 总部到分支只有单链路，想借助 4G 来做备份线路
- 现网使用古老的 RIP 协议加静态路由协议，想借机改造成相对稳定的 OSPF
上面的问题单独一个都挺好解决，但放在一起就很复杂，加上站点比较多，每个都得工程师去现场，所以整个项目花费了一年多还未改造完成，在我离职之后交由其他人继续完成。
大致的解决思路就是一些常见的技术：
- 通过 DSVPN（思科的 DMVPN）来加密站点之间的流量，保证数据安全
- 通过华为 VLL 技术实现跨三层的二层网络（这个技术和之后的 VXLAN 技术类似，也是挺巧合，刚好这个项目里需要，而我们就在华为的设备手册里找到了这个技术说明，最终用这个技术满足了用户需求）
- 组建 4G 专网，作为以太网之外的备份网络，通过浮动路由的形式保证有线网络故障后可以切换到 4G
- 将原来的路由改造为全网 OSPF
这四个技术，当时只有 1 和 4 在曾经培训时学习过，但项目中用的并不多。2 则根据官方的手册完成了配置，3 完全是现学现用 ，了解设备怎么配置 4G，用户侧的 4G 设备如何和现网打通，路由怎么协调之类的，每项都花过很多时间。
项目除了进展慢，其他都比较顺利，当时客户位置也比较远，我经常需要乘一个小时的地铁，然后再坐半小时的拼车才能到，好在很多割接动作都是中午做，应该是做完变更后下午可以找人验证是否有问题，所以项目做着并不怎么累。
某城商行数据中心新建
这个并不是公司的项目，而只是思科原厂在给客户写一些规划方案，缺少人力，友情支持下，去帮助做一些文档，和其他项目不一样的是，这个项目在重庆，并不在公司业务范围内，很感谢当时技术总监选中了我去帮忙。
其实那时候很纠结，公司的各位前辈对我都挺好，我相比其他人也会有更多的机会去参加外训，但我基本定下来要离开西安去上海，这时候你会感觉在浪费公司的机会，但同时又还没到需要提出离职的时候，于是只能一切照常。
2015~2017 期间，经常会和公司同事出差，有时候和技术总监一起 share room，对于技术大拿我一向很敬仰，要能力有能力，要境界有境界，讲东西也很自信，逻辑清晰，简直就是很多技术人膜拜的对象。和高手在一起共事，自然可以接触很多”高眼界“的东西，也能学到不少，不仅仅是知识层面，而是谈话方式、思维方式、为人处世等多个方面。
差不多在 2017 年刚开年，总监提到想把我从行业部转到专家组，专家组类似于一个咨询部门，每个人都会有自己精通的一些东西，可以在一些项目中指导其他人或者解决一些疑难 CASE，是公司最强力的后端力量，当时我很乐意就答应了，其实这也是工作一年多后就一直想要的东西，并不是前端做项目有多累，而是感觉自己需要接触更多的项目，而不仅仅只专注在一个行业，无论从个人发展还是对公司整体都有好处（技术经验可以应用到全公司的项目）。这事一直到 17 年中旬，也没有着落，因为可能的个人变动我也没再去追这个事，直到去支持重庆的这个项目。
到达重庆的第二天，在客户的小会议室休息的片刻，技术总监正式邀请我去他们部门，我当时有点意外，又在意料之中，一时不知道怎么回应。
后来思前想后，在某天一起吃串串的时候和总监说了我要离职的事，他应该也没想到会有这个意外的事件发生，中途也没说太多话。还记得那个串串叫饿狼串说，几年后再去重庆，还再次去打了卡。
某汽车制造厂网络改造
这应该是我在第一家公司最后的一个项目，项目也是比较杂，有交换机的改造，也有三个中心的 VPN 打通，也有无线的设备采购，需要远程支持客户进行配置。
每项技术在之前的项目中都积累了足够的经验，所以做起来相对顺利，那时候已经告知同事要走，所以也没有新的项目分配给我，我预估这个项目可以按时做完，就心态很好地，仔细的做完了这个项目。
还记得在做这个项目的时候，接到了 HR 的电话，在客户园区树荫下，接到了上海的 Offer。
一些印象深刻的 CASE
思科更换为华为后奇怪的丢包
这个项目的客户在陕北，一开始派三个熟悉网络的同事去做，项目内容也不复杂， 就是做一些网络改造，把思科设备替换为华为，这种事在那一两年很多，但每次我们做这样的事总会碰到一些奇怪的问题，这次也不例外。
具体碰到的问题是，每次完成思科设备到华为设备的割接后，在办公室测试网络时就会发生丢包，前后割接了三次，每次割接之后现象必现，但是现场工程师已经做了大量的排查，没有发现什么问题。第三次割接后，来自客户的压力实在过大，急需总部的支援。
于是我们一行四人赶黑驱车前往陕北，第二天到达客户现场。
丢包这种问题，根据以往的经验，要么是物理层不稳定，要么是设备性能不足，物理层我们已经做过一些排查，包括更换网线等等，故障依然未得到解决，于是我开始怀疑是设备性能问题。
在那时候华为设备我们卖的并不多，国产设备有个通病就是参数虚标，可能为了一两个项目在官方网站里把参数标的很高，实际设备性能可能是 1/10 甚至更低，而且通常一个设备型号的引擎和板卡也有高低配之分，这又可能使得用户想要的以及用户得到的差异很大，总之，我当时并不对国产设备的性能以及稳定性抱有幻想，所以当时的第一个排查方向就是测性能。
最终实时证明我想多了，即使设备的性能再低，也抵得住我们两台 PC 相互之间的对测，通过 iperf 做了各种打压，没发现任何问题。
接着，我们又注意到丢包好像有规律，差不多每 ping 10 个包会丢一个包，于是又猜想是不是设备启用了什么安全功能，导致在报文超过一定阈值之后丢包，我们也确实找到了类似的安全配置，但是将这些配置调大之后，问题并没有得到解决，排障一时间陷入僵局。
最后还是技术总监找出了问题，他从故障源（办公电脑）开始，逐跳去排查线路，结果发现办公电脑到接入交换机之间竟然有个不为人知的小 hub，这个 hub 是一台思科家用交换机，丢包实际上是发生在这个设备上，而丢包原因和一个思科私有协议有关，那就是 VTP 。
在传统以太网中，大家都会通过 VLAN 来隔离广播域，一般可能每个楼层有自己的一些 VLAN，因为一些历史原因，大家以前在做园区网的时候都是核心-汇聚-接入全二层一把梭，在这样的架构下，要使得用户网络能通，需要在核心配置所有 VLAN，在汇聚和接入配置与其相关的 VLAN（也就是要人工去筛选配置 VLAN），如果网络大了，会发现这样细致的配置 VLAN 会很累，所以有些时候大家喜欢给全网所有设备配置所有 VLAN，以此减少 VLAN 的配置复杂度，但这样带来的问题就是有些设备并不需要这么多的 VLAN，可以说是为了解决 A 问题，引入了 B 问题。
好在当时思科有一种技术可以很好解决 VLAN 的配置问题，那就是 VTP，有了 VTP 后，可以只在一台设备上配置 VLAN，其他设备去同步 VLAN，进而简化 VLAN 配置，但光同步还不够，因为有些设备可能不需要某些 VLAN，所以这个协议支持一项功能就是 VTP 修剪，交换机可以按需决定本地应该有哪些 VLAN。
再回到这个客户遇到的问题，以前思科核心是 VTP Server，将其更换为华为设备后，这个功能没有了，导致下面很多思科交换机会接收到很多与其无关的广播流量，正常的企业级交换机都撑得住这些流量，唯独那台家用 hub 撑不住，导致了丢包。
找到了问题症结，解法就比较简单，人工去做 VLAN 修剪，修剪之后效果立竿见影。
这个 CASE 我印象比较深，当时得来的经验便是，网络排错不仅需要精通各种知识，而且需要有线性排错思维，即排错要从端到端逐跳进行，经验及跳跃式的排错并不能始终保证可以发现问题。
后来在 2019 年，因为遇到的 CASE 实在太多，于是将思考整理成了公众号文章，原文在此：排错概论
下图：客户现场外的天空，小地方天生有这种自然空旷的美
交换机内存挂了
这个 CASE 之前的文章里介绍过，在此详细记录下。
本身故事不复杂，某运营商因为业务扩容，也因为设备老旧，需要把一台 C6509 更换为 C6513，割接工作主要由客户自己完成，但是需要我们公司的人配合以及保障。
因为该割接比较重要，于是公司加我三个人去现场值守，到了现场后发现，在那个地方最多也就容得下三个人干活，其他人都只能打酱油。
可能网络变复杂后，后期的维护都会变得很随意，这个客户直到割接的时候，大部分的光纤线还没有打标签，而这一台设备，就有上百条光纤线，接的满满当当，当时看到设备后我很震撼，这都敢割接？更让我震撼的是，他们就这么打算先给线打标签，再去割接，一个晚上搞定这个事。
震撼归震撼，如前面所说，我们多余的人都是打酱油的，一开始可能还会盯着他们来做，时间长了都觉得没什么意义，于是各自找个舒服的点去蹲着。
一开始是蹲着，后来腿累了，自然而然的坐下了。
随着夜深，精力也跟不上，于是开始找些包装盒垫在地上，尝试睡觉。但是睡到半夜又觉得很冷，因为机房都有精密空调保证持续的冷风输出，被冻的不行，就只能起来活动活动，找个暖和的地方。
逛遍了机房，最终发现有个好去处，那就是 IBM 小机的背后，那几台机器从正面看真是霸气，与众不同的外壳，在机器的后面，多个风扇疯狂输送着暖风，和地底下吹出的冷风形成鲜明的对比。
就这样躺一会儿，去看看客户割接，然后再吹吹暖风，熬过了一夜。
为啥不去外面待着呢？我也忘了，大概是出入都得有客户陪同，而客户都忙的不可开交吧。
半夜的时候，客户终于把线搭好标签，下架了原有的设备，上架了新的设备，然后开始开机检查，结果发现设备无法启动了，一番排查后发现内存坏了，无奈只能开始回退，做完回退后已是凌晨，还记得结束后几个人到门口，看着渐渐红起来的东方，抽着烟闲聊着，完后吃了早餐，各回各家。
这个 CASE 我没有什么贡献，只是一个旁观者，因为过程实在无聊，所以唯一的收获就是以上深刻的记忆。
下图：割接后的清晨
思科更换为华为后 IB 网络故障
这个 CASE 发生在思科核心更换为华为核心后，设备配置我们全部校对过，没有任何问题，在设备上线后，状态检查也无任何问题，但在业务测试时，发现有些业务系统无法访问，后来定位到和一组 IBoE 交换机有关系。
什么是 IBoE？我当时也是第一次听说，在 IT 系统里有种高速低延迟传输方案叫 Infiniband，一般当时的高性能计算都会用这种网络连接，而一般 IB 都是独立的系统，仅用作系统内部互联，系统对外访问可能还是通过 IP 网络。Infiniband 交换机的生产厂家不多，麦洛斯（Mellanox）是其中最大的一家，我也是这个项目里第一次听说这家公司，后来 NVIDIA 相中这家公司，收购了麦洛斯。IBoE 就是 Infiniband 协议 over 以太网，在以太网上传输 IB 协议的报文，这种交换机作用现在已经不记得了，在当时，我只关心这个 IBoE 交换机和故障有什么关联。
之前从未接触过这类设备，于是先从更换后的华为交换机着手，看与这台设备的对接配置是否有差错，以前思科使用 Port-Channel on 来和这个设备对接，按道理，华为也使用静态的链路绑定就可以对接成功，于是当时做配置翻译，也确实是这样做的。
但是对接完成后，通过抓包发现就是这里的对接出了问题，而静态绑定并不会有太多的便于排错的信息，静态绑定就等于双方都认为对端配置好了链路聚合，相互去按照自己的算法去发包，只有硬件故障后才进行切换。
实在想不到其他原因，就只能让客户把 IBoE 交换机的配置帮我们导了出来，然后我们做了割接回退，等好好研究完 IBoE 侧的配置再来尝试割接。
后来一两周，我找到一些麦洛斯官方的手册扫了一遍，大致知道设备如何进行配置。同时也去查了下链路聚合协议相关的文档，看能不能找到对接失败的蛛丝马迹，最后也没找出很靠谱的资料。
最终还是决定相信直觉，更换一下对接的协议，使用业界标准的 LACP active 模式来对接，那时候还发现，华为的设备压根没有配置 LACP active 模式的地方，当时对于能否对接成功打了个问号。
后来在周六协商好了时间窗口，在此尝试割接，同时修改了华为和麦洛斯交换机的配置，对接完成后上次的问题得到解决。
在割接后，设备的一些线还没能接完我就撤了，因为刚好那天和其他同事约好一起去华山，我保证没有重大问题后，剩下的另一个同事帮忙完成剩下的工作，客户也没说什么。
我乘着高铁从西安到了华山，等齐其他同事后一起坐大巴到了华山底下，在门口小店吃完晚饭，晚上 11 点就向山顶出发，漫长而又寒冷的一夜，第二天按时到了山顶，见到了日出。天亮了后在山上一直转到中午，后来很多人都没有足够的力气，于是大家一起坐缆车回家。回到西安已是黄昏，找昨天的同事拿了下电脑，回到家直接倒头就睡，很充实的两天。