Google的系统工程师(System Administrator)如何工作

kennyxue

本文根据系统管理领域知名博客 Thomas A. Limoncelli 的 What is system administration like at Google 整理而成，添加了部分笔者观点。

由于Google的服务已经集群化，系统工程师并不大量接触硬件比如做安装服务器等事情。另外大部分工作也已经自动化了，比如架设LDAP, 负载均衡等。对照而言，国内目前大部分互联网公司SA仍然要做大量重复的底层工作，比如拿一个业务的数据库过大需要拆分为例，从系统管理员的角度，需要做以下事情

• 同技术人员沟通目前业务特点，制定拆分方案并评估程序风险
• 搭建测试环境，技术人员测试程序兼容性
• 制定实施方案，保证业务的不停机平稳过渡
• 深夜上线
• 观察1-2天运行情况

我们需要思考上面工作是否是系统管理员以及技术人员有价值的工作。像Cassandra这样解决了分布式存储自动化扩展的问题是业内一种发展方向，尽管Cassandra的稳定性还需要改进）。
Google的系统工程师怎么做？
他们会通常1周值班，响应各种问题，比如完成上述场景中的扩容业务。然后有大约5周左右脱离一线工作来自由思考将这1周内碰到的工作进行自动化改进，将那些会反复碰到的问题通过脚本及监控程序完成，或者进一步反馈给技术人员改进应用程序来实现自动化。1:5只是个大约比例，时段可以灵活安排。比如也可以按天来安排，1天值班/7天改进。当改进完成之后，下次遇到相同的场景，自动化程序会完成大部分工作。如果在其他公司，SA通常忙碌在一线机械重复上述工作，但是在Google, 给系统工程师预留了相当多的时间让大家思考改进。
这就是Google的System Administrator自称SRE(Site Reliability Engineers)的原因。SRE会不断在优化所负责的系统，一些人关注运维层面，另外一些可能关注自动化工具。所有的SA都需要具备一定程序或脚本开发能力。
因此，当遇到Google的数据规模，自动化不是是否需要，而是如何更好实现的问题。
在Google其他一些令人兴奋的工作还包括

• 与开发技术人员是协同的关系。
• 只需关心技术，在技术领域也有职业生涯上升通道，不必转向技术管理岗位或其他。
• 同事都非常聪明，通常会觉得自己是最逊的那一个。
• 很多挑战，保守的估计领先行业2-10年，在这里工作就象给了你一个魔法水晶球，通过你的工作可以预见这个行业的未来。

受Google方式的启发，以下想到的一些可以研究的自动化方向
1. 程序部署C/C++/Java/PHP/Python/Ruby/C# 等语言如何不停机自动发布
自动发布如何简洁的解决模块依赖性，比如1天需要同时更新10个有相互依赖的模块，并且不能停止服务
Web容器虚拟化，同一Web容器上可以部署多个业务，业务之间互相隔离，互不影响。
将新开发的服务程序运维自动化。一般的服务程序从数量上来说，10是一个分水岭，10台以下的服务通过人工重复操作方式来管理也问题不大，但是10台以上就需要自动化管理的方法。很多优秀的开源程序(比如Tokyo Cabinet, Redis等)在单机上表现优秀，但是大规模部署不能。大公司中很多技术人员经常提到很多开源软件不适合他们就有这方面原因。
2. 资源部署MySQL
分布式文件存储
Cache，拿cache自动化管理举例
端口资源管理，不同业务使用不同端口，同一应用内不同的数据使用不同的端口，相关原因可以参看以前cache相关博文。
容量管理，不同的数据需要不同的容量
动态扩容，应用业务规模增长，比如从10G扩容到100G
Proxy功能，比如虚拟化端口映射，程序访问的是固定虚拟端口，这样不需要重启服务也可以随时扩充，应用也不需要一致性hash, proxy帮你做了。
3. 系统部署OS
反向代理与负载均衡
本地分区容量，批量管理
程序发布与停止，比如一个程序一个点击部署到100台服务器
虚拟化，比物理服务器更容易部署，资源利用率更高，部署更可控
大部分国内互联网公司基础技术还是比较原始的，这跟行业过分强调“好产品是运营出来的”也有关系，基础研发通常不受重视，长此以往，只能在门槛低的领域打拼，与Google的技术差异就不止10年了。

                               
登录/注册后可看大图

(图：大型机GEORGE的纸带编程年代)

ubuntuhk

Google的硬件架构真是一流，据说是得益于当年Sun走下坡路，于是不少Sun的资深工程师跳到Google，所以Google才这么niubility。

Fernando

所以Google招系统管理员，DBA的时候，面试起来也和程序员一样

nilei

我读phd的时候写的软件做实验要200-300个分布的电脑来24/7运行，整个环境很恶劣，cpu负载超大，而且scheduler明显有问题，一个进程被一挂可能就是10分钟，最伟大的就是有个防抖动的设计，物理内存一慢发现有抖动趋势，内存使用大户直接被kill掉，哪怕这个“大户”才用100m内存。莫名其妙的问题就更多了，带宽被人为限制到ssh也不够、内存有硬件随机故障、很多系统程序莫名其妙不能用（zip等）。在如此恶劣的环境下，我把软件运行了1年多，什么大风大浪也看到过了。

流浪的狗

原帖由 nilei 于 16-9-2010 23:34 发表

                               
登录/注册后可看大图

我读phd的时候写的软件做实验要200-300个分布的电脑来24/7运行，整个环境很恶劣，cpu负载超大，而且scheduler明显有问题，一个进程被一挂可能就是10分钟，最伟大的就是有个防抖动的设计，物理内存一慢发现有抖动趋势，内存使用大户直接被kill掉，哪怕这个“大户”才用100m内存。莫名其妙的问题就更多了，带宽被人为限制到ssh也不够、内存有硬件随机故障、很多系统程序莫名其妙不能用（zip等）。在如此恶劣的环境下，我把软件运行了1年多，什么大风大浪也看到过了。

1：这个是做软件实验吧。没有任何一个critical的商业系统敢这么干吧，如果任何商业公司敢这么干，董事会知道了的话估计所有技术部门的人，从一把手开始到底下所有的人全部开掉，我相信也不过分。
2：你这样的系统，如果CPU，内存或者I/O长时间的过高，即使能够正常运行，那这也是一个处与临界状态的系统，任何一点点的风吹草动就可能导致整个系统崩溃并且无法正常重新启动。
3：实验系统和商业系统有着本质的区别--我宁可维护100个高负荷的实验系统，也不愿意维护一个低负荷的商业生产系统。商业生产系统上面一出问题的话，压力非常的大，尤其是系统无法正常重启--这个时候，往往公司的领导，从1把手到10把手，全都守在你边上等你一个人--外面还有无数用户在等着。那种情况简直要人命。