小测aryaka服务

aryaka是一家做互联网加速的互联网公司。我们大猫同学想要用他们的加速服务来进行互联网服务。

到底要多快呢,大猫同学设想的是中国到美国在100ms以内。这个有可能吗?

通过公开的资料,中国到到美国有2条海底光缆: 分别为TPE和CUCN,其中TPE全长17700KM, CUCN是36800KM。

参考资料:

http://en.wikipedia.org/wiki/TPE_(cable_system)

http://en.wikipedia.org/wiki/CUCN_(cable_system)

同时我们知道,tcp通讯基本都是全双工进行的,所以RTT都是是2倍的物理距离。 同时物理原理告诉我们,光速每秒是30万公里/小时。由此我们就可以计算中国到美国最快可以到多久之内完成呢。

17700(TPE)/300000(光速) * 2 = 118ms

由此可知要实现中美之间80ms以内传输是完全不行的,除非你认为塞班和关岛也算美国本土。

因此我在测试之前我就知道这个要求是根本无法实现的。 但是为了想看看aryaka的一个服务,于是还是稍微测试了一下,并用tcpdump做了记录。

要使用aryaka的服务必须先跟对方的pop点进行连接,连接了这个pop点后就可以直接通过aryaka内部的路由到达我们洛杉矶的AWS服务器上。

但是连接了之后发现,ping的延迟还是在200ms左右,于是问了aryaka的工作人员,他们说他们对tcp的连接做了加速,于是就用tcp进行测试,发现连接真的很快啊,几ms就已经建立完成了,可实际要传输数据的时候还是在200ms左右。

tcpdump

而从tcpdump里的数据可以看到,实际的IP并不是我发起方的一个IP,而是他们在美国的一个POP点的IP。 于是我基本可以推测出来,所谓的tcp层连接快其实是一个假象。

推测出来的结果来就是:

1. aryaka内部网络是始终保持连接的。

2. 你一旦连接了aryaka的一个pop点后,这个pop点会立刻进行返回,并告诉你连接已完成,对对端也是pop点跟对端之间连接完成就认为是连接完成。

3. 实际数据传输的时候还是走的aryaka的内部网络,这个说实话还是很快的,从北京去往洛杉矶下载可以在450KB/s, 而不走他们的网络是70KB/s。

4. 断开连接同样也是跟pop点断开就认为是全部断开了

不过测试下来感觉aryaka比较适合对于传送数据要求稳定的要求比较好,毕竟比直接介入MPLS会节省很多费用啊。不过我也没有问过aryaka的价格结算方式。


Advertisements

2月的最后一天

今天是4年一遇的2月29日。今年真是啊,工作吧抓不住KPI,老被领导训。可我的想法呢,要是连基础的都没做好怎么可以着急上线呢?

人老了,学习的能力就变差了点,所以只能是更努力的接触新的事务。最近看了很多关于政治的书,很多都是关于国家兴衰的。想来公司也是一样的,左派右派,极左极右等等都有。

今年还把一个NOKIA手机给弄坏了,狠下心买了个HTC S510e。不过还是挺值得的,毕竟很多读书的感悟在坐地铁的时候都可以写上,每天的日程安排也可以在空闲的时间里写完。但是工作中还是有很多不可控的事情还是很多。但是基本上还是井井有条的。

在KPI中需要把每个事情都要做要timeline,而一旦之间有一步出现问题,那就需要尽快解决,然后再回到timeline上。而对于分解问题也是个大学问。

而对于向领导提供报告,这个也是个学问。主要是如下内容:
1. 首先你可以写一些目标或者概要以及介绍
2. 我们所面对的处境和问题是什么?
3. 当我们应用了新的解决方案会带来哪些好处(一个简单的图来进行描述)
4. 你可以先展示当前的网络架构和数据使用,然后展示你们自己的预估的数据方案和建议的网络设计

5. 根据语句,你说每天5GB增长,它确实是真实的每天增长的吗?还是只是偶然的。根据一周的趋势来进行预估。确定这些数据是从哪里来的? 通过预估他们会增加到多大, 比如追踪, 关键字广告, 活动等等,如果你能得到这些信息。
6. 在自己的方案A和B中进行比较,要找到比较的重点和方法。已经描述的架构的数据流,但是你解释下更多的优点和缺点在这些架构吗?比如性能,延迟等等并进行比较。
7. 对于其他方面的考虑,主要是上面缺少的内容

8. 保证所用的术语要前后一致。

IT资产管理系统

作为IT基础系统,以前就觉得监控和报警系统是非常重要,其实也是很重要的,但是这2块有很好的开源软件支持,比如cacti,nagios,zabbix这样的。以前不是特别注意资产管理系统。后来去了搜猫以后发现要管理那么多数量庞大的服务器还是不能光靠excel啊。

也不能用wiki来代替啊。于是又去sf.net上找合适的开源软件了。这2天就一直忙这个事情。由于sf上很多软件都没有截图,所以根本不知道有些什么功能。于是这2天就一直在测试这些东西。

glpi是太大名顶顶了,还有中文版本,还有很多第三方的插件,但是功能实在太多了,而且确实比较庞大。基于php和mysql,这个确实是我想要的。
rackmonkey这个是perl加mysql的。而且它的INSTALL文件说的不够详细,自己看error日志才搞定了。功能简单,满足对于机房管理的需求,但是没有硬盘啊,内存这些栏目,但是在机架部分做的比较好。

后来又用inventory和asset在sf和github搜索了大量的软件,基本上都有或多或少的问题。 比如racktable这个也基本针对是机房的,还有个winventory是基于windows的。

我的需求其实比较简单,首先是要有权限管理,其次要能手动录入各种资产信息,比如机架位置,CPU个数,硬盘,RAID信息,这个机器的IP以及用户名密码。其次要有搜索和排序功能。

但是最终也没有找到特别合适的,在硬件资产管理方面可以推荐用itdb,基本上硬件信息都很全了,是PHP+SQLITE的。这个真是脑残的选择,更加关键的是居然SQLITE的版本过高,centos5.7自带的版本没法使用。另外这个没有用户帐号信息的录入和保密功能。

用户帐号管理是用的cPassMan来进行管理的。这个东西版本更新还挺快,可以生成也可以管理密码。几次key认证也不用怕数据库被人导出。但是越做越复杂了感觉。还是1.8的版本更好用点。

看来进行定制还得自己来进行开发相应的功能。这个也是之前公司里每天做的最多的事情。这里可没那么多精力做这个了,都花时间去googlecode, sf, github上找现成的了,偶然还发现以前同事做的东西还给开源了。

还发现有一个叫MyDNSConfig的工具管理DNS也不错,以后用来管理DNS还是挺方便的,这种工具其实以前也都用过。

要做合适的东西都得自己去定制,以前公司还专门养一个部门做这一个系统。大部分系统都是基于php和mysql的。一般不会去用ror或者python来写。python最大的用途就是经常写点脚本,从来没有写过大型的web程序。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc

Linux System Admin & MySQL DBA

百度开放大会后感

可怜的小百度

今天参加了百度所谓的开放大会,这个会也成了宣传大会了给。百度以后会将垄断进行到底啊。新的首页成了很多新的网站和应用的入口了。而它们会将更多的依赖于百度。可是这个跟facebook貌似是一样的,因为我们没有知识产权保护和反垄断法。真是替它们担心啊,虽然现在或许增长快点,但是不表示它们会杀鸡取卵啊。

最可气的是小百度公司会务人员给我打过2次电话都说这个会议是有午饭的,可今天去了临到午饭时候却被告知只有部分人员有午饭,请其它人自行解决。你呀的,坑谁呢?明显我本上的餐券是被人人为撕下来的。你撕就撕了吧,也不事先通知,临到吃饭时候才被告知得自己解决?你要付不起这个钱就直接说,别跟小鸡子是的。一点都不大气。

这公司也被我列入黑名单了,另外2个被我列如黑名单的是KFC和必胜客,前者是之前发生过优惠券风波,当消费者是傻子,赔不起就别玩。看看人家之前美国DELL,把硬盘标错价了,结果全部给客户了。而DELL到了中国未必会这样做。必胜客是退出半价后,所有的半价商品的质量都大打折扣,真是一塌糊涂。

问了小百度公司的会务人员,它们的答复是由于今天来的人太多,导致无法给所有人提供午餐,那我又问了给哪些人提供了呢又?得到的答复是花880元买票的和今天7点以前来的人。哇!7点以前来,会议10点开始,你7点以前来,那看来是小百度的铁杆粉丝啊。对于它们我觉得没有意见,人家花钱了你自然要给人午餐,人家是铁杆你也给。那我不知道那些媒体记者和其它高级嘉宾呢?你不会也让它们自己解决吧。好吧,它们对你们来说是客户,而我们这些只是码农而已,掀不起多大的风浪的。你要得罪了它们麻烦可大了哦。

早知道如此,真应该让媳妇给我弄个媒体票得了,虽然也是不花钱,但是得到的待遇肯定是不一样的。

说人来的太多,可所有人都是要注册,然后等待通知的啊,而我还收到2次通知确定我是否来。既然这样你们就没有统计到确定要来的人数?还是发生了某种意外导致统计结果不准确呢?

其实吧这就是一个态度问题,你说人太多就算了,可你们的会务人员冷冰冰的说自己去鸟巢解决中饭。那你总得指个道啊,据我去了鸟巢那么多次的人我也不知道那边哪里有麦当劳啥的,只能坐车去大屯或者六道口啥的才会吃饭的地。

反正特别失败的一次会议。这个让我想起去年velocity
china的会议,虽然人多啊,可井井有条啊,大家也在报名的时候知道了哪些人是有午餐的,哪些人是没有的。而会议唯一的问题就是厅太小了,好多我看后面来的人都必需站着,不过实时口译还是比较给力的。而内容也确实非常充实。facebook在管理和技术上的分享非常好,淘宝技术上的分享也很不错。基本上是有个新的认识

百度这个新首页最重要的就是那个推荐系统,而要做好这个,就是收集非常多的用户数据并进行分析。看来以后数据存储和数据模型的建立是一个大的发展趋势,从我之前同事得到的信息基本是各个公司都在全力发展这个,而这个行业在中国最有可能做的最好的无疑是腾迅啊,掌握了大量QQ用户的信息,而现在又有大量使用QQ邮箱的用户,要进行精确分析简直易如反掌啊。像我们公司这样的第三方的生路也就是在细分领域中进行发展,避免跟腾迅和百度发生正面的冲突。而百度的人才储备和人才保留也是远远不够的,看到那么多前百度员工的离开,这个是有原因的。一个内部已经把领导者说的话当作毛泽东语录的公司必定不会有多大发展。而高级技术人员又是完全崇尚自由的,离开是必然的。哦,还有一个应该是阿里也有大量的用户购买和交易数据,这些应该比腾迅的用户数据更加有用啊。不过阿里虽然表面看着比百度好点,其实也差不多。

而所谓的百度易操作系统,那又如何呢?国内3大互联网公司都有,连中国移动和中国联通都有,太多的结果就跟linux面对桌面市场无能为力一样。

以后你要是看到一个公司CEO还在位的时候就出版自传啥的,那这公司你基本也不用去了。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

Engineering Reliability into Web Sites: Google SRE

Engineering Reliability into Web Sites: Google SRE

Alex Perry

alex.perry

原文:http://research.google.com/pubs/archive/32583.pdf

概要

这个主要讲的是在google的网站保障工程师(SRE, 国内应该称之为应用运维),解释了他的目标和描述它会遇到的挑战

在mountain view, zurich, new york, santa monica, dublin 以及 kirkland的SRE团队管理着许多google的服务和网站。

他们利用分布于全世界数据中心的基于linux的计算资源。

主要内容

  • 根据不同站点来划分组
  • 网站的失效和不可靠会耗尽人力成本
  • 工程师应该专注于消除未来的工作,而不是像救火队员一样,要有一定的预见性。
  • 一个新项目是如何转移到SRE团队的。这个主要是一个新项目是如何从开发转到SRE的。
  • 对于用户量的快速增长要有计划。主要是根据现有的增长速度来进行预测。
  • 估算SRE团队最合理的人数

网站 — 是一项综合的部署

  1. 团队需要确定用户可视化的(可测量的)的在线时间和质量水平
    1. 这个需要掌控所有相关软件和系统的情况
  2. 对于各个组件有深度的了解和知识是很有必要的
    1. 这是一个需要比较陡的学习曲线,这种曲线大部分由于各个组件的复杂性造成的
    2. 要持续的再学习,因为网站是一直都在升级的。要想一劳永逸是不大现实的。
  3. 对于使用共享组件架构的特殊性
    1. 要确定那些共享的组件有很好的可靠性。比如一个网站所用共享的中间层和底层组件。

Reliability – it just works

  1. 最小化的人力成本的使用
    1. 团队管理监控和开发都需要自动化。自动化监控和部署。比如puppet,nagios这些工具
    2. 这个意味着使用脚本工具和数据分析工具。一些初始化脚本和安装工具等等。
    3. 大部分失效都需要适当地自动恢复。当出现问题了能够自动恢复。比如自动切换和重启。
  2. 把更高的风险转移到方便处理的时候
    1. 在工作日之前学习那些已经处理掉的风险(Learn of age mortality risk during preceding workday)
    2. 那些刚开始的风险需要完美的解决,防止影响google现有的业务(Infant mortality ideally also avoids Google meals)

工程师—不是管理员

  1. 对于报警和通知规范需要细致的定义
    1. 在发出通知之前可能错误已经导致了问题。
    2. 通常定义报警和通知规范需要通过多个层次,多个级别,多个角度进行。这个主要是从多个维度来定义。
    3. 这些定义可以通过设计来手动和自动的进行增加。这个就需要自动化的管理平台
  2. 对于项目的升级和扩展进行负责
    1. 计划所有的需求,同时要重视效率。
    2. 文件的bug可以在合适的时候进行修复。

新思维: SRE是兼职的开发人员

  1. 一般工程师都会一周抽一天去做开发
    1. 在其它地方可能会就要利用晚上或者周末时间。
    2. Google的工程师每天都有20%的时间来做这些项目。
  2. 开发者有时候会有其它的想法
    1. 有多少老的网站的工作是需要快速回退的。
    2. SRE有20%的空余时间来做项目,这些项目有趣吗?

最初,网站是需要重点维护的

  1. SRE给出可以自动化的日常事务的指导
    1. 通过消除重复性的工作来减少工作负荷。
  2. SRE指出开发文档中的错误和疏忽,但是我觉得这个最好在开发阶段就指出来。
    1. 开发人员也许会在其它地方也同样给你帮助。
  3. SRE建议附加的长期的监控
    1. 这些建议应该覆盖所有的间隙和跟踪性能。
    2. 管理员需要充分的可信赖的监控。

上线一个新网站是一个契机

  1. 你不要对那些新上线的20%的网站而后悔
    1. 页面调度器可以发出比你想象的更多的警告(一般情况下网站会在任何时候发出警告)
  2. 但是在上线的几周内,SRE的专业知识是很有必要的
    1. 开发人员的工作压力可能降低到1%
  3. 剩余的1%可以在任何时候做
    1. 仅仅写好好的文档可以让别人方便接管
    2. 许多工程师都选择继续使用页面调度器

把网站推给了SRE

  1. 这个决定是逐步变为长期的
    1. 对于一个网站的日常工作会变得减少
    2. 通过优化和分析可以使软件逐步改进
  2. 开发人员仍然会保留很少的关注对于这个网站
    1. 工作主要对针对下一个版本,修复已知的bug
    2. 老的在线的版本会逐渐不重视了
    3. 一个明显的特征就是把这些网站推到SRE这边来进行维护了

on call – more than quick fixes

  1. SRE团队人员需要轮流值班
    1. 修复那些现在还不能自动修复的问题
    2. 通过累计发生的问题来确认优先级
    3. 把诊断的问题和解决方案进行文档话
  2. 一个永久的解决方案需要很长的时间才能完成
    1. 发现文件bug,开发补丁,测试,代码复查,提交
    2. 集成,版本和发布要进行日程安排
    3. 为什么要花大量的时间来做这些呢? 这个主要让SRE的变的更有条理。对于类似X度这样的公司整个运维部门整天就是忙上线实在是无语。

名声 – 越来越多的用户

  1. 网站的稳定性不能由于升级而降低
    1. 网站架构通常是可伸缩性和健壮的
    2. 这些是google软件工程师的核心技能。
  2. 算法的性能是成比例的扩大的
    1. 所以修复bug也要监控和自动操作
  3. 实际上工作压力是随着问题的增加而增加的
    1. 有效的人力确实被现有人数限制着的

事情的增加 — 更多的用户

  1. 工程问题可能会根据用户等比例的放大
    1. 软件中新的功能没有被完全实现。O(1)
    2. 在常规的硬盘挂掉导致服务器down掉。O(u)
    3. 内存中的宇宙射线,新用户的哈希是有效的。O(u2) 这个意思就是说由于算法的问题,导致本来2个用户应该是不一样的哈希结果,但是却变成一样了。这一般要到非常大的用户量才会发生。
    4. 以太网中的比特传输是无序的,所有包都是通过CRC校验的。O(u3) 这个的意思是由于网络流量非常大,以及并发特别高。导致CRC校验也会产生冲突。这得多大流量啊!!!
  2. 更高等级的请问题通常不太可能一开始就发生
    1. 因为他们是有可能发生的,但是是无形的,因此很难被修复。
    2. 但是它们发生后会使问题扩散的很快。

第一次出现 — 对于每一个小时

  1. 想象每10天用户数量就会翻倍
  2. 考虑网站的O(u3)问题
    1. 瞬时的页面比例 = exp(date /5)/k
    2. 累计的页面访问数量 = exp(date/5)5/k
  3. 在你收到第一个页面产生的问题
    1. 期望的第一个页面的时间 = 5 in (k/5)
    2. 在未来的3个星期内,它会每小时报告一次。

多久可以扩展一个网站

  1. 这个主要是看解决问题的决心
    1. 多长时间可以确定问题,并且一个一个解决
  2. 要早期的发现bug需要好的工具
    1. 远程诊断和相关维护的日志
    2. 在发现第2个警告前就要开始解决第一个问题。
  3. 一次就修复bug,这个需要快速地测试
    1. 确认以前的bug不会复现

false positives, false negatives

  1. 谨慎小心的报警会导致一个危机
    1. 导致在压力下会一有问题立即去修复。
    2. 这相反会消耗工程师的时间和精力。因为报警过于琐碎而浪费了工程师的精力。
  2. 通过对于归档数据的分析进行优化
    1. 监控系统通常是不出声的。(正常的时候当然不会报警呀)
    2. 新增加的问题会更容易被发现
    3. 一般问题马上会被侦测到,那网站会变的更快

轻量的SRE团队(Lower bound on SRE team size)

  1. 每周的一天:做自己的项目,就是那些20%没被分配的时间
  2. 每周的1天: 休息,公司事务, 志愿者,或者病假
  3. 每周的1天: 对于网站的特别培训, 学习网站的更改信息
    1. 所有的每个网站培训都是相同的对于团队大小。
  4. 每周的2天: 网站分析,计划相关内容,维护等等
    1. 对于一个网站来说每周需要多少人力?
    2. 这个是确定团队人数的低的边界。

估算on call能覆盖哪些需求

  1. 工程师能否对于一个警告不响应
    1. 如果是,那我们需要实现工程师冗余
  2. 你网站页面服务的失效比例是多少
    1. 有可能会超过10%,很难达到1%
    2. 5%会使用4种冗余的方法来达到99.999%
  3. 对于任何一个报警只能有一个工程师响应
    1. 使用优先级或者选举的手段来避免浪费精力。
    2. 那其它ON CALL的SRE不会感到困扰

网站是否需要合并

  1. 比较网站的工程操作和oncall需求
    1. 可能会让一个SRE团队来对多个网站值班
    2. 培训开销:每个工程师都要学习所有负责的网站
  2. 这种合并整合是一个长期的目标
    1. 有一些观点是,每个网站都会最终停止更新
    2. 然后工程师专门对付较低优先级的问题
    3. 比如一个网站,最终维护的趋势是变为0
    4. 但是覆盖需求的on call人员是固定不变的。

总结:

  1. 网站的有效性是需要不间断的工程性 的努力
    1. 这个比软件实现需要更长的时间段
    2. 工作要有短期目标和长期目标是非常重要的
  2. 大型网站需要一个管理员团队
    1. 如果他们一直都很忙,那就没有空间成长
    2. 让一个团队管理多个网站是比较经济的
  3. 撰写和修改软件来替代管理工作
    1. 随着网站的扩展自动化的好处会越来越多
  4. 团队尽量要小,每个团队都有一个合适的大小

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com

twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

厉建宇的阿里巴巴离职信

厉建宇是美籍华人,好多观念上跟我们有很大的不同。

下文就是他之前要离开阿里巴巴留下的离职信。回顾了他在蓝讯和阿里巴巴的路程。本文也展现了他的一些工作理念,应该说跟着这样的领导还是跟对人的。也许这就是google之所以伟大的原因中的一点:简单。 

中文不佳,全用英文写又无法让更多的同学了解我的心路旅程,所以请各位原谅我蹩脚的中文。

*一个简单的道理:一块2TB桌面级硬盘今天的价格约为700元,相同大小的企业级硬盘一块今天的要价仍然超过1,500元,这两个硬盘最大的差别是RVI震动率的设置(因此,桌面级硬盘在震动率稍大的时候,依然能够正常工作,企业级硬盘为了提升可靠性,所以当震动略大的时候,会停止工作,保护磁盘),两者连螺丝的位置都相同(不是用于固定硬盘的螺丝,是用于固定磁盘内部机构的螺丝),我们假设硬盘仍然坚守摩尔定律(每18个月容量增加一倍),一年半后就算我们需要更换所有的桌面级硬盘(注),我们还可以做到用相同的成本,获取两倍的存储容量!四年半后,我们将以同样的价格拥有四倍的存储!加上半导体制程的进步,当固态硬盘开始取代机械硬盘(约计在2015年前后发生),我们服务器的性能和效率能将再上一个台阶(每块SSD可以提供250MB/s吞吐量,而且只有2.5英寸(SFF),一台2RU的服务器可以配置24个SFF的服务器,也就是6GB的吞吐量,这也就不难解释为什么2012年开始销售的服务器会配置两个万兆以太网端口了)!

*成本!成本!成本!:我为什么放弃在ChinaCache的股权,回到美国求职呢?那是因为作为CTO,我没有阻挡我的CEO快速扩张视频分享下载(FLV)这条业务线,结果,到2008年中,当土豆在投资者(VC)的降低成本的要求下,自建CDN设施的时候,Chinacache的业务一下子下降了60%,几个月前刚刚购买的交换机和服务器都必须折价出售,最糟糕的是还找不到买家,IT设备的价格是天天掉价的!倘若当初CEO拒绝10%股权赎回的诱惑(VC要求业绩必须连续两年出现100%增长),将发展FLV业务的经费投资在集群效率的优化,那么ChinaCache就可能可以用更低的成本提供FLV下载的业务,加上时段复卖及规模效应,就可以将FLV下载业务的销售价格低于土豆(自建CDN)的成本价,土豆,优酷等视频分享业者也就不会在VC的压力下建设自己的FLV下载基础设施。两个月发不出薪水给普通员工啊!你们一定能够体会那种痛苦,我堂堂一个中国互联网骨干设施的先期建设者,居然要靠砸锅卖铁来等待VC的bridge loan来渡过那艰难的三个月,所以我把股权给了留下来的同事(不知道CEO有没有执行这个意愿),自己回到美国求职。相同的道理,阿里巴巴在过去十年,凭借优秀的商务模式,占据80%的电子商务市场,但是,业务模式创新的速度已不如前十年,同质竞争的压力又不断地增加………一种似曾相识的感觉涌上心头:2000年之后,思科分别在两个阶段受到来自Juniper和华为的追赶,ChinaCache只不过将类似的问题集中在一年之内爆发,所以,当这样的问题来临是,无论你请什么人来,都救不了这样的企业。

*新商业文明 – 谈厂商和用户之间的关系 (扭曲化的结果就是贿赂,无意义的折扣),电子商务在解决供需的问题,我们也应该用相同的概念来解决我们基础设施的问题。讲实在话,阿里巴巴和国有电信运营商采购的腐败就只有一步之远!如果厂商在我们团建时提供一桌四千元的晚餐,我们这些月薪一万元的SA工程师,怎么能够不嘴软呢?如果团建经费再多一点,如果厂商招待费放开一点,我们的工程师需要厂商那一点点小恩小惠吗?

*思科让我回去做主管EC3(企业级云计算),华为让我进入CTO办公室主管云计算业务,我都没同意,它们的薪水可都是高出阿里巴巴三倍的薪水!我想留下来,就是马总的一句“国有”企业 — 一个真正意义的公用事业!另外,是谁鼓励土豆,优酷建设自己的FLV基础设施呢?我怎么可能跟这些砸了我的事业的人再继续合作呢?这些设备厂商唯一想的事情就是让你多买一些,至于你能不能高效应用这些设备,它们才不关心呢!地球明天会不会因为Global warming而变得风雨无常,你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题,因为他们只关系自己的荷包是不是够满,是不是够钱能够买一部Audi R8 Spyder,明天会不会因为业绩不佳而被裁员…………

我愿意和Intel合作,是因为它总是能告诉我产业发展的方向,我愿意和英业达,富士康,广达,锐捷合作,因为它们总是能够非常快速的反映我们的需求(直接帮助提升我们服务器的效率),我们甚至做到让这些厂商提供原材料的价格(BoM cost),让它们自己提它们认为合理的利润,借此建立一种可持续发展的合作关系。可是,每一次一到采购,我们这些策略就执行不下去(总是买Dell,Huawei品牌的商用服务器),我也没脸再跟ODM厂商要求开发新的机种(一个原因是厂商没有因为前期研发的付出而获利,另一个原因是2011年项目没有获得支持,所以研发经费为0)。

就算在中国电信,也知道采购部门必须和需求部门分离,就这样还不能阻挡腐败的发生,我们阿里云却把运行维护,计划建设,采购放在同一个VP下,虽然这么做有助于解决(小)部门KPI被过份放大的问题,但是这三个部门合在一起,许多Check & Balance就消失了,结果当然不是以阿里巴巴的利益为优先,更不要提公用事业这个伟大的理想了!

*我为什么不愿再继续写代码 – 这几个月为了提升服务器的性能,我每天工作到半夜,连续了三四个月,在代码的世界里,我很快地就找到了自己,很快地就能够有一些成就感,特别是捡起15年没有再读过的TCP内核代码,我很快乐我能够找出它在LFN(高性能,高延迟(缓存))的不足,但是,做这个工作我只能带动几位工程师,做绿色数据中心,我却能够带动整个中国的互联网基础设施工业,这就是我为什么不愿意再继续写写代码,而是希望能够去改变一个产业。

注:厂商提供的桌面级硬盘的质保也是三年,而根据Google提供的数据,硬盘的年损坏率略低于4%,生命周期内损坏率约为8.6%,也就是说90%硬盘都能够工作三年,而不是一年半,那么一块硬盘差800元,12块硬盘就是10,000元,11,000台12盘的服务器三年的成本就节省一亿元人民币,这一亿元人民币难道不够让我们请10个高级系统工程师(三万元一个月也就是一亿元的10%),,将我们硬盘跟换的流程优化,所以他们就不必每次跟换硬盘的时候都必须工作到半夜12点?

########################################### 

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

sohu面试题(系统)

sohu系统工程师的面试题还是比较内容全面的。下面就是我之前进的时候的一些笔试题目,之后还有好多面试的,是一轮又一轮阿。应该说这些都是比较基础的题目,而不会考你一些源码啊,这其中还有一些开放的题目。比如15和16题基本可以根据自己的想法来写。

  1. GPLV2协议的主要内涵是什么?
  2. UNIX,Linux,BSD,Solaris,System V之间的关系是?
  3. Linux开机引导的步骤
  4. inode和VFS的涵义?  文件权限 4755的涵义?
  5. 64位和32位的主要差异。
  6. Linux内存管理的工作模式。
  7. DNS反向解析的工作过程。
  8. traceroute的工作原理。
  9. TCP3次握手过程。
  10. TCP滑动窗口原理。
  11. time_wait, fin_wait2的涵义。
  12. http1.1中keepalive1.1的涵义。
  13. apache的apxs和dso的关系。
  14. SQUID的cache置换基本工作原理。
  15. 大型web提供性能的方式。
  16. SCSI标准为什么被sas取代。
  17. RAID0,1,5,0+1涵义。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA