访问量： 5306

自2015年开始从事游戏行业一线运维工作，至今（2022）已经近7年。

网易游戏：2015.04 ~ 2021.04
灵犀互娱：2021.04 至今

文章目录

背景

为什么想写这么一篇大总结？

这么多年在一线游戏运维工作的过程中，除了本职技术工作之外，在非技术方面也不断积累了很多经验和教训。同时，结合以前带团队的经验以及对个人和团队的要求，也总结了一些管理方面的心得。

现在看上去会是一个好时机把这些经验总结都整合一起，以自勉、或分享。

个人经验可能会比较浅薄，所以更重要的是：寻找志同道合的同路人一起继续探讨。

文中内容看上去都是很虚的东西，真的有意义么？

这篇总结中几乎不涉及任何技术相关的细节，更多的是意识方面、形而上的东西。从以往经验来看，这些“虚”的东西恰恰是技术人、尤其是一线的运维同学需要提高的。所以，应该会有点作用，可以试试看。

1、运维人员的定位

运维叫什么？PE？SRE？

说到“运维”，我们一定对这些称呼不陌生：

（1）OP：OPeration，偏执行类的运维工程师
（2）SA：System Administrator，系统管理员
（3）PE：Product Engineer，应用运维工程师。
（4）SA：Solution Architect，解决方案架构师
（5）SRE：Site Reliability Engineer，网站稳定工程师。（来源于Google SRE）

列一个简单的表格可以对比一下上面几个称呼。

对比项OPSASystem AdminPESASolution ArchSRE
主要职责执行类系统+执行类应用负责人解决方案业务稳定
工具脚本命令、脚本系统、脚本系统、架构软件工程
成就感来源N/A救火救火，解决疑难杂症方案选型并实施预防+稳定
幸福感来源N/AN/A应用稳定方案沉淀消除琐事
门槛低低中高高
成长空间低中中高高
人员可替代性（越低越好）☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

什么是SRE？

在《SRE: Google运维解密》中对于SRE的职责有如下描述：

In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).
SRE需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。

对于SRE，关键在于R（Reliability），所以SRE的职责就是围绕业务稳定展开，所有工作都是为了用软件工程化的思想和实践，来保障业务稳定。

Google SRE要求非常高，SRE需要工程化的开发系统或工具来保证业务稳定，所以SRE本身首先是一名软件开发工程师，其次才是运维角色。正因为如此，所以在Google，SRE只负责最核心的业务的稳定性。

但和Google SRE不同，国内实行SRE制度的公司，大多对SRE个体的人员技能要求远远达不到Google SRE的水准，所以国内SRE制度一般是一种改造版，更多的需要依靠团队分工的力量达到Google SRE的水平。

什么是可用率？

可用率包含2个方面：

（1）服务停止：完全不可对外进行服务。玩家表现为：无法登录、无法游戏、无法对战等。

（2）性能下降：仍旧可以服务，但是性能指标已经低于SLA。玩家表现为：卡顿。

对于可用率，我们习惯性称呼为N个9，比如3个9就是99.9%可用率，对照下表，3个9就是月均不超过43.8分钟的停服时间，年均不超过8小时46分钟。

可用率年平均停服时间月平均停服时间
99%87小时40分钟7.2小时
99.9%8小时46分钟43.8分钟
99.95%4小时23分钟21.56分钟
99.99%52.56分钟4.38分钟
99.995%26分18秒2.16分钟
99.999%5分16秒25.9秒
99.9999%31.6秒2.59秒

可用率到底要达到几个9？

99.9%？

99.95%？

99.99%？

99.999%？

可用率多增加一个9，所需要付出的工作量和成本是指数级的，所以针对不同的服务，量入为出的分别制定各自的可用率目标，同时考虑ROI。

不同人眼中的运维

家人眼中：修电脑的

路人眼中：背包侠

策划眼中：背锅侠

Dev/QA眼中：管服务器的

同事眼中：给游戏兜底的

项目组对运维的核心诉求

对于游戏项目组而言，对运维人员的最、最重要的核心诉求，不外乎下面几个：

1、故障及时发现和快速恢复，改进措施有效且闭环；

2、保证较高的运维需求交付效率和质量；

3、变更和故障等方面的知情权；

4、基础设施服务的稳定性；

不难看出，所有的诉求也均是围绕着游戏业务稳定、玩家体验正常的目标，这跟SRE的职责非常吻合。

技术要专，还是广？

个人建议：在运维技术栈中，基础领域技术扎实，同时保证至少在2个领域比较精通，其它领域越广越好。

在传统运维时代中，Linux、网络、DB这些属于基础领域，是必须要求扎实的。而在云原生时代，基础技术栈上移为云计算、容器、K8S等。

精是为了在纵深领域可以深挖，对于故障排查、根因分析等场景会有很大帮助。广是为了可以在横向领域中融会贯通，有助于方案选型、少走弯路。

运维SRE的段位

（1）初级段位：与服务器打交道。

这时候，要做的事情更多是命令式、脚本化的重复性手动操作，让服务器在执行之后得出运行结果。一处编写、到处执行。

（2）中级段位：与系统和流程打交道。

这个阶段，更多的是考虑产品化、系统化的东西了，把可重复执行的脚本编排为运维作业和流程，进行系统上的执行，解放人力重复劳动，同时减少人为误操作。

（3）高级段位：与人打交道。

这里的“人”主要指的是运维的上下游。

上游也就是客户，来源于：游戏项目组、开发人员、策划、QA、部门内部，甚至是运维Peer。

下游指的一般是各个支撑系统的团队人员，比如：运维研发、DBA、云服务商等等。

对于上游客户而言，SRE更多的是需求跟进、方案选型、故障排查等职责，归根到底就是与上游形形色色的“人”打交道。

在前文，粗略介绍了国内SRE与Google SRE的不同，所以SRE自身如果不具备研发能力的时候，需要向下游寻求帮助，这时候要求SRE以业务的角度分析运维过程中的痛点，然后以全局、产品化的思路提出需求和优化方案。

2、做事方法

新手常犯的错误或误区

  • 两个极端：要么不问别人问题、要么凡事都先问别人。正确做法：自己先研究尝试解决，带着自己的思考去问别人。
  • 陷入做事，不抬头，不汇报进度和反馈问题。正确做法：主动、及时同步进度，如果遇到难题，需要及时同步出来。
  • 事情不了了之，不闭环。正确做法：凡事要有反馈，即使不打算或不愿意做了，也要告知出来。
  • 对自己的技术不自信或自负。
  • 错误的以为“只有自己知道怎么做”、“被依赖”是自身技术水平或不可替代性的来源。
  • 缺乏对线上正式环境的敬畏心。

怎么推进事情落地？

这是一个只可意会不可言传的话题，这里只列一些要点：

  • 要有同理心，站在对方的角度思考他的价值点在哪里。
  • 对业务/客户的价值要想清楚。
  • ROI要合理。
  • 制定备选方案进行对比。
  • 借助外力。

忙不过来了，怎么办？

比如：快到年关了，每个游戏都在忙着搞活动、扩容、对外测试、开新服，业务上的工作非常繁重，每个运维身上都背负太多工作在并行处理了。

碰到这种突发性运维工作突增，该如何处理呢？

短期：

  • 识别优先级，过滤掉非紧急需求。
  • 横向拉通全部运维需求，进行人员调配。
  • 降低项目组对交付时效的预期，注意不要降低交付质量哦。
  • 对于不是常态化的紧急需求（比如：17:30提的第二天上午就要的新环境部署），适当延缓交付时间。

长期：

  • 沉淀好FAQ知识库、工作流，减少重复性的、咨询类的沟通成本。
  • 把那些尚未自动化、自助化的运维需求全部记录下来，等到较空闲的时候逐一优化，避免再次陷入繁忙之中。
  • 工作量高峰期过后，需要进行一次复盘，根因分析，有针对性的解决存在的问题。

怎么做变更？

首先，什么是变更？变更是运行环境、配置、版本、进程、硬件、基础设施的变化，总之是在某个时刻前后，整个业务系统的快照发生了变化。分为主动变更和被动变更，这里主要指主动变更。

其次，在哪些情况下需要做变更呢？比如：版本更新、配置变化、软件升级、硬件更换、网络切割，等等都是需要主动进行变更。

那么问题来了，最重要的问题：怎么保证变更成功呢？站在运维人员的角度，思考过程大概如下：

  1. 我要做变更了，第一步要做什么？答案是先评估变更的必要性：为什么要做、不做行不行？
  2. 如果必须要做，接下来干嘛呢？制定一份详细的变更计划，按照5W2H分析法全部梳理清楚：谁来操作、什么时间、每个步骤是怎么样的、在哪里操作、变更后的收益是什么、怎么回滚、检查清单。
  3. 计划出来了，接着干嘛？要去提前通知相关人了，程序、QA、Peer全部通知一遍。
  4. 现在，他们都知道我要做变更了，也知道详细的计划了，那接下来干嘛？Review变更计划，看看我制定的计划各个步骤、操作对象，是不是对的。
  5. 人工Review都通过了，那可以去实施了么？还不能，因为这个计划还没有被演练测试过，万一所有人都错了呢，我们需要在测试环境或预发环境中测一遍才行。
  6. 好，测试也通过了，可以按照计划中的时间来执行了么？可以了。
  7. 真正执行变更时，我还要不要再通知一遍相关人员？当然要：我要开始了、进行到xx步骤了、变更结束了，这些关键节点都需要同步进度和结果。
  8. 全部都按照变更计划操作完了，也检查完毕没有问题了，也通知过人了，那变更结束？可能还不行，试着想想：变更中有哪些失误么、有哪些非预期的情况、重放一次能不能做的更好，也就是对于非预期的变更、或重大变更需要有一个复盘机制。
  9. ok，我也复盘完了，可以结束了么？可能还不行：改进措施都落地了么、相关的总结都沉淀好了么。
  10. 到这里，整个变更过程相对来说已经比较完备了，可以正式结束了。

怎么防止人为误操作？

先说一个错误答案：当我把每个误操作都经历一遍的时候，就能防止了^_^。

这当然不行，一线运维需要对线上业务保持高度的敬畏心。

列一些防误操作的要点：

  • 吸取他人教训。如同开车一样，怎么保证自己不出事故呢，一个方法是多看交通事故集锦，看得多了就知道什么犄角旮旯的失误都可能会出现，时刻需要小心。
  • 二次确认。无论是自己二次确认，还是他人二次确认，都能在一定程度上减少误操作。试想：一个指令或按钮点击之后，立马就开始执行了，完全没有回头机会，太可怕了。如果系统不支持二次确认，或者二次确认信息不完备，那就提需求直至完善。
  • 线上任何操作，都先经过测试。这个必须成为运维铁律。
  • 灰度操作，不要大批量同时操作，给自己一个死缓的机会。
  • 对于容易搞混的操作对象，加以颜色、提示等视觉效果的区分。
  • 拷贝命令进行执行的一个小技巧：先敲入#（表示注释，不执行），然后再拷贝指令，避免拷贝错。

临时做的改动，怎么记得改回来？

试想一下这些场景：

  • 还有3天才CBT，先把报警屏蔽一下吧。
  • 为了处理故障，先临时改了一下系统操作。
  • 流程里面临时屏蔽了一个操作，维护后才要开启。

好，对于这么多临时做的操作，怎么记得改回来？

  • 最好的办法：自动改回。比如报警系统上设置屏蔽时间段，过期后自动解除屏蔽。
  • 记录一个todo单。
  • 定个闹钟⏰。
  • 知会到其他运维小伙伴，互相提醒。

On-Call制度

Google SRE解密那本书中对On-Call制度有很详细的介绍了，这里不重复探讨这个理念，而是阐述下个人的理解。

On-Call是有准入标准的，达到标准才可以进入On-Call，同时也是对每位值班运维有一些基本要求，但除了这些之外，更多的是为了提升运维的幸福感：

  • 当周值班过程中，也并不需要所有需求都由值班来跟进，对于长线需求需要合理分配人力跟进。
  • 不值班的时候，可以有更多时间专注于工程化或跟进长线工作，避免被打断。
  • 不值班的时候，非工作时间可以减少日常问题的处理，只需要关注事件升级的重大问题即可。

以目标驱动的OKR工作法

O（目标）：振奋人心的，有一定挑战性的目标（允许部分失败）。

KR（关键成果）：可量化衡量的成果。

KA（关键行动）：为了达到KR，所付出的行动。即：所有的行动落实后，KR即可达成。

学习链接：OKR目标管理

3、思维方式

结构化思维

说道“思维”，就不得不提“结构化思维”，不论何种职业，结构化思维都是非常重要。

相关书籍：《麦肯锡结构化战略思维》、《麦肯锡思维与工作法》。

具体的做法在书中已经讲解的很详细了，这里不在赘述，更多理解它的意义：

  • 为了让我们站在更高的全局战略角度进行思考。
  • 更好的进行表达和沟通。

产品思维

作为一名游戏运维，我们需要换一种思路做运维，培养产品观，也就是站在用户的角度思考问题，主动去挖掘需求，提升运维综合服务能力并外输，最终增强用户体验。

举一个例子：

某海外游戏项目A 有网络加速的需求，运维针对这单个游戏项目定制化建设了一个网络加速解决方案和系统。

以产品思维的角度，怎么思考这个事情呢：

  • 这个是A项目的需求，背后有没有更多的需求可以挖掘呢？
  • 同类型的海外游戏B，有没有这个需求呢？
  • 如果不是海外游戏，国服游戏呢，会有这种需求么？
  • 其他游戏也有这个需求，专用于A的解决方案能覆盖到么？
  • 新游戏项目接入成本高么？运维人员的管理成本高么？
  • 游戏可以从中获得哪些收益？
  • 怎么把这个解决方案提升为一个产品去运营呢？

怎么看待和消除琐事

什么是琐事？

在Google SRE的概念里，琐事是指：运维中手动性的、重复的，可以被自动化的，战术性，没有持久价值的工作。同时，琐事还会与服务呈线性关系增长。

举个例子：每天手工查看某个游戏项目的10台服务器磁盘是否写满。这件事是手动重复性的琐事，是可以自动化的，对运维没有产生任何价值。如果业务增加到100、200台机器，这个琐事的工作量也会线性增长为10倍、20倍。

在游戏运维中，常见的一些琐事：

  • 服务器磁盘满的时候，手动清理日志文件。
  • 游戏QA测试环境版本更新。
  • 日志导出。
  • 咨询：怎么登录服务器、怎么申请资源、怎么接入xxx。
  • 等等。。

哪些看着像是琐事，但实际不是？

  • 一些管理类的杂事，这些是流程开销，而不是琐事。比如：团队会议、OKR制定、复盘总结、分享、绩效考核等等。
  • 一些脏活累活，是具有长期价值的，也不能简单的归为琐事。比如：为了做报警治理，需要梳理报警规则、重新定义、接入系统，等等有大量繁重的工作，但这些不是琐事。

识别了什么是琐事之后，怎么看待琐事？

作为一个合格的一线游戏运维SRE，我们需要天然的排斥琐事。最多容忍做2次（事不过三），然后采用工程化的思路开展优化、做成自动化，最终消除琐事。

怎么消除琐事？

  • 自动化：让系统代替人工。
  • 自助化：让需求方代替运维。

目标期望琐事占比多少？

最好是低于50%，Google SRE团队做到了低于33%。

怎么闭环？

闭环是一种能力，也是一种态度。

能力在于把一个事情做成，是结果的体现，而态度是过程的体现。

PDCA（Plan-Do_Check-Act）闭环思维：

  • Plan：做计划。
  • Do：按计划实施。
  • Check：检查复盘。
  • Act：改进。

以跟进大的运维需求为例，一个具有闭环意识的运维会怎么做？

  • 先明确计划：谁来跟进、何时交付、交付物是什么、什么方案。
  • 实施：主动沟通、同步进度、记录。
  • 检查：交付前检查、复盘。
  • 改进：流程优化、自动化。

如果换成一个没有闭环意识的运维会怎么做？

  • 主要精力用在前2点，也就是重点在于做了这个事情就好，而不是把事情闭环（缺少后面2点）。

一份训练主动性的清单

主动性是可以当做一个习惯，是可以培养的，列一个清单：

  • 需要来的时候，多了解一下背景，挖掘一下真正需求，并思考必要性、通用性。
  • 事情做完的时候，回头看看哪里做的不够好。
  • 有一些心得，及时总结下来，并分享出去。
  • 所做的项目运维动作，及时信息互通。
  • 遇到自己难于解决的问题，不管技术还是非技术，都及时反馈。
  • 定期审视业务架构、部署架构、流程机制，分析其中的弱点，加以改进。
  • 从现状一些细节问题，思考未来可能遇到的挑战，提前布局。

急他人之所急

这里的他人是你的客户或合作伙伴，“急他人之所急”本质上是要我们运维人员具有共情和客户意识。

一个典型的场景是，在业务出现故障的时候，项目组往往是特别急的，因为在根因尚不明确、故障没有恢复的时候，他们可能是处于黑盒状态，不知道当前状态、不知道处理进度。等故障恢复正常了，他们又特别关心问题原因是否找到了、是否有措施保证以后同类问题可以彻底避免了。

如果我们表现的也很“急”，甚至比项目组更“急”，在态度上表明我们也是非常关心业务运行状态的，在事情跟进上做到真正快速恢复、根因定位、改进到位。

这是赢得互信的一个途径。

向上管理

很多人知道“向上管理”这个概念，但是实际工作中并没有执行过，体感不强。

甚至有一些误区：疯了么，去管理那个决定你的工资、晋升、奖金的主管？

这里的“上”指的是谁？是主管么？

是，但不全是。这里的“上”，指的是你工作关系中的“上游”，可以是组织架构中的主管，也可以是业务线中的客户。

怎么向上管理？

  • 帮助决策：提出至少2套方案，梳理清楚优缺点对比、ROI分析、人力排期等。做选择题，而不是填空题。
  • 进度管理：所跟进的事项进度需要及时同步。
  • 预期管理：合理降低或提高预期。
  • 风险管理：梳理清楚风险点，以及可行的解决方案。
  • 信息传递：梳理重要事项做好信息同步，并且做到及时性。

他山之石，可以攻玉

这句话在大部分场合，是指借鉴别人做的好的经验，但是也需要反过来，吸取别人的教训。如同开车一样，要想提高安全意识不出事，最好的办法是多看看别人的事故集锦，思考危险可能来自于哪些情况、换做是我能否避免。

在游戏运维中，教训大部分来自于故障，尤其是人工误操作类的故障。从历史故障单中可以分析出很多同类问题，总结提炼为通用的改进措施，在更大的范围进行规避。

所以，建立“复盘机制”，可以帮助我们把教训主动分享出去；建立“故障分析机制”，可以帮助我们主动吸收别人的教训。

合理吐槽有益，过度吐槽伤身

人无完人、事无完事、系统也无完美的系统。所以我们很容易站在旁观者的外部角度识别出别的人、事、系统的问题，然后开始进行无情的私下吐槽。

什么是合理的吐槽？

有解决方案或指导意见的吐槽，才是有益的、合理的。这种吐槽是正向的，会推动问题的解决。

而纯粹发泄式的过度吐槽，则会形成怨气，并且容易传播开来，最终降低整个团队的士气。

故障真的那么可怕？

故障本身不可怕，可怕的是不重视它的态度。

这个心得来自于一个真实案例：在时隔一个月内，同一个重点游戏项目连续出现5次运维侧的重大故障。按照以往经验，别说一个月出现5次了，超过1次，项目组就会无法容忍，引发投诉。

从结果来看看我们当时是怎么做的：

  • 【时效性】所有故障在恢复后，当天给项目组发送了故障报告（其中2个故障是简报）。（注：时效性高要求，同时推广落地到故障报告、会议纪要等多个场景）
  • 【比项目组更急】紧急联合相关运维团队，排查根因、讨论复盘，制定改进措施。
  • 【改进彻底】对所有5个故障制定了覆盖详尽的彻底的改进措施，并按周同步落地进度。
  • 【价值外延】从中分析出通用问题，在全部游戏项目中都落地了改进。

看看项目组是怎么反馈的：没有产生不满情绪、无投诉。（按以往做做好的时候，100%肯定会有不满和投诉）

得出的结论：

  • 虽然有的故障是公共服务侧产生的，但是站在项目组角度，故障都是整个运维团队的责任，并不会再细分。因此，我们运维是一个团队，一荣俱荣、一损俱损。
  • 项目组对故障的态度：并不是怕出问题，而是怕没人重视，怕改进不彻底、再次出现。
  • 对于故障应该制定明确的SLA指标。比如：响应时间、恢复时间等。
  • 运维SRE具有对业务负责的态度，很重要。

4、软能力建设

哪个更重要？硬实力还是软技能

技术人很容易对自己熟悉的领域有技术情节，会在一定程度上认为个人技术水平，也就是硬实力，才是最重要的，其它的并不重要。

没错，技术水平是很重要，是我们从事这个职业的立命之本。它是一座每个技术人员这座大厦的地基，要求要很牢固，但是软技能相当于是大厦的每一层，它越多自然大厦就越高。

并且还有一个很重要的地方：技术水平经过大量的学习、实践，是可以很快很容易提高的。但是软技能不行，它更多的依靠一些天赋性的东西，很难在短期内通过训练习得。

所以，硬实力决定了我们的下限，软技能决定了我们的上限。

可量化的技术水平评估模型

评分标准：

关键指标分值评价标准得分权重
技术水平60是否满足岗位和职级的技术要求。不合格：小于0.7基本合格：0.7合格：0.8优秀：0.9卓越：1.0
靠谱度20做事稳重情绪稳定，凡事有始有终，清晰易懂不留坑。不合格：小于0.6合格：0.6较好：0.7优秀：0.8卓越：0.9~1.0
主观能动性20思考为什么这样做，如何做对，还有没有更好的方案，有哪些风险以及如何规避，有无遗漏，事后总结。不合格：小于0.6合格：0.6较好：0.7优秀：0.8卓越：0.9~1.0


计算公式：
加权求和。比如全部合格的话，得分为：60*0.8 + 20*0.6 + 20*0.6 = 72

三个关键指标：
1、技术水平：是否满足岗位和职级的技术要求。
2、靠谱度：做事稳重情绪稳定，凡事有始有终，清晰易懂不留坑。

靠谱度计算公式：K = i*a/c^2
其中：
K：靠谱度
i：个人性格稳定程度
a：个人能力的强弱
c：外界环境因素干扰大小

3、主观能动性：思考为什么这样做，如何做对，还有没有更好的方案，有哪些风险以及如何规避，有无遗漏，事后总结，遇到事情不推诿，不挑活。

要求
1）技术水平：必须合格。
2）靠谱度和主观能动性：至少一个合格，或更高要求必须“靠谱度”合格。
总分：合格线：72分。其中：72~79 合格、80~89 优秀、90或以上 卓越。

在技术水平必须合格的大前提下的矩阵象限：

主观能动性好主观能动性差
靠谱重点培养对象偏执行
不靠谱预研类，方案讨论类，等等，但需要有人兜底淘汰

下面，提供一个经过这个评估模型检验过的真实案例。

2020年底左右，使用这个模型，我对所带的小团队共计5个人分别进行了量化测评，最终情况如下：

人员总评分（72合格）单项情况最终结果
SRE 1483项均不合格，主观能动性0分新人，试用期不合格，辞退。
SRE 258仅技术合格，另2项不合格，靠谱度0分建议辞退。后最终转岗到其他部门，退出游戏运维组，相当于淘汰。
SRE 365技术勉强合格，靠谱勉强合格，主动性不合格暂时当外包用，转出到其他小组。类似NBA转到发展联盟。
SRE 4723项均合格新人，作为高潜培养。
SRE 5803项均合格，略有超出作为骨干。

个人知识体系建设

可能很多人不是很理解：知识体系，不是团队的么，为啥个人也要有？

其实两者需要兼而有之。

如果去仔细观察被打上“靠谱”、“专业”标签的优秀员工，不难发现他们身上有一套自己的做事方法和思维模式，这是因为他们已经形成了自己的知识体系了。

他们知道：

  • 技术上需要更关注哪些方向，团队的目标和个人的成长怎么结合。
  • 什么是正确的做事情，而不仅仅是做正确的事情。
  • 遇到问题，怎么拆解、怎么寻求帮助、怎么跟进解决。
  • 怎么不断提高自己的业务能力、软技能。

那怎么去建设呢？软技能方面，其实全在本文中了，可以借鉴一下。

及时复盘

在PDCA（Plan-Do_Check-Act）工作方法中，最重要的就是Check然后Act，也就是复盘。

复盘的意义在于回首过去和展望未来，哪些做的好，哪些做的不好。做的好的继续保持，不好的持续改进，这样在未来的场景下会做的更好。

那为什么要“及时”呢？

因为时机很重要，需要趁热打铁把所有相关的细节全部记录下来，同时在大家关注度比较高的时候，如果热度衰减之后再复盘的效果就会很差，甚至有一些数据会过期失效（比如监控数据）。

在什么情况下需要做复盘呢？包括不限于下面这些：

  • 重大故障发生后。
  • 重大变更后。
  • 游戏OB上线后。
  • 一些常态运作机制实行一段时间后，比如OKR。
  • 问题集中爆发时。
  • 周期性的常态复盘：半年复盘、年度复盘。

写的下来，讲的出去

对于技术上的知识点或经验，怎么代表真正理解和懂了呢？答案就是能把它写的下来、讲的出去。

这是个层次递增的过程，包含三个阶段：

第一阶段：理论知识学习了，也经过了实践。

第二阶段：清晰的写了下来，让别人可以看明白。

第三阶段：写下来之后，可以通过讲的方式表达出去，让别人可以听明白。

一般可以通过作为主讲人进行沙龙分享的方式来综合锻炼这三个阶段。

怎么写好一封邮件？

听到这个话题，是不是内心是这样想的：What？谁还不会写邮件。但事实的确如此，大部分人所理解的写邮件仅仅就是写邮件而已，这里探讨的是怎么“写好”，重点在于“好”。

首先，什么是“好”的邮件呢？我们从邮件的受众视角来分析怎么算“好”，然后就自然而然的知道怎么写好了。

比如，我收到了一封邮件，怎么判断呢：

  • 我是收件人还是抄送人：决定了我是需要知悉并跟进，还是仅知悉就好。
  • 邮件都发给了谁：比如有没有发给我所在的团队、相关同学是否都在收件列表中。
  • 主题够不够清晰：方便以后我搜索。
  • 如果我只需要知悉就好了，那大概率我是不了解细节的，那么有没有清晰的背景、结论、总结、摘要等信息，让我很容易就清楚邮件想表达什么。
  • 如果我是收件人，那么背景、细节我是基本清楚的，可能我重点关注结论性、需要跟进的事项就好了。
  • 除了内容，我还会在意其它一些细节的地方：
    • 邮件正文的文字格式是否统一。
    • 重点是否突出。
    • 段落是否清晰。
    • 是否有错别字。

现在，应该会有一个大概的脉络去写好一封邮件了，同时在写完一封邮件之后不要急着发送，可以自己审视一遍，重要邮件最好由第二个人帮助做一次校稿。

归根到底，邮件的主要目标受众是抄送人，而不是收件人！

所以不管写邮件还是写各种文档，最重要的是准确的找到谁才是你的目标受众，以TA们的的角度来组织内容编写。

执行力

什么是执行力：贯彻战略意图，完成预定目标的实际操作能力。

包含两层意思：一是能力、二是态度。

具备高执行力的人，有这么一些特点：

  • 对目标和交付质量清晰。
  • 有DDL意识，会在DDL之前完成。
  • 如果遇到技术难题或需要帮助，会及时反馈。
  • 不需要别人催促，会主动同步进度。

说到底，执行力就是把事情闭环（凡事有交代、件件有着落、事事有回音）。

5、流程规范和标准

为什么需要那么多流程规范？

一方面，是因为人是不可靠的，为了屏蔽掉人的因素差异可能导致的人为失误，需要把工作流落到流程规范中去，然后再通过把规范落到系统进一步规避人的因素差异。

另一方面，是为了提高效率、减少沟通成本。对于特定的工作流，大家只需要按照标准的流程操作就可以了。

再一个，是为了形成标准化，提高交付质量，本质也是去除人的差异导致的交付质量不标准。

总之，需要靠流程规范来把“失控”变为“可控”。

需求跟进质量标准

在需求全生命周期中，对提出方和接收方都提出了质量标准要求。

1、【提出方】需求评审

提出方质量标准

1）提出前，先评审需求合理性，是否通用需求；

2、【提出方】提出新需求

提出方质量标准

1）需求描述标准：

对于需求发起方，需要清晰、准确的描述需求，包括但不限于如下要点：

  • 描述清楚需求的背景；
  • 明确操作对象：比如，需要明确项目、环境、服务、外部系统等等；
  • 明确期望完成或交付的成果；
  • 明确期望的交付和操作时间：不明确交付时间的需求，按照中/低优先级安排；
  • 对于需求描述不清楚或有歧义引发的问题由需求提出者负责；

2）需求提出方式：aone系统；

3）知识库建设。

3、【接收方】首次响应

接收方质量标准

1）响应时间要求：

  • 工作时间、非工作时间所有紧急需求：1~5min内。
  • 工作时间的非紧急需求：1小时内，最晚当天工作日内响应；
  • 非工作时间的非紧急需求：最晚于下一个工作日响应；

4、【接收方】需求评审和讨论实现方案

接收方质量标准

1）实现方案需要考虑特殊性和通用性；

2）如果交付成果涉及线上操作，需要准备变更计划文档；

3）如果需求涉及第三方系统，需要拉上对应系统接口人一起讨论；

4）内部讨论结果需要形成结论，并整理成文档进行记录；

5）如果内部评估认为需求不合理，可以婉拒，但是需要经过TL Review；

5、【多方】多方沟通

提出方质量标准

1）对于长期事宜，需要明确各方接口人；

2）如有必要，拉通钉群便于沟通；

3）各方接口人各自同步回自己的团队相关人员知悉；

接收方质量标准

1）对于长期事宜，需要明确接口人；

2）长线需求，记录到aone进行跟踪；

6、【接收方】明确需求交付预期

接收方质量标准

1）再次明确/复述需求交付成果，确保交付质量；

2）明确最终交付时间。如果晚于需求的交付时间，需要说明原因并得到确认；

3）对于长期或涉及周边系统支撑的事宜，明确下次同步进度或下个里程碑的时间；

7、【接收方】处理需求

接收方质量标准

1）制定该需求的设计方案；

2）发起设计评审（必要时拉通提出方一起Review），通过后实施；

3）如果不通过需要重新制定方案，然后再次进入Review流程；

4）对于长线需求，需要制定分阶段的排期计划，同步到提出方和各接口人；

8、【接收方】定期同步进度

提出方质量标准

1）需求提出方，如果有涉及到外部依赖的情况，需要积极推进完成依赖项；

2）对于长期跟进事宜，非接口人对详细情况的了解，直接咨询本方的接口人；

接收方质量标准

1）明确当前已完成事项，待完成事项，最好提供一份具体的事项列表和状态进行追踪；

2）明确依赖的事情或人员；

3）涉及周边系统支撑的话，需要积极沟通并及时同步进度；

4）通知范围：各方接口人；

5）对于长线工作，需要明确下次同步进度的时间点；

9、【接收方】需求实现完成

接收方质量标准

1）整理和完善必要的方案实现、操作指引文档；

2）涉及变更操作的，需要明确指出最终结果和变更情况，确保知情权；

3）交付前，需完成自测；

4）通知进行验收测试，并提醒外部接口人对于新功能进行验证后方可上线；

10、【提出方】验收测试

提出方质量标准

1）提出方需要尽早安排并积极推进测试，由于未积极推进测试和验收导致的延期问题，由提出方负责；

2）新服务、新功能，必须经过QA验证业务功能无问题之后才可以进行上线；

接收方质量标准

1）配合完成测试和演练工作；

11、【多方】需求上线

提出方质量标准

1）明确上线时间点，并同意上线；

接收方质量标准

1）评估需求上线对正式环境的影响；

2）涉及线上操作的话，按照变更规范实施，不遵守变更规范产生的问题由接收方负责；

3）尽量避开维护、高峰期等时间点；

12、【多方】验证通过

接收方质量标准

1）部分需求上线后有一定观察期，在观察期结束后，需要再次反馈观察结果；

13、【多方】结束

提出方质量标准

1）确认需求正式结束；

2）对于有价值内容，进行经验总结并整理进知识库；

3）关闭需求单；

4）视情况可以对本次需求完成情况，进行反馈；

接收方质量标准

1）知会干系人本需求正式结束；

2）对于长线工作有记录状态的话，更新最终完成状态，发起需求关闭给提出方关单；

3）重大变更：按照变更规范结束本次变更；

4）对于有价值内容，进行经验总结并整理进知识库；

5）视情况在必要时进行复盘；

标准和规范的制定或优化能力

一般来说，通常会要求一线运维同学具有标准规范的执行力，这个是最基础的要求。

更高阶的要求是，要具备制定或优化运维标准和规范的能力，这时候需要考虑的切入点就会完全不一样了。

通常需要从如下视角来提高这个能力：

  1. 提炼归纳：从众多需求、反馈、建议、痛点中，抽丝剥茧式的提炼出通用性的东西，形成标准并落到系统和流程中。
  2. 理解业务场景，结合运维专业性，提高业务稳定性和质量。

游戏长线运营的挑战

游戏发展起来后，必定会朝着精品化战略的方向推进，当游戏长期（超过3年）运营，SRE在运维工作中就将会面临很多新的挑战。

客观情况：

  1. 机器过保，故障率升高；
  2. 软件版本老旧需要更新、官方源不再维护、软件停止更新。
  3. 证书过期；
  4. 机房相关：机器搬迁、更换IP、超电搬迁等等；
  5. 运维脚本、工具系统老旧；
  6. 人员的新旧迭代；

带来的问题：

  1. 业务迁移将成为常态；
  2. 如果规划不好，软件版本更新可能会遇到较大困难；
  3. 集群达到生命周期，无法继续使用；
  4. 面临需要调整优化的时候，当前SRE会由于历史欠账，无法推进下去；
  5. 容易踩坑；

所以，需要在项目初期就要做好长期运营的准备，提前规划好运维框架，避免这些问题。
要点：

  1. 简单化：满足容易迁移、容易维护、容易升级的目标；
  2. 文档化：尤其是在一些容易出问题的地方，比如：逻辑复杂、依赖关系、限制条件等等，进行详细描述；
  3. 脚本：完善注释、通俗易懂；
  4. 做长远考虑，尽量做到通用，而不是写死；
  5. 减少定制类的需求；
  6. 减少临时性、偷懒性质的操作；

6、运维定律

墨菲定律

简单来说，事情往往向你所想到的不好的方向发展，只要有这个可能性。

根据墨菲定律，可以得出4条结论：

1）任何事情都没有表面看起来那么简单；

2）所有的事情都会比你预计的时间长；

3）会出错的事情总会出错；

4）如果你担心某种情况发生，那么它就更有可能发生。

知易行难

“知”什么？难什么？

  • 知：自己的问题。难：自我改进。
  • 知：他人的问题。难：同理心。
  • 知：系统的问题。难：推进改进。
  • 知：流程的问题。难：优化流程。
  • 知：应该要做成什么样。难：实际做出来效果差了十万八千里。
  • 知：怎么做才是对的。难：真正做对。

所以，在大部分场景下，发现问题或讲一些大道理，是很容易的，难的在于行动。

故障是第一推动力

作为一线运维，对故障真的是又爱又恨。

恨它是因为一旦故障，业务首先受损，然后大家都连带受损。

爱它是因为，你会发现，很多原先推不动的事情，在故障发生后顺利的推进起来了，甚至不用推就自然而然的发起了。

懂的自然懂，所以这里不过多展开探讨了。

那什么是第二推动力？

可能你会觉得是来自老板的压力。

但我个人觉得是：客户声音，也就是外力。

如果我们是作为下游，需要有一个开放的心态接纳客户反馈，不管是好的赞美、还是差的投诉。从统计学角度看，真正传递到我们的客户声音占比会多少呢，可能只是冰山一角，所以更加要重视这种改进机会。

如果我们作为客户和下游系统的中间商，那这时候我们可以借助客户声音，推进下游系统进行优化改进。

Deadline是第一生产力

Deadline就是我们经常俗称的DDL，也就是截止的完成时间，按照计划要在这个时间前交付。

DDL是治疗拖延症的良药，同时，任何不加DDL的承诺都是耍流氓。

所以制定合理的DDL时间也是非常重要的，需要依据多方因素制定好事情优先级，各方对DDL达成一致，并严格执行。

缓事宜急干，敏则有功

对舒缓的事情，要急速解决，因为思想敏锐，往往获得成功。

急事宜缓干，忙中出错

对急迫的事情，应沉稳处理，因为急躁忙乱，常常漏洞百出。

今天偷个懒，明天还你一堆坑

常见的偷懒和留坑的场景：

  • 懒：临时找台机运行了个组件。坑：机器下线的时候会忽略这个组件运行，连带下线。
  • 懒：不想写文档记录了，或者简单随便写一下吧。坑：细节不记得了。
  • 懒：一些配置或IP写死在流程脚本中。坑：遗漏。
  • 懒：按照开发同学的需求，随意开放了一些端口。坑：安全漏洞。
  • 懒：不想花时间做成通用流程。坑：手动操作出错或遗漏。

偷懒，就是在给以后挖坑。

7、怎么体现运维价值？

忙于救火 VS 勤于预防

先思考一个问题：消防员为什么受人尊敬？

因为他们充当了英雄的角色，经常救人于水火之中，被救助的人往往心存感恩。

同样的道理，在游戏运维过程中，经常救火的一线运维人员，也是受人尊敬的。最根本的一点，他帮助业务及时止损了。救火的价值，是既可以主观感受到，也可以理性量化出来的。

第二个问题：如果整个一线运维团队经常处于救火状态，好还是不好呢？

如果救火变成常态，那就直接表明运维工作没有做好，虽然在关键时刻也能解决掉问题，但这只是事后的补救止损而已，而不是提前预防并规避。

第三个问题：大道理我们都懂，但是怎么量化勤于预防的效果呢？

举个例子，如果回顾一段周期内，发现并没有出现任何故障，业务可用性在当周期内是100%，那怎么衡量是你做了5项优化的成果，还是啥都没做、只是运气好业务运行稳定而已。

感性来说，可能大多数情况，人们往往会看不到你做的5项优化，习惯性的认为就是运气好而已，这时候运维的价值就会打折扣，也会对士气有所伤害。

个人觉得，要解决这个困扰的问题，需要有这些措施：

  1. 得到老板的支持，在整个运维团队中形成勤于预防优先于救火的工作导向。
  2. 通过对FMEA、风险管理、隐患治理等多种稳定性保障预防措施的实施，形成勤于预防的量化数据，最终呈现出可视化、可分析的统计报表。
  3. 在救火或故障次数达到一定量级的时候，当即开展一次复盘，分析出哪些是可以提前规避而没有做到的，对于同类问题进行彻底根治。

怎么获取成就感和幸福感？

先摘抄一下这两个名词的释义：

成就感：
做完一件事情或者做一件事情时，为自己所做的事情感到愉快或成功的感觉，即愿望与现实达到平衡产生的一种心理感受。

幸福感：
基于自身的满足感与安全感而主观产生的一系列欣喜与愉悦的情绪。

那么在游戏运维领域中，什么是成就感？

它是运维专业度的体现，是作为技术人的自我价值的实现，它更注重过程，更多时候是一次性获得的。

比如：

  1. 游戏正式上线，整个过程高效、专业，无故障产生。
  2. 解决了困扰业务很久的一个难题。
  3. 通过技术选型，为项目节约了大量的成本。
  4. 识别业务风险，推动进行了优化，规避了业务受损的可能性。
  5. 通过联合推进优化，解决了团队或业务中的痛点。

什么是幸福感呢？

它是一种达成某种良性优化结果或状态之后，获得的感受，它更注重结果，并且它是持续性的。

比如：

  1. 休息时，不被打扰。
  2. 报警自愈了，不再需要人工介入处理。
  3. 琐事、低价值的事情，越来越少。
  4. 维护过程，可以无SRE值守了。
  5. 沟通成本大幅降低了。
  6. 自己和团队更有活力了，个人技能有不断进步成长的空间。

那怎么获取成就感和幸福感呢？

成就感可能因人而异，但是幸福感大体一致。相对来说，成就感会更容易获得到，因为它更多的是个人的，是一个过程的感受，更多还需要自己挖掘和产生。

幸福感更难获取到，不过也可以梳理一些要点，比如一份幸福感提升计划清单：

  1. 对报警治理和收敛，提高报警有效性，降低干扰。
  2. 持续开展报警自愈机制的实施。
  3. 基于SRE工程化思想，不断消除琐事，全面实施自动化。
  4. 以自助化为目标，对运维侧的服务能力不断建设，并整体外输。
  5. 所有工作流都梳理出一份标准的运作流程，尽量减少人的差异性。
  6. 基于文档FAQ、手册指引、或者工作流，减少日常重复性沟通的成本。
  7. 采用复盘机制，定期或不定期对积累的问题展开逐一分析和解决。

如何体现客户价值？

在游戏领域，终端客户就是游戏的玩家，业务就是游戏服以及配套的服务，两者的价值体现是紧密绑定的。运维团队为业务创造了价值，最终也会在客户身上体现出来。

那这里的“客户”指的谁？不同人/团队的客户是不一样的。

人/团队客户
游戏项目组玩家
公共平台服务游戏项目组
一线游戏运维游戏项目组运营团队研发团队
运维研发游戏项目组一线运维QA团队合作团队

所以理清楚谁是你的客户之后，才可以更容易的思考怎么做到“客户第一”。

倾听客户声音

客户提了什么需求，背后真正的需求是什么，为了解决什么问题。

即便是客户投诉，也可以用一种正向、积极的心态来应对解决。

主动挖掘客户需求

方法有很多：定期回访、从浅需求中挖掘深需求。但这更多是需要具备很强的主观能动性才可以做到，这对很多人都是一个挑战。

所以，可以建立一种容易执行的制度，团队一起共同讨论，保持高效运作。

做好运维补位

以运维专业性，辅助或反哺业务在可用性、稳定性、安全等方面更加健壮。让前台业务团队对运维基建能力可以放心，也更安心的专注于游戏业务本身。

保持业务敏感度

疲倦或惰性，一般来源于年复一年的跟进同样的项目，尤其是在游戏长线运营之后。主观感受上，每天都是在面对同类型的工作内容，如果自动化程度不够高，这种感受就会更强烈，久而久之就容易产生懈怠。

为了保持业务敏感度，那就必不可少要保持新鲜感，而不是重复和安于现状。

要想打破这一点，可能有下面这些措施：

  1. 首先要先把自己的人力解放出来：消除无意义、低效、重复性的人工操作或沟通。在这个过程中会有很多新鲜感的事情。
  2. 通过流程规范来保证，而不是靠人。比如：通过故障处理规范保证所有故障及时解决和彻底改进、通过复盘机制保证在重大节点之后有回溯和展望未来的环节、通过需求跟进标准保证游戏项目组的需求被理解/挖掘和跟进交付质量、通过定期沟通和回访来前置性的对未来进行规划，等等。
  3. 人员轮换。但这个措施是个双刃剑，如果时机不成熟，不要轻易尝试，会带来很多额外代价（沟通成本、故障升高等）。

运维专业度

对一名游戏运维人员的最高评价就是：TA的专业度很高，做的工作对项目是有帮助和价值的。

专业度是一个多维的评价标准，包含了下面一些方面：

  1. 个人技术能力：技术水平因人而异，有高有低，但是如果经过大量的运维工作经验之后，技术能力会显著提升到满足需求的标准之上。
  2. 解决方案能力：仅仅有单个或一些技术栈的能力还不够，需要形成更专业的解决方案。更多时候，没有最完美的解决方案，只有当下最适合的。
  3. 应急能力：面对紧急需求或故障的时候，需要具备较强的应急能力。这需要做很多储备，一些小Tips：常用文档汇总在一起、制定应急预案并且容易被找到，等等。
  4. 个人或团队意识：
    1. 服务意识
    2. 优化意识
    3. 风险意识
    4. 闭环意识

服务意识

运维即服务，所以一线运维人员需要具备良好的服务意识，要为客户的满意度负责。

是否有服务意识，取决于做事方式上，一般可以有几种方式：

  • 与合作部门非技术岗位的同事进行沟通的时候，使用业务语言替代纯技术语言，以对方易懂的形式进行沟通，为目标达成一致。
  • 习惯于挖掘客户背后的真实需求。很多时候，客户提出的问题，可能并不一定是真正要解决的问题，而只是解决问题的其中一种尝试的办法，这时候需要运维深入挖掘背后的真实需求，一起找到最合适的解决方案。
  • 站在客户的角度去解决问题，并且在解决问题时关注目标，而不是困难。

服务能力外输

这里的服务能力，包括了一切可以服务于客户、服务于业务的运维能力。

比如：

  • 稳定性保障能力
  • 变更发布能力
  • 流程管理能力
  • 系统工具能力
  • 故障处理能力
  • 方案架构能力
  • 优化能力
  • 风险管理能力

我们可以通过SLO/SLA的方式，把运维服务能力量化出来，对外发布，并严格执行。

8、数据，数据，还是数据

什么是运维数据？有哪些价值？

在运维域，一切可以产生业务价值的数据都可以称作运维数据。

运维数据的类型数据价值
基础资源数据服务器数量、宕机率服务器成本成本优化
风险管理架构优化方案选型
变更数据变更记录
变更成功率		回溯分析
变更流程改进变更质量改进
故障数据故障率
MTTR发现来源故障等级分布		故障分析和故障治理
全局彻底改进可用性评估可用性提升
网络数据玩家网络情况
机房网络延迟接入点网络延迟RTT指标DNS指标		机房选型
部署架构设计网络加速方案
监控报表监控覆盖度
监控有效性		降低故障MTTR
成本优化
报警数据报警量
报警响应和处理时间智能报警的准确率和命中率处理率		报警收敛和治理
提高报警有效性及时发现业务问题保证业务问题及时发现并处理
工单数据工单分布情况
人均工单量各类型工单占比情况		分析量化人力分配情况和工单质量
识别低价值工单，工程化改造通过自动化/自助化的方式解决重复性工单
业务稳定性数据风险和隐患数量
可用性SLO/SLA达标情况演练数据		挖掘影响稳定性的因素，并彻底解决
持续改进减少停服时间

为什么运维数据非常重要？

运维数据是为所有的运维工作提供支撑依据的。

试想：

  • 没有报警数据，怎么知道从哪里入手开展报警治理、治理后的效果？
  • 没有工单分布情况的数据，怎么知道人力分配是否合理、是否有太多低价值工单？
  • 没有故障数据，怎么进行全局治理、怎么进行可用性提升？
  • 没有网络数据，怎么进行机房选型、部署架构优化？

怎么得到运维数据？

最低效的方式是靠人工从邮件、IM中统计，这是一种不可持续的方式。

高效的方式是落入到系统中，由系统定期自动统计出所需要的运维数据，更进一步可以由系统按照预制的规则，进行一次初步分析，剩下的才是需要人工进行判断的部分。

怎么分析运维数据？

方法论：

针对不同类型的运维数据，识别数据中的各个字段和含义，找到可以固化分析它的维度和方式，然后周期性进行分析。

以故障数据的分析为例阐述，怎么实施这个方法论。

1、识别数据各个字段的含义

原始的故障数据，其实是一个一个的故障单，每个故障单包括了下面这些字段和内容：

  • 归属项目：哪个项目发生的故障。
  • 故障分类：代码BUG、云商问题、误操作、网络故障，变更引发的故障等等。
  • 故障分级：灾难、严重、高、中、低。
  • 是否有监控报警。
  • 发现来源：监控、玩家反馈、产品组发现、运维主动发现。
  • 责任方：谁主导改进。
  • 时间点：发生时间、响应时间、处理时间、恢复时间。用于分析MTTR等指标。
  • 业务影响面：影响时长、玩家数、影响功能。
  • 故障Timeline：主要事件的时间线。
  • 故障根因。
  • Review记录：故障Review情况。
  • 改进措施：改进项目、状态、问题点、改进措施、验收标准、负责人、DDL。一般包括临时改进措施和彻底改进措施。

2、从哪些维度分析它？

可以从这些单维度或多维度进行分析：

  • 频发型同类故障：挖掘真正原因并根治。
  • 从故障根因中分析出通用、典型故障，进行全局治理。
  • 项目维度：提供项目粒度的故障详细数据供项目优化。
  • 责任方 + 故障分级维度：评估SLO/SLA是否达标。
  • 发现来源：分析哪些故障不是有监控发现的，从而改进提高监控覆盖度。

3、周期性执行分析

定期进行故障评审，输出全局的改进措施，并沉淀到故障防范清单。

最后，做一个数据驱动型的SRE

培养数据意识：

  1. 养成数据记录和数据分析的习惯。
  2. 凡事以数据说话，未经验证之前不要形成结论。
  3. 只有数据用起来才会发挥价值，所以去使用它，用好它，为业务服务

发表回复