Google的系统工程师(System Administrator)如何工作
- 同技术人员沟通目前业务特点,制定拆分方案并评估程序风险
- 搭建测试环境,技术人员测试程序兼容性
- 制定实施方案,保证业务的不停机平稳过渡
- 深夜上线
- 观察1-2天运行情况
他们会通常1周值班,响应各种问题,比如完成上述场景中的扩容业务。然后有大约5周左右脱离一线工作来自 由思考将这1周内碰到的工作进行自动化改进,将那些会反复碰到的问题通过脚本及监控程序完成,或者进一步反馈给技术人员改进应用程序来实现自动化。1:5 只是个大约比例,时段可以灵活安排。比如也可以按天来安排,1天值班/7天改进。当改进完成之后,下次遇到相同的场景,自动化程序会完成大部分工作。如果 在其他公司,SA通常忙碌在一线机械重复上述工作,但是在Google, 给系统工程师预留了相当多的时间让大家思考改进。
- 与开发技术人员是协同的关系。
- 只需关心技术,在技术领域也有职业生涯上升通道,不必转向技术管理岗位或其他。
- 同事都非常聪明,通常会觉得自己是最逊的那一个。
- 很多挑战,保守的估计领先行业2-10年,在这里工作就象给了你一个魔法水晶球,通过你的工作可以预见这个行业的未来。
1. 程序部署
自动发布如何简洁的解决模块依赖性,比如1天需要同时更新10个有相互依赖的模块,并且不能停止服务
Web容器虚拟化,同一Web容器上可以部署多个业务,业务之间互相隔离,互不影响。
将 新开发的服务程序运维自动化。一般的服务程序从数量上来说,10是一个分水岭,10台以下的服务通过人工重复操作方式来管理也问题不大,但是10台以上就 需要自动化管理的方法。很多优秀的开源程序(比如Tokyo Cabinet, Redis等)在单机上表现优秀,但是大规模部署不能。大公司中很多技术人员经常提到很多开源软件不适合他们就有这方面原因。
2. 资源部署
分布式文件存储
Cache,拿cache自动化管理举例
端口资源管理,不同业务使用不同端口,同一应用内不同的数据使用不同的端口,相关原因可以参看以前cache相关博文。
容量管理,不同的数据需要不同的容量
动态扩容,应用业务规模增长,比如从10G扩容到100G
Proxy功能,比如虚拟化端口映射,程序访问的是固定虚拟端口,这样不需要重启服务也可以随时扩充,应用也不需要一致性hash, proxy帮你做了。
3. 系统部署
反向代理与负载均衡
本地分区容量,批量管理
程序发布与停止,比如一个程序一个点击部署到100台服务器
虚拟化,比物理服务器更容易部署,资源利用率更高,部署更可控