存档

文章标签 ‘运维规则’

运维规则浅谈-10

2014年5月30日 2,828 views 没有评论

应该让最优秀的人去做工具/平台。

许多互联网公司都有基础平台的技术部门,专门开发一些基础平台/工具/服务,提供给各个应用研发团队使用。但这往往是一个短期内很难见到效益的事情, 许多时候,业务的发展并不是很快,一些实现,简单的三板斧就搞定了,自然需要不到更高效更稳健的平台级产品,所以,对于业务规模不大的公司,更多的的时候,是在做一些技术储备的事情。基础平台部门往往是伴随着公司的高速发展而壮大的,研发出来的产品/服务如果没有人使用,自然就得不到改进,然后就更加没有人用,这样可能导致一个恶性循环。 这个时候往往是考验 高层的一个决心的时候。 是否能够顶住压力,仍然保留适当比例的底层平台开发人员呢?

研发应用软件和研究平台/工具毕竟不是一样的。如果基础不老,其实业务的风险更大。集中人力/时间做一些平台/工具,其实是节省成本。 当然,前提是,你确实有一批高素质的工程师。

我觉得这点,应该学硅谷的一些公司,让最优秀的人去做平台,做工具,给最好的待遇,给予足够的尊重。对于他们的衡量标准也应该不一样。

运维规则浅谈-9

2014年5月29日 2,443 views 没有评论

运维规则浅谈-9

绩效的本质还是为了个人的发展的。绩效仅仅是绩效,如果以绩效为导向,可能导致工作的不平衡。 没有人不想发展,不想有高薪水的,所以绩效更本质的是应该帮助个人发展,帮助人赢得尊重。 如果本末导致,甚至绩效和个人的价值/行为有冲突,那么就需要考虑其合理性了。有人也许会说个人的价值观和公司的价值观有冲突了怎么办?但一个好的公司,应该是具备包容性的,而员工如果价值观和公司的价值观严重冲突,不能妥协的话,那么还是建议走人的好,继续扭在一起,对于双方都是损失。

绩效仅仅是工具,有时不好衡量人。不知道什么时候开始。绩效主义开始盛行。现在连一些事业单位都在开始绩效考核了。是否有道理呢?每个大公司都会告诉你,绩效考核是必须的。  管理人其实是很复杂的事情,要考虑到事情实在太多了,但绩效这个工具却一下子让事情简化了许多,许多东西,如果无法量化,还真的难以衡量,还真是是考验人的活。 有一些职位,或者一些公司高层,或者销售人员, 还是比较好量化一些指标的,对于他们来说,量化指标,往往是看得见的数字,但对于一些其他职位,可能就很去量化指标了。所以本质上,这是一个复杂的话,仍然需要 各种社会[……]

Read more

分类: 管理 标签: , ,

运维规则浅谈-8

2014年5月28日 2,740 views 没有评论

运维规则浅谈-8

定位瓶颈。

我们需要监控一切,这样我们才能预先发现系统的瓶颈。 对于一些资源的争用,通过监控系统就能够很直观的反应出来。而对于一些隐藏比较深的资源瓶颈,系统瓶颈,往往需要我们利用各种工具,靠经验去分析,判断。我们需要有意思的尽可能的通过监控系统去发现问题,让监控系统变得越来越智能,较少依赖于人的经验。

高级工程师和初级工程师有一个很大的区别,高级工程师知道如何去定位瓶颈所在。不仅知道如何使用工具,还知道何时、何地、为什么去使用工具,这样,他才有可能在问题爆发之前,就定位到瓶颈所在。 那么作为运维工程师,就有必要可以的去训练这种技能。自己测试/验证,wiki分享,组内分享都是可以考虑到方式。

定位瓶颈,还需要比较多的其他领域的知识,因为数据可能经过许多环节,如本地电脑、浏览器、dns服务、负载均衡设备、应用服务器等等。在熟悉自己的工具和领域外,了解其他领域大概有一些什么方法和工具是有帮助的。

运维规则浅谈-7

2014年5月5日 1,662 views 没有评论

运维规则浅谈-7

要避免重复造轮子。 一般来说,重复造轮子在每个公司都存在,而且许多人热衷于此,可能需要这样的项目来证明自己。 但是他们并没有考虑到一个投入/产出比。 能够充分利用社区的成果,利用公司已经有的成熟的框架,可以大大加快自己的项目进度,为什么非要自己做一个呢。 当然,重复造轮子,往往可以真正锻炼到团队,毕竟从头开始做一个东西,所累积的经验值可能比一般项目多得多,往往有助于个人的成长和公司后续的项目。

 

开源产品尽量选择国外的产品,虽然国内有许多公司拥抱开源,但更多的是个人行为,普遍的来说,国内的开源产品,往往缺乏维护,缺乏更高层次的性能/架构/扩展意识,在和国外的开源产品的竞争中,一般都败下阵来,即使是百度\腾讯\阿里也不例外.随着核心人员的流失,或者成员自己的KPI都难以保证,往往不能继续发展下去.  所以在使用其他公司的开源产品的时候,特别是缺乏社区参与的产品时,要很谨慎,最好确保自己有足够的能力进行修改,有专门的源码研究人员,否则一旦出了生产事故,debug本身需要时间,更何况不熟悉代码之下的debug。

 

不要轻信宣[……]

Read more