这是一个创建于 302 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前我是比较主动的，针对于已经发生的问题，甚至是隐患，都会主动想办法解决，避免更大的故障。但是最近由于生产迁移 kafka 时，对 kafka 的客户端基础包不了解，以及对业务方使用上不了解（虽然已经对操作进行了评估），导致了 2 次故障。事后想其实不迁移也不是不行，并没有非常明显的证据表明非迁移不可（唯一风险可能就是集群的每台机器 CPU 使用率都在 90%以上）。这两次故障对我的技术上和对于运维的认识有一些冲击，我不再想主动解决问题了，而是更倾向于生产系统能不动就千万别动，真的迫不得已或者故障已经发生再去处理吧。因为系统确实越来越复杂，个人、甚至叫上了各方负责人也不一定能评估出风险，还不如先不动。
 |
1
Tumblr 302 天前
该小心的时候要小心，该大胆的时候要大胆。
对于一些可能明显影响到业务的变更，组内讨论之后让领导拍板。 |
 |
2
brom111 302 天前
说句实话 问题你可以提，但是解决不一定非要解决。把风险说好，让你们总监他们去评估呗。
|
 |
3
alexsz 302 天前
能不动就不动----少走 10 年弯路 😁
|
 |
4
gxy2825 302 天前
猜测 OP 不是在比较大型的公司，我司也类似这思路，运维不太会去主动推进一些中间件、架构上的改变或者升级，基本都是开发侧评估确实快到非升不可的时候由开发去推进，运维只是配合
|
 |
6
mcV473b9u4GfJG81 302 天前
从犯错中学习，有些领导听不得这句话。。。
|
 |
7
yfixx 302 天前 via Android
在大胆中小心，在小心中更小心
|
 |
8
8355 302 天前  10
其实是你没参透这个问题的玄机，我来讲解一下。
机器负载高，你作为运维是有责任监控到这个信息的， 作为事件发起者你做的没错，但错在当了决策者， 只需要把这个事情汇报给上级或着对应业务负责人进行优化排查即可（很有可能优化下代码或着消费逻辑就好了），问他们要不要扩容或着迁移，决定权在他们而不是你，你只是配合实施工作。 如果需要迁移则需要他们对相关业务代码进行梳理形成文档（包括你需要如何迁移过程中需要操作的相关事项进行详细罗列），这样大家一起开会评估迁移成本/风险和操作是否合理是否有遗漏，是否可接受。 之后按照梳理好的文档在会议期间约定的时间对该迁移进行实施，同时在之前会议讨论中需要考虑到迁移失败以及各种异常情况做预案。 后面在实施前拉好群，约好时间，确定好责任对接人，开干，谁掉链子都可以写到复盘文档里。 方案有问题大家一起开会决定的，都有责任，甩锅是甩不了的，这样大家才会认真对待当个事儿来做。 以上形成的所有文档和会议记录以及拉群的聊天记录，看似效率很低，实际是多次提醒相关负责人当个事儿来办，别回复一下 ok 就当没事人了。 这一套方案下来可以降低 99%的失败率，1%就是所有人都没考虑到的情况，能力不行再修炼，大锅一起背，谁也跑不了，不用互相指责甩锅。 互联网大厂就是这种解决问题的方式，甚至可能比我说的更复杂，还要拉上架构以及各种相关负责人一起评估。 把压力传递出去，只有大家站在你这一队问题才好解决。 |
 |
9
asdgsdg98 302 天前
做的好是你应该的，做不好是你不行
越做越错，不做不错，给老板赚钱的部门主动点，做运维和后勤的还是悠着点吧 |
 |
10
BNineCoding 302 天前
小心主动一些。
|
 |
11
qsnow6 302 天前 1
计算机领域名言：不坏就别修它。
|
 |
12
whp1473 302 天前
为啥要动呢，又不会因为动了给你加薪水 给奖金
|
 |
13
rightR 302 天前
扁鹊见蔡桓公的故事告诉我们，没出问题的话别去动。
|
 |
14
nrtEBH 301 天前
遇到故障不可怕 不要第二次遇到就好了 每次故障都是经验 每次故障都是发 blog 的机会呀
|
 |
15
bt7vip 301 天前 via Android
运维典型的不出事看你是没事干，出了事感觉运维岗也没啥用，该出事还是出事。运维岗重在积极参与刷露脸，落到实际还是那句话，能跑就不要动。
|
 |
16
weiiai 301 天前
刚好最近也遇到了迁移 kafka ，有云平台的迁移能力，直接页面点击操作，本来想直接在业务运行的情况下替换节点，犹豫很久还是和主管报备后通知研发从业务的角度去迁移。
|
 |
18
hawhaw 301 天前 via Android
摆正自己的位置
|
 |
19
guoooo00oohao 301 天前
基础设施最重要的就是稳定
|
 |
20
zhangyoucaiyo 301 天前
上班三年的系统运维，最大的感触就是，多做多错，少做少错，不做不错
|
 |
21
zhoudaiyu OP |
 |
23
zhlxsh 301 天前 via iPhone
年轻大胆一点，不气盛叫什么年轻人。等年纪大了，碰到坑多了自己就学会小心了。
|
 |
24
uncat 301 天前
在虚拟化构建虚拟的集群
ansible/saltstack 写代码 code review/虚拟集群内走一遍 基本上后面也不会有太大的风险 |
 |
25
defunct9 301 天前
这个跟个人性格有关。我是绝对主动，看着不顺眼就改掉。但是前提是你要能 hold 住整个过程中的意外。
为了取回一个最高权限等了 3 个月才动手。 |
 |
26
GT1 301 天前
最近看到一句玩笑话，灰电平衡
|
 |
27
Firxiao 300 天前 via iPhone
“不做不错” 这种想法任何行业都是一样的 说白了就是懒政
年轻的时候不要老想着这个锅是谁背了 敢做敢当 让你牵头 你就得付出该有的责任 无论领导好坏，先从自己身上找问题，是不是评估不到位？测试环境测试了吗？ 哪里疏忽了？ 换个角度 现在利用率已经百分之 90 了 难道等出问题了 你再和领导解释 没发现这个问题？ 到时候是不是更被动？ 做运维不要害怕出错 而是出错之后 想办法找原因 积累各种故障/潜在问题的处理经验 流程文档什么的就不赘述了 愿你一觉醒来仍是少年 |
 |
28
NewYear 300 天前
不破不立……
|
 |
29
julyclyde 299 天前
情绪，是一个和技术水平同等重要的要素
你如果还想长期干下去的话，那各种隐患的解决工作早晚还是你的，躲也躲不掉 可以从长计议，短期内不要给未来挖坑，甚至可以推进逐步演进的改善；长期要提前培养好自己的技术水平、寻找合适的做大规模变更的时机 |
 |
30
franktopplus 299 天前 via Android
敬畏墨菲定律，所有的大故障都是小隐患积累的
|
 |
32
luhuisicnu 298 天前
有隐患可以提风险，让领导决定是否整改。
多做演练，步骤做仔细，大家一起评估。 这一套搞下来耗时不少，但是应该能解决问题。如果 kpi 与此无关，建议不要管。 |
 |
33
Felz33 298 天前
我最近正好也要迁移 Kafka ，有什么坑可以分享一下吗？
|
 |
34
pepesii 298 天前
能不动就不动
|
Select Language