运维程序员如何快速处理线上问题？

对于大多数运维程序员来说，时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。今天我们就通过案例分析来了解一下，运维程序员如何快速处理线上问题。

任何一旦掉进坑里，明智的做法一定是：跳坑_>填坑_>避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：

跳坑

‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到低。

线上服务的可用性决定着服务者的客户利益，影响着公司的收益。一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。为此，遇到生产故障后的一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到低。

填坑

‘填坑’——找到问题原因，根本上解决问题。

在恢复线上服务，尽大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填侍吵坑’也就意味中乎拿‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。

避坑

‘避坑’——举一反三，消灭隐患。

找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点?那些流程/规范/制度需要优化?这类问题是否在其他系统或者团队中也存在?通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。

线上故障处理的思路

依据线上故障处理的目标及目标的优先级，线上排障的一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。因此，可以将线上故障处理的步骤分为：

故障发现

故障定位

故障排除

故障回溯

其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。

上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障岁谈搭，恢复服务。这个思路类似于 *** 作系统的fork/join设计思想，目的在于提高效率。

在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到低且可控。霍营北大青鸟建议可以等到线上服务’撑’过去之后，我们再慢慢定位故障原因，根本上解决问题。

优秀码农，干活，凶猛的干活；优秀程序员，发现问题，解决问题。滑散

仅此而已。

好的程序员的基本要求（我认为）：

1. 学好数学：高等数学，线性代数，离散数学，算法，图论（可选），数值方法（可选），优化方法（可选），计算理论（可选）；

2. 打好基础： *** 作系统，编译原理，汇编语言，数据库原理，计算机网络，密码学，人工智能；

3. 多动手：至少用面向对象语言（C++/Java）写5万行；脚本语言（Perl，Ruby）写5千行；至少在工作中正确实践5种设计模式；维护过10万行代码的系统；参与过一次大项目的重构（或设计）；

4. 多交流： 至少做过3个新人的mentor；参与需求分析和项目计划的制定；独立领导过项目的开发进度；能建立在团队里的威信（人品和技术两方面）；

1和2是一个人在学生时代该干的，本科四年足够了；工作后干3和4，一般2年也能有所心得，最好能理论联系实际，做到融会贯通举一反三。而且要放下“唯代码独尊”的优越感，能正确定义开发的目标，并不断提醒自己这个目标。到此为止，优秀的程序员应该可以出炉了。

有些人可能不同意我的定义，但我认为，优秀的程序员不只是能写多好的代码，而是能独立解决问题（理论加经验），带领团队一起最大限度的实现需求（沟通能力）。代码只是其中的冰山一角啊。在实践中，“高效又优美”并不一定是好程序员，因为程序员的一个通病就是追求“代码完美”，耽误工期是常有的事，项目经理往往也没办法。优秀程序员则能正确做出取舍，做出“deliverable”的产品。优先的干的漂亮，不优先的不钻牛角尖。毕竟人的精力圆让敏是有限的，在有限的时间里，做出最好的产品橘枝，还是很有讲究的。更进一步，好的程序员还要能防微杜渐，通过有效的沟通，了解团队的走向，并在必要的时候提醒团队，甚至挺身“填坑”。

PS. 当然，我不是否认代码的重要性，代码能力很重要。但再优美的代码，如果不能“deliverable”，那它又有什么意义？公司给你一个项目，让你找一百万个文件中的重复文件，你可以用一个开发周期来做一个超完美的hash function，效率高，碰撞率低...但你这函数不是“deliverable”的，因为他还不能“找一百万个文件中的重复文件”。这样的程序员真的优秀么？我认为不是，因为他不分主次。

---