系统优化与进阶之道:大规模复杂场景下的技术创新实录
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

FreeWheel运维团队的演进

从公司2007年创立到现在,FreeWheel运维团队的发展大致经历了以下几个阶段:

· 传统运维。公司成立初期业务量较小,系统的复杂性也不高,各方面挑战都不大。此时运维团队规模很小,各项工作基本都是大家一起完成,包括网络规划、硬件安装、软件部署、监控报警等。日常管理工作通常是通过直接执行命令或编写简单脚本来完成。

· 运维职责分化。随着FreeWheel的业务快速成长,产品线不断扩展,系统模块数量及相互间关联依赖的复杂度随之增加,基础设施也变得越来越庞大,整体运维工作变得非常复杂,运维团队面临的挑战直线上升。在这段时期FreeWheel将整个全球运维团队进行细分,包括系统运维、网络运维、数据库运维以及产品运维。产品运维更侧重在产品部署、服务运行等产品环境,跟软件开发人员的沟通交流更为紧密,通常会结合自身的运维经验和需求提出建议,协助设计和搭建监控、报警系统,从而使FreeWheel业务产品能够更好、更稳定地运行。这个阶段运维团队的组织结构变得更加清晰,各运维小组的职责变得更加明确。

· DevOps。FreeWheel有一段时间成立了专门的DevOps团队,负责建设从代码管理、打包测试、上线部署到配置管理、报警监控的一整套管道流程和工具平台,力争打破开发和运维之间的边界,实现更好、更快的代码上线及服务变更。但在具体实践中,由于该团队所招聘的人员运维经验偏少,对系统上线和监控的理解不够深入,同时和众多的开发团队之间也难以保障充分沟通,导致开发和运维两方面的具体需求都得不到快速有效的响应。这一阶段FreeWheel走过了一些弯路,值得反思。

· SRE。SRE的角色定义在Google首先建立和推行,FreeWheel的产品运维组在过去一年中也进行了相关实践,结合自身现实情况,尝试使用工程的思想和手段来审视与改进生产环境的运维工作,并尽可能推动运维自动化。具体工作包括和产品开发团队一起梳理并建立CD(持续部署)流程和平台,对业务和产品进行实时监控,关注报警以及系统的稳定性、可用性,明确定义SLO(Service Level Objective),确保对用户承诺的SLA(Service Level Agreement)。