【云+社区年度征文】TeamLeader如何Owner老系统？

小诚信驿站 • 2023-01-02 • 云技术社区 • 269 阅读

做互联网的童鞋们一定都有过这样的经历，看过很多架构书，看过很多架构师成长指南，看过很多优秀的案例分享以及讲座。所以当我们刚毕业的时候，对于大厂的认知一定都是这样的。

优秀的文化
丰厚的薪酬
高可用的架构
海龟名校的人才聚集地

大厂：目前普遍认为的是根据市值排名的一些互联网公司，以及技术和文化等综合方面来认定。（这里未包含蚂蚁金服、今日头条、滴滴、快手）

一、大厂我们看到的样子

1.1、辉煌的战绩营收

1.2、高可用、高性能、高并发、超高业务复杂度

图片来源于《企业IT架构转型之道》阿里的中台战略架构图。

二、现实的样子

滴滴的宕机

京东的宕机

淘宝的宕机

微信的宕机

谷歌的宕机

三、我们的思考

原来大公司的背后是有很多血痛经验来学习的。当你明白了这些说明你已经步入了一个程序员的中年心态，或者已然是工作3-5年以上的中年程序员。那么今天要聊的就是，我们应该对于晚年的系统或者不成熟的系统如何面对呢？我带你走进现实的场景服务案例。

全年P3+故障50起。平均每个月4.16起.通俗的理解就是每周1起事故。这就是很多公司伴随业务快速上涨，但是并非是非常核心的C端部门现实中的很多场景。

我们业务研发部门应该如何做呢？来让我们的项目系统能够符合我们的理想态？

从四个方面来讲解：

重新审视现有业务---看清现状
选择合适的架构和技术栈---从痛点找抓手
稳定性建设---闭环现有系统，达到可运营
团队和文化建设---长久建设，沉淀知识

1、重新审视现有业务

比如以我这边团队的今年项目举例，曾经滴滴的方舟运行了将近8年伴随着滴滴快速的业务发展，利用PHP语言作为ALL in One，承载了居多的业务。随着人员离职，以及原有设计跟不上现有的业务高标准要求，以及精细化运营。我们应该如何办是好呢？合久必分，分久闭合，我们只能是拆，一方面拆的过程中，熟悉全部业务重构现有的系统，另一方面快速修复现状不满足的问题。

如果你是系统从0-1建设者，你需要进行如下步骤：

业务领域划分：划分业务领域，各个领域的技术骨干认领掉所负责的领域，组织结构相应调整，划清边界：搜索服务，商品服务，优惠券服务，购物车服务，支付服务，订单服务，配送服务，用户服务，售后商家服务等
理清业务优先级：P0业务，P1业务，P2业务等。哪些是核心一级集团服务，重点关注，哪些是非核心一级系统，可以争取下扩宽时间周期，尤其是在人力紧张的情况下（很多情况下都是人力非常紧张，永远很难满足当下盲目扩张的需求）。
服务边界拉齐：服务化改造，系统拆分。根据业务边界的拉清，系统之间的交互依赖也需要梳理并拉清。对于模糊的边界以及领域的模棱两可，及早发现并重新审视，系统拆的是否过度散，领域划分有问题。

基于上述现有业务的划分，这里举出我们团队当时划清业务以后的一张架构图，当时我们考虑的点有如下几个：

日常业务需求分析和抽象，如何支持通用性需求和个性化需求的设计方案-----工具化方案
功能模块的抽象和划分-----业务领域的拆分
未来服务化思路，以及周边系统之间的关系-----系统定位

技术图-1

从C端，B端场景接入，开放平台对外输出，解决方案平台，受理中心以及中台聚集所有复杂业务逻辑。龙骨作为数据层提供基础能力。

2、选择合适的架构和技术栈

技术系统架构的选择：《大型网站架构技术架构核心原理与案例分析》-李智慧书中所提到的演进过程，单机架构->MVC前后端分离架构->分布式服务->SOA服务->微服务->服务网格

技术图-2

每个时间段都有一套成熟的方案或者架构设计满足当前场景的需要，而你要选择的技术架构是要符合你当前现有的业务，以及团队的技术能力，现状来择取出最合适的方案。并非是一度追求先进的时髦技术。这里我们基于现有公司基础设施，初步设计为根据垂直业务拆分，进行了微服务化改造。如上技术图-1.

技术语言的选择

技术语言的选择，原有技术语言我们采用的PHP，随着互联网公司Java语言生态的成熟，框架社区的完善，众多解决的解决方案，Java工程师应用层的人才储备和可选人才居多。我们基于业务系统选择了技术语言为Java作为主力开发语言。当然如果是做底层框架开发可能Go语言更加适合你，如果是做推荐，深度学习python更加适合。这个就是基于你的场景而需要做的判断。

微服务化的服务治理

正如上文所说，我们提到的，服务进行了划分，从一个整体ALL in One的应用到多个垂直服务的改造，必然面临着服务之间的依赖随着业务的复杂度，交互的错综复杂性增高，出错率增大，沟通成本增大，服务调用响应时间耗时增加等诸多问题。这个是需要我们在选择技术语言的时候就要考虑好的是否有标准的服务治理手册/方案。否则只能是从一个坑跳进了另外的一个坑。

3、稳定性建设

服务稳定性建设的三个阶段

技术图-3

明确指标，拉齐标准定义：通常我们定义的服务指标有三类SLI，SLO，SLA。但是用来衡量服务方服务协议承担责任的是SLA协议。比如常说的可用性指标几个9.以及全年故障时间。
- 服务质量指标（SLI）：
  该服务的某项服务质量的一个具体量化指标，比如大部分服务请求延迟--处理请求所消耗的时间是作为一个关键的SLI。其他常见的包括错误率（请求处理失败的百分比），系统吞吐量（每秒请求数量）等。理想情况下，SLI应该直接可以度量一个具体的服务质量。真实情况就是很多无法度量，所以需要这些指标，比如客户端的延迟数据是最直接的用户指标。
  可用性是另外的一个SLI：代表服务可用时间的百分比。该指标通常利用“格式正确的请求处理成功的比例”来定义，有时候称为服务产出，对数据存储系统，持久性（数据能够完整保存的时间）。以及可用性接近几个9来近似接近100%可用。
- 服务质量目标（SLO）：
  服务的某个SLI的目标值，或者目标范围。比如定义一个SLO，要求请求响应时间延迟小于100ms.这个定义的是平均延迟，因为QPS升高通常会导致延迟升高，服务到达一定的负载水平性能下降很常见。比如全球Chubby分布式锁服务计划内停机来排查哪些强依赖的系统。
- 服务质量协议（SLA）：
  服务与用户之间的一个明确的或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。如果没有定义明确的后果，那么我们就肯定是在讨论SLO，而不是SLA。涉及到SLA的话就是违反合约的法律诉讼了。

技术图片-4

那么我们如何定义几个9呢？是否真的需要六个九还是三个九依赖于你服务的重要程度，以及面向的用户。用户期望的服务水平是什么？

服务是否直接关系到收入？
这是有偿服务还是免费服务？
如果市场上有竞争对手，那些竞争对手提供的服务水平如何？
这项服务是针对消费者还是企业的？

不同的服务，客户，业务对于SLA类型也不同常用的如下：

应用/服务的整体运行时间
页面加载时间
事务处理时间
API响应时间
报告响应时间
事件解决事件
事件通报事件

而这里以我们的举例，针对C端用户猜你想问司机或者乘客的请求响应整体耗时控制200ms以内，而针对B端客服/运营则接口响应时间默认1s，个别非常复杂的业务接口可以允许1s+;

事情发生前->准备工作：梳理

- 1、架构与依赖

强依赖
弱依赖
整个调用链路分析，请求流顺序梳理
预计的容量水位与规划

对于弱依赖要隔离，而强依赖则要保障，合理分析哪些需要制定降级，限流策略，增加缓存，资源调优的环节。

- 2、系统集成情况

DNS系统
负载均衡系统
监控系统

-3、容量规划

是否有广告推广规划，业务快速增长
现在的流量和增速
是否计算资源有剩余，防止扩容无资源

- 4、故障模式

系统中是否存在单点故障隐患
服务处理依赖系统的不可用性现状
过载流量方案（丢弃还是暂无）
请求是否有超时时间（防止导致资源耗尽）

-5、客户端滥用

请求失败的重试延迟（指数step增加）
保证自动请求中实现随机延时抖动

-6、开发需求方面

发布版本相关配置和分支
外部依赖，数据，服务，事件是否隔离
上下游系统对于版本的兼容更改通知

-7、灰度和阶段发布，功能开关控制

金丝雀理论
AB实验
灰度开关流量控制

事情发生中->工作实施：可定位
- 监控指标体系完善
- 系统监控指标监控
  - 网络
  - 磁盘
  - CPU
  - 内存
  - IO
- 业务监控
  - 错误码-异常信息监控
  - 上下游系统异常接口监控
  - 数据源异常监控
- 组件监控
  - redis内存，磁盘指标，连接数
  - MySQL单表数据量，慢SQL，并发数，响应耗时情况
- 告警机制可触达
- 工作报警群
  - 系统上线群
  - 代码部署群
  - 系统运维监控群
- 邮件
- 短信
- 电话
- 全链路监控
- 日志分析
  - 实时抽样分析
  - 错误日志分析
  - 日志条数监控
- 服务分析
  - 接口性能分析
- 风险分析
  - 跨机房风险
  - 异地多活状态检测
事情发生后->工作现场：可管控
- 故障通报：
  - 通报模版

1、事故说明

2、影响范围（当前故障造成的影响，例如：方舟打不开、无法操作补偿等，以及影响的客服面例如涉及几个职场/多少客服）

3、时间线（强调该时间为事故时间：

         若发现事故时间早于业务反馈时间，填写事故发生时间。

         若事故由业务方反馈时间，则以初次业务方反馈时间为事故时间）

4、事故原因（若未定位，写暂时未定位）

5、跟进人

6、现在的状态（恢复/跟进中）

限流：
    如果QPS，或者TPS超过安全阈值，进行限流处理。
    通知上下游压测，在确保其他服务稳定的前提下，自己服务的最大QPS
系统安全QPS计算公式
QPSsafe=( QPSpeak  -  QPSperiod_max ) * N
1. 计算并确认安全QPS。
2. 在一台机器上部署服务A（Service-A-Test），配置 Service-A-Test使用线上的服务B/C/D。
3. 准备线上流程query做压测用，（因采用阶梯式压测，需要使得每个压测梯度间的query不一样，避免cache影响）
4. 对 Service-A-Test进行压测，利用profiling等工具进行观察调优。
   因为是探测摸底，这里可以改采用阶梯式压测。QPSmax为单机服务极限QPS, QPSstart为最开始的压测QPS, QPSend是最大的压测QPS，QPSstep为每次加的QPS大小，压测次数m。
> QPSstart = QPSmax
> QPSend = min( 3 * QPSmax, QPSsafe QPS)
> QPSstep = ( QPSend - QPSstart ) / m
    可以利用限流策略来进行系统保护。
      
降级
   功能降级（短峰值）
   缓存降级（长峰值）
   削峰限流（长高峰）
   极端容灾（宕机）

容灾
  异地多活容灾
扩容 
  秒级弹性云扩容，一件

快速定位问题通常需要如下几个人员，

->事故总负责人(及时将进度同步到团队，可以让高层粗略了解进度，以免多次询问细节)

->事故主要处理人（跟进线上问题，一般是上线人或者系统最熟悉的人）

->事故处理团队（依赖方以及同事）

->后勤支持（一般运维侧同事）

故障解决

1）所有系统的bug或者故障很多都是由于变更部署开发导致，所以第一时间要务是回滚策略。
2）根据系统之前的预案进行限流、降级、切机房、扩容等服务处理
3）未知其他不可控问题，及时拉到相关干系人 进行快速处理。

-------------------------------------------
1. 时间轴 （具体到分钟级）
-------------------------------------------
<事故日期  2020-06-22>

2020-06-22 16:24 –  2020-06-22 16:35

【事故发现】

16:24 报警“HTTP 失败过多,10s超过5条（errno!=0）”

16:24 开始排查

16:26 多个职场在故障群报异常



【事故时间轴】16:24 报警“HTTP 失败过多,10s超过5条（errno!=0）”

16:24 开始排查

16:26 多个职场在故障群报XXX问题

16:28 定位是XX报错

16:33 定位“The MySQL server is running with the –read-only option”

16:34 联系dba

16:36 故障恢复



影响范围： 所有职场

-------------------------------------------
2. 事故影响
-------------------------------------------

2.1 对客服及用户影响
故障时间段内，XX功能都会受到影响，共影响XX个工单（不包括XX系统数据）

时间范围:  2020-06-22 16:24 –  2020-06-22 16:35

影响人群：所有用户

 -------------------------------------------

3. 事故原因/责任
------------------------------------------
触发原因
      1、DBA在做 从库主库互换的时候 忘记开写权限了

4.改进措施【暴露问题及改进措施】
------------------------------------------
暴露问题

改进措施

完成时间