运维是否会陷入防御性建设的漩涡！

新年伊始

“请系好安全带，收起小桌板，调直座椅靠背。” 2024年就这样从一份忠告悄无声息的开始了，然而从2023到2024 大家可谓真的是悲喜交加。

悲的是互联网所谓的“开猿节流、降本增效”引起的一系列恐慌和事故，让我们谈“障”色变，近在眼前的有：

• 2023年10月23日语雀故障
• 2023年11月12日阿里云故障
• 2023年11月27日滴滴故障
• 2023年12月3日 腾讯视频故障

喜的是大家的SLA指标终于可以清零重新开始了。

然而在欣喜之余，我们仍不能掉以轻心，在和小伙伴的交流中，一个想法油然而生：“「防御性编程是否会进一步演变成防御性建设呢？」”

防御性建设

何为防御性建设？以防御性编程为例，其目的是保护开发者自己，降低代码的可读性、可维护性，来达到明哲保身的目的。而防御性建设同样强调的是职业安全性，只不是相应的职级更高，虽然是从当前问题出发规划架构，但忽略技术债、非常规痛点问题，而更多着眼于未来的“高大上”。如此高级别防御，不仅引入了很多不确定的因素，还导致了架构复杂化，因此不但没有药到病除，反而更加雪上加霜，让人哑口无言！

那么防御性建设一般体现在哪几方面呢？

• 首先平台建设的目标一定是超前规划的，要支撑业务未来爆发式增长；
• 其次架构上相应的会有一个层次饱满、功能齐全、场景丰富的架构图（只有想不到，没有做不到）；
• 再次为支撑技术架构，离不开各种社区资源的加持，这里的坑位点比较多
• 没有技术评审，各种技术方案乱入；
• 使用版本过时、社区不活跃的开源组件以及各种魔改，缺乏持续性的版本迭代；
• 带有浓重个人主义的应用系统，缺少传帮带以及技术传承；
• 最后没有阶段性的系统交付，总是在被动交付、PPT交付；

是的，你没看错，以上几方面不但是防御性建设的具体体现，同时也是正常建设过程中所面临的问题。“向前一步是自由，退后一步是束缚”，防御性建设并不是主动解决问题，主打的仍是职业安全性，其他都是附加值。

还有比较关键的一点，任何建设的过程都离不开商业付费的支持，然而这其实是一把双刃剑。商业方案在初始阶段能够给我们带来认知上的提升以及跨越式的发展，但是后续随着需求的多样化，其也会成为制约我们发展的枷锁。因此对于商业方案的从一而终本身也就是个伪命题，它的生命周期也将会是防御性建设的重要一环，被束缚的感觉你懂的！

「结语」

然而谁也没想到“「开猿节流、降本增效」”这两个关键字的威力如此之大，不仅引发了生产故障，还造成了打工人的恐慌。如果任由这种现象级的影响继续扩大，上升到更高职级，那么防御性编程是否会进一步演变成防御性建设，2024我们都需要持续观望！

2024伊始，杞人忧天并不能解决一点问题，运维虽不至于防御性编程，但是却容易陷入防御性建设的漩涡。因此做好运维自己的规划，进而为层次饱满、功能齐全、场景丰富的架构添砖加瓦，这才是当下比较有意义的动作！

“请系好安全带，收起小桌板，调直座椅靠背”一直在耳边不停回荡，这话虽不至于让我们在职场起飞，但至少可以让我们安稳着陆。因此希望运维小伙伴们保持清醒，运维之路高举高打！