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

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

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

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

1. 同技术人员沟通目前业务特点，制定拆分方案并评估程序风险
2. 搭建测试环境，技术人员测试程序兼容性
3. 制定实施方案，保证业务的不停机平稳过渡
4. 深夜上线
5. 观察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的纸带编程年代)

• 为什么优秀开发者进入Google后就不参与开源了
• Twitter系统运维经验
• 多IDC数据时序问题及方法论
• Google说，一个Datacenter就是一台计算机
• 构建可扩展的微博架构(qcon beijing 2010演讲)