Tag Archives: Management

技术转型的背后

某公司开发人员对该公司 DBA 不愿意从 Oracle 转到 MySQL 评价说「读点源代码会死吗?」

我看到该信息后评论到「能读源代码有个屁用?」 这有些偏激,读代码当然有用,不过读懂代码只是锦上添花的事儿,并不代表能管理好数据库。

就我对 DBA 群体的了解,不愿技术转型的原因典型可能在于:

1. 不少 DBA 的「不愿意」其实是对对行政意志的抗拒. 一个大型团队里面,的确要经常面对并且服从各种决策,不过,如果技术决策无视具体环境,违背了客观规律,完全是出于一两个人的好恶的话,那么对于整个团队来说,并不是好事情。理性的人一定会提前发出自己的质疑或是忧虑。

2. 也有是出于对 MySQL 的「不信任」。这几年 MySQL 有了很大进步,开源社区对 MySQL 的改进也相当好,但是,缺陷还是很明显的,比如,对于联机维护的支持能力至今还是不够的,尤其是对于需要支撑密集并发事务的网络应用来说,达不到工业强度。「可靠性」有的时候比「好用」或是「便宜」什么的更为重要。或许有人不信,拿 Facebook 来反驳,人家不是搞定了么?没错,Facebook 搞定了,但是记住,Facebook 的产品业务类型跟贵公司业务是一样的吗? 如果 DB 本身无能为力,你能从架构角度保证不影响业务呢? 另外,去看看 Google 为什么要开发 F1。

3. 对于某种「不确定」性的恐惧。对于一个自己暂时无法掌控的事物有排斥感,这也可能是人的某种自我保护的天性,超出了自己的「技术舒适区」,担心自己被淘汰或是价值被稀释。如果遇到持这种想法的人,倒是可以对他激励一下,「不都是数据库么?」小马过河,试试深浅再说。

4. 或许还有其他原因,不一一列举。

不过,不管什么原因,「读点源代码会死吗?」这种话都类似于体委主任要刘翔顺便去跑个百米比赛一样,不都是田径短跑么(原理都没变,不都是数据库么)?跑快点就行了嘛 … 读懂 MySQL 代码的人一堆一堆的,能给 MySQL 提交 Patch 的开发者估计在各大公司也不在少数,但是如果几十台上百台服务器崩溃掉,整个技术团队都看着你的时候,你能气定神闲的分析代码然后写个管用的补丁出来么? 这个时候,可没有人会提 「 MySQL 给公司解决了多少成本」,管理者会暂时忘了那事儿,他这个时候关心的是「可用性」了。

DBA 和做 Coding 是泾渭分明的两种思维模式,并无所谓高下之分,会写代码的没必要看不起做运维的,掌控数据的也别看不起做功能实现的,都是看人担柴不费力,如果你是真的去经历一番,就会得出另一种结论。

PS. 这个话题还会引出另外值得讨论的话题来,比如「技术决策的是与非」,今天日子特殊,等我有空再写一下。

EOF

大技术团队的危险性

技术团队小的时候,似乎只有人手不够才是最大的问题。而随着队伍壮大之后,管理者会最终发现除了徒增更多的沟通交流成本之外似乎并没有带来额外的生产力。

一个庞大的技术团队就好比那艘叫做 瓦沙 (refer 2) 的大船,看似将来可以横行海上,其实自身恰恰最为危险。

大野心

这是大技术团队中最容易发生的一个问题。兵强马壮,高手云集,那就造一艘大船!逐一制定看似切合实际而实际超出团队能力的目标,要做就做大的,颠覆性的、革命性的、划时代的….项目,而对小项目根本不屑于一顾。历史给我们的经验教训是,凡是过于庞大的东西迟早要毁灭

对于大项目,我最喜欢讲的一个故事是”大山临盆”:

大山临盆,天为之崩,地为之裂,日月星辰,为之无光,
房屋倒塌,烟尘滚滚,天下生灵,死伤无数
--最后生下一只耗子

大一统

团队一大,管理者喜欢制定一些条条框框的东西,”规范化”是一把双刃剑,这事情本身没错,但不可采取”拿来主义”照搬别人的做法,也别听一些厂家的蛊惑而购买”停不下来的红舞鞋”。切记不可抹杀团队成员个性,不要降低团队成员生产力,不能以浪费团队成员激情为代价。不然的话,大团队也必然暮气沉沉。团队成员能动性发挥不出来,再加多少人力也于事无补,只能陷入焦油坑,越挣扎越难摆脱困境。

乱想录@BetaCafe

EOF