领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Abel Avram 译者 张龙 发布于 2011年1月3日
在1600 GMT时间12月22日,Skype服务开始无法访问,一开始是一小部分用户无法访问,后来受影响的用户越来越多,最后网络在24小时内干脆就无法访问了。一周后,Skype CIO Lars Rabbe谈到了这背后的原因。
Skype的核心依赖于第三代的P2P网络,它拥有大量的对等节点和超级节点,一个超级节点对应于成百上千个节点。由于Skype并没有中央目录来支持彼此通信的两个或多个节点之间的路由,因此虚拟网络将超级节点作为目录。当某个客户端连接到Skype后,它会将自身注册到一个超级节点上,超级节点会为该客户端分配一个IP地址,,这样想要与其建立连接的其他客户端就能找到它了。当某个用户想要启动IM或是向另一个客户端发起音频/视频会话后就会询问超级节点,然后就会获得目标IP,这样就会建立起这两个客户端之间直接的通信链接。超级节点是Skype网络的重要元素。
Skype还运行着大量的支撑服务器,他们负责发送离线消息。由于突然有大量未发送的消息,因此这些服务器会延迟发送这些消息。Window版本的Skype v5.0.0.152有一个Bug,它会导致应用在接收这些延迟发送的消息时崩溃。最新的Skype v5.0.0.156和Windows下的其他版本以及非Windows系统的所有其他版本则不受该Bug影响,但问题在于有50%的用户在使用这个有Bug的版本,而它正是Skype 5的首个发布版。大约40%的Skype用户都是在线崩溃的,这影响到30%左右的超级节点。
客户端还需要继续运行,重启应用的客户端会导致网络继续搜索仍旧运行着的超级节点,这导致了超级节点的过载。由于Skype在超级节点过载时会启动保护措施,因此这并不会消耗客户端系统过多的资源,超级节点会一个接一个地自动关闭,这会导致整个网络出现故障。
没有超级节点,Skype就将无法运作,因此公司一开始启动了上百个,然后是上千个超级节点,希望能够恢复服务。他们并没有指明使用了哪些系统,或许是他们自己的,也可能是Amazon EC2上的。网络开始基于这些超级节点来构建自身,服务在24小时后恢复了。他们说停止了大多数超级节点,留下了一些来处理各种突发状况,因为圣诞节Skype的使用量会很大。
我们从中学到的经验则是:除非必要,很多用户并不会更新自己的软件。Skype已经有更新的版本了,但如果没有遇到Bug,大多数用户是不会更新的。Skype打算重新检查自动更新过程,或许像Google Chrome那样做:
我们会重新检查向用户提供的“自动”更新过程,这样我们就能让每个人都使用最新版的Skype了。我们相信这些举措会降低这类故障发生的概率。
另一个问题是我们应该尽最大努力来保证软件是经过充分测试过的,Skype决定重新检查“测试过程来确定更好的检测手段以避免会影响到系统的Bug出现”。
最后要说的就是Skype服务器支撑网络的能力,比如用于处理离线IM的服务器,Rabbe说他们“会经常性地检查支持Skype用户的核心系统的能力,并继续在这些系统的能力和弹性上投入”。
根据Skype博客发布者Peter Parkes所述,Skype Connect企业版并没有受到此次故障的影响。
查看英文原文:Lessons Learned from Skype’s Outage
译者 张龙 热衷于编程,乐于分享,对新技术有强烈的探索欲,对Java轻量级框架有一定研究。
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
3 条回复
关注此讨论 回复