谈谈 Ops(二):流程和人

第二部分,我想谈一谈流程,依然来源于我的理解。Ops 的实践上面,有两部分内容紧密结合,不但共同显示了 Ops 的生产力,也在相当程度上体现了 Ops 的技术水平。这第一部分就是流程,也是今天要说的内容,另一部分是工具(也包括和使用工具相关的技能),下一次再说。

我认为 Ops 可以分为几个层次,最次的的一层,其特点是重度依赖于的人的直接“操作”。风险管理、因果行为,都通过流程来统一把控,并且遗憾的是只有流程——除了它基本没有可靠有效的工具,或是其他办法。

其实,流程本是个好东西。有时候 某些工程师被散漫和自由主义惯坏了,听到流程就反感。事实上,流程在很多情况下都有着举足轻重的作用。它们很容易控制 [……] 阅读全文

谈谈 Ops(一):我的运维经历

偶然地,在会看这些年写的文章的时候,发现涉及到软件工程方方面面的内容,但是关于 Ops 的内容却非常少。我觉得这是不太合适的,因为在实际工作中,Ops 显而易见地占据了一大块比重。于是我调整了分类目录,增加了这个单独的分类,并且这一次,我想零零散散地讲一讲我关于 Ops 的一些经历,以及关于 Ops 的一些观点。

所谓 Ops,指的就是 Operations,在中文翻译上看,我觉得“运维”这个词可能是最恰当的。作为一个软件工程师,Ops 有时会特指 DevOps,关于它的定义,在维基百科上有这样一张图片,我觉得基本正确地描述了 DevOps 涵盖的内容(见右侧图)。

可以看到三方面的内容,可是,由于我们会把 [……] 阅读全文

手滑的故事

slippery

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

UPDATE 没有 WHERE 条件

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

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

rm -rf

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

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

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

还有这篇文章 《让自家系统瘫痪,这事我也干过》,讲了一个关于使用 tr

[……]阅读全文

解雇专业的运维人员吧

mt 在很多情况下,运维占到软件成本的大块,专业的运维人员更是不好找。这样的人需要熟悉操作系统、网络以及数据库。而运维又是一件很苦逼的事情,成了算是软件写得好,研发团队的功劳;败了就得彻夜坚守岗位提供支持,不可控的因素太多。是上游团队的软件质量太差吗?

我在 09 年的时候曾经到过局方,呆了挺长一段时间,既是开局,也做运维的工作,和运维的工程师朋友一起蹲机房、守夜、切设备,知道其中无比的苦楚。很多情况下,版本的更迭、割接,都要在凌晨完成,需要仔仔细细地测试;不幸失败了还需要立即回滚,然后陪着项目组等领导骂,等新版本或者补丁到来,再重复熬夜的这段过程……

不如大胆一些,解雇你那些抱怨不止、喋喋不休的运维

[……]阅读全文

back to top