本文根据系统管理领域知名博客 Thomas A. Limoncelli 的 What is system administration like at Google 整理而成，添加了部分笔者观点。
Google的系统工程师(System Administrator)如何工作
由于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的纸带编程年代)
仰慕这种注重思考和技术的公司！
好文，收藏至20ju.com
“好产品是运营出来的”这句话放在当前大环境下,并不为错，国内技术发展阶段如此，大部分人心态也如此，同时，大部分技术人员不重视用户需求和市场分析也间接促使运营在产品中发挥了更多作用。boss终究是商人，是否愿意给一个短期看不到效果而且潜在需要持续投入的事情安排资源，这是很现实的问题。
自动化维护是从SA这个职业出现就应需而生的需求，国内从业人员也同样有这样的诉求和正在进行这样的实践，只是更多的时候，这种实践无法体系化延续发展下去或没有在行业中有效推广(一般都是按照自身业务需求进行点到即止的实现)。
回到文中提到的自动化方向，串起来就是“自动构建发布”-“自动部署”-“容量分析评估”-“自动部署(扩容)” ，这样一个方案或者说框架，需要进行整体规划设计(至少要先满足自身业务需求–这就是上面提到的点到即止，可能无法行业通用化)，同时要进行一定量代码编写。国内SA从业门槛较低，没有一个专业开发团队来支持，一般的SA无法完成上述需求。比较理想的方案是SA(sysarch)+SA(sysadmin)+Coder来实现。
再成熟的运维方案也会不断遇到新问题，，google,ms,amazon已经多次向我们证明有一个标准运维体系是非常重要的，同时这个体系也需要不断完善。维护这个体系，将会需要持续的资源投入。回到开始提到的，boss愿投资源否？
也是公司的一种机制问题。公司的机制不鼓励的话，让技术人员自告奋勇要做这么个自动部署系统是很难的，一方面决策权不在一线技术人员手中，何况做这个事情还要承担风险，多一事不如少一事，于是就都懒得改进了，虽然每个做这个事情的人都很痛苦。
我觉得与boss有些关系，但重要的是负责技术的人，能否在两者权衡，在做能很快看到效果的工作同时，又能多做一些无法短期看到的基础建设工作。其实boss也一样，在投资人和员工利益之间权衡。
欣赏Google，企业文化直接影响员工。。
怎么哪里都能见到草根网 的踪迹，神奇
给力的技术人士
Boss不重视运维，是因为公司没有做大或者Boss没有经历过 简陋的运维会造成多大的损失，吃过亏后来就重视了。
Google是工程师文化的公司；国内都是资本文化。
补充一句：山寨文化
模式很好！
博客非常的不错！博主也是非常的有学问！我会继续支持你的博客的
Your sharing is very useful. I have learned a lot from this article of yours. I will be back.