admin 发布的文章

原文出处: Marcus Blankenship 译文出处:36Kr
编者按:是的,为什么你们这帮程序猿整天就只想写代码?难道做什么不比怎么做更重要吗?但凡你对公司有点奉献精神对业务有点关心的话都不会这样,一切都是你的错,对吧?不对,《Habits That Harm Your Technical Team》作者 Marcus Blankenship 说错不在程序员,错在你们这帮领导。

我面试 Jamie 的时候,他看起来就像一位狂热的工程师。技术技能可靠,对流程和产品改进有想法,也有着很好的团队合作态度,是个明显的选择。

不过 2 年后,Jamie 变成了“那个家伙”。你懂的,就是那个只想不被打扰、埋头写自己代码的家伙。

我本来应该注意到迹象。现在回想起来,他没有站出来说过话,他没有像我预期那样贡献自己对流程或产品的想法,而他的“团队友好”型互动通常是挖苦别人。他经常讨论技术债务,说我们缺乏创新,以及拖我们后腿的“愚蠢”决定。而他的评论和反馈显示出他已经深受“我早就告诉过你了”的情绪之困扰。

Jamie 可能曾考虑过要离开公司。如果他这么做,那我就不能说了。尽管我肯定希望他离开。不过我们现在人手不足,而且我需要能找到的所有帮助。

结果呢?

结果还是老一套,又一位只想着写代码的程序员被孤立了。

环境塑造人

太多经理认为问题出在 Jamie 身上了。如果他是一位好一点的员工、有奉献精神的员工,或者至少多一点关心的话,都不会发生这样的事情,对吧?

不幸的是,不对。

冰冻三尺非一日之寒,热忱的程序员变成偏执的程序员不是一夜之间的事情。但是事情的发展速度比你想象的要快。

第一次建议非常重要

你如何处置新程序员的想法会发出重要信号。不管好坏,这都为他们的预期做好了准备。这决定了他们会不会在将来分享更多的想法……或者闭嘴不再多管闲事。

当然,一些想法在你的环境未必可行。有的可能需要“等我们没那么忙”的时候再进行讨论。有的想法看起来很好,但跟这里的潜规则是有冲突的。

不管是什么理由,鄙视或者贬低你的程序员的想法,尤其是在他们刚来的几个月内做出这种举动是糟糕的做法。

满腔热情被泼冷水之后,他会试着换种方式表达自己的想法,为的是想得到成功的结果。但是如果还是好心被当成驴肝肺的话,他就会意识到唯一的取胜之道就是不玩了。

这恰恰是你不希望你的程序员吸取的教训。

他不再提出想法,不再要求跟客户见面,并且真诚地试图去理解业务。

到最后就变成了双输的局面。

想法越大,风险越大

记住,你的程序员在提出新想法的时候其实是在冒险。想法越大,风险越大。

为什么是风险?因为我们的想法反映了我们自己、我们的观点以及我们的热情。我们不会推动自己不关心或者认为不可行的想法。我们把自己最好的想法贡献出来,希望能够被接受。

这需要有暴露脆弱的勇气,我们只有在相当确定不会受辱的情况才会大胆吐露自己的想法。如果我们认为自己的想法不会被接受的话,就不会再说出去了。

对想法的反馈塑造了行为

那么你的程序员退回去只做能让自己成功的事情,也就是写代码,就是很自然的事了。

令人悲哀地,他满腔的创造、创新和开发热忱都没了。

也许它已经变成了对代码质量或者代码指标不切实际的想法。

他对市场份额和业务健康的担忧已经被对头衔和工资的担忧所取代。他变得更加关心自己挣了多少,自己的头衔是什么,以及自己 LinkedIn 的形象怎么样。

他对改变世界的热情已经被对开发过程的挑剔所替代。

不过更糟糕的是,他对“我们没有开发正确的东西”的担心会被“我们没有把东西开发正确。”的担心取代。

他已经学会了不对要开发什么提供输入,于是他开始对怎么去开发变得痴迷。

对于他来说,你的文化已经变成了适者生存。

你的培训都教了些什么?

尽管你永远都不会直接说这些,但你的培训和文化也许会教这些:

“我们的公司不喜欢小人物的大想法。”
“你做好开发的事情就行了。我们会找出客户想要什么的。”
“你就是个程序猿。”
“嗯……为什么你有十万个为什么。你没有代码可写了吗?”
你的真正文化是什么?

文化不是贴在墙上的口号,也不是在面试的时候你介绍的公司使命。文化是大家的做事之道,是大家真正关心的东西。

德州农工大学教授 Ifte Choudhury 指出:

文化是一群人的生活方式——行为、理念、价值观以及他们接受的象征,一般都是潜移默化,通过一代代人的沟通和模仿而传递下去的。

如果你想知道自己的文化是什么类型,那就看看大家是怎么做的。

如果你不喜欢自己看到的东西,那就去改变它。文化不是命令。而是学习、榜样以及模仿。

作为领导,值得别人效仿是你的工作。

因为文化不是 Jamie 的错。文化是我们的错——团队领导、软件经理以及 CTO 的错。

所以,别再指责 Jamie 了,开始做出你的文化需要的改变吧。越快越好。

如果Nginx没有仅仅只能代理一台服务器的话,那它也不可能像今天这么火,Nginx可以配置代理多台服务器,当一台服务器宕机之后,仍能保持系统可用。具体配置过程如下:

  1. 在http节点下,添加upstream节点。

upstream linuxidc {

  server 10.0.6.108:7080; 
  server 10.0.0.85:8980; 

}

  1. 将server节点下的location节点中的proxy_pass配置为:http:// + upstream名称,即“
    http://linuxidc”.

location / {

        root  html; 
        index  index.html index.htm; 
        proxy_pass http://linuxidc; 

}

3.  现在负载均衡初步完成了。upstream按照轮询(默认)方式进行负载,每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。虽然这种方式简便、成本低廉。但缺点是:可靠性低和负载分配不均衡。适用于图片服务器集群和纯静态页面服务器集群。

除此之外,upstream还有其它的分配策略,分别如下:

weight(权重)

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。如下所示,10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。

upstream linuxidc{

  server 10.0.0.77 weight=5; 
  server 10.0.0.88 weight=10; 

}

ip_hash(访问ip)

每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

upstream favresin{

  ip_hash; 
  server 10.0.0.10:8080; 
  server 10.0.0.11:8080; 

}

fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。与weight分配策略类似。

upstream favresin{

  server 10.0.0.10:8080; 
  server 10.0.0.11:8080; 
  fair; 

}

url_hash(第三方)

按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

注意:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法。

upstream resinserver{

  server 10.0.0.10:7777; 
  server 10.0.0.11:8888; 
  hash $request_uri; 
  hash_method crc32; 

}

upstream还可以为每个设备设置状态值,这些状态值的含义分别如下:

down 表示单前的server暂时不参与负载.

weight 默认为1.weight越大,负载的权重就越大。

max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后,暂停的时间。

backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态

  ip_hash; 
  server 10.0.0.11:9090 down; 
  server 10.0.0.11:8080 weight=2; 
  server 10.0.0.11:6060; 
  server 10.0.0.11:7070 backup; 

}