作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处，谢谢!
网址: http://www.it-infra.cn/How_to_handle_interruption
今天读了<<时间管理--给系统管理员>> 主要原因是当年拜读了Thomas A. Limoncelli的系统<<系统网络管理技术实践>> ，获益菲浅，一直是作为我在IT基础设施部门的指南，仿佛是海上迷雾中的灯塔。以致在现在这家IT基础架构相当优秀公司里，我仍能找到这些思想的影子，优秀的系统管理员都有共同的性格/思维的特性，难道不是吗？
这本时间管理的薄书（加上后记也只是210页），浓缩了接近二十年IT基础设施管理工作中积累的经验，有很多精彩的篇章。其中有一点我想的比较多，那就是如何帮你的系统管理团队搭建防“扰”墙?
相信每个系统管理员在专心做某个项目性的工作，都会对寻求支持的来电这种事情大为光火，呵呵...... 每次手中事情被中断之后，都要补上好几分钟才能把刚才的思路接上，而且非常容易出错。
书中在多处强调“共同防线”，简单来说就是两个系统管理员商量好，一个SA上午处理各种会被打断的杂事务，另外一人在处理一些项目事务，下午则反之。当然，如果重大故障影响了业务中断，那两个家伙必须一起扑上去解决问题。我个人觉得这个处理方法非常棒且灵活。
我们还有很多技巧，比如在系统管理员处理重大故障的时候，我们可以让其它人员来接听电话，向用户解释出了什么问题，我们正在处理，解决之后通知他/她们等等，避免打断系统管理员的思路。但这只是头痛医头，脚痛医脚，如果没有计良好的支持体系，这些技巧也用不多长时间，这本书最后，我觉得也是系统管理员时间管理较高的境界，就是一句话"最终的时间管理技巧是良好IT基础架构"，当然也包括支持架构，这句话在书中的第158页。
在良好的IT支持架构下搭建防“扰”墙才是最根本的办法。在大型公司或者非常庞大的系统，比如Google, Yahoo及其它需要系统网络支撑整个核心业务的公司，他们不但有数量庞大的服务器，网络设备，跨时区支持，而且这些公司都要求非常高的SLA可用性。我们IT infrastructure Manager怎么建立可靠，灵活，高效的支持结构？ 我在这里分享一下实战的经验:
第一：把系统管理团队分成三个虚拟组(Build virtual groups)。
首先是虚拟组是普通系统管理员组(Junior SA)，第二个是系统管理员组(SA)。第三个虚拟组我们称为系统架构组(Senor SA / Sys Arch)。
第二：建立请求跟踪系统(Ticket tracked system)
比较有名的商业的ticket系统叫：BMC Remedy Action Request System
开源的项目有RT系统，也是这Thomas推荐的：RT System
第三：建立值班轮倒制度
建立值班制度，假设公司要求你网站的业务是7X24小时，比如Dell.com，这个时候就要求有24小时值班人员。
第四：把监控系统跟你“请求跟踪系统”连接起来，并在重大故障时短信/电话值班人员
第五：值班支持
平时只有前二个虚拟组成员值班，先让Junior SA（第一组成员）挡掉80%的工作，另外15~20%难度比较大的转到后面SA（第二组成员）上，可能是会有5%的问题涉及到架构性，则转给架构组成员进行研究。
举个例子：公司有5位Jr SA，2位SA，1位Sr SA，平时上班时候，只安排2位Jr SA，1位SA进行值班，处理所有请求跟踪系统过来的请求，以及接听IT热线打过来的电话，时不时还要看看监控报告系统。而其它3位Jr SA就可以进行一些项目性的工作，如公司上线搜索系统需要在机房物理安装十台服务器，包括的工作从资产部门领取硬件到系统安装完成。而另外一位SA就可以准备该搜索系统相关系统配置脚本及验证十台服务器的相关配置。另外一个大牛呢，Senior SA/ Arch就在琢磨怎么用开源的东东搭一个在服务器关机的情况如何远程重启/开机，免得那几个Jr.SA老在抱怨大周末把他们叫到机房重启服务器去。
这样IT支持体系结构不但保证了日常运行维护的请求响应及项目性的IT支持，而且建立了稳固的“防扰墙”，系统管理员高兴，客户happy，你也Happy。
网址: http://www.it-infra.cn/How_to_handle_interruption
今天读了<<时间管理--给系统管理员>> 主要原因是当年拜读了Thomas A. Limoncelli的系统<<系统网络管理技术实践>> ，获益菲浅，一直是作为我在IT基础设施部门的指南，仿佛是海上迷雾中的灯塔。以致在现在这家IT基础架构相当优秀公司里，我仍能找到这些思想的影子，优秀的系统管理员都有共同的性格/思维的特性，难道不是吗？
这本时间管理的薄书（加上后记也只是210页），浓缩了接近二十年IT基础设施管理工作中积累的经验，有很多精彩的篇章。其中有一点我想的比较多，那就是如何帮你的系统管理团队搭建防“扰”墙?
相信每个系统管理员在专心做某个项目性的工作，都会对寻求支持的来电这种事情大为光火，呵呵...... 每次手中事情被中断之后，都要补上好几分钟才能把刚才的思路接上，而且非常容易出错。
书中在多处强调“共同防线”，简单来说就是两个系统管理员商量好，一个SA上午处理各种会被打断的杂事务，另外一人在处理一些项目事务，下午则反之。当然，如果重大故障影响了业务中断，那两个家伙必须一起扑上去解决问题。我个人觉得这个处理方法非常棒且灵活。
我们还有很多技巧，比如在系统管理员处理重大故障的时候，我们可以让其它人员来接听电话，向用户解释出了什么问题，我们正在处理，解决之后通知他/她们等等，避免打断系统管理员的思路。但这只是头痛医头，脚痛医脚，如果没有计良好的支持体系，这些技巧也用不多长时间，这本书最后，我觉得也是系统管理员时间管理较高的境界，就是一句话"最终的时间管理技巧是良好IT基础架构"，当然也包括支持架构，这句话在书中的第158页。
在良好的IT支持架构下搭建防“扰”墙才是最根本的办法。在大型公司或者非常庞大的系统，比如Google, Yahoo及其它需要系统网络支撑整个核心业务的公司，他们不但有数量庞大的服务器，网络设备，跨时区支持，而且这些公司都要求非常高的SLA可用性。我们IT infrastructure Manager怎么建立可靠，灵活，高效的支持结构？ 我在这里分享一下实战的经验:
第一：把系统管理团队分成三个虚拟组(Build virtual groups)。
首先是虚拟组是普通系统管理员组(Junior SA)，第二个是系统管理员组(SA)。第三个虚拟组我们称为系统架构组(Senor SA / Sys Arch)。
第二：建立请求跟踪系统(Ticket tracked system)
比较有名的商业的ticket系统叫：BMC Remedy Action Request System
开源的项目有RT系统，也是这Thomas推荐的：RT System
第三：建立值班轮倒制度
建立值班制度，假设公司要求你网站的业务是7X24小时，比如Dell.com，这个时候就要求有24小时值班人员。
第四：把监控系统跟你“请求跟踪系统”连接起来，并在重大故障时短信/电话值班人员
第五：值班支持
平时只有前二个虚拟组成员值班，先让Junior SA（第一组成员）挡掉80%的工作，另外15~20%难度比较大的转到后面SA（第二组成员）上，可能是会有5%的问题涉及到架构性，则转给架构组成员进行研究。
举个例子：公司有5位Jr SA，2位SA，1位Sr SA，平时上班时候，只安排2位Jr SA，1位SA进行值班，处理所有请求跟踪系统过来的请求，以及接听IT热线打过来的电话，时不时还要看看监控报告系统。而其它3位Jr SA就可以进行一些项目性的工作，如公司上线搜索系统需要在机房物理安装十台服务器，包括的工作从资产部门领取硬件到系统安装完成。而另外一位SA就可以准备该搜索系统相关系统配置脚本及验证十台服务器的相关配置。另外一个大牛呢，Senior SA/ Arch就在琢磨怎么用开源的东东搭一个在服务器关机的情况如何远程重启/开机，免得那几个Jr.SA老在抱怨大周末把他们叫到机房重启服务器去。
这样IT支持体系结构不但保证了日常运行维护的请求响应及项目性的IT支持，而且建立了稳固的“防扰墙”，系统管理员高兴，客户happy，你也Happy。
2009/01/30 18:44 |
[置顶] 某中大型网站系统架构--实战案例研究
作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处，谢谢!
网址: http://www.it-infra.cn/Web_Site_Architecture
你是否一直考虑网站架构要有冗余性，安全性? 同时又有经济性呢？
你是否经历过痛苦的思索网站的架构到底怎么样还算合理？
怎么保证关键业务能够冗余，而其它业务可以选择冗余或不冗余。资金紧张的情况下 可以选择不冗余，一旦资金到位，系统架构又具备一定的灵活性，从而非常方便增加冗余设备？
相信每个网站的系统网络部门都经历了网站系统架构的艰苦摸索，从一开始只有简单的几台服务器，随着业务增长，到了上百台服务器，但从未停止过探索。下面我想把从几次实战的中实验贡献出来，该架构已经在好几个较大的网站已经实施过，其中一个已经运行了4~5年，其中经历过无数次业务高峰的考验。
网址: http://www.it-infra.cn/Web_Site_Architecture
你是否一直考虑网站架构要有冗余性，安全性? 同时又有经济性呢？
你是否经历过痛苦的思索网站的架构到底怎么样还算合理？
怎么保证关键业务能够冗余，而其它业务可以选择冗余或不冗余。资金紧张的情况下 可以选择不冗余，一旦资金到位，系统架构又具备一定的灵活性，从而非常方便增加冗余设备？
相信每个网站的系统网络部门都经历了网站系统架构的艰苦摸索，从一开始只有简单的几台服务器，随着业务增长，到了上百台服务器，但从未停止过探索。下面我想把从几次实战的中实验贡献出来，该架构已经在好几个较大的网站已经实施过，其中一个已经运行了4~5年，其中经历过无数次业务高峰的考验。
转载出处：DBA Notes
http://www.dbanotes.net/opensource/wikipedia_arch.html
本想自己从PDF文档中抓出重点翻译一下，但看Fenng兄已经在Blog讲得比较细，就直接转载，谢谢了，正文如下：
维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。
来点直接的数据：
- 峰值每秒钟3万个 HTTP 请求
- 每秒钟 3Gbit 流量, 近乎375MB
- 350 台 PC 服务器(数据来源)
架构示意图如下：
