运维与个人英雄主义

什么是个人英雄主义？

根据互动百科，个人英雄主义有以下释义：

不突出依靠人民群众的力量，而强调个人力量而去完成某种社会任务的英雄主义思想和行为。与“革命英雄主义”相对。它以个人主义为原则，强调个人在社会生活和历史活动中的作用，将“人民群众的力量和智慧”置于次要地位。

以上释义是一个适用于所有行业的解释，那么对应到运维领域，个人英雄主义该怎么定义呢？我的理解是下面这样的：

依靠个人力量去维护一个有问题的系统，使外界看来一切都很正常，这个过程中会涉及牺牲个人利益。

这里我们需要对系统进行一下定义，系统可以是以下任何一个或者他们的组合：服务、团队、流程、软件

个人英雄主义在运维中的表现

前面对系统进行了定义，在运维的过程中一般会给系统定义SLA，或者一些其他可以描述系统正常运转的指标。

但是现实中的系统往往达不到预定的SLA或指标，这时候英雄出现了，他或她会尽全力试图使系统达到预定SLA或指标。

通常英雄会通过以下努力来力挽狂澜：

• 每天工作到很晚
• 占用自己的周末时间

具体实例

工单队列

英雄的团队负责一个工单系统，对外承诺的SLA是24小时处理，每周由不同的团队成员轮班。

由于业务系统的高速发展，每天都有很多新的工单进来，在8个小时之内根本处理不过来，我们的英雄会工作到很晚去处理，每天的工作时间从8小时发展到10小时、12小时、16小时，以确保可以达到承诺的SLA。

服务SLA

英雄的团队负责一个生产服务，该服务设定的SLA是可用性4个9。但是由于该服务的软件架构设计、发布流程、监控设置等问题，该服务达不到4个9。

我们的英雄会每天巡视服务的监控系统，人肉定位异常、回滚有问题的发布、提前发现资源预警、重启有问题的程序等等，以确保可以达到承诺的SLA。

个人英雄主义好不好

回答这个问题需要看站在什么样的立场来看待好不好。

1. 从公司角度

   短期内对公司是有利的，系统正常运转没有出现故障；长期来看对公司是不利的：因为更深层次的系统问题被掩盖，当系统高速发展时问题会暴露出来。迟早英雄的个人精力会被耗尽，离职或者转组之后问题暴露出来。

2. 从团队其他人角度

   短期内团队其他成员有更多时间投入到项目中，而不被琐事打扰，因为不少琐事已经被英雄处理了；团队会被表面现象迷惑，认为当前运维的系统运转良好，从而不会投入人力去改进，但是问题会随着系统发展和英雄的离开暴露出来，那时候解决会花费更多的时间和精力，损失也比之前修复问题要更严重。

   英雄的工作方式会潜移默化的影响其他人，影响团队成员判断什么才是更有价值和长远影响的工作，也会影响团队成员对所维护系统的期望（什么样的系统才是一个正常运转的系统）。新成员可能会理所当然的认为，系统就是这样工作的。

3. 从英雄个人角度

   除了所谓的个人成就感，英雄本人是没有什么好处的。你也许会争论说系统缺了英雄就没法运转了，英雄应该获得升值和奖励。但是问题是，别人并不知道英雄所做的这些努力，而且往往这些努力是短暂的重复性的，并不能解决根本问题，仅仅停留在靠一个人的时间精力可以维持的程度，在技术驱动的公司这样的工作并不能使英雄升职加薪。

   更可怕的是，随着时间的推移，系统变得更加庞大和复杂，英雄个人无法修复所有问题时，不仅会花费更多的时间而且会打击英雄的自信心、降低工作效率和创造力，最终导致英雄的离职和转组。

4. 从系统角度

   由于英雄的积极努力，看似系统是运转良好，但是深层次的系统性问题被掩盖了。英雄变成了系统正常运行的单点，但是其他人并不知道；系统的问题不能被暴露出来，从而没有任何改进，在系统复杂性变大时，问题会以更严重的方式暴露出来，后期的改造往往意味着更高的成本。

如何避免个人英雄主义？

在遇到突发问题时，个人英雄主义对暂时度过难关是有帮助的。但是长远来看则应该建立正确的期望，团队运维的系统不应该依赖任何英雄就能做到正常运转。

为什么会发生？

前面讲了那么多的不好，那为什么还会发生呢？原因主要有以下几点：

1. 短期修复很容易实现，你知道可以完成。（尤其是受冒名顶替综合征影响）
2. 修复往往立竿见影，带来的成就感。（治标不治本）
3. 自认为所做的工作非常重要。（其实缺乏全局观念）

如何避免？

如何在运维中避免个人英雄主义，首先需要团队经理或者技术领导能够意识到这个问题，理解这种思想、行为对个人/团队/系统所带来的巨大负面影响，然后采取行动

1. 思想传达

定期、及时的传达个人英雄主义带来的问题，让团队成员清晰的认识到没有必要忍辱负重的维护不合理的SLA或指标；鼓励团队成员分享所遇到的问题；鼓励团队成员及时向上级反馈问题。

2. 工作安排

根据团队成员反馈的问题，合理制定工作，对系统进行改进，使之不依赖于任何单点就可以达到预期的运行状态。团队成员把时间花在可以对系统产生长远收益的项目上。

这是个很高的要求，因为并不是所有人都能看到一个项目对系统能带来的长期收益，抑或是有些人只关心功能的快速上线，这时候运维经理需要顶住迫切上线的压力，合理安排团队成员的时间，以短期被动换取长期的主动。

3. 合理预期

如果系统的SLA或者指标没法达到，承认这个事实，然后对系统进行改进。

这会使系统短时间内达不到SLA，但是通过投入精力改进系统，修复真正的底层问题，系统会最终恢复而且是恢复到一个长期稳定不需要人额外关注就可以达到SLA的状态。

4. 消除单点

团队负责运维的系统很多时，难免会产生不同团队成员负责不同组件的情况，这时即便没人想成为那个英雄也难免被成为那个英雄。

这时每个组件的负责人，就需要尽力消除自己这个单点：

• 文档记录组件的架构和功能
• 提供工具自动化处理尽量多的场景
• 为手工流程提供检查清单
• 知识分享
• 人员互备

结束语

个人英雄主义会使人联想到运维团队就好比救火队员的形象，英雄总是能及时扑灭大火，但是也随时忙于扑灭大火，却没有时间把起火的原因彻底解决从而不用忙着扑火了。

减少运维中的个人英雄主义，其实就是降低甚至消除系统对人的依赖，自治程度越高的系统才可能达到更高的SLA，更快速的发布等等。

对于领导来说，要把运维工作搞好，就要发现和消除系统对个人英雄主义的依赖。对于个人来说，要把运维工作做好，就要有不充当个人英雄的意识。

把下面一句话送给做运维的朋友：

Don’t sacrifice your social life for professional life and later regret it.

作者：吕宏利
来自微信公众号“云中慢步（cloudify）”：在硅谷原创分享分布式系统、数据中心生产环境、云计算前沿的实践经验和剖析研究

本文链接：https://www.yunweipai.com/10993.html