存档

‘管理’ 分类的存档

运维规则浅谈-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服务、负载均衡设备、应用服务器等等。在熟悉自己的工具和领域外,了解其他领域大概有一些什么方法和工具是有帮助的。

应该如何正确对待员工的抱怨 (转)

2014年5月14日 3,882 views 没有评论

应该如何正确对待员工的抱怨

以前写的一篇文章,做了一些修改。

在上一家公司的时候,一次新员工培训的主题是员工的工作态度。当时有一个案例:有两个员工,能力不相上下,都合格的完成了工作任务,其中一个员工完成任务的同时中总是抱怨,发牢骚。案例的问题是“给这两个员工进行绩效考评,一个是A,一个是B,你会怎么评?”。

我记得当时我们都豪不犹豫的把总是抱怨的员工评了B,理由是抱怨对团队氛围和士气的危害很大。

现在想来当初的这个判断很草率,不够深刻。

管理者如何正确对待员工的抱怨?

首先应该对员工的抱怨足够重视。

其一是抱怨对团队的危害性。抱怨为严重危害团队氛围和士气。

其二,可以把员工的抱怨理解成客户的抱怨。余世维在一个讲座中提到,“会抱怨的客户是好客户”,因为客户的抱怨有助于提升公司的产品和服务。员工从一定意义上来说就是管理者的客户,管理者要提供“服务”来提高客户的工作效率。既然客户的抱怨有助于提升公司的产品和服务,那么员工的抱怨是否就有助于发现公司流程、制度的缺陷,提升公司的管理水平?

其三,管理者的重要任务之一是发现问题,既然有员工抱怨,那么不是公司管理出现了问题,就是[……]

Read more

分类: 管理 标签:

运维规则浅谈-7

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

运维规则浅谈-7

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

 

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

 

不要轻信宣[……]

Read more

运维规则浅谈-6

2014年1月22日 2,702 views 没有评论

运维规则浅谈-6

虽然我维护的数据库,都尽力会做到完善,有些东西融入到了骨子里,用心、用心、再用心,自然就基本无忧了,服务可用性永远是第一目标。 但国内的现状,或者或我了解的公司,确实有些片面放大了故障现象。 即使是google、facebook、twitter、亚马逊这样的公司,也时不时出一次故障,影响面不一定比国内的公司小。 这个世界上,只要存在着硬件载体,就必然伴随着各种各样的故障。有时为了追求可用性,设计复杂的架构,或者准备过多的冗余设施,往往导致解决方案的成本剧增,而解决方案的复杂,很可能增加维护成本和后期改造的难度。国内的众多公司,真正需要99.99%的高可用的到此有多少呢?有多少不能承受单点故障呢? 许多时候,产品才是王道,短期的失效,可能并不影响到用户的流失。

有时出现性能问题,往往是一件好事,因为往往伴随着流量的巨大增长。而在一定时间内,问题总是可以解的,我还从来没有碰到过用时间解决不了的技术问题,那么出现各种问题,检讨总结之类的往往可以事后总结,重要的经过问题的解决,经验/技术都能够上一个台阶。

当然,不是鼓励 冒险主义, 有计划的冒险才是可取的。在不[……]

Read more

运维规则浅谈-5

2014年1月22日 1,444 views 评论已被关闭

传统行业的容量规划,往往比较固定,可以预知,按生产任务来安排即可。而互联网行业有许多变数,业务的增长,新增的业务,有时资源很紧张,有时资源又很空闲。如果不能从更高的规划角度了解情况,可能导致资源的手足无措。 作为基本的团队,可能不太了解实际的高层想法,但也应该尽可能的贯彻传达一些想法/方向,尽可能不导致资源浪费。

有一些公司可能部分服务器自己托管在IDC,部分使用云服务, 这样也是一个比较折中的想法。而在未来的创业团队,可能部署在云上是更值得考虑的事。amazon已经入华,未来我需要试用下。由于云计算的大量普及,传统的许多调优方式在云中可能不太适用,那么针对云服务的调优(包括数据库),是需要考虑、着力的。

容量规划,应该是提早发现需要扩容,要更主动。 需要留有一定的余量,这样才能心中有数不慌。 如果容量突然扩展,可能导致业务的影响,甚至下线,我们可以理解这也是某种程度的单点,需要尽力避免。
应该把容量规划,作为一个常规的工作定期check。 如果有合适的预测模型更好,但更多情况下可能仍然是基于自己的经验分析,了解业务越深,对性能的规划,会更准确,更前瞻。

分类: 管理 标签: , ,

运维规则浅谈-4

2014年1月20日 1,486 views 评论已被关闭

The devil is in the details.
在做任何操作前,建议都详细看下文档。 产品的说明手册,比如 raid卡的说明文档,就需要仔细阅读,选择合适的参数配置。
往往,默认的配置并不适合生产环境,数据库的升级,网上可能有各种操作说明文档,但会遗漏许多细节,而在特定的生产环境是什么都有可能发生的,所以,要详细阅读下相关版本的升级帮助。甚至准备万一情况下,降级的策略。

由于公司的分工,往往某些人只负责部分系统,缺乏对整体系统的把握,或者即使有相应的方法,但由于基础的测量手段跟不上,不好把握生产环境。 有可能的话,应用系统运维工程师,应该画出自己的物理部署图,了解自己的系统, 对于数据流的图,软件研发同学也应该画出,以便相关人员参考、诊断问题。有相关的网络/物理部署/数据流图,有合适的各个层次的衡量手段,这样我们才能更准确定位到瓶颈所在。
系统维护人员,应该能知道自己的系统瓶颈所在,以及如何确定,要分清楚是什么资源瓶颈, 不要混淆了现象和原因。

运维规则浅谈-3

2014年1月20日 1,449 views 评论已被关闭

比较怀疑国内的公司是不是都严格遵守了“N+1”的策略。一主一从,如果严格执行,可能许多服务器备用。 不过现在的数据库服务器都比较强劲,多实例下,已经节省了许多备用资源了。
对于应用服务器,大量服务器下,更多的是考量弹性扩展的能力,可以动态的添加计算资源,比留一些备用/限制节点更合适。

一般来说,对数据进行备份的成本远远小于丢失数据带来的损失。
我们的数据库服务器一般在从库进行备份, 但随着数据越来越大,也需要留意大数据/大量节点下的一个趋势,数据使用副本,而不备份也是可能的。

一般的架构/服务 可能要经历 分散 ,集中,分布几个阶段。 集中有几种的好处,但也可能带来瓶颈,充分利用资源,尽可能并行处理,是需要考虑的。

分类: 管理 标签: ,

运维规则浅谈-2

2014年1月20日 1,522 views 评论已被关闭

保持简单。 生产中常见的问题,是复杂性导致的问题,在这里要区分,那些是必然复杂的,那些是”想当然的“,”错误的理解“导致的复杂性。 如跨IDC的网络复杂性就是必然的,需要更复杂的处理策略。 比如 程序/项目 过多的数据流层次,就可能是不需要的,层次多了,而没有合适的协议约定,往往导致连锁反应,诊断困难,开发复杂。

cache or buffer 数据,应该限定在保护不容易扩展的资源,如数据库的大量读取。 或者提升用户体验,如在靠近用户的城市部署图片cache节点。 当资源很好的水平扩展的时候,添加cache层往往不是一个好主意的,可能因为cache的失效,导致应用的连锁反应失败,这样的情况可以看作一个”单点“。

没必要重复造轮子,也没有什么都从外部获取工具/代码/框架。有时从头开始做一个东西,可以锻炼团队,即使失败了。 在合适的时间以合适的成本切入是需要考量的,投资回报率是是需要考虑的。
这点需要”允许出错“的企业文化,或者”允许出错“的运维文化,传统的KPI可能对此形成不必要的桎梏。