一个纯正程序员的啰嗦
作为普通的开发人员，我们会遇到对于时间分配的思考，没有金标准，只有某些看起来也未必靠谱的 “最佳实践”。不同人眼中对于整体的时间分配也有自己的看法，这篇文章旨在探讨其中的一两种情况。
Ops 的事务类型
Ops 的事务很多很杂，首先要明确一点的就是，Ops 远不止 oncall，远不止线上产品维护。整个软件工程流程中的配置、部署、环境搭建、升级、打补丁，甚至问题定位、故障排查等等，都或多或少可以算作 Ops。
记得在读书的时候，老师给我们把日常事务划为四个象限：紧急重要、紧急不重要、不重要但紧急，以及不重要不紧急。Ops 和一般软件开发活动在这四个象限的分布上来比较，更多地，会偏重于 “紧急 [……]阅读全文
第二部分，我想谈一谈流程，依然来源于我的理解。Ops 的实践上面，有两部分内容紧密结合，不但共同显示了 Ops 的生产力，也在相当程度上体现了 Ops 的技术水平。这第一部分就是流程，也是今天要说的内容，另一部分是工具（也包括和使用工具相关的技能），下一次再说。
我认为 Ops 可以分为几个层次，最次的的一层，其特点是重度依赖于的人的直接 “操作”。风险管理、因果行为，都通过流程来统一把控，并且遗憾的是只有流程——除了它基本没有可靠有效的工具，或是其他办法。
其实，流程本是个好东西。有时候某些工程师被散漫和自由主义惯坏了，听到流程就反感。事实上，流程在很多情况下都有着举足轻重的作用。它们很容易控制[……]阅读全文
偶然地，在会看这些年写的文章的时候，发现涉及到软件工程方方面面的内容，但是关于 Ops 的内容却非常少。我觉得这是不太合适的，因为在实际工作中，Ops 显而易见地占据了一大块比重。于是我调整了分类目录，增加了这个单独的分类，并且这一次，我想零零散散地讲一讲我关于 Ops 的一些经历，以及关于 Ops 的一些观点。
所谓 Ops，指的就是 Operations，在中文翻译上看，我觉得 “运维” 这个词可能是最恰当的。作为一个软件工程师，Ops 有时会特指 DevOps，关于它的定义，在维基百科上有这样一张图片，我觉得基本正确地描述了 DevOps 涵盖的内容（见右侧图）。
可以看到三方面的内容，可是，由于我们会把 [……]阅读全文