生产环境下由于应急运维操作导致的故障如何避免？

[zhoudaiyu]

有一些应急场景下需要执行一些平时运维自动化平台或者脚本难以覆盖到的运维命令，需要在服务器上现场敲命令执行，但是情急之下，难免因为粗心大意以及缺少交叉验证（因为人手不是很充足，有时候大家都各忙各的）引发了其他故障，扩大故障影响面。请问大家这种情况怎么能尽量避免呢？因为现阶段运维平台还是难以覆盖到全部场景，我想到的是一个人操作的时候，把要执行的最终命令发到群里让大家看一下，没问题就直接粘进去执行，还有执行前要有灰度操作，或者至少能模拟出执行命令前的大致情况，才能执行。不知道大家对这方面有啥好的想法或者一些实践能指点一下。

[fuzzsh]

处理故障谁还有空看群。。

[MuscleOf2016]

小范围修改验证灰度

[perfectlife]

这时候就凸显运维的经验和水平了

[darkengine]

预算足的话准备一台一模一样的备机，需要现场敲命令的现在备机上运行一遍，没问题再复制粘贴到生产服务器上执行

[GopherDaily]

故障处理是很考验人的，不要寄希望有人能给你 review ，我个人觉得核心的几点：
- 胆大，其实这个是前提，遇到大问题，脑子直接宕机的人是不适合的
- 心细，在得出判断后，再想：如果是 xxx ，那么 yyy ，尽量再去找 yyy 的证据，然后采信 xxx
- 日常积累

[8zip]

核心是避免应急场景
紧急情况翻车才是常见的

[opengps]

既然已经是在线开发，那么要做的恐怕也就是多备份了。
联机开发错误必然直接影响线上，多个人看一遍比你单独找人测试一遍效率质量都要更低

[idblife]

这是真正考验个人水平的时候

[echo1937]

1 、危险操作先报告，批准后再操作；
2 、解决方案测试环境上先测过，再上生产环境执行；
3 、现场执行 2 人作业，一人作业一人监护（参考电力作业）

[coolloves]

我们有紧急情况的时候,都是一人工作 n 人围观.

[killva4624]

找那么几个关键的人一起帮你 review 命令；
另外一个个人经验是，涉及到文件覆盖类的话，尽可能保持回滚能力，不能一把梭之后无法回头。
比如要手改代码或者覆盖二进制文件、配置文件，先 cp 一个备份；