如何重塑中小企业运维价值(3)
关于日常演练,据我所知,大多数的IT企业很少去做灾难的日常演练.因为“没时间、太忙”等等等等,可是你知道吗?如果不做灾难演练,当灾难来临,比如“rm –rf /”一个命令下去,虽然是手误,但多少都会让你惊慌失措.“我*,我竟然做了什么?”. 灾难演练与灾备同样重要,演练数据库被黑,所有表都被清空;演练“内网 GitLab 被删,如何恢复并通过日志找到线索”等等;演练突如其来的 DDOS,怎么应对以及做流量清洗. 在粮草丰盛的日子里,做好“弹尽粮绝”的准备.虽然你不可能把方方面面都做到提前预判,但至少会锻炼出来你敏锐的嗅探能力,比如在磁盘报警时,你有充足的时间可以更换磁盘. 我们曾遇到,在我们的测试机器(二手的服务器)上,磁盘(做的Raid 5)嘀嘀嘀响了一个多星期(在另一个办公室,我们不知道),直到被行政人员提醒,及时更换了硬盘.也就是这时候,才开始实施了监控. 因为在这之前,只是觉得这台服务器的磁盘写速度不如从前,但考虑到机器是旧的,就没有顾忌太多.但于此同时,某开发负责人“手误”,把自己 GitLab 的分支全删了,说来也奇怪,他自己竟然没发现(后来才知道,这家伙要离职,提前做好准备),因为我们有备份,及时给找回. 代码的压缩包不大,可以备份很多历史场景(每日备份),但对此,是因为之前做过演练,但仍然“防不胜防”.
说起防,“日防夜防,家贼难防”,这是真的!看新闻曝光过某大型电商企业内部员工泄露了上亿条数据.但我之前的职业生涯却是遇到过的,公司的开发经理因为太善于内部政治斗争,被手下一个想要“上位”的家伙给害了. 这个想要“上位”的家伙是一名开发,比较有心,有次因为要使用技术负责人的 GitLab 的权限,让开发经理在这名开发的机器上进行登陆和操作,这家伙悄悄的记录了对方的密码(居然还是弱口令). 在之后的不到一个月时间里,他使用技术负责人的权限拷走了公司所有代码,并进行了日志清除.但他的水平确实比较 low,并不知道我们还对日志进行了二次备份. 在他个人与技术负责人发生正面的“政治斗争”时,用开发经理的权限删除了公司内网 GitLab 上的所有代码,并栽赃我们的开发经理.这时候,开发工作陷入停滞.老板急了,要求我们立即恢复. 可是,每个开发人员的机器上,都有自己正在撸的代码.所以,至少在1个工作日之内,影响并不是很大.我们用了半个小时,就发现了他的具体攻击过程,先改自己机器网卡的 MAC 和 IP(我们路由有记录,虽然我们在路由上做了 ARP 绑定,但也只是不能上外网),再然后,使用开发经理的帐号密码登陆 GitLab,删除所有代码,擦掉本机记录,然后再把网卡 MAC 和内网 IP 地址改回去. 我们向老板反馈,老板报警,至于后面的事,不用说大家也都明白了.很庆幸我们提前做过演练和对应方案,也很庆幸我们找到了直接的关键人,但更重要的是,这种家贼,确实难防. 为什么不能建立一种“公开、透明、可监控”的机制,来预防“家贼”事件的发生?这是值得很多企业去思考的一个问题.经济学上有一种叫做“逆向选择法”,也就是(似乎是行政HR的活儿)“员工的利己行为分析”. 员工具体会发生哪些“利己”行为,哪些才是对公司有伤和无伤的,我想每个不同的企业都有自己的判断与思考. 但往往,人是最不可靠的,特别是在企业正在迫切需要发展的阶段,企业到底需要“靠谱”的人,还是需要“可靠”的人?这个问题,你可以来发邮件找我撕逼,我打算在下一篇内容探讨这个问题. 4、结论总之,一切问题的发生,总有其必然的原因.就是说,一切皆有“因果”.我们要拥抱所有可能发生的问题,在我们的能力的范围内,做好充足的预判及应对措施. 当然,“能力的范围”也会随着你的努力而不断的扩大.这当然是学习和提升的过程,是自我价值体现的过程,也是运维价值实现的过程! 另外,我要推荐另一篇文章,“互联网运维杂谈”公众号(waynewang_ops)发过的一篇文章“谈谈运维的价值和思路”,作者谦益(有兴趣的同学可以自己找一下). 小弟读的书少,你也许可以骗我,但我不一定会当真.最后,欢迎关于运维业务的探讨与撕逼,可以发邮件给我,stackworm@qq.com,可以找我好好的撕逼. 原文来自微信公众号:高效运维 (编辑:ASP站长网) |