技术转型之路一:现状和治理思路

自从接手后端技术团队之后,面临的就是一个烂摊子,大小事故不断,新老人几乎没有衔接,导致大量业务代码逻辑无人知晓,架构设计没有办法追本溯源,比较长一段时间内都是急于救火,完全无暇顾及技术和管理,人员也是基本放任状态。

在突击解决了几次线上面临的大事故之后,暂时摁住了故障频发的势头,让技术团队可以稍缓一口气,做一些早该进行的工作。

现状描述

整个后端技术团队支撑的是一组日活达百万的产品,包括各个公众平台,还包括一部分线下订单业务,涉及支付。现在面临的外部状况是:

  • 服务突发故障导致线下交易受阻,用户投诉
  • 业务需求压力过大,开发人员缺少,业务需求难以快速消化

内部状况是:

  • 数百台服务资源利用和管理不善,忙的忙死,闲的闲死
  • 架构设计几乎是透明,导致新人无从摸索,出故障不能快速定位和解决
  • cache 服务、proxy 服务、nginx 服务、rpc 服务、注册和发现服务、异步任务服务、数据库服务彼此耦合严重,调用依赖非常混乱,变更困难,升级困难
  • 服务监控使用了多种监控手段,包括 glance、zabbix、munich
  • 异步任务存在多种技术选型,rq、beanstalkd、celery
  • 缓存集群使用多种技术选型,twproxy、codis、sentinel
  • 数据统计和存储使用多种技术选型,MySQL、MongoDB、hadoop、influxdb
  • 部署环境存在多种技术选型,walle、fabric、ansible
  • 服务以单体应用存在,无降级措施,无限流措施,一损俱损
  • 数十个 worker 单台机器部署,CPU 经常超负载
  • 几百个 crontab 任务
  • 同一业务代码散落的多个代码仓库改动升级困难
  • 等…..

治理思路

思维决定了行动,无思不行,行辅助思,从行中总结提升思维的高度和境界,思维反过来指导行为时间

从上之下

公司业务使用的是云服务器,购买、新建、管理相对来说都非常方便,云厂商提供了类似业务分组、标签、名称等管理手段来管理服务器。为了让业务服务部署清晰,划分明了,首先从机器名称功能分组开始梳理,保证机器的具有单一职责,方便动态扩容和管理

功能和名称划分清晰之后保证业务开发人员能以上帝视角审视所有服务以及它们之间的联系。

开放权限,人人参与

为了让每一个开发者都能透彻了解它们开发、部署的服务以及运行状态,放开所有监控工具权限,放开云厂商的机器管理权限,让每一个人都能快速了解到部署的机器,也可以通过云厂商提供的监控及时了解机器的状态。

开发者要能做运维,会做运维,运维必须要有开发者参与,此举才能保证 devops 理念的实践和落地

定位问题,各个击破

整理和梳理技术团队现在面临的每一个问题,按照优先级排序,逐个投入资源彻底解决,与其不断救火,不如集中力量完全消灭一处火源,逐步降低故障率。

系统化所有日常工作

用系统来工作 这本书的作者详细阐述了如何自己从救火队长变成了每天只需工作一两个小时的高效能人士,作者的基本理念就是把你所有的工作都系统化,让它们自己运转,也就是把自动化上升到了一个新的高度,系统化

为了能最大效率的提升技术团队的效率和产出,在找到每一个问题并击破之后,就要想办法如何让每一个问题都演变成可以自己工作的小系统,小系统彼此联合形成一个更大的系统。

三月沙 wechat
扫描关注 wecatch 的公众号