谈谈 Ops(最终篇):工具和实践

除了主要内容——工具和实践,这篇文章也对“谈谈 Ops”系列做一个汇总,提供一个访问入口。之前几篇,从一个纯粹 dev 狭窄的视角,谈了谈自己对 Ops 的一些认识:

在往下继续以前,如果没有看过前面的文字,不妨移步阅读,因为上面的内容对下面的内容做了一定程度的铺垫。

现在在写的这一篇文字,我准备是最后一篇,主要谈论这样几个事情:一个是工具,另一个是实践。我依然还是从 dev 的视角,而不是从一个专业运维的视角来记叙。

工欲善其事,必先利其器。我在主要且通用的工具 [……] 阅读全文

谈谈 Ops(三):事务、团队和时间分配

作为普通的开发人员,我们会遇到对于时间分配的思考,没有金标准,只有某些看起来也未必靠谱的“最佳实践”。不同人眼中对于整体的时间分配也有自己的看法,这篇文章旨在探讨其中的一两种情况。

Ops 的事务类型

Ops 的事务很多很杂,首先要明确一点的就是,Ops 远不止 oncall,远不止线上产品维护。整个软件工程流程中的配置、部署、环境搭建、升级、打补丁,甚至问题定位、故障排查等等,都或多或少可以算作 Ops

记得在读书的时候,老师给我们把日常事务划为四个象限:紧急重要、紧急不重要、不重要但紧急,以及不重要不紧急。Ops 和一般软件开发活动在这四个象限的分布上来比较,更多地,会偏重于“紧急 [……] 阅读全文

谈谈 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