运维，反面的思考 | 行业论坛第11讲笔记

Scalers点评：这是成长会翼非易(Zack)7月5日行业论坛第11讲。运维可能大家没有听说过，但是这次Zack却把这个领域讲的深入浅出，让大家理解一种领域的思路。我请Zack把笔记与大家作分享

1 分享的主题

我主要想以我的角度，告诉大家什么是运维。选择这个题目-《运维，反面的思考》 ，是因为运维关注是系统的异常。相比于“是”，运维更关注“否”，事情的反面。我带领大家了解，也是旨在带领大家从反面来考虑事情，希望能够给大家一些思考和帮助。

2 运维简介

先整体了解运维，然后在摊开来了解更细节的内容。

2.1 什么是运维

运维简单讲，就是当系统出问题的时候，尽快介入去解决，保障系统正常运行。

详细来讲，运维主要做以下三类事情：

1）出现问题，快速介入去解决；

2）制定工具，自动探测和处理；

3）制定策略，尽可能地发生问题。

以上也是符合人类解决问题的思路的。大家遇到问题，刚开始是遇到一次，解决一次；当出现多了，就想能不能问题出现了，自动解决；当然，解决问题最好的方式是，就是让问题不再发生。运维也是如此。

2.2 为什么需要运维

首先，自适应能力（Self-adaptive ability）：

判断输入的特征，根据特征自动调用相应的处理方法，以此得到最佳效果。

其次，系统是人设计处理的，但人不是神，设计不出来完美无缺的系统，所以系统的自适应能力是有限度的。当输入的特征不在预先设定好的范围以外，系统就不知道如何处理，有可能出现异常。这个时候，就需要人为介入解决和恢复。所以，运维应运而生。

2.3 运维的类别

从底层到上层，运维可以这么分类：

1）基础运维：管理维护计算机设备、网络等等；

2）业务运维：和业务相关，比如网购系统，就有人员处理网购的各环节额问题，比如登陆失败，支付失败等等；

3）管理运维：各行各业都有规章制度，运维也是一样。管理运维就是制定规章制度；

4）信息安全管理：维护人员的权限很高，换言之，什么数据都能看的。所以如何保障数据不被泄露，在当今也是一个比较重要的维护类别。

3 做运维的原理

技术，归根结底来讲，其实是思想的实现。运维里的技术，有以下几个。

3.1 冗余

概念：系统构成要素配置成多个。

简单来讲，冗余就是实施前准备多种方案，这样当出现一种方案无法实施的时候，采用备用的其他方案，来保证实施能够完成。

做冗余是有成本代价的，合理的冗余方案，即既有备份的方案，又有可承受的成本代价，业界一般采用N+1或者N+2.

3.2 健康度检查

健康度检查是时刻检查系统是否正常，这样可以当系统出现问题时，运维人员能够快速接到通知和介入处理。

3.2.1 基础资源检查

基础资源就是指：你使用的但是不属于自己的对象。

基础资源检查包括：

1）网络的检查，一些探测的指令：ping、telnet、traceroute（tracert）

2）计算机设备：内存、CPU、磁盘等

3）外部服务：比如做购物网站，付钱的时候，交付时采用银行的交付系统来进行转账支付的。

外部服务延伸：如果可能，尽可能把外部资源的依赖，转换为内部资源。这样来降低外资源的不可控性。

3.2.2 服务监控

不仅需要监控资源，还需要监控自身服务的正常与否：

1）服务存活：服务在不在；

2）响应是否正常：服务在，但是否正常干活，需要发请求去验证。

3.2.3 流量监控

系统处理的能力是有上限的，如何避免系统被撑死：

1）被动的方法：设定上限，超过则拒绝响应（不友好）；

2）主动的方法：延缓分散请求的频率，即降低请求同时发生的次数。

3.3 数据一致性

数据的传播是需要时间的。当一方数据发生变化还没有及时通知相关方时，假如此时用户访问相关方的数据，其实访问的是已经“过期”的数据，这时候出现数据的不一致性。

数据时刻保证一致性是很难的，当前业界更多地保证数据的最终一致性。也就是说，经过一段必要的时间后，用户看到的数据是一致的。

当出现数据无法保证最终一致性的时候，就需要进行数据的补偿，来减少用户的损失。

综合3.1、3.2、3.3，可见运维的演化就是在2.1中描述的过程。刚开始人为介入去切换（备份方案替代原有方案）；然后用健康度检查来定时监控系统，出现问题呢，能够发现，然后采用预先定义好的预案进行处理；再次，设计出让问题不再发生的方法（比如流量监控中的延缓分散请求频率）；最终多一点的是，如果出错，系统需要进行补偿。

4 做运维的风格

运维也有自己一套的做事风格，来提高办事的效率。

4.1 试与做

前期大胆地试，因为这个时候，即使错了，因为不是正式，都是可以接受的。但正式的情况，就需要根据预先指定的方案，小心行事。

4.2 经验与怀疑

经验在运维中，能够快速给予思路；但有时候经验有可能带你误入歧途。所以在走每一步的时候，都要问自己要做什么、经验得到的结果是什么、两者是否相匹配。

4.3 积累

运维复盘更多的是针对问题，特别是重复的问题。复盘以下方面：

1）记录问题：描述发生问题的场景；

2）记录步骤：把处理问题的时间和做的步骤详细记录；

3）原因：记录做2）中每一步的原因

4）总结：将2）和3）中做的正确的（good）列出来；不好的（bad）列出来。并想如何改进不好的方面。

4.4 沟通

1）重要不紧急：先发邮件（好处是自己过一遍脑子，提高和别人沟通的效率）；

2）紧急：面对面沟通（高效，没有条件，只能电话会议）；

3）尽可能拒绝电话：

①电话对方可能在忙别的事情，打断别人，别人不可能立即切换到你这边。

②电话影响周围的同事。

4）寻求帮助，从别人的角度出发

①尽可能做到自己能做的；

②发现下一步无法进行，则找对应的同事请求帮助；

③别人接手不代表你可以撒手，要参与进去，帮忙协调资源。

5 做运维的感悟

沉浸工作，总会有些感悟。

5.1 时间安排

时间安排可根据自己的时间进行调整，可以参考：

1）时间比较可支配：平均7件，5~9件波动；

2）时间经常被打断：必做3件，选做2-4件

5.2 分享

分享带来的好处：

1）分享的准备就像备课，准备的过程就是提升的过程；

2）讲出来是证明与否的最佳方式之一；

3）提高知名度：提高知名度可以带来更多机会去参与这个领域，你也因此变得越来越专业。

5.3 加班

写代码、上线、赶进度，加班就是这么来的。

5.4 家庭

工作后，平衡生活和工作是必要的。但当出现需要牺牲一方的时候，希望你的选择不是家庭。

Family always comes first.

6 推荐

1）黑客与画家：较浅显介绍计算机；如果对技术没有兴趣，可以忽略技术，里面还是很多工作中的道理。

2）思考，快与慢：想要了解自己大脑的工作原理，此书可以看下。

3）一个人的朝圣：暖心的鸡汤书

4）WPS的论坛：很多PPT模板，包括本次的PPT，可以参考。

7 问题

1）Q:运维包括哪些？

A:我的理解是第一章里的分类，也就是从基础底层到业务上层，术业有专攻，是最佳的方式。

2）Q:运维是如何准备突发预案的？

A:原则是快速处理和影响面尽量小。

分两种：

·假如问题是你自己系统能搞定的，那无非是如果它能自动恢复，就设定脚本自动触发恢复（比如自动重启）；如果无法恢复，则依赖重要性：如果不重要，就隔离出去，不影响核心服务，其他时间再处理；否则，最不济的就是需要通知运维人员去手工处理了。

·如果是有外部服务的，那需要两个产品线一起讨论应急的预案，比如我出现问题，你怎么办；反之亦然。当然，如果你是他的下游，一定要要求他的报警能够通知到你，否则出了问题，一是你不知道系统异常了，客户反过来通知你，你就囧了；另外一步步排查，也非常耗费时间。

当准备好应急预案，一定要做相关应急的演练，不然真出问题，再找文档处理，黄花菜都凉了。

3）Q:运维的思维是怎么样的？对后端开发有什么意见？

A:运维的目的是保障系统的安全运行，所以有时候开发赶进度只写功能，我们是很被动的。这个时候，经常我们陷入进度和安全的两难情况。这也需要开发、运维相互理解。开发如果想到非常全面，测试非常充分，那运维是很喜欢和你合作的，省心。

此外，运维想问题，相比开发会更全面些，我了解到，开发更可能注意功能开发，但运维会把出现的问题列出来，然后帮助开发将系统开发的更完善。

4）Q:状态监控具体的内容？
A:因为要关注服务的状态，我建议可以从这几方面监控：

①服务存活需要监控：进程的监控进程、线程的监控线程

②服务是否正常需要监控：后台服务响应请求的时间、一段时间内请求成功率；

③服务使用的资源需要监控：数据库连接数、CPU、内存等等，理应用到的资源就需要监控

④数据监控：TPS、ART，也会为总结汇报做准备

5）Q:运维的日常工作

A:我按重要性排列下：

①如果系统出问题，恢复问题肯定是第一位的；

②支持开发的投产任务，包括资源申请、上线准备等等；

③做一些监控方案和应急的脚本；

④参与需求讨论，完善开发设计方案和提供解决问题的思路；

⑤做一些统计报表和汇报

8 复盘

本次准备到分享，历经3个月，复盘如下：

1）刚开始在五月的时候，我其实想讲，如何做好一个信息系统的维护的：但我意识到有可能太专业了，非技术的同学会被我讲晕的。为了让更多人听懂，我讲思路调整到讲讲运维里发生的一些事情。事实也证明，场景式的分享会带给大家更多思考，大家也会参与进来。分享完，很多同学提问题，这点，自己很开心。

2）在准备PPT过程中，使用了一个模板，认为好的PPT页面，也会吸引大家的积极性。

3）试讲过程其实工作量蛮大的，也非常感谢各位试听的同学。问题是我主要脑补的很丰富，但一讲的时候，就乱七八糟。后来还是在周末的时候充分组织了下语言，也列了下提纲，包括题目、各页之间的衔接。如果你真的没有语言天赋，写下来确实是最好的方式。

4）本次分享，我做了大量的准备。光想我就用了5月一整月。再次感受到：只有你认真付出，肯定会得到收获。

5）最后，说下自己对行业论坛的感受：当我刚开始想讲运维的时候，其实也感觉说讲不出来什么。就和你面试一样，别人问你特长是什么，可能说不出来。所以我觉得行业论坛真的是一个契机，一个发现自己闪光点的机会。所以，最后由衷希望更多的朋友能够参与进来。

这次分享收到很多朋友的建议和帮助，由衷的感谢讲讲讲群的各位试听的朋友，感谢S君，感谢Hemon。

历届行业论坛分享：

L09：面试技巧与解析

ScalersTalk ID:scalerstalk

本文作者Scalers，游走在口译世界的IT从业者。微信公众号ScalersTalk，网站ScalersTalk.com

ScalersTalk成长会回复“VIP”查看.口译100小时训练计划群C 456036104