染卷不卷'blog

12年站长,AI实践中。互联网 IT行业,工作见闻、技术教程全分享。

新文随笔

跟一甲方交接运维工作,看普通运维人的防御性措施与自保

本篇目录

背景

跟这家甲方公司合作好几年了,老板之间在合作前也是比较熟悉的朋友。这家公司业务规模不算大,成立之初就一直亏损,但老板还有其他产业勉强撑了3、4年,最近已经结束了第二轮人员优化了,他们的IT部门基本算是散了就留了一个后端开发。对方的后端不是很懂运维,甲方老板就想让我们这边“帮帮忙”,具体怎么谈是老板的事,当时的情况就是已经通知他们运维和其他IT人员下个月拿赔偿走人了。据说这个决定很突然可以说是没有任何征兆,看这架势谁都不知道公司还能撑多久,后来我了解到赔偿应该是按N算的给一个月缓冲期,但是赔偿金需要分期支付。

交接过程

1、唯二的交接资料(部署文档+账号台账)

我这边接到通知时对方还有一周就到最后截止日期了,赶紧做了一个交接清单(什么部署文档、网络拓扑架构、巡检日志、运维台账……),结果交接前面聊的时候对方说只有一个部署文档在wiki 其他的只有账号密码账册。虽然很难相信一个使用阿里云全家桶的企业运维只会有这么一些工作资料,当时我也没多说什么。事后问他们领导是什么意见,好在也没太为难人就说有什么就交接什么吧,毕竟赔偿金公司确实没办法一次性给到位,人家有点小心思也正常。聊到最后又听了一遍金句“没有谁是不可替代的……”

2、运维工作现状

交接完上面2个资料,又找他们剩下唯一的开发了解了下情况。说是自从这个运维来了之后,就把之前的手动发版流程,全部改成了jenkins 发版、回滚,云服务器监控告警、快照备份等基础设施功能都进行了补足。后面系统运行一直比较平稳……

然而就是在他们公司第一轮裁员且工资延迟发放后,很多人工作状态发生了变化。摸鱼的人开始变多,告警群隔几天就会出现磁盘90%告警之类的,甚至出现几个因为磁盘100%导致业务系统卡死的情况。每次都是要紧急联系运维来解决,当然每次只要联系上了也都是能搞定的(最近一次磁盘满就发生在2周前,也就是人事通知一周后)。对了,还有他们运营反馈测试环境已经有三个多月都上不去了,后台打不开,但是不知道什么原因没有处理……

3、运维事项梳理

该公司业务比较简单,N个web后管(含信息化系统) + C端微服务(不到10个微服务),全部是阿里云上自建或买的现成云产品。数据库和SSH服务器连接配置是运维最后一天下午重装系统前才导出交接的,之前交接的账号台账有多个文件,不同文件里面还存在历史遗弃的账号,还有的账号信息在不同文件之间都有,但是密码不一样的情况。总之没有一个现成可用的最新的台账,有几个数据库、ssh的密码台账上的都不对,还是最后一天导出的连接配置是对的(应该是修改了密码,客户端能连上但是没有更新台账)。基本都是企业账号绑定企业手机问题不大,慢慢开始梳理吧:

  • 修改几个阿里云主账号密码,绑定MFA验证。排查云账号、AK。
  • 梳理全部云资产,尤其是ECS服务器跟交接台账进行匹配、验证、修改。
  • 修改、增加安全组收拢ssh、mysql 可访问ip,禁止办公ip外的访问。
  • 清理服务器账号、访问公钥,限制未知端口,重点服务器全部存一次永久快照。
  • 使用AI做了个服务器信息只读采集脚本,采集每个服务器的系统信息、环境变量、软件包、进程信息、监听端口及对应程序路径、docker信息、nginx等反代配置(域名+ssl证书)、定时任务、系统账号……。
  • 统计云服务账单,梳理各类云产品续费方式,整理包年包月产品到期节点、资源包覆盖使用情况、按量付费产品消耗情况。
  • 回顾报警群消息,依次处理相关告警事件(主要是服务器磁盘清理,少量安全报警)。
  • 第三方系统账号验证、修改(给台账当天,AppStore开发者邮箱账号被人重置为手机邮箱也是没谁了,好在信息都有找回了)。

上面这些做完也只是完成了基本的运维信息,确保短期内不会有意外情况,在没有更详细的资料情况下后面只能等有时间了再跟开发逐个确认一遍业务系统。服务器磁盘清理还是比较意外,日志没有轮转几十个G的单日志文件第一次见。然后3年前的jar包还留着,所有服务器上超龄项目包加一起上百G是有的。交接完第一周是忙的晕头转向,服务器、资源包陆续到期续费(有个CDN资源包月初已经到期就是没人续导致一直走按量扣费),SSL证书还是翻合同找到当时采购证书公司的联系人拿到新证书……

后面还有一些运维相关事项需要持续,核心是进行“降本”:

  • 重新梳理所有业务系统,鸡肋的系统要下线或合并到一体化综合控台,空闲的系统要集中部署特定服务器,节省不必要的服务器开销。
  • 服务器漏洞、nginx版本、java&php等供应链漏洞排查(是的不仅仅是这个甲方,包括我们公司也是没有专职的信息安全人员的,都是能做一点是一点)。
  • 云上的测试环境必须制定计划下云,在本地搭建测试环境,释放对应服务器资源。
  • OSS、CDN、带宽费用想办法进一步缩减(比如OSS存储现在有上百T 要想办法直接清理或迁移线下备份后再清理, 所有高频接口排查请求频次是否合理及返回信息需压缩或精简冗余的返回字段, 业务后台图片上传也要评估压缩方案……)
  • 如今业务体量下降严重,已有的阿里云微服务配套产品购买太多资费太贵,最终要切换为手动搭建的微服务环境。
  • …………

普通运维的出路在哪?

至少我是看不到普通运维出路在哪,管的服务器没超过50台的,只能算初级运维吧。而且现在AI发展迅速很多中小公司已经没有专门的运维岗了,要么就是直接招全栈搞定一切。如今就是一个小白把ssh信息给codex或者别的其他AI智能体都能做一些服务器运维,这进一步加剧了某些公司领导认为的“运维无用”论!

我始终认为运维作为一个保障岗位,天天没事那才是正常的好运维!感觉不到他的存在正是因为人家做的好,我也并不认同需要偶尔“搞点事”再去解决以体现运维价值这种方式。当然遇到一个开明、专业、懂你的好领导会更好!更更更好的是公司效益不错、人人有盼头!

虽然出路不明,但也要走好脚下的路:

1、做好本职工作,放平心态与人为善。

2、利用空闲时间多提高自己,能锻炼专业能力的任务不要推脱。

3、一定要去了解AI、学习AI,看别人是怎么用于工作的。

4、打铁还需自身硬,不要纠缠、陷身于“烂”环境。

5、学会沟通和表达,埋头技术时别忘了抬头看路、看远方。

6、记住:你的离开就算公司损失再大,也几乎不会有同事、领导会因此承担责任,你并不能因此“惩罚”到他们……

染卷

本站文章也会定期同步到微信公众号,可以关注下避免错过~

建站 12年 74天
微信公众号

发表评论

邮箱不会公开,带 * 为必填。