小学四年级玩老爸购物中奖而得的小霸王电脑学习机,大学四年级玩新浪的DELL服务器。
分页: 1/5 第一页 1 2 3 4 5 下页 最后页 [ 显示模式: 摘要 | 列表 ]
  老婆在我的豆瓣上看到我想读这本书:《时间管理——给系统管理员》(Time Management for System Administrators,By  Thomas A. Limoncelli),于是悄悄买了这本书,送给我作为情人节礼物。虽然我现在主要从事系统架构与系统开发,研发时间比以前充足得多,手中的服务器异常的稳定,不像以前有那么多系统运维的琐事,但这本书却使我受益匪浅。

  我翻阅了一下,虽然页数不厚,但内容很不错,书中告知了很多时间管理技巧,是作者工作经验的积累,非常值得借鉴!另外,语言也十分风趣。本书不只适合系统管理员,也适合所有从事IT业的人。

  书籍简介:
  中文书名:时间管理
  副标题:给系统管理员
  英文原版书名:Time Management for System Administrators
  译者:O'Reilly Taiwan公司
  作者:Thomas A.Limoncelli
  ISBN:9787564109059
  页数:210
  定价:26.0
  出版社:东南大学出版社
  装帧:平装
  出版年:2007
  豆瓣上的介绍:http://www.douban.com/subject/2253513/
  英文原版下载:http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=4824885

  时间是珍贵的东西,对于系统管理员而言尤甚。没有其他工作会把那么多领域的事情一次推给一个人做。使用者经常以他们的请求干扰你,让你无法完成经理指派给你的长期项目;还有你的计算机就是不听话,总是在最关键的时刻与你耍脾气。尽管你精通职务上的技术,但是仍然发现必须在晚上和周末加班,只是为了满足一些要求。这只会随着时间给自己增加压力。

  本书讨论的策略,不但帮你解决日常工作,还有能力处理无法避免的突发状况。作者将自己长期的职业生涯,诸如,支持桌面应用、服务器管理以及安全和软件开发等等,在本书中详实地举例说明。这意味着,你将得到有实战经验的建议,而非象牙塔般、从未在混沌的网络中工作过的陈腔滥调。

  在其他技术上,你将学习如何:
  ·管理干扰
  ·消除时间的浪费..
  ·保持有效的日程表
  ·将经常发生的事情变成例行公事
  ·专注在手边的工作
  ·以客户预期排列优先级
  ·文件化和自动化处理以便快速执行...
  这个情人节,我只能晚上和老婆一起过了。因为2月14日、15日两个周末,我在参加北京金山软件公司的重要研发培训──《软件需求管理最佳实践》,讲师为曾任微软亚洲工程院测试经理的陆宏杰。

  课程大纲:
  课程主要议题:
  1、对软件需求的理解
  课程的中心思想是通过需求分析来提高项目整体效率和产品定位,节省开发、测试、管理的实施成本。对于每一个具体环节将从客户、开发、测试、管理的角度分别看待需求分析。
  讲解软件项目的需求划分技巧;以及如何管理多名需求人员对产品/项目的整体把握,保证多名需求人员对需求理解的一致性;产品型和项目型软件在需求分析时的区别、技巧、以及如何快速把握需求关键点。

  2、需求文档
  很多时候需求人员过分关注特定的理论图形或表达法,而忽略了需求文档的实用性,这一部分从实际出发,讲解需求文档的质量标准、到底应该细致到什么程度才能对开发、测试及管理提供有力支撑,结合实例讲解需求和架构的配合,需求和开发的交互。
  分析是否需要进行多次需求文档的转换,这样做的目的和结果是怎样的。分享需求文档的评审流程和规范,为什么要这样做,能够为管理层提供哪些支撑。

  3、需求的细化
  不仅讲解对显性功能和隐性功能的需求细化原则和技巧,而且分析为什么要考虑这些方面,不这样做会怎么样,每一部分都结合实例进行,同时结合需求细化讲解需求对测试的影响和交互,从测试的角度看待需求分析有什么样的配合技巧。

  4、需求人员在整个软件生命周期中的作用
  需求人员应该对整个软件生命周期提供持续的驱动力,需求人员在开发阶段、测试阶段、变更处理、甚至商务处理可以发挥哪些重要的作用。
  同时,分别从“任务”和“人员”两个不同角度讲解如何优化项目开发模式,把瀑布式、迭代式等多种项目管理方法结合,利用最小化的资源提供最大化的产出。
 
  课程中逐一要解决的问题:
  1、需求分析缺乏经验
  2、团队对设计目标的理解不一致
  3、需求分析过程同软件开发过程严重脱节
  4、无法有效的将从客户获取的信息转换成软件设计文档
  5、开发人员和需求分析人员互相不认可,无法形成有效的协作
  6、需求不明确,测试很难开展

  更多信息见:http://www.msup.com.cn/?mod=training&show=6

百度的网通机房挂了几分钟

[不指定 2008-12-11 16:36 | by 张宴 ]
  2008年12月11日16:21~16:26,百度的网通服务挂了。网通机房的两个F5 BIG-IP虚拟IP:202.108.22.5、202.108.22.43全部无法访问。16:27左右恢复正常。

  下面是我写的一个“CDN智能DNS解析分析工具”,可以列出各类用户访问 www.baidu.com 被解析到的服务器IP地址(可以看出百度主站的IDC全在北京,前段时间还有一个北京长城宽带的多线IDC,现在去掉了),当时直接访问百度电信机房的两个虚拟IP是能打开的:

  中国电信用户[北京]
  220.181.6.19 (北京市·电信)
  220.181.6.18 (北京市·电信)

  中国网通用户[北京]
  202.108.22.5 (北京市·网通)
  202.108.22.43 (北京市·网通)

  中国铁通用户[北京]
  202.108.22.43 (北京市·网通)
  202.108.22.5 (北京市·网通)

  中国联通用户[北京]
  202.108.22.5 (北京市·网通)
  202.108.22.43 (北京市·网通)

从豆瓣宕机看IDC单点问题

[不指定 2008-10-31 17:26 | by 张宴 ]
  豆瓣从上午11点开始宕机(见:http://blog.douban.com/douban/2008/10/31/139/),到现在已经超过6个小时了。

  豆瓣的服务器托管在京东某BGP机房,我在那个机房有机器,试了试,从IDC内部是能访问的。另外,和豆瓣同一IP段的http://59.151.41.22/从外部是能够访问的。所以,我估计是IDC机房内豆瓣那一组线路的问题。

  看来,多IDC异地容灾还是很重要的。IDC不出问题则以,一出问题,就成了最大的单点。

  IDC机房内部到豆瓣路由是通的:
[root@localhost ~]# traceroute www.douban.com
traceroute to www.douban.com (59.151.41.93), 30 hops max, 38 byte packets
1  59.151.xxx.xxx (59.151.xxx.xxx)  0.929 ms  0.917 ms  0.954 ms
2  59.151.96.65 (59.151.96.65)  0.534 ms  0.249 ms  0.263 ms
3  211.151.227.86 (211.151.227.86)  1.931 ms  1.100 ms  2.053 ms
4  59.151.41.93 (59.151.41.93)  0.259 ms  0.252 ms  0.265 ms


  从IDC机房内部是能访问豆瓣的:
[root@localhost ~]# wget http://www.douban.com/
--16:12:15--  http://www.douban.com/
          => `index.html'
Resolving www.douban.com... 59.151.41.93
Connecting to www.douban.com|59.151.41.93|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,074 (17K) [text/html]

100%[=========================>] 17,074        --.--K/s            

16:12:15 (12.21 MB/s) - `index.html' saved [17074/17074]


  8月19日消息,百度大规模拆空搜索服务器硬盘传闻获得百度官方证实,19日下午,百度宣布搜索服务器正式使用闪存(Flash Memory)技术代替硬盘并大规模商用,百度自称是全球首家服务器使用闪存技术的互联网公司。

  这是否预示着一个新的存储时代的到来?

  点击在新窗口中浏览此图片

  相关新闻:
  http://tech.sina.com.cn/i/2008-08-19/16072400910.shtml
  http://tech.163.com/08/0819/14/4JNF85V1000915BF.html

Tags: , , ,
  1、通过镜像站
  http://mirror.optus.net/sourceforge/
  http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/

  2、通过Google代理(虽然是针对手机上网的,但是PC上的浏览器也可以访问)
  http://www.google.com/gwt/n
  http://www.google.com/gwt/n?u=http%3A%2F%2Fsourceforge.net

  3、找国外代理服务器

  4、名称以F开头的某软件(不便公布)

2008开源在中国

[不指定 2008-6-24 08:29 | by 张宴 ]
  虽然没有订阅过全年的《程序员》杂志,但是,买到的这本以“2008开源在中国”为主题的2008年06期《程序员》,还是值得一看的。

  点击在新窗口中浏览此图片专题布局:
  (1)2008开源在中国
  (2)说不尽的开源——记“开源在中国2008”研讨会
  (3)摸着石头过河——记开源社区huihu.org
  (4)莫等闲,抬望云和月
  (5)从一封信说起——记姜太文博士和他的XOOPS项目
  (6)比开源更自由的存在——哲思自由软件社区专访
  (7)解密淘宝网的开源架构
  (8)自由软件和新浪网
  (9)项庄舞剑,意在沛公?——评国际软件巨头的开源策略
  (10)大企业如何助力开源
  (11)让漫天繁星在指尖随心闪耀——专访开源专家马越
  (12)开源商业模式介绍
  (13)与开源共成长
  (14)ZK创始人叶明宪的开源进行时
  (15)开源者说——一个开源项目贡献者的自白
  (16)开源离我们有多远——中国开源现状调查
  (17)开源授权协议(License)初探
  (18)一个程序员谈开源  

  架构专栏:
  (1)Web架构师的能力
  Web架构师要在技术和业务之间找到平衡,选择最低成本的技术来实现业务需求,还要适当地为业务发展保留适当的平台空间。  

  (2)炫目的敏捷架构师
  随着敏捷软件开发的理念和方法论逐渐被越来越多的人接受,敏捷架构师在团队中的地位也越来越重要,本文讲述一个敏捷架构师应该具备的一些基本素质。  

  (3)写给Web2.0站长,不仅仅是泼冷水
  看到国外Web2.0站点的火热发展,国内众多Web创业者两眼发红,抄得兴起。然而没有扎实的技术积累和人才储备,要想持续发展几乎是不可能的事情。  

  (4)豆瓣的架构  
  经常有人说web2.0融资困难,商业模式不清楚,可能这是真的。但从技术上看,互联网技术不可能一成不变,本期选登的这两篇文章,可以让我们看到这方面的发展。  
  keepass 能帮助您安全的管理密码。你可以把所有的密码都放入一个带锁(密码)的数据库中,这样你就只用记住该密码(锁)就可以了。而数据库是用当今最先进的加密算法(AES)进行加密的。

  KeePass 官方下载地址:http://keepass.info/download.html

  KeePass 1.11 绿色中文正式版:
  运行平台:Windows

和谐[原创]

[不指定 2007-10-22 23:02 | by 张宴 ]
这是一篇隐藏日志。您需要以合适的身份登入后才能查看。
这是一篇隐藏日志。您需要以合适的身份登入后才能查看。
Tags:
  今天,我将自己s135.com域名的MX记录绑定了微软的“Windows Live Custom Domains”免费自定义域名邮箱,注册了类似 的邮箱,每个邮箱的空间大小为2G。邮箱Web登录地址为:http://mail.live.com/

  然后,我下载了微软的“Windows Live Mail Desktop”邮件客户端软件,它可以发送、收取 hotmail 和 Live Mail 的电子邮件,还有两项重要的功能就是可以同步服务器和客户端的电子邮件文件夹、可以使用MSN的联系人列表。由于 hotmail 和 Live Mail 免费邮箱不支持POP3和SMTP协议,所以 Foxmail 等一般的邮件客户端软件无法收发 hotmail 和 Live Mail 的邮件,而“Windows Live Mail Desktop”除了支持POP3和SMTP协议外,还支持HTTP协议,可以通过URL地址 http://mail.services.live.com/DeltaSync_v1.0.0/sync.aspx 收发 hotmai l和 Live Mail 邮件。

  点击在新窗口中浏览此图片

Tags:

缅怀QQ、MSN时代[原创]

[不指定 2007-7-25 15:01 | by 张宴 ]
  为了防止使用QQ、MSN等IM工具而导致商业机密被竞争对手截获,要求所有人禁止使用QQ、MSN,改用新浪自己的聊天工具UC讨论业务、传递文件。

  我的UC号103500(特殊号码:10+新浪员工号3500)在入职那天就拥有了,但我未曾理过它,直到今天才去使用。以后,将天天与它相伴了。

  说实话,目前公开发布的UC2006正式版确实不怎么样,不过正在内部测试的UC2007beta1无论从UI界面,还是功能上来说,都还不错。以下为2007年7月19日的UC2007beta1内测版截图:

  点击在新窗口中浏览此图片

  在理想国际大厦18层,告别QQ、MSN时代,就在今天;在全国,告别QQ、MSN时代,时间依旧遥远……
Tags: , ,
  上午11:23左右,在公司无法访问百度,开始我还怀疑是公司网络(网通线路)的问题,后来在BBS上看到还有其他地区的网通用户也都无法访问百度。

  后来获知,百度服务器托管的中国网通土城IDC机房发生故障,百度的网通服务器全部无法访问。托管在该机房的大型网站还有搜狐、TOM、九城。我用Linux的dig命令查询出百度的网通IP──202.108.22.5、202.108.22.43,直接访问IP也无法打开:
引用
[root@zhangyan4 zhangyan4]# dig www.baidu.com
;; ANSWER SECTION:
www.baidu.com.          84      IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       303     IN      A       202.108.22.5
www.a.shifen.com.       303     IN      A       202.108.22.43

  20多分钟后,百度恢复正常。我再次dig一下www.baidu.com,发现域名已经解析到220.181.37.4、220.181.38.4这两个电信的IP上:
引用
[root@zhangyan4 zhangyan4]# dig www.baidu.com
;; ANSWER SECTION:
www.baidu.com.          129     IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       356     IN      A       220.181.37.4
www.a.shifen.com.       356     IN      A       220.181.38.4


  百度在DNS服务器更改域名A记录后,几分钟后理应可以生效。但是域名的TTL记录设置了缓存的时间,在这个时间内,如果需要重新解析域名,会直接从用户本地的缓存读取,而不是直接向DNS服务器请求。这样就导致了在百度网通机房发生故障的那段时间内,访问过百度的网通用户在百度切换域名后的一段时间内仍然无法访问。

  上周,我部署过一组的服务器,可以像百度一样进行电信、网通线路互相切换的容灾处理。但电信切到网通,网通切到电信,必将导致其中一方用户的访问速度变慢,所以只是解决故障的权宜之计。等我们部门本季度的服务器采购到位后,我们将部署北京电信与外地电信,北京网通与外地网通之间的冗余互备。
  点击在新窗口中浏览此图片

迈出北京,扎根全国[原创]

[不指定 2007-7-12 23:58 | by 张宴 ]
  sina播客的访问量越来越高,北京机房的网络带宽越来吃紧,服务器的系统负载居高不下,每天的系统报警邮件不下百封。必须对播客的原有网络构架做出调整了,于是,在北京以外的城市部署服务器,成了迫在眉睫的事。

  这周三,我加班到晚上11点,终于画出新的网络逻辑结构图和网络物理结构图,Q3(第三季度)将按照这种结构在全国部署服务器。同事LB更郁闷,填的服务器采购单因为成本上升的百分比太高,被打回重填N多次。今天,我们的“先遣部队”──从博客部门借来的几台服务器在广州电信机房安家,采购的新服务器将陆续到位。
  新浪与中国电信之间,一项涉及到我所在部门──的合作昨天正式对外公布。新浪的视频内容资源+电信的网络带宽资源,形成了一种强有力的优势互补。播客等形式的视频分享网站,对网络带宽的要求很高,需要支付给基础电信运营商高额的带宽租赁费用。新浪与中国电信达成合作,将节省播客的高额带宽成本,再加上新浪和中国电信互联星空的用户群基础,从而间接形成了对其他视频分享网站的竞争优势。可惜我离开北京回学校弄毕业论文去了,不能亲眼目睹新闻发布会。

  

  新浪科技讯 2007年5月17日,新浪与中国电信联合召开新闻发布会,正式宣布双方在播客业务上结为全面合作伙伴关系,将以联合品牌“新浪-互联星空播客”的全新形象跟网民见面。今后,网民不仅将体验到速度更流畅、内容更丰富的播客平台,而且无论在新浪网,还是互联星空网站都可使用播客的全部服务。

  在视频分享领域,基础电信运营商与门户网站的全面合作,在国内尚属首例。双方合作后,新浪将负责新浪-互联星空播客的运营,中国电信将提供新浪-互联星空播客运营所需的网络资源。此次新浪与中国电信在播客产品上的全面合作,不仅是新浪在网络视频平台建设方面的重大举措,也是中国电信整合互联网资源的有益尝试,成为中国网络视频发展史上的又一里程碑。一方面,中国电信的带宽优势将大大提升播客视频的浏览速度,实现播客用户体验的一次飞跃性发展;另一方面,新浪强大用户基础和内容资源则使中国电信轻松完成网络视频分享平台的建构,成为中国电信互联星空无可替代的内容资源。

  播客的核心价值在于音视频互动和分享,对于网民而言,除了内容的丰富生动之外,音视频的浏览速度快慢直接影响用户体验,因此,高投入的网络硬件需求成为播客发展的关键因素。新浪与中国电信合作将大大提升播客音视频的浏览速度,使画面更加清晰流畅,为广大网友提供更优质快捷、更人性化的网络视频服务,让网民真正享受播客“自娱众乐”的乐趣。

  附:“新浪、中国电信”播客产品合作专题(http://tech.sina.com.cn/focus/sina_dx_V/index.shtml
分页: 1/5 第一页 1 2 3 4 5 下页 最后页 [ 显示模式: 摘要 | 列表 ]