别拿CTO的愚蠢,干掉新人对生活的希望

杨志洪 2017-06-09 10:36:35
作者介绍

杨志洪DBAplus社群联合发起人,新炬网络首席布道师。Oracle ACE、OCM。OOW、GITC、Gdevops大会演讲嘉宾,对数据库、数据管理有较深入研究。合译《Oracle核心技术》。

 

一大早起来,看到某厂商的官方微信推出的一篇文章,说的是一个人入职第一天就被干掉,而且面临起诉。

 

英文原文链接见:
https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/?st=J3HYL8QW&sh=bed17cf0

 

 

不想翻译了,简单解释下。

 

这孩子第一天上班,老板给了他一份文档,搭建本地开发环境。那个写文档的人傻白痴,居然账号密码、甚至连接方法都是到生产库的。这个孩子以为是测试数据,然后清除了里面的所有数据。半小时后,生产业务的人叫嚣起来了,这小孩意识到自己误删了数据。然后CTO就让他滚蛋了。最扯的是,数据居然没有备份。

 

对于这个问题,英文媒体下的评论区太热,直接关闭了。截取一部分给你看看。

 

先看来自Crazy on tap上的。

 

 

再看看Twitter上的。

 

 

看到这些评论,整个人都舒坦了。

 

 

看到这里,你有没有觉得很爽!

 

其实今天还看到一篇题为《血泪总结!创业公司的CTO,你一定要主动规避这些坑》的文章,有这么一段:

 

 

“先让我从印象最深的一次宕机讲起。有一天,有一台机器的容器挂了,我对技术人员说,你把机器重启一下吧!然后他就去了。结果没几秒钟,突然收到报警。我问那位同事,你做了什么?他反问,你不是让我重启服务器吗?

......

所以,作为技术管理者,一定要清楚地对下属表达自己的意见,否则,一旦出现操作上的‘歧义’,后患无穷。

 

关于数据库的经验分享,首先是永远不要忽视数据库的重要性。我要求数据中心的管理人员,每个礼拜的固定时间要进机房巡检,是真的去人为地一台台巡检,并把这件事当做日常的工作之一。

 

第二点经验之谈是数据库怎么备份都不嫌多。这方面我也是吃亏长见识,公司的数据存储量不大,平均一个小时备份一次,当时出了一次意外,有一小时的数据丢失了,最终找到硬盘公司,花了几万元才把数据恢复出来,重新再合并回去。”

 

说得很坦诚。我们无从得知的是,如果真的那机器后面没起来,这个技术人员是不是会跟上面那孩子一样,手足无措地回家去了。而且,这件事可能成为他这辈子的阴影,说不定新婚之夜因此不举了呢。别笑,真有类似这样的案例。

 

人非圣贤,孰能无过。难得的是勇于承认自己的问题。

 

我自己带团队也犯过这样的错误。黑色愚人节和黑色星期五,发生在某年的四月和五一。连续两个月,团队出这样的问题,你可以去算一下我的心里阴影面积了。

 

分别是什么问题呢?

 

四月一号,是一个工程师接到工单,工单上写着要“解绑某个用户的数据库读写权限”,工单流转到数据库组来,他按照字面意思就做了。然后,就有业务反馈不能用了。

 

发生这个事故,有两个原因,一个是本身流程有问题,工单需求本意是解绑个人用户的相关4A权限。但是,工单里居然有核心数据库用户名。二是,实习生本身的问题,工单本身是最简单的事情。要求任何有疑问的地方,不要去执行,而是先找你的指导老师。这位工程师因为对各种技术理解和沟通都算上乘的,所以很有傲气,觉得自己理解的没问题、自己做的没问题。到最后离开了,她依然认为自己按照工单这么操作是可以的,觉得流程才是导致她犯错的原因。

 

对于更高一级领导来说,影响了业务才是天大的事,就算各打五十大板,直接导致问题的那端,总是难逃其咎的。

 

这个事情发生后,团队的心理压力都很大。

 

但是到了五一,还是又出了问题。

 

一贯有工作认知的某同事,在做数据清理的时候,本意是清理某个分区的,他把整个表都清理了。总共涉及了8张表。虽然多年过去了,这些数字真的不会忘记。

 

幸运的那些表是历史表,生产业务无感知。我前前后后投入了6个人,弄了一个月才把数据恢复回来。

 

今天晚上跟一个老客户聊天,认识十几年了,现在我们一班小朋友在给他做维护。他觉得我们现在的团队很好,新进团队的一个小朋友他感觉非常不错。他之所以对这位小朋友感觉特别好,是因为这位小朋友是我们从别的大客户调过来的,他就觉得干过大型系统的人,就是不一样,说什么他听得懂。

 

他说的其实是什么意思呢?他说的是,这个人是经过调教的。

 

什么算是经过调教的呢?

 

懂得游戏规则,遵守游戏规则,在规则内创新。

 

我之前写过一篇文章,名字叫做《运维DBA的四大纪律9项注意》,可以算作一种规则。但具体到各个团队,其实会有更加分解的东西,更加场景化定制化因地制宜的东西,才具备可操作性。

 

 

最近还有一个类似的案例,某正在准备IPO的P2P公司,首架被废,百度里的信息已经被清理干净了,脉脉里还在。由于下面员工误操作,导致公司损失百万级,然后老大被干掉了。

 

这才是合理的方式。

 

有人还记得光大证券乌龙指事件么?

 

2013年8月16日,光大证券自营系统由于“存在程序调用错误、额度控制失效等设计缺陷,并被连锁触发,导致生成巨量市价委托订单,直接发送至上交所,累计申报买入234亿元,实际成交72.7亿元。”这个事件是公司赔付,公司老大被掳,N多人被追责。

 

作为一个团队领导来说,有些责任是你天生要背的。如果是运气走背字,那你就等着水星上旋吧。

 

最重要的是先有规则,制定规则流程,宣贯规则,检查确认。没宣贯到,那是你领导责任,宣贯了,但是小朋友还是没做到,那还是你领导责任,你选人看人带人的能力不行啊。

 

以前听过一句话,一个公司的天花板是CEO,一个团队的天花板是团队负责人。最开始的时候真是不懂,现在看得多了,觉得这就是真理。别拿自己的愚蠢,去谋害更多人的青春啦!

 

回到数据库运维这个层面。回到前面有个CTO说,让员工每天手工去检查数据库,我看了直冒冷汗。这是要不折腾死兄弟不罢休啊。

 

那怎么干才是正道呢?

 

虽然我们自己也总结了一套道术器——六脉神剑。但是,我们这次非常荣幸邀请到平安科技数据库技术部总监汪洋,来讲解他们的数据库运维的道法术,几千套数据库包含Oracle、Postgre、Mongo、Redis等各种不同数据库的运维,这个有意思,我也很期待。

 

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告