运维总监职业安全保障手册

临到年关，不少运维总监担心过完节回来就丢了工作。他们在保障系统可靠性的同时，还想提升自己的职业安全性。此处笔者总结了几条实用技巧。

不要上云

不要上云！不要上云！不要上云！

按照老规矩，重要的事情说三遍。不上云的话，你可以做到除了你自己，谁也搞不清你的系统长什么样。你们在香港机房租赁的那个机柜跑的究竟是大数据集群，还是计费系统，还是无关紧要的公司论坛，只有你知道。有心想炒掉你的 CTO 暗地里安排人登录机器查看，这个人傻乎乎的到处问 SSH 密码，问了三个礼拜都没问出来，因为聪明的你，根本就没启用密码登录，用的是密钥登录，而密钥在你笔记本的 /Users/weidajiagoushi/Documents/dog_pics/miyao 文件夹里。CTO 有了密码才敢大胆炒掉你，而 CTO 炒掉了才可能拿到密码，你看，他陷入了鸡生蛋蛋生鸡的两难困境。

建设多云统一管理中台

那些已经不幸上云的朋友，也不用悲观。你可以提议：“不能被云厂商绑架我们，必须构建一个对应用透明的统一云管系统，对应用层提供底层无关的统一接口，保障系统可以在阿里云/AWS/华为云/腾讯云之间无缝迁移，避免被云厂商绑架。”

当然有无聊的人会问：“我们这一年两千万营收的企业，值得云厂商绑架吗？”

此时，你绝对不能姑息这种挑衅，一定要义正严辞的反驳：“根据 CEO 的规划，我们每年翻番，若干年后就达到小 100 亿，那时候再做可移植性，时候就太晚了。”

只要说服了管理层建设统一云管平台，你就可以招兵买马（或者挪用应用开发团队的码农），自己搞一个系统。子曰“师出有名”，所以你第一件事就是要取个很好的名字。可以叫它 “福利来公司统一多云操作平台”，或者 “福利来公司基础设施中台”，或者“福利来公司计算融合平台”，或者更 fancy 一些， 叫它 F2P: Fulilai Fusion Platform 也行，听起来比较洋气。

然后你要画一个很厉害层次很丰富的架构图，类似下面：

如果有工程师提出抗议：“你这破架构图不是给人看的，我看不懂。”

你要很有风度的解释：“啊哈，我还有一个给初级开发者看的版本。” 这样你就巧妙的把这个人打成了初级开发者。

初级开发者版的架构图可以参考这个^[1]：

是不是看上去很高大上？应该有的，不应该有的，全都有了，应该可以满足公司业务增长到 500 亿了。

但是上面这个图有一点不好，它没有把安全列进去，下面这个包含安全的架构图^[2]可以参考：

这个图的好处在于：除了横向的层之外，你还有竖向的列。安全竖起来画，表示你这个安全是覆盖了整个技术栈的全栈安全，从头到脚的安全，而不是云厂商的什么“Shared Responsibility Model^[3]”，高下立判！

有的朋友就问了：”画这么复杂，我做不出来怎么办？” 我说“朋友，你不要装傻，你见过哪个 IT 系统是按 PPT 画家画的样子去施工的？” 对于云管系统，基本上，你能让人创建虚拟机，挂个磁盘，基本就差不多了。你要是弄个 Redis 或者 Nginx 安装包，那就是行善积德，可以在家门口挂个“大善人”牌匾了。但是你绝对不能说“Redis 安装包此处下载”，你要分别叫“用户实时行为数据中台”和“流量统一接入子系统”。同样道理，你装几个 Hadoop 组件，就要叫“大数据分析预测平台”。

在此之外，你还要整个开源大语言模型的推理服务，虽然没有人用，但是这表明你这个系统是面向未来的，非常重要，不能省。要是有傻帽过来说：“你这个是人工智障，我根本不用，我只用copilot。” 你就慈祥的微笑，告诉他：“小伙子，这是公司立项批准的唯一 LLM 服务，你用其他系统，如果泄漏了公司数据，那是你的经理失职呢。”

有人又问：“马工你搞什么鬼，不是做多云管理系统吗，怎么搞这么多乱七八糟的？” 嘿，哥们你抓到精髓了。最为关键就是你要煮一盘除了你自己没有人搞得懂的大杂烩。最好达到这么一个目标：不仅你的上司和同事搞不懂你这个系统的定位，即使是你最亲密的部下，也分不清系统中哪一些是充数的垃圾，哪一些是真正能用的砖头。你的不可或缺性，还能有更好的保障吗？

魔改开源软件

尽管你的 F2P V2.0 用户只用它开虚拟机，但是不妨碍你提供100个功能，以及使用1000个开源软件。

使用开源软件，有个很大的好处：公司不用付费，省下来的钱可以让你招兵买马。但是也有个很大的坏处：代码人人都可获得。如果老板把你这个总监开了，换另外一个老司机运维，看得懂的Redis 代码还是看得懂，看不懂的 Redis 代码还是看不懂，情况没有变得更糟。

那么，在 CTO 开掉你的时候，怎么让情况对 CTO 变得更糟呢？答案就在一念间：魔改它！

比如你用Kubernetes，必须魔改它以支持固定 IP，理由非常充分：我们公司业务非常特殊，和全世界都不一样，就需要固定 IP 的容器！

魔改软件类似领养孩子。它是社区生出来的，但是被你领养了以后，它就和社区没有关系了。只要魔改得足够多，Linus 本人都不敢碰你的 Linux，Hashimoto 本人都没信心维护你的 Consul， 章文嵩本人看到你的 LVS 都要摆手“另请高明”。你想想你的 CTO还敢动你吗？

你要是用了魔改软件，就是搞出一个大故障，领导也只能正能量的鼓励你：“失败是成功之母，我们不追求100%可用性。” 尽管他恨你恨的牙痒痒，但是他怕你跑了，更没人能收拾烂摊子呀。

使用过了维护期的软件

有认真的朋友问：“我用的开源软件 MySQL 有点复杂，魔改不了，怎么办呢？” 认真的回答是：“那也有办法，不要升级就好了。”

比如你就一直用 MySQL 5.1。别人问，你就说升级有风险，而且够用。这样过了若干年，除了你自己，没人知道这些 MySQL 实例打了什么补丁。它们在你们公司的地位类似土地庙的土地爷像：每个人都看到它长灰了，但是没人敢碰它。你作为土地庙主持，自然身份就水涨船高了。

其他技巧

运维总监的职业安全性保障，是一个长期工程。除了上面说的，还有很多其他技巧。比如你可以向滴滴学习，什么都按照社区最佳实践反着来。社区推荐一个 Kubernetes 集群 5000 个节点， 你就整十万个节点。又比如社区推荐Infrastructure as Code，你就偏要鼓励图形化编排。总而言之，无中生有出世界上独一无二的知识，并且控制这种知识的扩散，是你职业安全的最大保障。

瑞典马工启用了一个有评论区的公众号账号《云计算散弹枪》，还请大家移步关注下，在评论区一起愉快的交换信息和观点。

参考资料