运维平时工作到底是需要小心一些，还是要大胆主动一些？

[zhoudaiyu]

之前我是比较主动的，针对于已经发生的问题，甚至是隐患，都会主动想办法解决，避免更大的故障。但是最近由于生产迁移 kafka 时，对 kafka 的客户端基础包不了解，以及对业务方使用上不了解（虽然已经对操作进行了评估），导致了 2 次故障。事后想其实不迁移也不是不行，并没有非常明显的证据表明非迁移不可（唯一风险可能就是集群的每台机器 CPU 使用率都在 90%以上）。这两次故障对我的技术上和对于运维的认识有一些冲击，我不再想主动解决问题了，而是更倾向于生产系统能不动就千万别动，真的迫不得已或者故障已经发生再去处理吧。因为系统确实越来越复杂，个人、甚至叫上了各方负责人也不一定能评估出风险，还不如先不动。

[Tumblr]

该小心的时候要小心，该大胆的时候要大胆。
对于一些可能明显影响到业务的变更，组内讨论之后让领导拍板。

[brom111]

说句实话 问题你可以提，但是解决不一定非要解决。把风险说好，让你们总监他们去评估呗。

[alexsz]

能不动就不动----少走 10 年弯路 😁

[gxy2825]

猜测 OP 不是在比较大型的公司，我司也类似这思路，运维不太会去主动推进一些中间件、架构上的改变或者升级，基本都是开发侧评估确实快到非升不可的时候由开发去推进，运维只是配合

[gxy2825]

@gxy2825 个人偏激一点的看法是运维属于做了很多事不容易让人看到功劳，一旦出错了就会被各方指责（当然开发也类似）

[Bateman]

从犯错中学习，有些领导听不得这句话。。。

[yfixx]

在大胆中小心，在小心中更小心

[8355]

其实是你没参透这个问题的玄机，我来讲解一下。
机器负载高，你作为运维是有责任监控到这个信息的，
作为事件发起者你做的没错，但错在当了决策者，
只需要把这个事情汇报给上级或着对应业务负责人进行优化排查即可（很有可能优化下代码或着消费逻辑就好了），问他们要不要扩容或着迁移，决定权在他们而不是你，你只是配合实施工作。
如果需要迁移则需要他们对相关业务代码进行梳理形成文档（包括你需要如何迁移过程中需要操作的相关事项进行详细罗列），这样大家一起开会评估迁移成本/风险和操作是否合理是否有遗漏，是否可接受。
之后按照梳理好的文档在会议期间约定的时间对该迁移进行实施，同时在之前会议讨论中需要考虑到迁移失败以及各种异常情况做预案。

后面在实施前拉好群，约好时间，确定好责任对接人，开干，谁掉链子都可以写到复盘文档里。
方案有问题大家一起开会决定的，都有责任，甩锅是甩不了的，这样大家才会认真对待当个事儿来做。

以上形成的所有文档和会议记录以及拉群的聊天记录，看似效率很低，实际是多次提醒相关负责人当个事儿来办，别回复一下 ok 就当没事人了。

这一套方案下来可以降低 99%的失败率，1%就是所有人都没考虑到的情况，能力不行再修炼，大锅一起背，谁也跑不了，不用互相指责甩锅。

互联网大厂就是这种解决问题的方式，甚至可能比我说的更复杂，还要拉上架构以及各种相关负责人一起评估。
把压力传递出去，只有大家站在你这一队问题才好解决。

[asdgsdg98]

做的好是你应该的，做不好是你不行
越做越错，不做不错，给老板赚钱的部门主动点，做运维和后勤的还是悠着点吧

[BNineCoding]

小心主动一些。

[qsnow6]

计算机领域名言：不坏就别修它。

[whp1473]

为啥要动呢，又不会因为动了给你加薪水 给奖金

[rightR]

扁鹊见蔡桓公的故事告诉我们，没出问题的话别去动。

[nrtEBH]

遇到故障不可怕 不要第二次遇到就好了 每次故障都是经验 每次故障都是发 blog 的机会呀

[bt7vip]

运维典型的不出事看你是没事干，出了事感觉运维岗也没啥用，该出事还是出事。运维岗重在积极参与刷露脸，落到实际还是那句话，能跑就不要动。

[weiiai]

刚好最近也遇到了迁移 kafka ，有云平台的迁移能力，直接页面点击操作，本来想直接在业务运行的情况下替换节点，犹豫很久还是和主管报备后通知研发从业务的角度去迁移。

[silentsky]

@8355 说的挺好的 运维有想法是好的 拉上开发一起讨论解决 别一个人扛

[hawhaw]

摆正自己的位置

[guoooo00oohao]

基础设施最重要的就是稳定

[zhangyoucaiyo]

上班三年的系统运维，最大的感触就是，多做多错，少做少错，不做不错

[zhoudaiyu]

@Tumblr
@brom111
@8355
@whp1473
@hawhaw 我是提了建议，但是领导让我牵头，但是出了问题领导躲在后面不承担，锅扣我头上了，我也只是不想发展到集群真的问题了，那样过于被动

[8355]

@zhoudaiyu 如果你领导是这种人的话，以后说话记得留证据，文本聊 不要线下聊了。

[zhlxsh]

年轻大胆一点，不气盛叫什么年轻人。等年纪大了，碰到坑多了自己就学会小心了。

[uncat]

在虚拟化构建虚拟的集群
ansible/saltstack 写代码
code review/虚拟集群内走一遍
基本上后面也不会有太大的风险

[defunct9]

这个跟个人性格有关。我是绝对主动，看着不顺眼就改掉。但是前提是你要能 hold 住整个过程中的意外。
为了取回一个最高权限等了 3 个月才动手。

[GT1]

最近看到一句玩笑话，灰电平衡

[Firxiao]

“不做不错” 这种想法任何行业都是一样的 说白了就是懒政
年轻的时候不要老想着这个锅是谁背了
敢做敢当 让你牵头 你就得付出该有的责任 无论领导好坏，先从自己身上找问题，是不是评估不到位？测试环境测试了吗？ 哪里疏忽了？
换个角度 现在利用率已经百分之 90 了 难道等出问题了 你再和领导解释 没发现这个问题？ 到时候是不是更被动？
做运维不要害怕出错 而是出错之后 想办法找原因 积累各种故障/潜在问题的处理经验
流程文档什么的就不赘述了
愿你一觉醒来仍是少年

[NewYear]

不破不立……

[julyclyde]

情绪，是一个和技术水平同等重要的要素

你如果还想长期干下去的话，那各种隐患的解决工作早晚还是你的，躲也躲不掉
可以从长计议，短期内不要给未来挖坑，甚至可以推进逐步演进的改善；长期要提前培养好自己的技术水平、寻找合适的做大规模变更的时机

[franktopplus]

敬畏墨菲定律，所有的大故障都是小隐患积累的

[bclerdx]

@Bateman 人非圣贤孰能无过？

[luhuisicnu]

有隐患可以提风险，让领导决定是否整改。
多做演练，步骤做仔细，大家一起评估。
这一套搞下来耗时不少，但是应该能解决问题。如果 kpi 与此无关，建议不要管。

[Felz33]

我最近正好也要迁移 Kafka ，有什么坑可以分享一下吗？

[pepesii]

能不动就不动

[kindlingx]

@zhoudaiyu 最近团队在做相关的工具，楼主的问题基本就是我们特别想要解决的一类问题之一，还有就是想试试不知道除了 AIOps 之外，是不是有可行的路能够帮助运维、开发，不至于天天被动还加班。楼主有兴趣的话不知能否简单聊聊？想了解了解平时工作中的一些困境。