Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

手滑的故事

Posted on 06/10/201506/23/2019 by 四火

slippery

最近看到这篇文章 《小伙伴们手滑集》,觉得感慨很多,强烈推荐大家阅读。比如这样的例子:

UPDATE 没有 WHERE 条件

而我则经历过 delete 没有写 where 条件的惨剧,这个惨剧是某些 case 下面代码调用触发的,不是手动执行 SQL 发生的。

还有臭名昭著的,我没有经历过,但是我有不止一个同事干过这样的事情:

rm -rf

都只是手稍稍地温柔地 “滑了一下” 而已嘛……

这些事情我觉得一下子很亲切,似乎全世界的软件工程师都是如此得同一。

出的事故多了以后,变得战战兢兢,如履薄冰,尤其是回车键这样的敲击,似乎总是带着颤抖落指。

还有这篇文章 《让自家系统瘫痪,这事我也干过》,讲了一个关于使用 truncate 语句清空数据库数据的故事。及时报告老大,但是领导给了这样一个反馈:

赶紧恢复数据,最迟明天早上必须要解决,不要让用户感觉到。

其实这样的话是非常给程序员压力的,我可以想象当时那种场景。线上数据丢失是如何惊心动魄。

作者给了这位老大一个很高的评价,但是我不这么认为。这件事情最终大事化小、小事化了的做法是很不错的,但是给出时间点压力这样的事情其实对当时火烧眉毛的情况解决并没有帮助。

 

谁都会有手滑的时候,我最大的感受是,在 “线上系统维护” 这样的事情上,“人” 远没有 “机器” 可靠。

造成的恶劣后果多半为 “服务停止” 或者 “数据丢失” 两种,尤其是后者,有时难以挽回,损失惨重。

我经历过的 “手滑” 惨剧也有一些,当然没有那么恐怖。

  • 比如在杀 Hadoop job 的时候,有一个重要的线上 job 还在跑,被我杀掉了,当时吓了一跳,赶紧找熟悉这些 job 的 oncall 来看,还好这个 job 是幂等的,重跑就行了。如果运气不好,干掉一些特殊的 job,结果或许就糟糕了。前年年底就有一个组内 job 的问题因为维护的工程师的操作触发了 sev 1(最高级别)的线上问题。
  • 再比如我曾经有过 “手滑” 把一个造成服务不可访问的问题留到版本中发布出去了,结果测试同学们也没法发现该问题,最后导致线上服务无法使用,被迫连夜赶补丁打上去。
  • 再再比如有不止一次,想把线上 log 之类的文件给删掉,但是手滑,删错了目录,把一些线上重要数据或者服务文件夹给干掉了……

看那些 manager 们,还有公司们对工程师们操作线上数据和服务手滑以后的严重后果,基本上有这样几种反应,后三种我都见过,第一种有同事经历过:

  1. 当即批评,事后追责。这时最差的公司和领导。
  2. 对外道歉平息风波,对内查清问题追究操作人员责任,绩效差评。这是中庸的公司和领导。
  3. 对外冷处理,对内以鼓励为主,但是评估问题根因和改进。这种做法就好得多了。
  4. 内外一致,详细分析问题,包括连续问几个 why,问题责任主体只定位到团队,不追究个人。这个做法也不错。

我想对于这样的问题,有一个原则就是,我相信责任主体工程师早就懊悔万分了,再责怪他,对解决问题只能起到反面的效果。

 

没有手滑的人生,是不完整的。

没有手滑经历的程序员,是不成熟的。

 

我相信关于这样的问题发生之后的后续改进,不同人会有不同的看法,我先说一说那些最不靠谱的办法:

  • 公开批评和个人责任落实。事实上绝大多数情况下,犯错的同学已经心有余悸,良心惴惴不安了。更大的批评砸头上只能带来消极的结果。最消极的结果就是减少工作产出,正所谓,“不做不错”,不让我犯错,我不干活就是了。
  • 把问题的检查写到文档,比如 checklist 里面去,等到类似场景的时候拿着 checklist 排查。这也是一种比较不好的做法,也许会好过什么都不做,但是:(1)这样的问题要确保足够的可重复性,否则只会导致这个 checklist 越来越复杂,直到最后根本无法实行;(2)这始终是个笨办法,工程师被条条框框牵着鼻子走只会让工作氛围和积极性越来越差。
  • 强化 “人” 的管理和监督流程,这也是一个好不到哪去的办法,比如对线上操作需要得到领导审批,最大的问题在于这会大大降低效率,降低工作热情。而这样的效率降低,很多职位高的人却看不到。

反过来,也有好的实践,大多数实践都能够做到,规避了问题,并且在 “不知不觉”,或者是没有明显代价的情况下实现的。

比如说,Linux 下,建立和使用不同权限用户的习惯,可以很大程度上避免手滑删文件悲剧的发生。

当然,这在有些情况下只是理想状态,多数团队都要做好足够充分的备份和容错,毕竟手滑难以避免,来势凶猛,如何脱身和保全数据并不容易。

 

今天的行文风格有点奇怪,啰嗦倒是依旧,只是文字如此稀疏。

最后,我想说,我写这些文字的初衷,仅仅是发发感慨,这样的事情看起来如此之亲切。

尤其是意识到手滑的那一刻,身后那凉飕飕的感觉,肌肉抽搐,浑身颤抖,如鬼抚背,难以忘记……

呃,还是说多了。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 谈谈 Ops(二):流程和人
  2. 扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了?”
  3. 时间投入上的权衡
  4. 不安分的工程师
  5. 西雅图第一周

4 thoughts on “手滑的故事”

  1. hax says:
    07/20/2016 at 9:30 PM

    update/delete 没有 where 是 sql 的设计缺陷。有些数据库系统设置成默认不允许没有 where 子句,才是正解。

    评论里的 if (…); 用 coding style 检查即可解决。

    其实大部分的手滑都是可以通过技术手段减少发生可能的。不过许多所谓管理者往往只会用非技术的蠢办法。

    Reply
  2. LULU says:
    08/02/2015 at 8:56 PM

    看了你的文,我乐死了。从你在 ITEYE“ 一些中文编程语言” 的文章跑过来的。

    Reply
  3. 麦田技术博客 says:
    06/19/2015 at 11:52 AM

    我手滑了一下 过来看看

    Reply
  4. Anonymous says:
    06/18/2015 at 2:06 PM

    以前手底下有个程序员 if  (…) { … … }   结果在 .) {中间写了个;   结果就成了 if  (…); { … … } 然后死活两天都不知道为啥 if 语句没效果

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme