http://wiki.tomtalk.net/index.php?action=history&feed=atom&title=%E7%B3%BB%E7%BB%9F%E7%AE%A1%E7%90%86 2026-04-24T08:18:42Z 本wiki的该页面的版本历史 MediaWiki 1.24.2 http://wiki.tomtalk.net/index.php?title=%E7%B3%BB%E7%BB%9F%E7%AE%A1%E7%90%86&diff=2738&oldid=prev 2012-10-01T02:46:09Z

<p>‎<span dir="auto"><span class="autocomment">Google的系统工程师(SA)如何工作</span></span></p> <p><b>新页面</b></p><div>==Google的系统工程师(SA)如何工作==<br /> <br /> ;Google的系统工程师(System Administrator)如何工作<br /> <br /> 由于Google的服务已经集群化，系统工程师并不大量接触硬件比如做安装服务器等事情。另外大部分工作也已经自动化了，比如架设LDAP, 负载均衡等。对照而言，国内目前大部分互联网公司SA仍然要做大量重复的底层工作，比如拿一个业务的数据库过大需要拆分为例，从系统管理员的角度，需要做以下事情：<br /> <br /> *同技术人员沟通目前业务特点，制定拆分方案并评估程序风险。 <br /> *搭建测试环境，技术人员测试程序兼容性。 <br /> *制定实施方案，保证业务的不停机平稳过渡。 <br /> *深夜上线。 <br /> *观察1-2天运行情况。<br /> <br /> 我们需要思考上面工作是否是系统管理员以及技术人员有价值的工作。像Cassandra这样解决了分布式存储自动化扩展的问题是业内一种发展方向，尽管Cassandra的稳定性还需要改进。<br /> <br /> ;Google的系统工程师怎么做？<br /> <br /> 他们会通常1周值班，响应各种问题，比如完成上述场景中的扩容业务。然后有大约5周左右脱离一线工作来自由思考将这1周内碰到的工作进行自动化改进，将那些会反复碰到的问题通过脚本及监控程序完成，或者进一步反馈给技术人员改进应用程序来实现自动化。1:5只是个大约比例，时段可以灵活安排。比如也可以按天来安排，1天值班/7天改进。当改进完成之后，下次遇到相同的场景，自动化程序会完成大部分工作。如果在其他公司，SA通常忙碌在一线机械重复上述工作，但是在Google, 给系统工程师预留了相当多的时间让大家思考改进。<br /> <br /> 这就是Google的System Administrator自称SRE(Site Reliability Engineers)的原因。SRE会不断在优化所负责的系统，一些人关注运维层面，另外一些可能关注自动化工具。所有的SA都需要具备一定程序或脚本开发能力。<br /> <br /> 因此，当遇到Google的数据规模，自动化不是是否需要，而是如何更好实现的问题。<br /> <br /> 在Google其他一些令人兴奋的工作还包括：<br /> <br /> *与开发技术人员是协同的关系。<br /> *只需关心技术，在技术领域也有职业生涯上升通道，不必转向技术管理岗位或其他。<br /> *同事都非常聪明，通常会觉得自己是最逊的那一个。很多挑战，保守的估计领先行业2-10年，在这里工作就象给了你一个魔法水晶球，通过你的工作可以预见这个行业的未来。 <br /> <br /> 原文地址：http://user.qzone.qq.com/250332234/share/1291635502</div>

Tom